c++ AVR HAL

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Last Edited: Tue. May 22, 2018 - 02:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!!

Last Edited: Tue. May 22, 2018 - 02:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
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!!
Isn't that about what <avr/io.h> pulls in?

Moderation in all things. -- ancient proverb

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Rather than an ‘off the cuff remark’, stating your reasons gives us a means of separating opinions from facts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think the Arduino people are insane.

Very few of the inefficiencies in the Arduino world are due to the use of C++.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
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 !
Methinks you are painting with too broad a brush.

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.

Moderation in all things. -- ancient proverb

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just seems like an "alarm bell" to me saying "author probably didn't have first idea what they were doing". YMMV.