RTEMS on AVR?

[Joel Sherrill <joel@OARcorp.com>]

Evgeny Belyanco wrote:
> Wednesday, August 3, 2005, 6:41:29 PM, you wrote:
> 
> RC> Primarily:
> RC> * RTEMS is not 16 bit clean (!).
> RC> * Some parts of newlib need to be fixed.
> 
> 
>>>I am not sure, that it is possible - due to low resources of AVR.
> 
> RC> That's what we want to find out.
> 
> RC> It definitely won't fit onto the small AVRs, but there are chances it
> RC> could fit onto larger AVRs. ATM, avr support is more or less more an
> RC> experiment aiming at "slimming down" RTEMS ("Tiny RTEMS") and at getting
> RC> it 16 bit clean, but an actual target.
> 
> Tiny RTEMS is good idea, AVR - not.
> 
> 1. Highest AVR like Mega128, Mega64 is not price effective in
> comparison with modern ARM - Philips LPC2xxx, Atmel AT91SAM7S64, etc.
> 
> 2. Atmel push customers to ARM - why??
> http://www.atmel.com/dyn/resources/prod_documents/doc3323.pdf
> 
> IMHO, Tiny RTEMS on LPC2116 or AT91SAM7S64 will bring a lot of users
> to RTEMS, who now spending their time for uCOS-II, etc. And it is more
> perspective for RTEMS future (IMHO).

I see nothing wrong with RTEMS having support for both architectures.
If a port has no users, then it is sacked.  So if people want to use
AVR or ARM, we don't really care as long as the bulk of RTEMS code
continues to be shared across all architectures.


> If it is possible to build RTEMS for ARM target with min. req. 8kb RAM
> & 32...48 kb FLASH (for system), and services better then uCOS-II, it
> will be great!!

The most general question facing TinyRTEMS is "What features should be
in the tiniest configuration?"  Ralf and I have bantered back and forth.
Clearly some features will never fit in a low end target -- the BSD 
TCP/IP stack springs to mind.  But other features are harder to decide
on.  My general take is that RTEMS could end up with a fair number
of "point configurations" like number of priorities, is priority 
blocking supported, is priority inheritance supported, etc.

So TinyRTEMS will set all the point features to their smallest 
configuration setting but users may be able to generate a
medium sized RTEMS with a mix of features.

I added code for 16-bit IDs as a step in this direction.  If you
are going small, there is no reason for extremely large number of
objects or multiprocessor node information in the ID.

Ralf has focused on making sure the code is 16 bit clean.  When you
use an int, you need to make sure it is OK with only 16 bit ints.

I am concerned that in the smallest RAM configurations, the notion
of each task having its own dedicated stack might be unsupportable.
8K RAM definitely doesn't make you want to give each task a portion
of that.  There are alternate schemes to be looked at when memory
is that right.

So TinyRTEMS is a concept and a goal.  We do not have feature 
requirements defined for what the "tiniest RTEMS" will be.  Any
comments and thoughts would be appreciated.


> 
> 
> Evgeny Belyanco
> Chief Designer KB KCC
> **********************************
> * E-mail: ea at kbkcc.ru
> * Phone (cel.): +7 901 510 9046
> * Fax: +7 095 926 9787
> * Web: http://www.kbkcc.ru
> * Post address:
>    KB KCC, suite 209,
>    ul. Butirsky Val, bld. 68
>    Moscow, 127055, Russia
> **********************************
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985