RTEMS on AVR?

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear fellows,

I would like your opinion for a possible complex application with AVRs. My target is a AT90USB90 or a ATMEGA328P.

I would like a way to program on AVR using pre-emptive multitasking/multithreading paradigms with Ada, and on a programming forum, someone suggested that I could use RTEMS to program in AVR. RTEMS is a RTOS (Real-Time Operating System) used in several real-time interesting applications with several different targets. But some other good people have the opinion that it would not be a good choice, because the RTEMS support for AVRs is very limited, when comparing with the full RT features RTEMS implements.

I found in RTEMS CPU Architecture Supplement, the description of the AVR support, and I guess it's very interesting to implement, even considering the limitations they talk about. And mainly because I'm used to limitations much bigger than the showed there.

Maybe you good AVR experts (I'm very far from this!) could have a better opinion about this? I think RTEMS is very usable for AVRs (and would be a good OS choice), what do you think?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Gnu Compiler Collection has a Bunch o Compilers..... c, c++, pascal, fortran, and ada. Whether they all got ported to the avr is fuzzy. Some messages here say they can compile c++ with the winavr gcc compiler. The runtime library with all those subroutines you never think about were all compiled up by Eric W, long time AVRfreak and obviously a Real Good compiler porting expert. If, by some miracle, you manage to cobble up an AVR ada compiler, and somehow manage to actually compile all the RTEMS ada rtos source code, you will be like the Last Of The Mohicans, the Only Person In the World that is an expert in AVR ada. Best of luck to you. How about using Freertos, a Known Working rtos for avr? I guess they are still using ada a lot up on Mars? There is a bottomless bar in Tampa about 25 miles down the road from Zephyrhills called the Mons Venus. Sort of a word play on your location.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
The Gnu Compiler Collection has a Bunch o Compilers..... c, c++, pascal, fortran, and ada. Whether they all got ported to the avr is fuzzy. Some messages here say they can compile c++ with the winavr gcc compiler. The runtime library with all those subroutines you never think about were all compiled up by Eric W, long time AVRfreak and obviously a Real Good compiler porting expert. If, by some miracle, you manage to cobble up an AVR ada compiler, and somehow manage to actually compile all the RTEMS ada rtos source code, you will be like the Last Of The Mohicans, the Only Person In the World that is an expert in AVR ada. Best of luck to you. How about using Freertos, a Known Working rtos for avr? I guess they are still using ada a lot up on Mars? There is a bottomless bar in Tampa about 25 miles down the road from Zephyrhills called the Mons Venus. Sort of a word play on your location.

Actually I would not be the One! lol There are some other attempts, like the AVR-Ada, (and an interesting link on Arduino playground). But AVR-Ada does not support tasking yet. I still got to run it on a AT90USB90 chip, very good, just the tasking issue for being better. I also just found an MSc thesis for ARM systems with Ada 2005 (on this site). Interesting that on that thesis it's used the FreeRTOS with import pragmas for binding to Ada (I did not read full yet, since I just got that now). I did not consider FreeRTOS at first because I would like to use Ada (no problem with C, just other programming paradigms), but it could be an approach. I began to consider RTEMS, but I still did not finish the system setup, so I cannot evaluate it yet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AFAIK, RTEMS is far too large for an 8-bit AVR (it seems that the AVR port you refer to is AVR32) You might see what FreeRTOS offers.

Or, if you want to try Ada with real (language-based) tasking - an excellent goal, IMO - move up to something in the ARM family.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
AT90USB90

What is that?
Why do you think running OS on something without ANY hardware os support is interesting? No MPU, supervisor/user/OS modes, priorities, exceptions, DMA, no OCD with traps or even decent breakpoints. I would say it is more painful than interesting. Start with FreeRTOS on ATMega, post your experiences.

RTEMS CPU Architecture Supplement wrote:

The AVR family architecutre support a single unified 4 GB byte address space

Never mind the spelling, RTEMS is supposed to be "widely" portable. And for AVRs, being on the lowest end of this "wide", it emulates core OS functionality in software. Why do you think you need it when most of the emulated features are already present in a 2$ 32-bitters?

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pvrego wrote:
I would like a way to program on AVR using pre-emptive multitasking/multithreading paradigms with Ada, ...
Consider GNAT for AVR32 UC3.
Pre-emption can open a can of worms if not designed correctly; a lot of designs simply use protected queues between tasks/processes/threads so as to avoid the potential for deadlocks, priority inversions, etc.
Consider a cooperative method instead of a preemptive method unless it's obvious that preemption is necessary.
For AVR, there is: 1. community AVR-Ada, 2. AdaCore GNAT, 3. AdaCore GPL GNAT by Libre, 4. maybe AdaCore SPARK for AVR if it exists.
IIRC for multitasking, AVR-Ada is forthcoming and SPARK has it; SPARK is Ada using formal methods.
pvrego wrote:
I think RTEMS is very usable for AVRs (and would be a good OS choice), what do you think?
Likely overkill. I'm partial to QP for AVR.
Scheduler is cooperative or preemptive.
State machines to get one to design first instead of implement first.
Ada has a C interface so could use Ada with this C QP.
Most GNAT's are configured and made to include C in addition to the obvious Ada so likely could use one compiler for the entire application (app, QP, C lib, Ada lib, GCC lib, GNAT RTL).
Lots of RTOSs for AVR and, IIRC, there's a list in AVR Freaks Tutorials.
Consider a CSP design (Communicating Sequential Processes) so that the application will be more portable to different RTOSs and, with work, to different languages (or a thunk layer/abstraction layer).

An Ada guru called me (company was buying a GNAT license) and inquired about the design of the application. I described it to him and he recommended no RTOS (i.o.w. keep the ISRs plus big loop design); that was not as desired per the lead software systems engineer but it worked well.
Make certain you really need a RTOS.

Ada is easier on bigger iron though obviously do-able on 8-bit AVR and some 16-bit MPUs and maybe 16-bit MCUs.
Consider ARM; Linux if enough RAM would be relatively not difficult else ARM EABI (bare metal) would not take too much effort.
Likely could use an existing ARM GNAT on Linux native on QEMU instead of creating a cross compiler though creating a GNAT cross compiler may not be difficult.
There is a uCLinux on larger ARM Cortex-M3; that'll get a complete Ada (i.o.w. full tasking) on GNAT on an ARM Linux.
http://www.linux-arm.org/LinuxKernel/LinuxM3
Linux and uCLinux should work unless have a hard real-time constraint; can usually do soft real-time and most throughpout constrained applications on Linux.
An example of Ada on bare metal ARM is GNAT GPL 2011 mindstorms-nxt-windows; an Ada cross-compiler for ARM7 no RTOS (cross-compiler on Windows).
The LEGO MINDSTORMS NXT has an ARM7 communicating with an AVR mega (mega hard real-time controls the motors).
There is the and a BSD Unix on its 32-bit MCU.
If not power constrained and not memory constrained, consider these.
A number of systems use a MCU for the hard real-time part of the application and another MCU for the non-real-time part of the application (i.o.w. rest of the application on top of Android or whatever on whatever).
Edit: Added Cortex-M3 Linux URL.

"Dare to be naïve." - Buckminster Fuller

Last Edited: Sat. Feb 11, 2012 - 04:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The LEGO MINDSTORMS NXT has an ARM7 communicating with an AVR mega (mega hard real-time controls the motors).

Can you provide some tear-down link?

EDIT: Ok, already got one:
http://thenxtstep.blogspot.com/2...

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Whether they all got ported to the avr is fuzzy.

There was an issue of WinAVR (not sure if it was 2006, 2007 or 2008) that included an Ada compiler. Eric stopped including it later because they did not maintain the port as GCC moved on.

There are still remnants of it:

http://sourceforge.net/apps/medi...

This talks about building it from source:

http://avr-ada.sourceforge.net/c...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ada on a small memory 8 bit micro makes little practical sense, IMO.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
Ada on a small memory 8 bit micro makes little practical sense, IMO.

Full Ada, certainly true. Same with full C++. But both are useable and offer advantages with appropriate limitations.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here are some rtems build reports:

http://gcc.gnu.org/ml/gcc/2011-0...
http://gcc.gnu.org/ml/gcc/2011-1...

And as you see from the following patch there is at least some effort to support rtems on avr:

http://sourceware.org/ml/newlib/...

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brutte wrote:
Quote:
AT90USB90

What is that?

I'm sorry, I meant AT90USB162. But now it has just arrived an ATMEGA320P, more interesting for this.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
Consider GNAT for AVR32 UC3.

I will take a look on it.

Quote:
Pre-emption can open a can of worms if not designed correctly; a lot of designs simply use protected queues between tasks/processes/threads so as to avoid the potential for deadlocks, priority inversions, etc.
Consider a cooperative method instead of a preemptive method unless it's obvious that preemption is necessary.

Ok, but no problem with it. It should be part of the design.

Quote:
For AVR, there is: 1. community AVR-Ada

I know AVR-Ada, and find this project wonderful, but it yet lacks some important real-time features I'd like to consider in this design (exceptions, tasking, tagged types,...), but maybe they will implement some of them yet this year, so it can be a good approach too. Also the documentation is very good. There is a good presentation about AVR-Ada from FOSDEM-12 on Arduino Talk, thanks to Jacob Sparre.

Quote:
AdaCore GPL GNAT by Libre

GNAT GPL is very good and I use it very much for academic purposes only (and that's the case), but an Windows-to-AVR (or *2AVR) cross-compiler is not available on Libre site. Actually if I would use Lego Mindstorms, there is a great open-source cross-compiler available on Libre, but unfortunately it's not the case.

Quote:
maybe AdaCore SPARK for AVR if it exists.
IIRC for multitasking, AVR-Ada is forthcoming and SPARK has it; SPARK is Ada using formal methods.

I know SPARK quite well too. But yet we'd need the *2AVR cross-compiler.

Quote:
Most GNAT's are configured and made to include C in addition to the obvious Ada so likely could use one compiler for the entire application (app, QP, C lib, Ada lib, GCC lib, GNAT RTL).
Lots of RTOSs for AVR and, IIRC, there's a list in AVR Freaks Tutorials.
Consider a CSP design (Communicating Sequential Processes) so that the application will be more portable to different RTOSs and, with work, to different languages (or a thunk layer/abstraction layer).

I will consider. Making an Ada-C porting is not too complex, but consumes time. But this is the case where making a porting to FreeRTOS, for example, would be easier.

Last Edited: Wed. Mar 7, 2012 - 01:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
Here are some rtems build reports:

http://gcc.gnu.org/ml/gcc/2011-0...
http://gcc.gnu.org/ml/gcc/2011-1...

And as you see from the following patch there is at least some effort to support rtems on avr:

http://sourceware.org/ml/newlib/...

That's the point. There is actually a good effort in RTEMS team to support AVRs. Maybe using this could be good enough to help improving the porting.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pvrego wrote:
... an Windows-to-AVR (or *2AVR) cross-compiler is not available on Libre site.
http://libre.adacore.com/libre/download2?config=avr-elf-windows&version=2011
pvrego wrote:
Making an Ada-C porting is not too complex, ...
Not necessary since Ada has package 'Interfaces.C' but don't know if that package is in any of the AVR Ada toolsets; if not, the binary API should be shared so likely a pragma Import and/or pragma Export.
pvrego wrote:
... porting to FreeRTOS ...
Do-able but FreeRTOS does not have a POSIX interface whereas, IIRC, RTEMS does. GNAT has easier ports to a POSIX interface but has definitely been done to other OS interfaces; there's the Ravenscar profile (easier for Ada on bare metal).
pvrego wrote:
There is actually a good effort in RTEMS team to support AVRs.
IIRC, mega128 on two AVR simulators so there's hope though I wouldn't be surprised if you'd have to use a larger AVR than your original targets. If you're able, port to a readily available AVR board (Atmel, etc.) so that OAR could make that board a part of their RTEMS regression testing.

"Dare to be naïve." - Buckminster Fuller