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
AVR GCC port
Re: AVR GCC port
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
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
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: AVR GCC port
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
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
Re: AVR GCC port
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
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
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: AVR GCC port
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
ciao,
Giovanni
Re: AVR GCC port
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:
Code: Select all
typedef struct {
volatile uint8_t *tcr; // Timer control register, TCCRx or TCCRxA
volatile uint8_t *val; // Timer value, TCNTx
volatile uint8_t *cmp; // Timer compare value, OCRx or OCRxA
} timer_t;
timer_t timer0;
timer_t *tmr = &timer0;
tmr->tcr = &TCCR0A;
tmr->val = &TCNT0;
tmr->cmp = &OCR0A;
// OCR0A = AVR_TIMER_COUNTER - 1;
// *timer0.cmp = AVR_TIMER_COUNTER -1;
*tmr->cmp = AVR_TIMER_COUNTER - 1;
The listing shows that the three statements result in the same assembler:
Code: Select all
89:../../os/hal/platforms/AVR/hal_lld.c **** OCR0A = AVR_TIMER_COUNTER - 1;
104 .loc 1 89 0
105 0060 9BE9 ldi r25,lo8(-101)
106 0062 97BD out 0x27,r25
89:../../os/hal/platforms/AVR/hal_lld.c **** *timer0.cmp = AVR_TIMER_COUNTER - 1;
99 .loc 1 89 0
100 005a 9BE9 ldi r25,lo8(-101)
101 005c 97BD out 0x27,r25
84:../../os/hal/platforms/AVR/hal_lld.c **** *tmr->cmp = AVR_TIMER_COUNTER - 1;
114 .loc 1 84 0
115 007e 9BE9 ldi r25,lo8(-101)
116 0080 97BD out 0x27,r25
Do you think it's OK to use throughout the code without any performance impact?
Cheers,
Vik
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: AVR GCC port
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
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
-
- Posts: 359
- Joined: Sat Jan 07, 2012 6:22 pm
- Location: Brazil
- Has thanked: 1 time
- Been thanked: 20 times
- Contact:
Re: AVR GCC port
How about creating an AVR board and start moving threads related to this arch there so that things are better organized?
Re: AVR GCC port
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.
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: AVR GCC port
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
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
Who is online
Users browsing this forum: No registered users and 22 guests