10 Nov 2010

Hey guys, a few quick questions relating to the ScmRTOS if you dont mind:

Once the process stack(s) gets filled up due to context switching, is there a mechanism in place to prevent additional context switches from occurring?

When in an ISR and ScmRTOS interprocess communications are used such as a channel for example, what happens if an attempt is made to push something into a channel and its full. usually the process that is attempting the pushing will go to sleep until the channel is available again but in the case of an ISR, this is not a process so what happens?




10 Nov 2010

Hi Greg

In answer to your first question, have a look in the documentation starting at page 29.

WIth regards to using interprocess communication within an ISR, you'd be wise not to call something that can block. I'd check if the channel had space before putting anything onto it, and then you need to make a decision whether to lose the new item, or pop something off the channel to make space. You have to bear in mind that if you are in this situation, you are not emptying the channel fast enough to keep up with your interrupts, so something has to give (and you might want to flag up a channel overflow).




10 Nov 2010

Thanks Daniel,

I did try looking in the manual before posting the question and it didnt stand out at me. Based on your suggestion I had another look and found this:


"Stack size estimation becomes a difficult task because every process may be
interrupted at any time and it is not known what ISR has interrupted current
process, so RAM requirements is not known as well and a user must define the
stack size for the worst case."

So this means that we must just be careful with stack usage?


With regard to my second question, I was checking for enough space before using the channel but was just curious as to what happens if a blocking situation would occur.



11 Nov 2010

Hi Greg

With regards to monitoring stack usage, the scmRTOS version here (as a library) has the UsedStackSize() method of a process implemented, so you can check how much stack each process needs.

From OS_Target.h, you can see that a separate return stack is not used (SEPARATE_RETURN_STACK 0), and also the context switch scheme is by software interrupt (scmRTOS_CONTEXT_SWITCH_SCHEME 1).

In terms of what happens if you block in an ISR, why not try it? I suspect that you'll crash the mbed with an overflow of unserviced interrupt requests (if they keep coming) since interrupt requests are queued up.