I got the EventRecorder to work at last, but in the component tab it doesn't show the name of the threads. They are all called "RTX Thread". I already entered a name in the osThreadAttr_t, but it is not visible during debugging. I can also see the thread_id in HEX format, but I would have to know those by heart which is not practical.
Adam Lins said:I do think that the event recorder can be overwhelmed and miss events. Use the filtering options in the EventRecorder view and in the RTC_Config.h file to reduce the number of events and the missing threads should re-appear.
I have already reduced the events to a minimum. I guess I have to live with it then. It might also be caused by the ULINK ME2. I think it is not the fastest JTAG.
Adam Lins said:As for multiple threads running on the same core -- there could be a few different causes for that apparent behavior. I would guess that your code is relying on the kernel preempting threads, because I don't see a lot of 'blocked' threads.
I am not that experienced with the multithreading design options yet. This design was also not made by me.
From what I have seen it works like this:Threads are created with the same priorities and after the execution of each thread an osThreadYield is called. Is this an okay solution? From what I understand the threads should be managed by the kernel and not manually. There are also a lot of problems with the design. TCP threads are running when nothing happens. A lot of computing time seems wasted. A lot of host buffer overflows are shown in the EventRecorder. The operation seems a bit sluggish at times. I probably need to optimize it properly.
I am just curious how it is even possible that multiple threads are running concurrently on a single-core processor.
Concurrent execution of threads is not the same as concurrent execution of instructions from different threads. System Analyzer says multiple threads are in the RUNNING state. That doesn't mean the instructions for the code in each thread are executing concurrently at the timescale of the CPU clock.
System Analyzer gets its data from the EventRecorder, so everything being in the RUNNING state could just be an artifact of data logging falling behind (as you noted). You can trim back RTOS events to the critical ones you need to get debugging done, which might just be a few custom events.
The IDE will use bandwidth on the debugger link to maintain System Views, watched variables, memory, etc. Turn off any of those you don't need to maximize the bandwidth for EventRecorder.
Instead of osThreadYield() I prefer to wait for signals sent to the thread (which can be set in an ISR) and/or timers. That means most of the time is spent in the RTOS idle thread. On the other hand, use of osThreadYield() could be appropriate for your design. Unless things aren't working as desired.
I had to revert back to an old code and I made the same changes to see events. Now the System Analyzer never shows thread, although the Event Recorder is active and working...
Adam Lins said:Concurrent execution of threads is not the same as concurrent execution of instructions from different threads. System Analyzer says multiple threads are in the RUNNING state. That doesn't mean the instructions for the code in each thread are executing concurrently at the timescale of the CPU clock.
It makes sense that not every instruction is visible in the Event Recorder or System Analyzer.
Adam Lins said:Instead of osThreadYield() I prefer to wait for signals sent to the thread (which can be set in an ISR) and/or timers. That means most of the time is spent in the RTOS idle thread. On the other hand, use of osThreadYield() could be appropriate for your design. Unless things aren't working as desired.
This is a good tip. I will try to maximize the performance after everything has been implemented.
Thank you for your extended explanations and your time. It has been really helpful!