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/.
Sébastien Lorquet squalyl at gmail.comHi, 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.htm>