ATMega328 / Arduino

[Vik]

Hi all,

I'm making changes to Chibios trunk to make it work on an ATMega328 / Arduino board. Having created a new board directory called ARDUINO and new demo (both based on the Arduino Mega), I found that some changes are also needed to os/hal/platforms/AVR/serial_lld.c due to the different timer interrupt names. What's the preferred way of dealing with minor differences between chips in a platform?

BTW, when I build the ArduinoMega demo using avr gcc, the compiler is complaining about several integer overflows. The timer in particular definitely overflows on certain values. Is this a known issue or am I doing something wrong (as much as I can do something wrong with typing 'make' :/ )?

Thanks in advance.

Cheers,
Vik

[Giovanni]

Hi Vik,

Currently the AVR port is not being actively developed because there are no maintainers for that family.

There is an unofficial but well supported ChibiOS branch dedicated to Arduinos, probably you should give it a try: http://code.google.com/p/rtoslibs/

The author is very active in maintaining them.

Giovanni

[Vik]

Hi Giovanni,

Thanks for the quick reply. I had a look but I'm not interested in embedding Chibios into Arduino, I'd like to just run native Chibios on an ATMega328 in the Arduino board.

Given the lack of maintainer, I think I am going to get an ArduinoMega clone off ebay and dust off the AVR port a bit I'd just like to know in advance how you'd like the multiple MCU stuff laid out before I start hacking away at it, because I'd like any patches I create against trunk committed back. If there is an example of this type of stuff for another architecture where a single "platform" file supports multiple MCUs, just let me know and I'll do something similar.

Cheers,
Vik

[Giovanni]

Hi,

You are very welcome as a Maintainer for the AVR side of the project, there is a lot of interest on AVRs but nobody stepped up until now. Contact me in PM if you need details.

Supporting a family of MCUs is far more complex than supporting specific devices, look at the STM32 or SPC5xx support for example. You need to make an accurate analysis of the problem before star writing code or you are in for a lot of rework later (and I know this very well...).

Giovanni

[jscott]

I had a look but I'm not interested in embedding Chibios into Arduino, I'd like to just run native Chibios on an ATMega328 in the Arduino board.

Hi Vik,

I have also run through the process of working with the Arduino platform. What I have found is that is is good for a somewhat limited set of applications. If you have an app that does much with strings, you may find that you run out of ram very quickly. GCC does not have a good way to deal with strings that are stored in Flash. Instead, it copies all the strings to ram in crt0.

Because of this, the ATMega328 with 2k of ram, does well as a sensor processor that does not
need to do much storage. The ArduinoMega2650 with 8K of ram is really the low end for projects
that need more than a couple of processes, or needs to handle much data in ram.

-John Scott
www.atl123.com

[Vik]

Hi John,

I agree that GCC's implementation of the PROGMEM stuff is awkward and it's actually easier to use an MCU that has enough RAM for the strings. And the ATmega328 does not -- even the test thread won't fit into it.

I'm mostly interested in getting the ATmega328 working because I'd like to write an ADC low level driver for AVRs (mainly to help out a friend's project). Right now I only have a pair of Arduino boards around so I might as well put a bit of effort into it until I get a Mega. But if this works, I'll actually dust off an abandoned "fun" project I did a couple of years ago using Arduino where I ran out of CPU cycles due to the lack of scheduling.

Cheers,
Vik

[Vik]

Hi all,

While building the AVR demo, I noticed that the *S2ST macros were prone to integer overflow in the avr-gcc build. The following patch seems to fix that. I just cast CH_FREQUENCY to long before multiplying.

I don't think this will affect the other architectures in any way, but you are welcome to prove me wrong here

Giovanni, is this OK to check in?

Cheers,
Vik

Code: Select all

--- os/kernel/include/chvt.h    (revision 5863)
+++ os/kernel/include/chvt.h    (working copy)
@@ -44,7 +44,7 @@
  * @api^M
  */^M
 #define S2ST(sec)                                                           \^M
-  ((systime_t)((sec) * CH_FREQUENCY))^M
+  ((systime_t)((sec) * (long) CH_FREQUENCY))^M
 ^M
 /**^M
  * @brief   Milliseconds to system ticks.^M
@@ -57,7 +57,7 @@
  * @api^M
  */^M
 #define MS2ST(msec)                                                         \^M
-  ((systime_t)((((msec) * CH_FREQUENCY - 1L) / 1000L) + 1L))^M
+  ((systime_t)((((msec) * (long) CH_FREQUENCY - 1L) / 1000L) + 1L))^M
 ^M
 /**^M
  * @brief   Microseconds to system ticks.^M
@@ -70,7 +70,7 @@
  * @api^M
  */^M
 #define US2ST(usec)                                                         \^M
-  ((systime_t)((((usec) * CH_FREQUENCY - 1L) / 1000000L) + 1L))^M
+  ((systime_t)((((usec) * (long) CH_FREQUENCY - 1L) / 1000000L) + 1L))^M
 /** @} */^M
 ^M
 /**^M
@@ -156,6 +156,8 @@
 /**^M
  * @brief   Enables a virtual timer.^M
  * @note    The associated function is invoked from interrupt context.^M
+ *          The timer MUST NOT be already set when this function is invoked,^M
+ *          call chVTReset() before if there is a risk of this.^M
  *^M
  * @param[out] vtp      the @p VirtualTimer structure pointer^M
  * @param[in] time      the number of ticks before the operation timeouts, the^M

[Giovanni]

I am not sure it is OK because on AVR because systime_t is a 16bits type, wouldn't that simply move the truncation to the outer cast? Alternatively you could decide to make systime_t an uint32_t in AVR/chtypes.h.

Giovanni

[Vik]

Actually the truncation occurs when multiplying with CH_FREQUENCY and it only occurs at the MS2ST or US2ST macros. The first cast in S2ST is superfluous and can be dropped from the patch. To be more precise, it can also overflow there, but systime_t is 16 bit anyway.

Changing systime_t to 32 bit isn't necessary in my opinion. It currently has a maximum value of 65536 which is 65.536 seconds at a CH_FREQUENCY of 1000Hz, or 6.5 seconds at 10KHz. It sounds adequate to me.

According to http://gcc.gnu.org/wiki/avr-gcc long is 4 bytes on AVR, which sounds right, but uint32_t is probably a better choice if stdint.h is available on all architectures. Shall I change the patch this way?

Cheers,
Vik

[Giovanni]

I am undecided on this, you may also simply change CH_FREQUENCY to 1000L instead of 1000 with the same effect.

Giovanni