ATmega328P Datasheet may show an error on DDRB register bit names ?

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


On page 117 of my ATmega328P datasheet the document clearly show the DDRB register with its corresponding bit names: DDRB7...DDRB0

Yet, when I input a code line in Studio7 , I get an indication that DDRB1 is not a valid constant name.

    DDRB   |= (1 << DDRB1) ; // an underscore appear on DDRB1
    DDRB   |= (1 <<  DDB1) ; // instead DDB1 seems to be the correct name

Also, if I open the DDRB file with "Goto Implementation" feature of Studio7, I find that , indeed, the iom328p.h file open and show the correct name for all DDRB bits are "DDB1"

So, I have to conclude that the Microchip Datasheet for the ATmega328P is wrong.

 

Is that a correct assumption ?

Or is the iom328p.h file wrong ?

 

 

This topic has a solution.
Last Edited: Mon. Oct 18, 2021 - 10:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Perhaps a reason to report in link

AVR Errata - Unpublished, and other "Gotchas"

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Forget the red squiggly thing (often wrong). The big question is "does the code compile without build errors". If it does, ignore the eye candy. 

 

BTW what's the appeal of something like (1 << DDRB3) anyway? Isn't (1 << 3) just clearer and easier to read? 

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

Ha Ha - If we look at a different processor (let's take the next in numeric sequence -> iom329p.h ) we find:

#define DDRB    _SFR_IO8(0x04)
#define DDRB7   7
// Inserted "DDB7" from "DDRB7" due to compatibility
#define DDB7    7

So "DDRB7" was always there but "DDB7" was added for compatibility (with what - who knows).

 

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

Great observation clawson. Point well taken.

My first thought is that this comment is likely from an expert view.

We beginners, tend to emphasize on details for it is a prerequisite to become an expert.

 

Mind you, DDRB |= 8 ; could also do the job,

as well as DDRB |= 0b00001000 ;

 

DDRB |= (1 << DDB3 ) ;  is the way it is shown in the Datasheet page 100.

Page 117 shows otherwise. Since I am following the Datasheet code like a parrot (beginner),

when an error is choking from Studio7 then I have to find the bottom of the story so that one day I become an expert too. enlightened

 

Thanks to www.avrfreaks.net I can clarify all those interrogations along my tedious journey to, perhaps,  become an expert one day. smiley

 

Last Edited: Mon. Oct 18, 2021 - 10:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:
So "DDRB7" was always there but "DDB7" was added for compatibility (with what - who knows).

I for fun just checked my (probably antique) mega 48/88/168 datasheet and there they also use DDB. as the mega328 is a logical successor to that might be that they started from this datasheet and made the 328 datasheet from that.

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

On page 117 of my ATmega328P datasheet the document clearly show the DDRB register with its corresponding bit names: DDRB7...DDRB0

Are you sure you're not looking at an ATmega328PB datasheet?

The latest ATmega328P datasheet I can find (as well as previous versions) has DDBn in the register descriptions,

while the latest ATmega328PB datasheet has DDRBn

Make sure you're using the right datasheet because there are other significant differences between the two chips.  (Why Atmel switched names, I have no idea.  I think the idea of having unique bit names for individual port bits is sort-of weird anyway (though people will point out search/cref/etc advantages.)  I also don't know why Atmel made such a small part number change for such major changing to a chip.  Sigh.)

 

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

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).

Last Edited: Tue. Oct 19, 2021 - 10:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
BTW what's the appeal of something like (1 << DDRB3) anyway? Isn't (1 << 3) just clearer and easier to read? 

+1

 

This has come up a few times recently.

 

eg, https://www.avrfreaks.net/commen...

 

EDIT

 

More recently, this is the one I was actually thinking of:

 

https://www.avrfreaks.net/commen...

in which I wrote:
They are actually pretty pointless - you might as well just give the register name, and 5.

 

In fact, they could be considered unhelpful in that (as here) they mislead people into thinking that they are somehow "special".

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Oct 19, 2021 - 09:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

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

 

westfw, funny enough, I just downloaded a new datasheet for the ATmega328P and found that the available version on Microchip website is 1 year earlier then the one I have in my computer. And, the DDRB register bits are called the correct name DDB.

 

Obtained year ago               - DDRB7. . .DDRB0:    Atmel-42735B-ATmega328/P_Datasheet_Complete-11/2016                            (2016 ) incorrect

 

Obtained from the web on Oct 2021 - DDB7  . . .  DDB0: ATmega328P [DATASHEET] 7810D–AVR–01/15                                    (2015 !!! )   correct

 

Obtained 10 minutes later Oct 2021 - DDB7  . . .  DDB0: 2020 Microchip Technology Inc. Data Sheet Complete DS40002061B-page 100 ( 2020 ) correct

 

Furthermore, on page 61 of the 2015 version the name DDB0 is utilized, yet on page 100 of the 2016 version Atmel also utilized the DDB0 naming. Go figure.

 

All document titles are clearly showing ATmega328P.

Last Edited: Tue. Oct 19, 2021 - 05:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

FredCailloux wrote:
the DDRB register bits are called the correct (sic) name DDB.

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"

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Oct 19, 2021 - 04:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

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

Not to be a contrarian but i'd like to mention one very interesting usage of the naming of register bits.

Say you run a long code and you are searching for this line where you know you are using DDB5 bit from the DDRB register.

With a code line like DDRB |= (1<<DDB5);  you can just search the code text for "DDB5" and quickly find the interesting line.

Try doing that with DDRB |=(1<<5).

 

Of course one can argue that you can always do the text search with "DDRB" and find the register name instead of the bit name.

 

I guess its just a question of preference.

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

a far better approach would be to give it a name which reflects your usage; eg, LED_PIN_NUMBER - rather than just the "raw" pin & port names

 

Then, if you want to move the LED pin, you just change the definition of LED_PIN_NUMBER

 

For example:

// The ATmega328P-Xplained-Mini User LED (LED0) is on PB5
#define LED0_PIN_NUM    5
#define LED0_PIN_REG    PINB
#define LED0_PORT       PORTB
#define LED0_DDR        DDRB

// Make the LED pin an output
LED0_DDR = ( 1 < <LED_PIN_NUM ); 

// Toggle the LED state
LED0_PIN_REG = ( 1 < <LED_PIN_NUM ); 

 

EDIT

 

See also in the previously-linked thread: https://www.avrfreaks.net/commen...

 

EDIT 2

 

I just noticed that in mt  text, I wrote "LED_PIN_NUMBER", but in the code example, I put "LED_PIN_NUM" - so which one of them is "right", and which is "wrong" ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Oct 19, 2021 - 05:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FredCailloux wrote:
you can just search the code text for "DDB5"

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.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Here's some more different notations for the bits in an ATmega328P register - where those bits don't have any particular function other than being the nth bit in that register:

 

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...