Discussion:
RFC: RTOS for Calypso
(too old to reply)
l--putt
2011-04-16 19:35:30 UTC
Permalink
Hi!

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
Sylvain Munaut
2011-04-17 07:51:37 UTC
Permalink
Hi,
   many target MCUs but are their any other than ARM in BB chipsets?
There are yes.
But maybe not in any we intend to target ... All recent ones are ARM at least.
(and the others we don't have nearly enough doc ...)
   cooperative multithreading: Is that OK? We still have IRQs for
realtime...
Personally If we were to get an OS I would have loved to have 'tasks' and be
able to assign priorities to them ... currently we do way too much in IRQs.

Those tasks aren't real time but it's important not to block them too much.

Running them in IRQ isn't good because they block other stuff that
really needs to be in IRQ (keyboard, serial, ...).
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?
I think we should use the OS dispatching for everything (so don't add
a layer 'above' the OS), _but_ indeed, the only FIQ we should have
should be the L1 TDMA and nothing else. Any OS maintenance task or
other stuff should be IRQ at most. And even then, it should be minimal
(currently we do way to much stuff in IRQ context).

Then for whatever 'task' we have running, the l3/l2/l1 async should be
prioritized but ideally without using IRQ.

This should be sufficient so as to not have problems.


Cheers,

Sylvain
l--putt
2011-04-18 12:32:34 UTC
Permalink
Hi!

Maybe I should ask simpler:
1. Did anybody choose an OS or has found a decision regarding OS?
2. What experiences regarding timings and CPU idle time do you have?


In the meantime, I deduce from the lack of responses that there is no
clear OS decision yet. I'll try a more serious porting attempt to find
out if NUT/OS is OK.
Post by Sylvain Munaut
Hi,
Post by l--putt
many target MCUs but are their any other than ARM in BB chipsets?
There are yes.
But maybe not in any we intend to target ... All recent ones are ARM at least.
(and the others we don't have nearly enough doc ...)
My sentence is missing an "important". Anyway, seems to be a major problem.
Post by Sylvain Munaut
Post by l--putt
cooperative multithreading: Is that OK? We still have IRQs for
realtime...
Personally If we were to get an OS I would have loved to have 'tasks' and be
able to assign priorities to them ... currently we do way too much in IRQs.
NUT/OS provides threads with priorities which should run most of the
stack. Because of the RTC-IRQ comment, I was worried the IRq overhead of
an OS might be too much for TDMA stuff.
Post by Sylvain Munaut
Those tasks aren't real time but it's important not to block them too much.
Running them in IRQ isn't good because they block other stuff that
really needs to be in IRQ (keyboard, serial, ...).
That's why I suggested FIQ: If the OS spends too much time in IRQ
context, TDMA things are still handled because FIQ has higher priority.
Post by Sylvain Munaut
Post by l--putt
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?
I think we should use the OS dispatching for everything (so don't add
a layer 'above' the OS), _but_ indeed, the only FIQ we should have
should be the L1 TDMA and nothing else. Any OS maintenance task or
other stuff should be IRQ at most. And even then, it should be minimal
(currently we do way to much stuff in IRQ context).
Then for whatever 'task' we have running, the l3/l2/l1 async should be
prioritized but ideally without using IRQ.
This should be sufficient so as to not have problems.
Well, that's about what I intended. Just don't have any experience with
realtime applications...
Post by Sylvain Munaut
Cheers,
Sylvain
Wolfram Sang
2011-04-18 15:16:13 UTC
Permalink
Post by l--putt
1. Did anybody choose an OS or has found a decision regarding OS?
2. What experiences regarding timings and CPU idle time do you have?
I can't find the mail right now, but I remember Harald stated that, when
it is time, he wanted to choose the OS himself to be sure all needs are
met. Maybe the wiki could be updated in that regard as the question pops
up every once in a while?

Regards,

Wolfram
Marius Cirsta
2011-04-18 18:51:33 UTC
Permalink
I've read some pretty nice things about RTEMS and aa plus is seems to
have Nano-x ported to it and running nicely. This way there's a good
starting point for the GUI. It also seems to be pretty much POSIX
compatible.
I'm not sure about the more advanced features needed here as I'm not
an expert but it certainly looks interesting to me. Also judging by
where it is used ( aeronautics and other critical areas ) it seems to
be pretty solid.
Post by Wolfram Sang
Post by l--putt
1. Did anybody choose an OS or has found a decision regarding OS?
2. What experiences regarding timings and CPU idle time do you have?
I can't find the mail right now, but I remember Harald stated that, when
it is time, he wanted to choose the OS himself to be sure all needs are
met. Maybe the wiki could be updated in that regard as the question pops
up every once in a while?
Regards,
  Wolfram
Harald Welte
2011-04-18 22:24:05 UTC
Permalink
Post by Wolfram Sang
Post by l--putt
1. Did anybody choose an OS or has found a decision regarding OS?
2. What experiences regarding timings and CPU idle time do you have?
I can't find the mail right now, but I remember Harald stated that, when
it is time, he wanted to choose the OS himself to be sure all needs are
met. Maybe the wiki could be updated in that regard as the question pops
up every once in a while?
I have never found the time to actually make that decision/selection,
so there is no status update.

I'd still like to have a say in the decision, but I'm welcome for the
discussion that has started right now and definitely like to look at
the proposals (like ethernut OS)
--
- Harald Welte <***@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Alan Carvalho de Assis
2011-04-19 14:59:34 UTC
Permalink
Hi Harald,
Post by Harald Welte
I have never found the time to actually make that decision/selection,
so there is no status update.
I'd still like to have a say in the decision, but I'm welcome for the
discussion that has started right now and definitely like to look at
the proposals (like ethernut OS)
I think we could consider NuttX as well:

http://nuttx.sourceforge.net

This RTOS implements POSIX APIs and have many features "inherited" from Linux.
It is completely reconfigurable to fit small foot-print microcontrollers.

Just my 2 cents, I hope someone enjoy it.

Best Regards,

Alan
Marius Cirsta
2011-04-19 18:00:21 UTC
Permalink
On Tue, Apr 19, 2011 at 5:59 PM, Alan Carvalho de Assis
Post by Alan Carvalho de Assis
Hi Harald,
Post by Harald Welte
I have never found the time to actually make that decision/selection,
so there is no status update.
I'd still like to have a say in the decision, but I'm welcome for the
discussion that has started right now and definitely like to look at
the proposals (like ethernut OS)
http://nuttx.sourceforge.net
This RTOS implements POSIX APIs and have many features "inherited" from Linux.
It is completely reconfigurable to fit small foot-print microcontrollers.
Just my 2 cents, I hope someone enjoy it.
Best Regards,
Alan
Marius Cirsta
2011-04-19 18:01:28 UTC
Permalink
Sorry about that , darn gmail.....

Yes , nuttx seems pretty OK and it's author is very nice , a man to
work with. The problem would be that it's written by just one man and
I don't even know how it's doing on the GUI side.
Nuttx though seems more oriented towards micro controllers and and
targets with less resources.

As for nano-x it's one of the lightest GUIs around and I don't know if
there really are any better options for embedded open source graphics.
It's not really an X11 , not a full one anyway. And from what I've
heard you can get it to about 100 K which is certainly something in my
opinion.
 Yes , nuttx seems pretty OK and it's author is very nice , a man to
work with. The problem would be that it's written by just one man and
I don't even know how it's doing on the GUI side.
 Nuttx though seems more oriented towards micro controllers and and
targets with less resources.
As for nano-x it's one of the lightest GUIs around and I don't know if
there really are any better options for embedded open source graphics.
It's not really an X11 , not a full one anyway. And from what I've
heard you can get it to about 100 K which is certainly something in my
opinion.
On Tue, Apr 19, 2011 at 5:59 PM, Alan Carvalho de Assis
Post by Alan Carvalho de Assis
Hi Harald,
Post by Harald Welte
I have never found the time to actually make that decision/selection,
so there is no status update.
I'd still like to have a say in the decision, but I'm welcome for the
discussion that has started right now and definitely like to look at
the proposals (like ethernut OS)
http://nuttx.sourceforge.net
This RTOS implements POSIX APIs and have many features "inherited" from Linux.
It is completely reconfigurable to fit small foot-print microcontrollers.
Just my 2 cents, I hope someone enjoy it.
Best Regards,
Alan
Drasko DRASKOVIC
2011-04-19 22:23:55 UTC
Permalink
On Tue, Apr 19, 2011 at 4:59 PM, Alan Carvalho de Assis
Post by Alan Carvalho de Assis
http://nuttx.sourceforge.net
This RTOS implements POSIX APIs and have many features "inherited" from Linux.
It is completely reconfigurable to fit small foot-print microcontrollers.
Hi Alan,
I agree on this one also. I took a look at this OS some time ago,
seems like really well done code.

It would be my first choice after the eCos.

BR,
Drasko
Harald Welte
2011-04-20 07:13:49 UTC
Permalink
Post by Drasko DRASKOVIC
On Tue, Apr 19, 2011 at 4:59 PM, Alan Carvalho de Assis
Post by Alan Carvalho de Assis
http://nuttx.sourceforge.net
This RTOS implements POSIX APIs and have many features "inherited" from Linux.
It is completely reconfigurable to fit small foot-print microcontrollers.
Hi Alan,
I agree on this one also. I took a look at this OS some time ago,
seems like really well done code.
nuttx seems quite interesting, I'm reviewing the source code at the moment.
--
- Harald Welte <***@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Nordin
2011-04-20 08:35:15 UTC
Permalink
If you're looking for a suitable RTOS, I advise you to also give a
look at freertos.org. It already runs on a lot of microcontrollers with
different architectures. It's worth looking at.
Post by Harald Welte
Post by Drasko DRASKOVIC
On Tue, Apr 19, 2011 at 4:59 PM, Alan Carvalho de Assis
Post by Alan Carvalho de Assis
http://nuttx.sourceforge.net
This RTOS implements POSIX APIs and have many features "inherited" from Linux.
It is completely reconfigurable to fit small foot-print microcontrollers.
Hi Alan,
I agree on this one also. I took a look at this OS some time ago,
seems like really well done code.
nuttx seems quite interesting, I'm reviewing the source code at the moment.
Scott Weisman
2011-04-20 09:14:28 UTC
Permalink
Hey everyone.

As a sort of side interest of mine, I have collected links to a number of
open source RTOSs (nothing like ROUSs, or so I've heard). NutOS and TNKernel
are two I've never heard of. Thanks for the info on them.

Here are other RTOSs that I know about:

http://code.google.com/p/rt-thread/
http://www.bertos.org/
http://www.chibios.org/dokuwiki/doku.php
http://en.wikipedia.org/wiki/Contiki
http://www.tinyos.net/
http://l4hq.org/ (not sure about this)

Technically, eLua probably also qualifies. It already has support for
similar hardware too. I kind of like this idea personally.

The Lua integration in NutOS is interesting for the same reason eLua is.

I have used Lua a bit in customizing the editor I use (TextAdept). While
there are things I don't like about it, it's got some very expressive and
powerful features too.

I haven't looked deeply into any of the above, but none of them seemed too
compelling to me (except for eLua).

Regarding some of the comments on a GUI layer, that is something I did
follow with a little interest a LONG time ago (mid to late 1990s). There
really doesn't seem to be much that is open and designed for hardware like
this.

This is one I remember, when it was actually active:

http://www.picogui.org/

Scott
Post by Alan Carvalho de Assis
Post by Drasko DRASKOVIC
On Tue, Apr 19, 2011 at 4:59 PM, Alan Carvalho de Assis
Post by Alan Carvalho de Assis
http://nuttx.sourceforge.net
This RTOS implements POSIX APIs and have many features "inherited" from
Linux.
Post by Drasko DRASKOVIC
Post by Alan Carvalho de Assis
It is completely reconfigurable to fit small foot-print
microcontrollers.
Post by Drasko DRASKOVIC
Hi Alan,
I agree on this one also. I took a look at this OS some time ago,
seems like really well done code.
nuttx seems quite interesting, I'm reviewing the source code at the moment.
--
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Alan Carvalho de Assis
2011-04-20 14:18:15 UTC
Permalink
Post by Harald Welte
Post by Drasko DRASKOVIC
On Tue, Apr 19, 2011 at 4:59 PM, Alan Carvalho de Assis
Post by Alan Carvalho de Assis
http://nuttx.sourceforge.net
This RTOS implements POSIX APIs and have many features "inherited" from Linux.
It is completely reconfigurable to fit small foot-print
microcontrollers.
Hi Alan,
I agree on this one also. I took a look at this OS some time ago,
seems like really well done code.
nuttx seems quite interesting, I'm reviewing the source code at the moment.
Hi Harald,

I think nuttx is a nice option for developer with Linux background.

Unfortunately few people know this great RTOS exist. Using nuttx on
OsmocomBB certainly will let more people discover about it (a good
side effect).

NuttX is a Linux for microcontroller which uClinux cannot fit in.

Best Regards,

Alan
Harald Welte
2011-04-18 23:03:34 UTC
Permalink
Post by l--putt
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.
Post by l--putt
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.
Post by l--putt
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
Post by l--putt
powerful but complex (at least at first glance)
doesn't sound like what I'd be looking for.
Post by l--putt
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.
Post by l--putt
Since we seem to barely need an OS, a full-blown OS like eCos seems
excessive.
ACK
Post by l--putt
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.
Post by l--putt
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.
Post by l--putt
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 <***@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Marius Cirsta
2011-04-19 09:23:21 UTC
Permalink
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 ) .
Post by Harald Welte
Post by l--putt
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.
Post by l--putt
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.
Post by l--putt
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
Post by l--putt
    powerful but complex (at least at first glance)
doesn't sound like what I'd be looking for.
Post by l--putt
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.
Post by l--putt
Since we seem to barely need an OS, a full-blown OS like eCos seems
excessive.
ACK
Post by l--putt
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.
Post by l--putt
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.
Post by l--putt
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
--
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                 (ETSI EN 300 175-7 Ch. A6)
Sébastien Lorquet
2011-04-19 10:11:45 UTC
Permalink
Hi,

Do we really need an X11+Win32 GDI API implementation for such a small
screen?

Sebastien
Post by Marius Cirsta
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 ) .
Post by Harald Welte
Post by l--putt
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.
Post by l--putt
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
Post by Harald Welte
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
Post by Harald Welte
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.
Post by l--putt
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
Post by l--putt
powerful but complex (at least at first glance)
doesn't sound like what I'd be looking for.
Post by l--putt
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
Post by Harald Welte
some more thought. In the end, it comes down to the application
developers,
Post by Harald Welte
i.e. you :)
I've just had a quick look and noted that they already have LUA
integration,
Post by Harald Welte
which is something we always thought of as a great idea. Executing LUA
scripts
Post by Harald Welte
on the phone itself would make it highly customizable - without touching
the C
Post by Harald Welte
source code and recompiling all the time.
Post by l--putt
Since we seem to barely need an OS, a full-blown OS like eCos seems
excessive.
ACK
Post by l--putt
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.
Post by l--putt
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.
Post by Harald Welte
One of our main issues still is debug output, as printing stuff through
the
Post by Harald Welte
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.
Post by Harald Welte
Post by l--putt
If yes, is it reasonable to independently handle GSM stuff with FIQ and
only
Post by Harald Welte
Post by l--putt
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
--
http://laforge.gnumonks.org/
============================================================================
Post by Harald Welte
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch.
A6)
Drasko DRASKOVIC
2011-04-19 22:12:44 UTC
Permalink
Post by l--putt
FreeRTOS
   What is the problem?
