RFC: RTOS for Calypso

Marius Cirsta 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:
>
>> FreeRTOS
>>     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.
>
>> TNKernel
>> http://www.tnkernel.com/tn_description.html
>>     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.
>
>> eCos
>> http://ecos.sourceware.org/about.html
>>     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.
>
>> NUT/OS
>> http://www.ethernut.de/en/
>>     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
>> realtime...
>
> 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
>> excessive.
>
> ACK
>
>> 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
> provided.
>
>> 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.
>
> Regards,
>        Harald
> --
> - 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 mailing list