RFC: RTOS for Calypso

Harald Welte laforge at gnumonks.org
Mon Apr 18 23:03:34 UTC 2011

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.

> 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. 


> 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 mailing list