Too Windows oriented for my taste. Documentation is full of build on
Cygwin and friends. Don't like.
Post by l--putt
TNKernel
http://www.tnkernel.com/tn_description.html
   Scheduler, Mutexes, Queues, etc. available
   strange (at least unfamiliar) API for memory
Dunno, I have absolutely no experience with this system. What is this
: http://www.tnkernel.com/ydt.html ? I want OpenOCD, not this.
Post by l--putt
eCos
http://ecos.sourceware.org/about.html
   many target MCUs but are their any other than ARM in BB chipsets?
Best candidate by all means. Many developers, real industry-grade
stuff and fun to work with.
Post by l--putt
   powerful but complex (at least at first glance)
Are you sure : http://opensource.zylin.com/smallecos.html ?

It is totally configurable, you can make it complex as you want.
Experience that can serve every developer on this list, including the
community around eCos. Can be used for future projects and more
serious phones (we have LTE coming, after all ;)).
Post by l--putt
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...
Not sure about dev community gathered around the project ?

My $0.2.

BR,
Drasko
Harald Welte
2011-05-14 16:46:37 UTC
Permalink
Hi all,

I'd like to re-vitalize the RTOS discussions.

I've now spend some hours reviewing the Nuttx documentation, source
code, change logs and other information, and I'm impressed!
Wolfram Sang
2011-05-15 20:17:28 UTC
Permalink
As for where to put the code: I already have a git-svn clone of Nuttx,
and will push that to a soon-to-be-created nuttx.git repository on
git.osmocom.org. The core calypso support (irq, uart, spi, etc.) should
all go in that tree. Meanwhile we will figure out how it would be
possibel to keep the gsm related 'application' code out-of-tree from
the nuttx code base.
Nuttx is BSD, osmocom code is GPL. So, shall osmocom code for Nuttx be
relicensed and only the application-repro contain GPL-code (probably no
problem for drivers, but what about l1-code)? Or are we keeping GPL and
keep in sync with upstream on our own (merging could get quite ugly if
that diverges too much)?

