RFC: RTOS for Calypso
squalyl at gmail.com
Tue Apr 19 12:11:45 CEST 2011
Do we really need an X11+Win32 GDI API implementation for such a small
On Tue, Apr 19, 2011 at 11:23 AM, Marius Cirsta <mforce2 at gmail.com> wrote:
> 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>
> > 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
> > our code will be messages that are placed in queues. This can be actual
> > gSM signalling messages (LAPDm frames), but also any kind of
> > 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
> > some more thought. In the end, it comes down to the application
> > i.e. you :)
> > I've just had a quick look and noted that they already have LUA
> > which is something we always thought of as a great idea. Executing LUA
> > 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
> > One of our main issues still is debug output, as printing stuff through
> > 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
> >> If yes, is it reasonable to independently handle GSM stuff with FIQ and
> >> 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>
> > "Privacy in residential applications is a desirable marketing option."
> > (ETSI EN 300 175-7 Ch.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the baseband-devel