RFC: RTOS for Calypso
mforce2 at gmail.com
Tue Apr 19 09:23:21 UTC 2011
Harald , just out of curiosity , what's you opinion regarding RTEMS ?
At first glance it seems pretty good, and already has a GUI
implementation ( nano-X based ) .
On Mon, Apr 18, 2011 at 5:03 PM, Harald Welte <laforge at gnumonks.org> wrote:
> On Sat, Apr 16, 2011 at 09:35:30PM +0200, l--putt wrote:
>> What is the problem?
> To be honest, just looking at the source code makes me want to run
> away. Several other people in the vicinity of the project have the
> same feeling. Also, I find their Makefiles/build system hard to
> underestand, and there seems to be no clean separation between OS
> and application - or maybe I was not trying hard enough to find out
> and/or understand.
>> Scheduler, Mutexes, Queues, etc. available
>> strange (at least unfamiliar) API for memory
> Actually this looks quite interesting. Yes, it seems like it has
> little activity and at least the manual was last modified in 2006,
> but it has all the core elements we need.
> The queues also look interesting. In the end, a lot of what is happening in
> our code will be messages that are placed in queues. This can be actual
> gSM signalling messages (LAPDm frames), but also any kind of events/primitives
> that we have between various subsystems. Having proper infrastrucutre in
> this area is definitely useful - if whatever OS we choose doesn't have
> it, we will likely have to write our own queue code.
>> many target MCUs but are their any other than ARM in BB chipsets?
> there are non-ARM baseband chips, especially older Infineon/Siemens. But
> I think there is absolutely no point in looking beyond ARM for the scope
> of OsmocomBB
>> powerful but complex (at least at first glance)
> doesn't sound like what I'd be looking for.
>> minimalistic RTOS, easy to port
>> seems to have sound community
>> familiar APIs: malloc, fopen's devices, ...
>> cooperative multithreading: Is that OK? We still have IRQs for
> I'm not entirely sure if cooperative multithreading is sufficient. This needs
> some more thought. In the end, it comes down to the application developers,
> i.e. you :)
> I've just had a quick look and noted that they already have LUA integration,
> which is something we always thought of as a great idea. Executing LUA scripts
> on the phone itself would make it highly customizable - without touching the C
> source code and recompiling all the time.
>> Since we seem to barely need an OS, a full-blown OS like eCos seems
>> For compatibility with MT6235 user space, malloc and
>> fopen is the right direction. Hence, my favourite is NUT/OS.
> I tend to agree with your preferences based on the selection you have
>> 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 there still are such issues, they are mostly due to badly written code.
> One of our main issues still is debug output, as printing stuff through the
> UART is terribly slow and time-consuming. A proper thread taking care of
> this might make things better. Also, we should start using DMA, if we can.
>> If yes, is it reasonable to independently handle GSM stuff with FIQ and only
>> give IRQ to whatever OS we choose?
> The GSM L1 should remain a FIQ, all other IRQ handlers should be short,
> the remainder handled in OS/user context.
> - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch. A6)
More information about the baseband-devel