Regards,

Wolfram
Sylvain Munaut
2011-05-15 20:29:03 UTC
Permalink
Post by Wolfram Sang
Nuttx is BSD, osmocom code is GPL. So, shall osmocom code for Nuttx be
relicensed and only the application-repro contain GPL-code (probably no
problem for drivers, but what about l1-code)? Or are we keeping GPL and keep
in sync with upstream on our own (merging could get quite ugly if that
diverges too much)?
I'd keep GPL for everything except custom modification of nuttx code
(if even required).

There is no problem to have mixed BSD and GPL code in the same
repository as long as the header of each file has clear mention.
All our drivers (even for board / platforms / ...) will be new files
and all of L1 as well.

Keeping in sync with upstream shouldn't be that hard if done
periodically. I also assume they don't rewrite their whole API every
month ...

Cheers,

Sylvain
Harald Welte
2011-05-16 05:19:13 UTC
Permalink
Hi Wolfram,
Post by Wolfram Sang
Nuttx is BSD, osmocom code is GPL. So, shall osmocom code for Nuttx
be relicensed and only the application-repro contain GPL-code
I think all the calypso driver code to get the Soc supported in NuttX
(spi/lcd/i2c/uart/flash/sercomm/...) should eventually go Nuttx upstream
and I have no problem re-licensing that under the BSD-style license.
Post by Wolfram Sang
(probably no problem for drivers, but what about l1-code)? Or are we
keeping GPL and keep in sync with upstream on our own (merging could
get quite ugly if that diverges too much)?
I think the L1 would be two parts: the synchronous part in the FIQ,
and one 'userspace' task (might have multiple threads) for everything
else.

