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

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

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 4:59 PM, Alan Carvalho de Assis acassis@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

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:

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.

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:

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 , 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,

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

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

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.

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