RTEMS on AVR?

[Joel Sherrill <joel@OARcorp.com>]

Ralf Corsepius wrote:
> On Thu, 2005-08-04 at 11:02 -0400, Paul Evans wrote:
> 
>>Hi,
>>
>>I've talked to Atmel in the past about the price of the SAM7 vs. the AVR,
>>and the rule if thumb is about twice the cost. That's not to say the SAM7
>>isn't attractive in absolute cost terms, but for higher volume applications
>>the AVR (which is a smaller die and has no IP licensing) will cost less.
> 
> ACK, just consider that price is just one criterion among several ones.
> Sometimes, "space", "power consumption" or "personal
> experience/preference" are more important.

Agreed.  Related to personal experience is corporate/product history.
If someone has an existing line of products using an architecture, they
may decide to continue to use that architecture.  RTEMS has also been
used as a transition enabler.  Long ago, the MIPS and AMD A29K ports
were submitted by the same company at the same time.  They then could
transition to RTEMS on their existing products and new product line
at the same time.  It provided a common baseline for them independent
of architecture.

>>In applications where 16K of RAM is enough, I agree that a "micro RTEMS"
>>would be a great alternative to Salvo or UCOS. Having used RTEMS on a 68K
>>with 128K RAM I think it should be possible, especially if not all the
>>managers are used (just semaphores, queues, and the scheduler perhaps?)
> 
> Exactly, that's what at least I hope for (I once used RTEMS on SH1's
> w/128k RAM, no pthreads, no itron, no networking).

I recall a m68k robotics application that fit into 96K.

It still should be possible if a limited feature set is used and
there is no code pulled in to support unused features.  A tiny example
of this is that the ISR and normal thread dispatching code
generically provides hooks to handle asynchronous signal dispatching.
If you were in a system that had no POSIX signals or RTEMS Classic API
signals, then this code could be left out.

--joel