I'm using the RTX RTOS and I noticed that in the latest version there is a new feature which is a stack high water mark. I've been able to use this while debugging in the IDE but was wondering if there's a way to get this information from the RTOS so that I can monitor this in normal operation? Currently I have my own stack monitoring thread that uses the RTOS' task control block structure to manually calculate stack usage but if I could grab this high water mark data instead then my stack monitor thread could be slimmed down considerably. So, if anyone knows where within the RTOS this high water mark data resides or how to access it please let me know.
Thanks
Thanks! I wouldn't say that the stack overflow protection in the RTOS isn't enough for our software rather the maximum stack usage is just nice to have for our monitoring and logging scheme that we implement. Again this isn't essential it's just a nice to have feature and since the stack high water mark is new I just wondered if it would be available to use to speed up and simplify our current monitoring scheme.
Thanks, Doug
Remember that unless the hardware has special support for it, the only normal way to check how much stack a task consumes is to either - poll the stack pointer at a reasonably high frequency - to fill the stack with a magic pattern and scan how much of the pattern that has been overwritten - to instrument the generated code with special prologue/epilogue code that checks the consumed stack when calling/returning.
An OS can detect an overrun stack by placing magic values directly after the stack end and check if this pattern has been modified. But except for that, it can only sample the stack pointer at situations where it gets involved. So when a time slice is over, or when you call one of the OS functions. And if it hooks all interrupts, it could sample the usage even if there is no explicit OS call.
So the best in your case would, in my view, be either a high-priority interrupt sampling the stack usage. Or a low-priority background task that checks for amount of overwritten magic values. The low-priority route has the advantage that it mostly just affects the amount of power a bit - unless it gets totally starved so it never gets a chance to collect any information. The disadvantage with it is that it can only tell usage - but have no idea what code path that might represent the costlies call tree.