I am using a 9p-9215 with 8MB SDRAM. I know that ThreadX places no restrictions on the number of threads in an application, however there must be a reasonable number of threads to use. Obviously each thread will require it’s own stack which can limit the number. I currently have about 17 threads running (outside of the basic NET+OS stuff). I am in process of adding a feature that I can run multiple times (8-16). So I am considering whether a loop in a single thread (ugh) makes more sense than 8-16 more threads in the APP. Multiple threads are more elegant and easier to manage but I don’t want a resource squeeze. Just wondering if anyone has a “rule of thumb” they use?
Also, how can I determine stack usage on each thread? Is there a application note or white paper on this?
Thanks,
Adam
Well I found this in the ThreadX User Manual. Which basically answers my question with my question…
“The stack requirements for threads can be quite
large. Therefore, it is important to design the
application to have a reasonable number of threads.
Furthermore, some care must be taken to avoid
excessive stack usage within threads. Recursive
algorithms and large local data structures should
generally be avoided.”
I also found this regarding Stacks which should help…
" A favorite trick is to preset all stack areas
with an easily identifiable data pattern like (0xEFEF)
prior to creating the threads. After the application has
been thoroughly put through its paces, the stack
areas can be examined to see how much was
actually used by finding the area of the stack where
the preset pattern is still intact."
I have done this before just wondering if there was some tool built into ESP.
If anyone cares to chime in on this discussion with some words of wisdom and what is the meaning of “reasonable” would be welcome!
Thanks in advance.
Adam
Also, how can I determine stack usage on each thread? Is there a application note or white paper on this?
I allocate all my stacks through a call which notes the location and size. It appears to me that ThreadX automatically initialises the stack to 0xef when you create the associated thread. I then periodically run a routine which scans up from the bottom of the stack looking for the first byte that isn’t 0xef; this gives stack usage.
I’ve found this very effective - I only started doing this a few weeks ago, and its already identified one stack which was too small - something that could have taken ages to track down. ThreadX didn’t actually crash on stack overflow - I don’t know whether it has any specific protection, or whether I was just lucky.
Main point to remember is that most variables created within a function are assigned space on the stack; so large structures or recursive calls can eat stack. I have one task which only uses a few hundred bytes of stack; I have others which approach 10K. It all depends what you’re doing.
My inclination for your requirement would be to create multiple tasks (which is what I do in a similar situation). I have about 40 tasks in total running on a CC9P9215 no problem, and so far found the amount of available RAM to be more than adequate.