Hi All, We're building a custom board with a no-standard power sequence. The processor and a TCA6418 GPIO expander come up first on a low-current 1V8 supply. The TCA6418 controls the enable pins for

hi i'm facing a problem when i building the external_lib sample > west build -b nrf52dk_nrf52832 [1/142] Performing build step for 'mylib_project' FAILED:

Reminder: Zephyr Project: Dev Meeting When: 09/09/2021 3:00pm to 4:00pm (UTC+00:00) UTC Where: Microsoft Teams Meeting Organizer: devel@... An RSVP is requested. Click here to

Hi, <katsuhiro@...> wrote: The reason why we set _current to the new thread is that we can't set it after we switch to the new thread. The newly switched thread will just start running

PINCTRL: - devicetree description (option 1 vs option 3) Option1 (grouping by device): NRF: https://gist.github.com/gmarull/e2afed5c97a188f3830ff0bd59d3d3ae NXP:

Can't you just check that flag in the context switch code?  It seems like that would be faster on average (most DSP workloads try very hard to avoid doing synchronous context switches to avoid the

Hello, Thanks for your advice. Current RISC-V implementation (CONFIG_USE_SWITCH=n) is using 'ecall' (this is SW interrupt instruction) to execute context switching explicitly. And jump into

Hello, Thank you for reply. Currently, No. I'm trying to add a support for CONFIG_USE_SWITCH=y case. Sorry for confusing. Older means CONFIG_USE_SWITCH=n. Does not means Zephyr's

Hi, <katsuhiro@...> wrote: Does RISC-V support USE_SWITCH? AFAICS, even with v1.11, we are setting `_current` to `new_thread` in `_Swap()` before calling `_arch_switch()`. What version are

Katsuhiro Suzuki wrote: > Newer switching sets NEW thread handle into _current_cpu.current > BEFORE calling arch_switch(). This implementation will face a > problem in RISC-V environment if thread

Hello kernel guys, I have question about newer version of context switching (CONFIG_USE_SWITCH=y). Newer switching sets NEW thread handle into _current_cpu.current BEFORE calling arch_switch(). This

Reminder: Zephyr Project: APIs When: 09/07/2021 4:00pm to 5:00pm (UTC+00:00) UTC Where: Microsoft Teams Meeting Organizer: devel@... An RSVP is requested. Click here to

Cancelled: Zephyr: Networking Forum This event has been cancelled. When: Tuesday, September 7, 2021 3:00pm to 4:00pm (UTC+00:00) UTC Where: Microsoft Teams Meeting Organizer:

Reminder: Zephyr: Networking Forum When: 09/07/2021 3:00pm to 4:00pm (UTC+00:00) UTC Where: Microsoft Teams Meeting Organizer: tsc@... An RSVP is requested. Click here to

Hi everyone I am currently trying to write a driver for an STMicroelectronics LIS3DHH accelerometer. I based my code on the existing LIS2DH code that is already integrated in Zephyr and tried to adapt

Hi all, Sorry for the late notice, the are no items in the agenda for Today’s networking forum – please let me know if there is any topic you want to discuss. Otherwise, I’ll cancel the

Hi, Dev. Team I am trying to get the LWM2M example working on the NRF5340dk. I got it working using QEMU. - I flashed the lwm2m example using "nrf5340dk_nrf5340_cpuapp". - I am not sure which network

Hi Roberto, As per the discussion in the Toolchain WG meeting today, I have created an issue about this: https://github.com/zephyrproject-rtos/sdk-ng/issues/395 Please comment on the linked issue if

Hi all, Agenda for tomorrow: - Bluetooth: Switch to inclusive naming terms - Issue: https://github.com/zephyrproject-rtos/zephyr/issues/38348 - Pinctrl: Side-by-side comparison of two (similar)

Zephyr: Toolchain Working Group When: 09/06/2021 3:00pm to 4:00pm (UTC+00:00) UTC Where: Microsoft Teams Meeting Organizer: Torsten Rasmussen Description: Live meeting minutes: