RFC: RTOS for Calypso

Sébastien Lorquet squalyl at gmail.com
Tue Apr 19 10:11:45 UTC 2011


Hi,

Do we really need an X11+Win32 GDI API implementation for such a small
screen?

Sebastien

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>
> 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)
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110419/68d42936/attachment.html>


More information about the baseband-devel mailing list