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 -

Hi, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'm not sure what this means... This code is valid. The scheduler lock is per-thread. If the thread goes to sleep, it relinquishes the CPU,

Hello Gil, I am starting to work on supporting Zephyr on Texas Instruments' "SensorTag" device. To this end, I need to add support for the CC2650 MCU. I looked at the support you added for the

hi all: i review the code of zephyr of riscv arch, with the aim that to porting this to the mips arch because the reiscv is the most like the mips, when i read the function" __irq_wrapper" , and

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/11163 : Revert tests: disable qemu_riscv32 on test_ecc_dh test [REVERT ME] - https://gerrit.zephyrproject.org/r/11162 : tinycrypt:

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/11101 : samples/net/http: Add HTTP over TLS sample application - https://gerrit.zephyrproject.org/r/11114 : arc: add _tsc_read -

Actually, I'm leaning toward the opinion that the names of the I/O shouldn't matter. But what does matter, are the properties associated with that object. Take GPIO, for example. Some GPIO

<paul.sokolovsky@...> wrote: SoC uart mappings are one thing. Board uart mappings are another. SoC uart mappings are merely assigning an index to a base address and then generating the label

"Jon Medhurst (Tixy)" <tixy@...> wrote: Nope, I really appreciate different people approaching this from different sides, and considering the usecases and details they have in mind. Well, I

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/11062 : arm: enable direct interrupts feature - https://gerrit.zephyrproject.org/r/11087 : Merge net branch into master -

Yes, I agree with that. That's why I original asked about which 'name' aliases in DT we're being used for, a) the name you pass to device_get_binding, or b) the name used in C macro name inside

"Jon Medhurst (Tixy)" <tixy@...> wrote: I understand this discusses details of DT bindings and processing, but for my own and other folks' understanding, I'd like to point that for a device

Hello Andy,

Hello Daniel, Daniel Thompson <daniel.thompson@...> wrote: To clarify, the concern behind my original mail is exactly regarding having a good consistent scheme for "SoC-wide defaults". Across

Hello Maureen,