Hello, The current Zephyr Sensor API assumes that devices have a single channel of a particular type. Although this may be the most common case for most devices, it is not a rule (e.g. SI1153 can

Hi Paul, thanks for the very useful hints und links! /apps_structure.html#support-for-building-third-party-library-code I didn't know about these docs, thanks! This is something i really looked

Alright, I'll follow your advice then. I agree that, ultimately, Device Tree and Kconfig files should be completely separate anyway. Best regards, -- Geoffrey Le Gourriérec

Hello Richard, Richard Peters <mail@...> wrote: This mail crosses its way with one you sent me privately, about doing the same thing with MicroPython, so let me try to answer both

Hi Geoff, While it is probably a good idea to look for good research solutions we actually need to make sense what it does, and what doesn't make sense, for zephyr. Pretty much any layer that

Hi Community, I use these flags to link jerryscript against zephyr in my project makefile: ALL_LIBS += jerry-core export ALL_LIBS LDFLAGS_zephyr += "-L $(JERRYOUT)/lib" export LDFLAGS_zephyr 1.

On Nios II we currently just support the very simple IIC (Internal Interrupt Controller) and nested interrupts aren't possible. Andrew

Should be supported on architectures where the hardware has support for it. It is a feature of the kernel. ARM, ARC, x86 do support it. [ChuckJ] To clarify. On ARC, FIRQ can be nested on top of

While I don't personally have answers to these buffer-management questions, I am certain they are well-studied, because they are intermingled with lots of other well-studied questions and use-cases

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/11230 : RFC drivers/timer: Refined version of nRF RTC driver. - https://gerrit.zephyrproject.org/r/11233 : Bluetooth: SMP: Fix passkey

Hi, Should be supported on architectures where the hardware has support for it. It is a feature of the kernel. ARM, ARC, x86 do support it. Not entirely sure about Nios2 and

<jukka.rissanen@...> wrote: We do however still need to figure out, for udp, how to prevent: - rx path starving tx path to dead lock - multiple tx paths deadlocking (by attempting to

Hi Piotr, I agree that having too fine grained setup for the buffers is bad and should be avoided. The current setup of RX, TX and shared DATA buffers has worked for UDP quite well. For TCP the

Some pins have been pulled up and some have been pulled down. Not able to change it. It seems to be perpetually stuck in that mode. Also pin 8 (Zephyr pin 16) not functioning. Any suggestions?

hi all: i have reviewed the cortex-m arch about the interrupt flow, and found that cortex-m support max 255 interrupt entry and it allows interrupt with higher prio preempted another one with

Hi, So, what should be the final solution to the NBUF DATA issue? Do we want to redesign echo_server sample application to use shallow copy, should we introduce NBUF DATA pool per

Hi Geoffrey, Good question. I understand "SimpleLink" to describe a family of connectivity SoC's. But an SoC can include a heterogeneous mix of CPU core types: ARM cores (of different

Can you raise a JIRA issue and add some details of the failure you are seeing ? Thanks /Marcus

Hello, This patch https://gerrit.zephyrproject.org/r/#/c/11176/ is breaking some network applications (i.e. samples/net/mqtt_publisher). A local revert solves the issue for me. Regards, Flavio

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/11183 : sensor: fix typo in sensor.h - https://gerrit.zephyrproject.org/r/11166 : ext/lib/mbedtls: Add the TLS configuration file -