Both should be fine as GPL, and I don't expect major headaches with
keeping it in sync. The FIQ handler is completely independent from the
RTOS and pre-empts it anywhere. If Nuttx right now is blocking FIQs, we
should propose to change that in upstream, but still keep the L1S in our
tree.

Regards,
Harald
--
- Harald Welte <***@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Scott Weisman
2011-05-16 16:27:20 UTC
Permalink
I mentioned RT-Thread in the last email I sent to this thread. I don't know
if anyone looked into it, but it has some intriguing features that I think
are also worthy of consideration. It looks to be actively developed and is
licensed under the Apache Licence 2.0. Here's a summary from their site (
http://code.google.com/p/rt-thread/).

The GUI mentioned below is nothing to write home about, but it has TTF
support, among other things. That particular feature might seem heavy, but
it is nice to know it's available.

Scott

RT-Thread Kernel
Object oriented real-time core (while remaining the elegant and flexible
style of C Programming Language);
32 or 256 priority scheduling multi-thread scheduling; Using the round-robin
policy ensures that all threads having the same priority level will be
scheduled equally;
Synchronization of threads: semaphore and mutual exclusion semaphore (mutex)
to prevent priority inversion;
Complete and efficient support for communication between threads, including
mailbox, message queues, event flag;
Static memory management supports thread suspend/resume when it
allocates/frees a memory block and thread-safe dynamic heap management;
A device driver framework to provide standard interface to high level
application;

