AVR Freaks

I'm not going to pollute the "Errata" thread with this but you are wrong, this is not a datasheet error so should not be in the "Errata" thread.

iom328p.h has this:

C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr>grep DDB iom328p.h
#define DDB0 0
#define DDB1 1
#define DDB2 2
#define DDB3 3
#define DDB4 4
#define DDB5 5
#define DDB6 6
#define DDB7 7

You include iom328p.h via io.h which has this:

C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr>grep portpins *
io.h:    #include <avr/portpins.h>
io.h:#include <avr/portpins.h>

The portpins.h file has:

/* PORT B */

#if defined(PB0) && !defined(PORTB0)
#  define PORTB0 PB0
#elif defined(PORTB0) && !defined(PB0)
#  define PB0 PORTB0
#endif
#if defined(PB1) && !defined(PORTB1)
#  define PORTB1 PB1
#elif defined(PORTB1) && !defined(PB1)
#  define PB1 PORTB1
#endif
#if defined(PB2) && !defined(PORTB2)
#  define PORTB2 PB2
#elif defined(PORTB2) && !defined(PB2)
#  define PB2 PORTB2
#endif
#if defined(PB3) && !defined(PORTB3)
#  define PORTB3 PB3
#elif defined(PORTB3) && !defined(PB3)
#  define PB3 PORTB3
#endif
#if defined(PB4) && !defined(PORTB4)
#  define PORTB4 PB4
#elif defined(PORTB4) && !defined(PB4)
#  define PB4 PORTB4
#endif
#if defined(PB5) && !defined(PORTB5)
#  define PORTB5 PB5
#elif defined(PORTB5) && !defined(PB5)
#  define PB5 PORTB5
#endif
#if defined(PB6) && !defined(PORTB6)
#  define PORTB6 PB6
#elif defined(PORTB6) && !defined(PB6)
#  define PB6 PORTB6
#endif
#if defined(PB7) && !defined(PORTB7)
#  define PORTB7 PB7
#elif defined(PORTB7) && !defined(PB7)
#  define PB7 PORTB7
#endif

This is a "mop up" file so that if an individual ioXXX.h defines PB3 but not PORTB3 it will define one in terms of the other. Similarly if there is PORTB3 but no PB3 that will be defined.

The fault, if there is a fault here, is that in AVR-LibC there is not an equivalent ddrpins.h that either defines DDRB3 in terms of DDB3 (or for other micros DDB3 in terms of DDRB3).

This is NOT a datasheet error - it's an omission in the C library. Specifically of the avr-gcc C compiler. I imagine other AVR C compilers may well have all these symbols.

(of course what's nice about AVR-LibC is that it is FOSS so anyone is at liberty to open a case in the Bugzilla http://savannah.nongnu.org/bugs/... and provide a suggested solution that the maintainers might consider for inclusion in the next release of AVR-LibC - so if it bothers you - fix it for everyone).

Actually, thinking about it, I guess that because the ioxxx.h are auto-generated from the .atdf file one might say the fault was Atmel/Microchip's but not in the datasheet - in the ATDF to .h conversion program.

But what does "correct" mean ?

The name has no effect on the operation - it's just a more human-friendly way of referring to the bit instead of just by its number & address.

So long as the text is consistent with the table, that's all that matters.

Similarly in the code: the name is just arbitrary - it's the bit number & port address that matter.

Of course, it's very helpful for human readers if the provided headers are consistent with the Datasheet - and convey some meaningful indication of their functions.

It's not that one is "correct" and another is "incorrect"; it's just that they've decided to use different - but equally valid - names.

They could just as well call them Tom, Dick, Harry, etc ...

That would be a lot less helpful, but no more nor less "correct"

The flaw with that, as discussed above, is that there is absolutely nothing that specifically links or constrains DDB5 to DDRB - it's just a '5', and it could be applied to absolutely anywhere that a '5' would be valid.

ie, you could write

DDRA |= (1<<DDB5); 

and that would be perfectly valid, and there is no way for the compiler to detect any problem with that at all.