ChibiOS Free Embedded RTOS

Hi all,

I've started some work on the existing AVR port with the aim of expanding it to support a few more devices and boards, as well as extending HAL support on it. It's a work in progress and I will later try to incorporate as many patches from other people as I can (if you have any, please send it to me or post it below).

In the meantime I would also appreciate some feedback on this patch, particularly on how to best organise the code for multiple AVR devices and their similar, but slightly different peripherals.

A changelog for the patch:

* Fixed integer overflow in AVR port
* Added documentation for chVTEnable()
* Added a compile fix for the C++ wrapper (#if CH_USE_MEMCORE around a
function call)
* Added compatibility aliases for different USART names in different
AVR MCUs
* Move timer setup and interrupt handler to
os/hal/platforms/AVR/hal_lld.c
* Renamed the USE_AVR_USARTx flag to AVR_SERIAL_USE_USARTx
* Add new board file for ATMega328 based Arduino boards, based on
Arduino Mega
* Add new demo for ATMega328 based Arduino boards based on Arduino Mega
It has the following changes compared to Arduino Mega:
- Changed CH_FREQUENCY in Arduino demo to test timer prescaler
auto-configuration
- Removed test thread as it would not fit into RAM on the ATmega328

This now compiles for the Arduino Mega and ATmega128 as well, but I was only able to test it on the ATmega328, so if you have other AVR boards, I would appreciate if you could give it a try. It was created against revision 5865 from svn.

Thanks in advance.

Cheers,
Vik

Hi all,

I created GitHub clone of the repository and applied my changes against it: https://github.com/viktorradnai/ChibiOS

Testing would be still welcome.

Cheers,
Vik

Hi Vik,

I will review the common parts and comment on that, for the AVR part it is basically up to you, when your branch is ready we can merge.

BTW, sorry if I am slow in answers in latest weeks but I am changing the ISP, the old one already disconnected the carrier and the new one has yet to act... I am connecting via 3G and have few megabytes left for this month...

Giovanni

Hi Giovanni,

There is no rush. I'd like to get a few fundamental things right in the core though, because it will get harder to change that later. I was thinking about things like the best way of handling MCUs with multiple timers, serial ports, etc. without too much code duplication.

I think the best way would be to create a struct containing all the addresses for the various registers (TCCRx, etc) and then manipulate those. I will still need a header that will populate these structures based on either feature autodetection eg #if defined(TIMER1) or failing that using the MCU name eg. #if defined(__ATMEGA328P__). I couldn't find any obvious examples of others doing this to copy, so suggestions would be very much welcome.

Cheers,
Vik

The risk with pointers to registers is to increase the code size, each access would have to go through a pointer, loading a pointer requires several instructions.

ciao,
Giovanni

Giovanni wrote:The risk with pointers to registers is to increase the code size, each access would have to go through a pointer, loading a pointer requires several instructions.

That's a very good point, thanks. I did do a quick test though, and in this particular case it did not seem to make a difference:


The listing shows that the three statements result in the same assembler:


Do you think it's OK to use throughout the code without any performance impact?

Cheers,
Vik

It is possible that the instruction set is able to handle that efficiently but:

1) There is the size of the structures themselves to account into the total size.
2) Are structured allocated in program space (flash) or data space (RAM)? probably accesses in program space would produce slower and larger code and I would not use RAM for that, RAM is very scarce in AVRs.

Giovanni

How about creating an AVR board and start moving threads related to this arch there so that things are better organized?

utzig wrote:How about creating an AVR board and start moving threads related to this arch there so that things are better organized?

Giovanni will do that presumably once he's got his internet access sorted out again

In the meantime I'll probably have to write something like this and check how the compiler handles it. I presume that the main difference will be that structures of constants will live in RAM while the constants (ie #defines) will probably live in program space. But that's just my guess. On the other hand, on a device with 5 timers, having 5 functions for everything a timer does seems like a waste of flash.

It is just that I forgot to do this during weekend...

Forum created, both of you set as moderators. Please PM me your SF usernames in order to gain access to the repository. If you want threads moved here please make a list and I'll do the move.

Giovanni