19 Apr
2011
19 Apr
'11
12:11 p.m.
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(a)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(a)gnumonks.org>
wrote:
http://laforge.gnumonks.org/
============================================================================
On Sat, Apr 16, 2011 at 09:35:30PM +0200, l--putt
wrote:
in
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 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.
needs
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 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.
code.
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
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(a)gnumonks.org> "Privacy in residential applications is a
desirable marketing option."
(ETSI EN 300 175-7 Ch.
A6)