How to avoid code duplication in my new RTEMS port

R. Diez rdiezmail-rtems at yahoo.de
Fri Jul 26 09:07:33 UTC 2013


Hi all:

I am the same RTEMS newbie from yesterday, who is still trying to port RTEMS to the Arduino Due. 8-)

I was able to flash a modifed RTEMS hello.exe to the board that just hangs near the beginning, and I can step through the infinite loop with GDB. The next thing I need is a serial port driver, in order to get some sort of serial/debug console up and running.

I was advised in this mailing list to look at the following code:

  http://git.rtems.org/rtems/tree/c/src/lib/libcpu/arm/at91rm9200

That CPU is older than the Cortex-M3 one I need, but it is from Atmel too and it looks alike, it has an ARM Thumb core and the serial port documentation in the datasheets looks very similar. The fun would be to know which UART bits and pieces have changed over the years.

One option would be to start from scratch, painfully copying all #defines for all the UART registers. I might be able to copy code from some other real-time OS or library, which ones would you suggest to steal such #defines from? Should I expect most such licences to be incompatible with RTEMS?

The trouble is, I would probably need to repeat this work for many other peripherals in the future.

Another way would be to try to move the existing at91rm9200 UART code to some shared directory inside RTEMS, rename it to "Atmel-ish UART" and adapt it. I would feel uncomfortable doing this, as I don't know much about RTEMS yet and I cannot test any changes with the original at91rm9200 board.

An alternative could be to use the Atmel Software Framework, which should help keep the code generic for many Atmel processors. That has its disadvantages too, so I have just posted a question about it in this forum:

  http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=134829

One thing I didn't mention there is that you would need the Atmel Software Framework installed if you want to build RTEMS for the affected Atmel CPUs (or with all BSPs). In any case, I would like to have feedback from the RTEMS side too about using such hardware abstraction libraries from Atmel and/or ARM.

Thanks,
  rdiez




More information about the devel mailing list