Hi all,
I'm currently looking for available c++ HAL layer to accommodate into my project. The best option that I could find was this:
https://github.com/jypma/AvrLib
Also there was a similar topic with an intent to build something like this in following post:
https://community.atmel.com/projects/avr-hal-atmega-series?skey=hal%20layer
Does anyone know about any avr HAL written in c++ ?
Br,
geronimo
clawson 
HAL is quite difficult for AVR because different devices have different registers and bit names so it needs an extensive amount of work to work for the 300+ models.
A reasonably good approach is what Fleury does in his Uart library for example:
#if defined(__AVR_AT90S2313__) || defined(__AVR_AT90S4414__) || defined(__AVR_AT90S8515__) || \
defined(__AVR_AT90S4434__) || defined(__AVR_AT90S8535__) || \
defined(__AVR_ATmega103__)
/* old AVR classic or ATmega103 with one UART */
#define UART0_RECEIVE_INTERRUPT UART_RX_vect
#define UART0_TRANSMIT_INTERRUPT UART_UDRE_vect
#define UART0_STATUS USR
#define UART0_CONTROL UCR
#define UART0_DATA UDR
#define UART0_UDRIE UDRIE
#define UART0_UBRRL UBRR
#define UART0_BIT_U2X U2X
#define UART0_BIT_RXCIE RXCIE
#define UART0_BIT_RXEN RXEN
#define UART0_BIT_TXEN TXEN
#elif defined(__AVR_AT90S2333__) || defined(__AVR_AT90S4433__)
/* old AVR classic with one UART */
#define UART0_RECEIVE_INTERRUPT UART_RX_vect
#define UART0_TRANSMIT_INTERRUPT UART_UDRE_vect
#define UART0_STATUS UCSRA
#define UART0_CONTROL UCSRB
#define UART0_DATA UDR
#define UART0_UDRIE UDRIE
#define UART0_UBRRL UBRR
#define UART0_BIT_U2X U2X
#define UART0_BIT_RXCIE RXCIE
#define UART0_BIT_RXEN RXEN
#define UART0_BIT_TXEN TXEN
#elif defined(__AVR_AT90PWM216__) || defined(__AVR_AT90PWM316__)
/* AT90PWN216/316 with one USART */
#define UART0_RECEIVE_INTERRUPT USART_RX_vect
#define UART0_TRANSMIT_INTERRUPT USART_UDRE_vect
#define UART0_STATUS UCSRA
#define UART0_CONTROL UCSRB
#define UART0_CONTROLC UCSRC
#define UART0_DATA UDR
#define UART0_UDRIE UDRIE
#define UART0_UBRRL UBRRL
#define UART0_UBRRH UBRRH
#define UART0_BIT_U2X U2X
#define UART0_BIT_RXCIE RXCIE
#define UART0_BIT_RXEN RXEN
#define UART0_BIT_TXEN TXEN
#define UART0_BIT_UCSZ0 UCSZ0
#define UART0_BIT_UCSZ1 UCSZ1
#elif defined(__AVR_ATmega8__) || defined(__AVR_ATmega8A__) || \
defined(__AVR_ATmega16__) || defined(__AVR_ATmega16A__) || \
defined(__AVR_ATmega32__) || defined(__AVR_ATmega32A__) || \
defined(__AVR_ATmega323__)
/* ATmega with one USART */
#define UART0_RECEIVE_INTERRUPT USART_RXC_vect
#define UART0_TRANSMIT_INTERRUPT USART_UDRE_vect
#define UART0_STATUS UCSRA
#define UART0_CONTROL UCSRB
#define UART0_CONTROLC UCSRC
#define UART0_DATA UDR
#define UART0_UDRIE UDRIE
#define UART0_UBRRL UBRRL
#define UART0_UBRRH UBRRH
#define UART0_BIT_U2X U2X
#define UART0_BIT_RXCIE RXCIE
#define UART0_BIT_RXEN RXEN
#define UART0_BIT_TXEN TXEN
#define UART0_BIT_UCSZ0 UCSZ0
#define UART0_BIT_UCSZ1 UCSZ1
#define UART0_BIT_URSEL URSEL
etc.
etc.
That is define "common names" for the bits that have different names on each device. Then the code just accesses UART0_UBRRL or whatever and does not care whether the device calls is UBRRL or UBRR0L or whatever.
PS that second link you gave, which links on to Github is horrendous. It has things like:
#define _UCSRA *(volatile unsigned char*)(0x2B) #define _UCSRB *(volatile unsigned char*)(0x2A) #define _UCSRC *(volatile unsigned char*)(0x40) #define _UDR *(volatile unsigned char*)(0x2C) #define _UBRRL *(volatile unsigned char*)(0x29) #define _UBRRH *(volatile unsigned char *)(0x40)
No one should be doing anything like that!!
gchapman Does anyone know about any avr HAL written in c++ ?
https://github.com/jfpoilpret/fast-arduino-lib#status
https://marketplace.visualstudio.com/items?itemName=jfpoilpret.fastarduino
Hi all,
thanks for the suggestions.
Fleury uart lib is in C but never the less it's nicely written and documented, so it will help.
The FastArduino looks promessing, especially since it's road-map has just started. AvrLib as stated before supports DI but that isn't really necessary so I'll have to look a bit more through both of them before deciding.
Br,
geronimo
PS that second link you gave, which links on to Github is horrendous. It has things like: #define _UCSRA *(volatile unsigned char*)(0x2B) #define _UCSRB *(volatile unsigned char*)(0x2A) #define _UCSRC *(volatile unsigned char*)(0x40) #define _UDR *(volatile unsigned char*)(0x2C) #define _UBRRL *(volatile unsigned char*)(0x29) #define _UBRRH *(volatile unsigned char *)(0x40) No one should be doing anything like that!!
clawson It is, my point is that no user written code should be reinventing the IO address wheel because the ioxxx.h files already do all that for you. Perhaps the author was aiming for "UART support without io.h" but I have no idea why they'd do that - if the ultimate intention was to make this a library for 300+ models of AVR they'd be creating 300+ identical copies of what is already (for the most part machine generated) in avr/io.h - seems like a support nightmare !
A hardware abstraction layer more complicated than the Fleury library is almost certainly a really bad choice for AVR, given how small the chips are. I wouldn't seriously consider using C++ for them, and I think the Arduino people are insane.
Rather than an ‘off the cuff remark’, stating your reasons gives us a means of separating opinions from facts.
I think the Arduino people are insane.
Very few of the inefficiencies in the Arduino world are due to the use of C++.
It is, my point is that no user written code should be reinventing the IO address wheel because the ioxxx.h files already do all that for you. Perhaps the author was aiming for "UART support without io.h" but I have no idea why they'd do that - if the ultimate intention was to make this a library for 300+ models of AVR they'd be creating 300+ identical copies of what is already (for the most part machine generated) in avr/io.h - seems like a support nightmare !
In this particular instance, I think it was a bad choice,
but I had to go to the website to find out.
To me, the "user-written code" issue is a non-starter.
The issue is how, how often and by how many it is used.
If the answer is substantially the same as that for <avr/io.h>
then the coding rules are the same: <hal/io.h>
Also, we do not know that maligned code was user-written.
It might have been derived from the same xml files as <avr/io.h>.
It might have been derived from <avr/io.h>.
A human author might do it to attempt toolchain-independence.
No claim that this particular author is doing particularly well,
just that the rationale for a particular criticism was incorrect.
clawson Just seems like an "alarm bell" to me saying "author probably didn't have first idea what they were doing". YMMV.