16 Apr
2011
16 Apr
'11
9:35 p.m.
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
17 Apr
17 Apr
9:51 a.m.
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
18 Apr
18 Apr
2:32 p.m.
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.
On 17.04.2011 09:51, Sylvain Munaut wrote:
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.
Well, that's about what I intended. Just don't have any experience with
realtime applications...
Hi,
My sentence is missing an "important". Anyway, seems to be a major
problem.
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, ...).
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.
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
5:16 p.m.
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?
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
8:51 p.m.
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.
On Mon, Apr 18, 2011 at 6:16 PM, Wolfram Sang <wolfram(a)the-dreams.de> wrote:
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?
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
19 Apr
19 Apr
12:24 a.m.
On Mon, Apr 18, 2011 at 05:16:13PM +0200, Wolfram Sang wrote:
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 <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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?
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? 
4:59 p.m.
Hi Harald,
On 4/18/11, Harald Welte <laforge(a)gnumonks.org> wrote:
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
8 p.m.
On Tue, Apr 19, 2011 at 5:59 PM, Alan Carvalho de Assis
<acassis(a)gmail.com> wrote:
Hi Harald,
On 4/18/11, Harald Welte <laforge(a)gnumonks.org> wrote:
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
20 Apr
20 Apr
12:23 a.m.
On Tue, Apr 19, 2011 at 4:59 PM, Alan Carvalho de Assis
<acassis(a)gmail.com> wrote:
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.
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
9:13 a.m.
On Wed, Apr 20, 2011 at 12:23:55AM +0200, Drasko DRASKOVIC wrote:
On Tue, Apr 19, 2011 at 4:59 PM, Alan Carvalho de
Assis
<acassis(a)gmail.com> wrote:
nuttx seems quite interesting, I'm reviewing the source code at the moment.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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.
Hi Alan,
I agree on this one also. I took a look at this OS some time ago,
seems like really well done code. 
10:35 a.m.
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.
On 20-4-2011 9:13, Harald Welte wrote:
On Wed, Apr 20, 2011 at 12:23:55AM +0200, Drasko
DRASKOVIC wrote:
On Tue, Apr 19, 2011 at 4:59 PM, Alan Carvalho de
Assis
<acassis(a)gmail.com> wrote:
nuttx seems quite interesting, I'm reviewing
the source code at the moment.
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.
Hi
Alan,
I agree on this one also. I took a look at this OS some time ago,
seems like really well done code. 
11:14 a.m.
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
On Wed, Apr 20, 2011 at 10:13 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
On Wed, Apr 20, 2011 at 12:23:55AM +0200, Drasko
DRASKOVIC wrote:
On Tue, Apr 19, 2011 at 4:59 PM, Alan Carvalho de
Assis
<acassis(a)gmail.com> wrote:
> 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.
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 <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
4:18 p.m.
On 4/20/11, Harald Welte <laforge(a)gnumonks.org> wrote:
On Wed, Apr 20, 2011 at 12:23:55AM +0200, Drasko
DRASKOVIC wrote:
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
On Tue, Apr 19, 2011 at 4:59 PM, Alan Carvalho de
Assis
<acassis(a)gmail.com> wrote:
nuttx seems quite interesting, I'm reviewing the source code at the moment.
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.
Hi Alan,
I agree on this one also. I took a look at this OS some time ago,
seems like really well done code.
19 Apr
19 Apr
1:03 a.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
11:23 a.m.
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:
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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)
20 Apr
20 Apr
12:12 a.m.
On Sat, Apr 16, 2011 at 9:35 PM, l--putt <ichgeh(a)l--putt.de> wrote:
FreeRTOS
What is the problem?
Too Windows oriented for my taste. Documentation is full of build on
Cygwin and friends. Don't like.
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.
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.
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 ;)).
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
14 May
14 May
6:46 p.m.
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!
10:41 p.m.
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
15 May
15 May
10:17 p.m.
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
10:29 p.m.
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
16 May
16 May
7:19 a.m.
Hi Wolfram,
On Sun, May 15, 2011 at 10:17:28PM +0200, Wolfram Sang wrote:
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.
(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 <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
6:27 p.m.
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.
6:33 p.m.
Scott Weisman wrote:
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
11:14 a.m.
On Sat, May 14, 2011 at 6:46 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
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!
From all that I've seen, it really seems like a good fit.
* it tries to stay as close to POSIX and other Unix APIs as possible
* you can actually have executable programs in the file system
* it contains a small interactive shell
* the changelog is verbose and releases are frequent
* there's a test suite
* there are already ports to other ARM7TDMI microcontrollers
* there is a small UI framework and the notion of drivers for SPI-
attached LCDs (with 1/2/4 bpp)
* it has tasks and threads, pre-emptive and with priorities
* it has posix message queues, which we could use for passing around
primitives between elements in the stack
* it can be used on Unix-like and Windows/Cygwin host OS
* it has its own scripts to generate toolchains, which means we
could possibly standardize on one of those toolchains
Hi Harald,
as I mentioned before, I think that Nuttx is an excellent choice.
Of course, not everything is perfect
* there seems to be no writeable FS we can put in NOR flash
* it has no scripting language integration (like lua) yet
Which RTOS that can fit in ARM7TDMI mem does ? I can see that eLua has
ARM7TDMI support (http://www.eluaproject.net/en_status.html), but I am
not sure what are the memory requirements...
* i didn't find any memory allocator optimized for
pools of objects
of the same size (like 'struct msgb' or the like). Something with
an API [not implementation!] of the SLAB/SLUB in Linux would probably
be a good start.
I've done some example compile runs for arm7, including the shell and
the graphics support (nx example). I end up with an object code size of
something like 70 kilobytes, which is pretty good!
This is really good.
So unless anyone raises major objections, I think we
should move ahead
with Nuttx. Who is interested in working on the calypso port?
I am very interested in taking a roll in this. While pure protocol
stack is not my biggest passion, RTOS and device drivers (platform
stuff in general) is something I really like to work on.
Let's use this list for coordinating the effort.
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.
As soon as you push the code I will take a look at it.
Should we make some list of priorities / roadmap ? I think that
dividing the work in the set of tasks that go bottom-up, from the HAL
to shell and apps, would be better for organization.
Best regards,
Drasko
1:08 p.m.
On 14.05.2011 18:46, Harald Welte wrote:
Indeed. The TI C5471 DSP/ARM chip seems to be virtually a predecessor of
the Calypso.
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.
From all that
I've seen, it really seems like a good fit.
* it tries to stay as close to
POSIX and other Unix APIs as possible
* you can actually have executable programs in the file system
* it contains a small interactive shell
* the changelog is verbose and releases are frequent
* there's a test suite
* there are already ports to other ARM7TDMI microcontrollers * there is a small UI framework and the notion of
drivers for SPI-
attached LCDs (with 1/2/4 bpp)
* it has tasks and threads, pre-emptive and with priorities
* it has posix message queues, which we could use for passing around
primitives between elements in the stack
* it can be used on Unix-like and Windows/Cygwin host OS
* it has its own scripts to generate toolchains, which means we
could possibly standardize on one of those toolchains
Of course, not everything is perfect
* there seems to be no writeable FS we can put in NOR flash
There is nxffs but with its limitations you are probably right...
* it has no scripting language integration (like lua)
yet
* i didn't find any memory allocator optimized for pools of objects
of the same size (like 'struct msgb' or the like). Something with
an API [not implementation!] of the SLAB/SLUB in Linux would probably
be a good start.
I've done some example compile runs for arm7, including the shell and
the graphics support (nx example). I end up with an object code size of
something like 70 kilobytes, which is pretty good!
So unless anyone raises major objections, I think we should move ahead
with Nuttx. Who is interested in working on the calypso port?
I'm already working on the IRQ subsystem and took a look at the UART.
But there are open questions, see above...
Let's use this list for coordinating the effort.
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.
Regards,
Harald
1:18 a.m.
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.
7:22 a.m.
Hi!
On Mon, May 16, 2011 at 01:18:26AM +0200, suraev(a)stud.ntnu.no wrote:
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.
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 <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
4736
days inactive
4766
days old
baseband-devel@lists.osmocom.org
27 comments
13 participants
participants (13)
-
246tnt＠gmail.com -
Alan Carvalho de Assis -
Drasko DRASKOVIC -
Harald Welte -
l--putt -
Marius Cirsta -
Nordin -
Peter Stuge -
Scott Weisman -
suraev＠stud.ntnu.no -
Sylvain Munaut
-
Sébastien Lorquet -
Wolfram Sang