FinSH shell
Command line that accepts C-like expression;
Access system core functions directly via command line like C Programming
Language grammar;
Access system global variables directly via command line like C Programming
Language grammar;
Command history records and automatic complete for the Command Prompt;

Device File System
Virtual File System optimised for small device
POSIX style API;
Support the different implementation of file systems
Wrapper for ELM Chan's FatFs filesystem.

LwIP, a lightweight TCP/IP protocol stack
Standard BSD Socket interface;
IP, ICMP, UDP, TCP supported
DNS, DHCP, PPP supported
TFTP-HTTP-FTP supported (refer to the netutil component)

RT-Thread/GUI
Integrated with RT-Thread;
Multi-Thread supported;
Multi-Window supported;
Rich Widgets such as: label, button, checkbox, radiobox, etc.
Client/Server Architecture;
Client: Workbench/View/Window Architecture;
Chinese GB2312 display.

RT-Thread Branches 0.3.x
STM32
LM3S
ATMEL 7X256
LPC2478
x86

RT-Thread Branches 0.4.x
mini2440
AVR32
Renesas M16C
Cortex-M0 (NXP lpc1114)

RT-Thread 0.4.x branches has been starting in Google SVN trunk. It will
include more microcontrollers porting and involve following features:

Enhanced features on RT-Thread/GUI, include framebuffer optimized, input
method, TrueType font, Alpha Blend etc.
Application Module.
Other features.
Peter Stuge
2011-05-16 16:33:51 UTC
Permalink
TTF support
See also http://nothings.org/stb/stb_truetype.h

