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
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
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:
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 ...)
My sentence is missing an "important". Anyway, seems to be a major problem.
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.
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.
Well, that's about what I intended. Just don't have any experience with realtime applications...
Cheers,
Sylvain
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
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@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
On Mon, Apr 18, 2011 at 05:16:13PM +0200, Wolfram Sang 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?
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Harald, On 4/18/11, Harald Welte <laforge@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
On Tue, Apr 19, 2011 at 5:59 PM, Alan Carvalho de Assis <acassis@gmail.com> wrote:
Hi Harald,
On 4/18/11, Harald Welte <laforge@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:
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
On Tue, Apr 19, 2011 at 4:59 PM, Alan Carvalho de Assis <acassis@gmail.com> wrote:
I think we could consider NuttX as well:
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
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@gmail.com> wrote:
I think we could consider NuttX as well:
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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@gmail.com> wrote:
I think we could consider NuttX as well:
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.
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@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@gmail.com> wrote:
I think we could consider NuttX as well:
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@gnumonks.org> http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On 4/20/11, Harald Welte <laforge@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@gmail.com> wrote:
I think we could consider NuttX as well:
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
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> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Sat, Apr 16, 2011 at 9:35 PM, l--putt <ichgeh@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
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!
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
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
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
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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.
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
On Sat, May 14, 2011 at 6:46 PM, Harald Welte <laforge@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
On 14.05.2011 18:46, Harald Welte 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! > 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 Indeed. The TI C5471 DSP/ARM chip seems to be virtually a predecessor of the Calypso. > * 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
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.
Hi! On Mon, May 16, 2011 at 01:18:26AM +0200, suraev@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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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