18 Apr
2011
18 Apr
'11
2:32 p.m.
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:
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.
Well, that's about what I intended. Just don't have any experience with
realtime applications...
Hi,
My sentence is missing an "important". Anyway, seems to be a major
problem.
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 ...)
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.
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.
Cheers,
Sylvain