RFC: RTOS for Calypso
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:
>> 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
> 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
More information about the baseband-devel