Thanks. Looks like we have everything in place then. Cheers, -- Maciek Borzecki

I have pushed it to gerrit: https://gerrit.zephyrproject.org/r/#/c/1142/ https://gerrit.zephyrproject.org/r/#/c/1143/

also look at include/misc/stack.h for Stack usage analysis helpers Anas

Can you point me to the patch? I can't see it in the original email in the thread (save my email doing funky stuff :) Thanks

That part is already in the kernel: CONFIG_INIT_STACKS fills the stacks with 0xaa when threads are initialized.

Hey Yannis,

<maciek.borzecki(a)gmail.com> wrote: Now that I've seen the patch it got me thinking. What if we added an opt-in debug code for fiber/tasks that helped to measure stack usage? This could be something

I briefly considered this approach but after doing some reading concluded it was unsafe. http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html Andrew

Hi, <giannis.damigos(a)gmail.com> wrote: You can post the patch and add me for review. From what I've seen, there's ~10 tests that fail under sanitycheck with SRAM overflow from hundreds of bytes, to

Could MQTT-SN work for you?

Hi all, a quick question regarding sanity check and test cases. I modified the test-fifo test case reducing the amount of memory statically allocated for fibers' stack. This permits the test_nano to

Thanks a lot for the reply If TCP support to the network stack is provided then Can I use the MQTT client library to make support for MQTT ? Can you please tell me when can I expect the TCP support

QA test suite actually has similar requirement for test case filtering by expression. We took a lightweight approach, directly use "python expression" instead of creating a new one. The benefit of

wrote: Yes, TCP is not supported right now. Yes, I am currently working on adding TCP support to the network stack. Cheers, Jukka

Hello everybody, I recently wanted to have a more fun with the k64 and wrote a little kernel module. I don't know, if it is needed for the real kernel and if the structure is right. But if anyone is

Hi Under Zephyr RTOS net/ip/net_core.c, Support for IPPROTO_UDP is available and Support for IPPROTO_TCP is mentioned as not yet supported Does it mean the Zephyr RTOS network stack has support only

Beside the issue above, the proposal looks good to me and will definitely improve and expand the coverage. Lets find a way to make this work without adding the parser into the tree

Yeah I'll take it out of the patch series. I've asked Juro to look into including it into the Zephyr SDK, which is where we typically put our dependent packages. If that doesn't work out we would just

Hi Anas, Any updates on the Cortex-M0 porting effort? Is there any public code (even WIP) to look at? Best Regards, -- Anderson Lizardo

I see nothing bad in the proposal. I would refrain from copying PLY into the source tree for the following reasons: - Support. Updating the library, which is not the part of the project may be a