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/.
l--putt ichgeh at l--putt.deHi! Is AreasOfWork in the wiki still up to date? I intend to work on the UI (Sorry Dieter, GSM testset too expensive at the moment :( ) and want to choose a RTOS. A small collection that I came across: FreeRTOS What is the problem? TNKernel http://www.tnkernel.com/tn_description.html Scheduler, Mutexes, Queues, etc. available strange (at least unfamiliar) API for memory eCos http://ecos.sourceware.org/about.html many target MCUs but are their any other than ARM in BB chipsets? powerful but complex (at least at first glance) 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... 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. In fact, I tried porting it to calypso just for fun. With some wrappers, Osmocom's platform files can be used. Only turns on the backlight and occasionally outputs some bytes on the UART at the moment. However, I still call this success. It took me just a day from knowing nothing about NUT/OS and very little about calypso and ARM to do this. Seems promising in terms of portability and documentation to me. 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 yes, is it reasonable to independently handle GSM stuff with FIQ and only give IRQ to whatever OS we choose? Regards, Stefan