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@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@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@gnumonks.org
============================================================================
"Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch.
A6)