Some fonts are rendered really beautifully, others not so much,
others still not at all. It doesn't do bells and whistles kerning
but hey, it's a 67kb public domain TTF renderer!


//Peter
Drasko DRASKOVIC
2011-05-16 09:14:06 UTC
Permalink
Post by Harald Welte
Hi all,
I'd like to re-vitalize the RTOS discussions.
I've now spend some hours reviewing the Nuttx documentation, source
code, change logs and other information, and I'm impressed!
l--putt
2011-05-16 11:08:51 UTC
Permalink
Post by Harald Welte
Hi all,
I'd like to re-vitalize the RTOS discussions.
I've now spend some hours reviewing the Nuttx documentation, source
code, change logs and other information, and I'm impressed!
I would argue that this might be the biggest drawback of Nuttx.
Documentation and source comments are quite coarse. This might be fine
if you have basically a single developer who knows the stuff by heart.

I don't like to rely on guesses for the parameters of RTOS calls. For
example, "context" of irq_dispatch seems to be the saved user space
context. It also seems to be ignored anyway but who knows!?

Doxygen documentation of NutOS etc. at the other extreme might be
excessive. Thus, maybe not a major problem.
Alan Carvalho de Assis
2011-05-16 12:23:25 UTC
Permalink
FYI

---------- Forwarded message ----------
From: Gregory Nutt <***@yahoo.com>
Date: Sun, 15 May 2011 07:52:18 -0700 (PDT)
Subject: Re: Fwd: RFC: RTOS for Calypso
To: Alan Carvalho de Assis <***@gmail.com>

Hi Alan,

I also notice that they are using a TI dual core, ARM7TDMI and C5 DSP.
I already have support for a TI chip like that (the C5471) and also
for an ARM9 with C5 DSP (DM320).

See http://focus.ti.com.cn/cn/lit/ml/sprt239/sprt239.pdf

I have a c5 DSP bridge driver somewhere around on my backup disks as
well. I never released it into NuttX because there was never any
need. Perhaps that could be useful now.

Somewhere I also have tools that will convert the TI proprietary
object files and logic to manage loading different programs into the
DSP. The bridge also supports communication channels to communicate
with the DSP.

Greg
2***@gmail.com
2011-05-14 20:41:59 UTC
Permalink
Hi,
So unless anyone raises major objections, I think we should move ahead
with Nuttx. Who is interested in working on the calypso port?
I'd definitely like to be involved in that, especially for the GSM specific
part and
L1 integration and possibly trying to define more abstract interface for it
(so that we can switch from calypso to MTK. The current common code makes
calls from common code to calypso specific stuff directly).

I'm off until next week but after that I'll definitely look into it.

Some things from the top of my head that needs to be taken care of from the
get go (to be on solid ground):

- Platform (mtk / calypso / qemu?) and board support. Possibly even variant
(US / EU versions)
- Configuration options (TX enable / debug mode / ... )
- For each type of device (spi / i2c / keyboard / ...), define a
clear 'Driver API' that each specific driver
- As you said, memory allocator :)

(note that some/many of those may be taken care of by nuttx itself)
Meanwhile we will figure out how it would be
possibel to keep the gsm related 'application' code out-of-tree from
the nuttx code base.
Any idea how to do that yet ?

Essentially the GSM part is three things :

