RFC: RTOS for Calypso
drasko.draskovic at gmail.com
Mon May 16 09:14:06 UTC 2011
On Sat, May 14, 2011 at 6:46 PM, Harald Welte <laforge at 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
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.
More information about the baseband-devel