This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Marius Cirsta mforce2 at gmail.comHarald , 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) > >