Odd WGMx constants for ATmega328PB?

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

Hi all,

 

The ATmega328PB has three 16-bit timers: TC1, TC3 and TC4.

Each timer has its own control registers, which include the WGM (Waveform Generation Mode) bits. There are four of these (WGM[3:0]), as specified in Table 20-6 in the datasheet. So far so good.

 

Now, one would expect a standard naming convention for the constants representing these bits, i.e. WGMxy where x is the timer and y is the bit.

That's what we get, for example, for Timer1 in the header file iom328pb.h (comments mine):

#define TCCR1A  _SFR_MEM8(0x80)
#define WGM10   0 // <===
#define WGM11   1 // <===
#define COM1B0  4
#define COM1B1  5
#define COM1A0  6
#define COM1A1  7

#define TCCR1B  _SFR_MEM8(0x81)
#define CS10    0
#define CS11    1
#define CS12    2
#define WGM12   3 // <===
#define WGM13   4 // <===
#define ICES1   6
#define ICNC1   7

 

However, moving along to Timer3 and Timer4, we find that WGM32, WGM42 and WGM43 are not defined at all, while the mysterious WGM44 is defined - value 3. 

 

So... what's going on? Is that just sloppy writing in the header file, or is there a deeper meaning here?

 

Thanks in advance

 

P.S. I did not test any code for these timers yet - maybe I'll get to it later today :-)

 

 

 

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

Yup, we found that too. It's already fixed and will be available in the next released revision.

 

 

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

MannImMond wrote:

Yup, we found that too. It's already fixed and will be available in the next released revision.

 

Ok, thanks.

BTW, I just managed to check, and Timer4 is working fine (at least in CTC mode) smiley

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

I'm using atpack 1.0.91 and there it is defined like this:

#define TCCR1A  _SFR_MEM8(0x80)
#define WGM0    0
#define WGM1    1
#define COMB0   4
#define COMB1   5
#define COMA0   6
#define COMA1   7

#define TCCR1B  _SFR_MEM8(0x81)
#define CS0     0
#define CS1     1
#define CS2     2
#define WGM2    3
#define WGM3    4
#define ICES    6
#define ICNC    7


I assumed that the idea was to use the same defines for TC3 and TC4. I thought that was the new way of doing things. But I see that in 1.0.98 the new "generic" defines are no longer there...

Last Edited: Sat. Apr 30, 2016 - 09:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, the comment/question/response really deal with the vagaries of one particular [infinite vale?] brand of toolchain?  And not the chip itself, or the datasheet?

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:

So, the comment/question/response really deal with the vagaries of one particular [infinite vale?] brand of toolchain?  And not the chip itself, or the datasheet?

 

My original question was about Atmel Studio 7, so yeah, I guess it's one particular brand of toolchain, but a pretty major one smiley

I don't really know what's the "atpack" that ezharkov mentioned above. I only use the default built-in features.

 

The datasheet for the ATmega328PB (from 10/2015) is giving me all kinds of pains: in this case, it doesn't even mention the WMGxy format, only the generic form "WGMy" which is not defined in AS7 when you select ATmega328PB as the target. The datasheet also doesn't mention the existing Power Reduction Register PRR1. I bet there are more issues I haven't discovered yet...

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

What matters here is the XML. What does it say? (I'm not near a PC so cannot check). 

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

What does XML say? Which one? No idea where AS7 XMLs come from, but the ATDFs from packs seem to match the include files. I.e., for example, ATmega328PB.atdf from the 1.0.98 pack has that "mysterious" WGM44.

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

Yup  the ATDF file. The fact is that the compiler headers are generally autogenerated from that XML so it's not really the compiler at fault if it simply inherited what someone typed into the XML. 

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

ezharkov wrote:
What does XML say? Which one? No idea where AS7 XMLs come from, but the ATDFs from packs seem to match the include files. I.e., for example, ATmega328PB.atdf from the 1.0.98 pack has that "mysterious" WGM44.

So it is not the chip; nor the datasheet; nor the toolchain per se; but rather the description file provided by Atmel from whence the chip-include arises.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

In theory, they should all be derived from the chip design ...

 

 

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

"In theory, they should all be derived from the chip design" - I thought so too. And they probably are. Most likely the XML files is not the primary source that defines the "chip design", but rather something that is generated from that primary source, whatever that is. In that case WGM44 is just a bug in that utility that generates the XML files.


"So it is not the chip; nor the datasheet". I definitely hope that WGM44 is not the chip! I'm actually using TC4 and all 4 WGM bits - it seems to work as expected. Regarding the packs vs datasheets. In the datasheet they actually use common bit names for the 3 16-bit timers. The same thing in the 1.0.91 pack. But in the newer 1.0.98 pack they seem to be moving back in the direction of having 3 different sets of defines for the 3 timers.

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

MannImMond wrote:

Yup, we found that too. It's already fixed and will be available in the next released revision.

 

Hmmm, well apparently it's not in the 7.0.934... which also took away the perfectly valid CS40 frown