AVR Freaks

Of course, the API/HAL proponents would say that it takes less time to learn their API - but they would, wouldn't they?!

In principle, it should be true - you should be able to simply write stuff like

setup_uart( 9600, 'n', 8, 1 );   // Set UART to 9600 baud, No parity, 8 data bits, 1 stop bit

instead of having to calculate the baud rate divisor from oscillator frequency, prescalers, etc, and look up all the other registers for setting the other options.

Which is great, as clawson said, for the 95% of cases where you want a "common" set of settings - but no help when you come to a case that needs an "unusual" configuration or use-case that the API hasn't thought of.

nothing you mention (ADC, UART, PCINT) sound like anything particularly complicated

Indeed:  in the example above, it really isn't that hard to work out the baud rate divisor, etc - it's just a handful of 8-bit registers on an ATmega.

Where the HAL approach really comes in is for the chips with far more complex peripherals - where you may have to be setting many dozens registers, each of which has 32 bits to deal with.

My approach would be to start with the API - as that should at least get you something that works.

Then, if it meets all your requirements you're done.

If it doesn't meets all your requirements, then you can look into optimising or replacing it.

eg, see: https://community.atmel.com/comm...

This is where the learning curve "overhead" for APIs often comes in - as you have to try to understand what it's doing, and how you can adjust that to your specific requirements.

also sometimes known as, "Hardware Abstraction Layer".

Amen!

Or not, as I have learned...the hard way.

Even if you are not, the AVR is pretty easy to learn, and just start a thread about the peripheral you have questions on and we will help.

Creating your own 'drivers' is pretty simple to do.

Right Side Jim

Quick for example....

USART0, 9600 Baud, 8-N-1, 8 Megahertz System Clock, no RX or TX interrupt or buffers:

// USART0 initialization
// Communication Parameters: 8 Data, 1 Stop, No Parity
// USART0 Receiver: On
// USART0 Transmitter: On
// USART0 Mode: Asynchronous
// USART0 Baud Rate: 9600
UCSR0A=(0<<RXC0) | (0<<TXC0) | (0<<UDRE0) | (0<<FE0) | (0<<DOR0) | (0<<UPE0) | (0<<U2X0) | (0<<MPCM0);
UCSR0B=(0<<RXCIE0) | (0<<TXCIE0) | (0<<UDRIE0) | (1<<RXEN0) | (1<<TXEN0) | (0<<UCSZ02) | (0<<RXB80) | (0<<TXB80);
UCSR0C=(0<<UMSEL01) | (0<<UMSEL00) | (0<<UPM01) | (0<<UPM00) | (0<<USBS0) | (1<<UCSZ01) | (1<<UCSZ00) | (0<<UCPOL0);
UBRR0H=0x00;
UBRR0L=0x33;

You also need to set up the IO pins:

// Port D initialization
// Function: Bit7=In Bit6=In Bit5=In Bit4=In Bit3=In Bit2=In Bit1=Out Bit0=In 
DDRD=(0<<DDD7) | (0<<DDD6) | (0<<DDD5) | (0<<DDD4) | (0<<DDD3) | (0<<DDD2) | (1<<DDD1) | (0<<DDD0);
// State: Bit7=T Bit6=T Bit5=T Bit4=T Bit3=T Bit2=T Bit1=T Bit0=T 
PORTD=(0<<PORTD7) | (0<<PORTD6) | (0<<PORTD5) | (0<<PORTD4) | (0<<PORTD3) | (0<<PORTD2) | (0<<PORTD1) | (0<<PORTD0);

Instead of me posting the START way of doing things I created a project and only turned on the USART0 with the same parameters.  I have attached it for your review.  Get some Advil and keep it close

Right Side Jim

Make sure you understand the datasheet of that 324pb. It has some must-know areas. Between the low power crystal and the max current in the reduced number of ground pins on that part, I would recommend against it. It can only handle 100mA to ground, unlike most similar mega (e.g., 324p, 328p, 328pb). The low power crystal has tripped up several people (same on 328pb); look at the new AVR128DB datasheet guidelines for its high-speed crystal; that is also correct for the low power crystal layout.