RFC: RTOS for Calypso

[l--putt]

Hi!

Maybe I should ask simpler:
1. Did anybody choose an OS or has found a decision regarding OS?
2. What experiences regarding timings and CPU idle time do you have?


In the meantime, I deduce from the lack of responses that there is no 
clear OS decision yet. I'll try a more serious porting attempt to find 
out if NUT/OS is OK.


On 17.04.2011 09:51, Sylvain Munaut wrote:
> Hi,
>
>>     many target MCUs but are their any other than ARM in BB chipsets?
>
> There are yes.
> But maybe not in any we intend to target ... All recent ones are ARM at least.
> (and the others we don't have nearly enough doc ...)
>
My sentence is missing an "important". Anyway, seems to be a major problem.

>>     cooperative multithreading: Is that OK? We still have IRQs for
>> realtime...
>
> Personally If we were to get an OS I would have loved to have 'tasks' and be
> able to assign priorities to them ... currently we do way too much in IRQs.
>

NUT/OS provides threads with priorities which should run most of the 
stack. Because of the RTC-IRQ comment, I was worried the IRq overhead of 
an OS might be too much for TDMA stuff.

> Those tasks aren't real time but it's important not to block them too much.
>
> Running them in IRQ isn't good because they block other stuff that
> really needs to be in IRQ (keyboard, serial, ...).
>

That's why I suggested FIQ: If the OS spends too much time in IRQ 
context, TDMA things are still handled because FIQ has higher priority.

>
>> Open question: How much overhead can we afford, i.e., how much spare time is
>> there on the CPU? Does "Disable RTC interrupt as it causes lost TDMA frames"
>> (layer1/init.c) indicate issues? (Yes, sorry, haven't read GSM specs yet...)
>> If yes, is it reasonable to independently handle GSM stuff with FIQ and only
>> give IRQ to whatever OS we choose?
>
> I think we should use the OS dispatching for everything (so don't add
> a layer 'above' the OS), _but_ indeed, the only FIQ we should have
> should be the L1 TDMA and nothing else. Any OS maintenance task or
> other stuff should be IRQ at most. And even then, it should be minimal
> (currently we do way to much stuff in IRQ context).
>
> Then for whatever 'task' we have running, the l3/l2/l1 async should be
> prioritized but ideally without using IRQ.
>
> This should be sufficient so as to not have problems.
>

Well, that's about what I intended. Just don't have any experience with 
realtime applications...

>
> Cheers,
>
>      Sylvain
>
>