Draft: Zephyr support

[PhilippHaefele]

Add Zephyr support

First work in progress state:

For tests I'm currently using west build -p always -b nucleo_f429zi samples\basic\threads -DCONFIG_THREAD_MONITOR=y -DCONFIG_THREAD_NAME=y

west build -p always -b nucleo_f429zi samples\basic\threads -DCONFIG_DEBUG_THREAD_INFO=y should also work and get's the J-Link Plugin working too

Open points

• [ ] Inform user when CONFIG_THREAD_MONITOR is not set
• [ ] Check if stack_info.size is always in Bytes and not number of stack entries
• [ ] Add support for more arches and inform user when not supported (it's not always callee_saved.psp)
• [ ] Try to get information like real address and type of kernel objects (semaphore, mutex etc.) the tasks are pending on (we only have their _wait_q_t *pended_on right now) => when CONFIG_TRACING and CONFIG_TRACING_OBJECT_TRACKING are enabled, it seems that we have lists of all object types => see tracing_tracking.c for link list entry points

[haneefdm]

I was about to merge and then I saw your open points. If I merge this PR will be closed and we will lose the open points. Maybe we should create an issue that we can attack later. I know nothing of Zephyr so...

I am sorry for not attending to this extension. I now have a 4-day holiday and see if I can make some progress in publishing the extension.

[haneefdm]

@PhilippHaefele Could I email you? My email address is public on Github. We have some admin issues to take care of.

• I want to add you and other contributors as collaborators on Github
• I want each author of an RTOS to maintain and tend to issues of that view. Means, I need contributors to be owners
• I do want to have a test project for each RTOS that any of us can readily use.

I want to make these policies public on a CONTRIBUTIONS page or in general users as well. I don't have the bandwidth to handle every detail when I am not even aware of many of these RTOSes. It has to be a community effort.

Please contact me via email.

[haneefdm]

@PhilippHaefele Is there any value for launching a memory view for the stack address? What possible value is there? I did the Link type because I blindly copied MS Embedded Tools, but how does a user practically use it

[PhilippHaefele]

@PhilippHaefele Is there any value for launching a memory view for the stack address? What possible value is there? I did the Link type because I blindly copied MS Embedded Tools, but how does a user practically use it

You're right and i didn't thought about the usecase before. I can only think of a case where the stack end / size is not available and the user wants to have a look into the memory and have an educated guess on the current stack usage. Also it sometimes helps to see what maybe took a lot of stack space by having a look into the patters of the data in the stack.

So over all i do not really see a big need for that

[haneefdm]

I just release the extension. I had to do several things that involved code changes.

• Standardized formatting
• Updated to ES2022 because the linter was giving me too many issues
• Readme page now lists all the contributors.

I did not update Zyphyr source code as you till have a TODO list you are working on. @PhilippHaefele, you may want to merge and fix any issues that might come up.

@vrepetenko you may be affected as well. At some point, I think we should split up the 2nd column as it would look better and more compact with separate columns. May also take less space.

[haneefdm]

FYI: https://marketplace.visualstudio.com/items?itemName=mcu-debug.rtos-views