RFC: RTOS for Calypso

l--putt ichgeh at l--putt.de
Mon Apr 18 12:32:34 UTC 2011


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

More information about the baseband-devel mailing list