- A collection of drivers for the hw part
- A FIQ handler (the only one)
- A background task that communicates with serial. (altough currently it's
all handled in IRQ and that's bad)

I'm kind of in favor of progressively recopying all the code we have in a
new directory and clean it up as we go. (so we keep the currently working
L1 in the current dir and just progressively import functionality).
This way we can at each addition take care of what we did wrong the first
time around.

(And I'd definitely like to be involved in that process).


Cheers,

Sylvain
s***@stud.ntnu.no
2011-05-15 23:18:26 UTC
Permalink
Hi.

This was probably discussed before so links to rtfms are appreciated,

Am I right that some rtos is required only if the device has just baseband processor?
In case of openmoko we can implement support for L1CTL in FSO framework and use any
existing Linux running on application processor?

cheers,
Max.
Harald Welte
2011-05-16 05:22:33 UTC
Permalink
Hi!
Post by s***@stud.ntnu.no
Am I right that some rtos is required only if the device has just baseband processor?
well, RTOS is mostly required for running other tasks aside from L1 such
as L2, L3, MMI (UI), etc.
Post by s***@stud.ntnu.no
In case of openmoko we can implement support for L1CTL in FSO
framework and use any existing Linux running on application processor?
Of course you can do that. But I think after the RTOS port of OsmocomBB
is completed, not many people will still try to maintain the old
pre-RTOS code.

But at least in one version of the new proposed RTOS based firmware, we
would expose the same L1CTL interface via SERCOMM on the UART, so you
could still run the same layer23/mobile stuff on the host PC (or
Openmoko Application Processor).

Regards,
Harald
--
- Harald Welte <***@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Gregory Nutt
2011-05-16 21:21:45 UTC
Permalink
Hi, List,

I heard through the grape vine that you are considering using NuttX.  I don't want to influence your decision, but if the decision is final, I would like to offer any support to the project that I can give.
Indeed. The TI C5471 DSP/ARM chip seems to be virtually a predecessor of the Calypso.
I have quite a bit of experience working with these TI dual core chips and would be happy to help out as much as possible.  With the ARM7/c5 family, I have developed OS support (uClinux) for the C5471, DSC21, DSC24, and DM270.  Also the DM320 (ARM9/c5, Linux).

I founded this business in Costa Rica (http://www.ridgerun.com, also once called Cadenux).  But have not been involved with the more recent ARM11/Cortex A8/c6 chips.
I'm already working on the IRQ subsystem and took a look at the UART. 
But there are open questions, see above...
There is a porting guide here may be helpful to you: http://nuttx.sourceforge.net/NuttxPortingGuide.html.
But it does a some "To be provided" sections -- particulary in the IRQ section.
I have a c5 DSP bridge driver somewhere around on my backup disks as
well.  I never released it into NuttX because there was never any
need.  Perhaps that could be useful now.
These DSP bridge drivers present interfaces to load programs into the DSP and to support an integrated, seamless messaging system between the ARM7 and the DSP.

The DSP interfaces differ from chip to chip and the drivers that I was referring were targeted for uClinux.  However, if that is something you are interested in, I would be happy to do the port a driver and integrate DSP messaging with the NuttX messaging.

Greg
Harald Welte
2011-05-19 07:36:38 UTC
Permalink
Hi Gregory,
Post by Gregory Nutt
I heard through the grape vine that you are considering using NuttX.
 I don't want to influence your decision, but if the decision is
final, I would like to offer any support to the project that I can
give.
thanks a lot for your feedback and assistance, it is very much
appreciated.
Post by Gregory Nutt
Post by Alan Carvalho de Assis
I have a c5 DSP bridge driver somewhere around on my backup disks as
well.  I never released it into NuttX because there was never any
need.  Perhaps that could be useful now.
These DSP bridge drivers present interfaces to load programs into the
DSP and to support an integrated, seamless messaging system between
the ARM7 and the DSP.
The DSP interfaces differ from chip to chip and the drivers that I was
referring were targeted for uClinux.  However, if that is something
you are interested in, I would be happy to do the port a driver and
integrate DSP messaging with the NuttX messaging.
The DSP/ARM interface on the Ti Calyspo is very much defined by the mask
rom code in the DSP. I think it is extremely GSM specific, and we
already have full support for it in our existing osmocom-bb code... so
I don't think we would be able to base this on anything existing.

Regards,
Harald
--
- Harald Welte <***@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Loading...