AVR families overview

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

Can anyone point me to a good overview of what AVR families are available from a peripheral compatibility perspective (i.e. the SFRs that make up a peripheral use a standard in memory layout)?

 

When I took a look at the 8-bit AVR® MCUs page about 9 months ago, it simply stated that there are the tinyAVR, megaAVR, and XMEGA families which glossed over things like the differences between "classic" megaAVRs and the 0-series. Now it just lists "Featured AVR MCU Families". I did find the AVR® Microcontrollers Peripheral Integration PDF but it seems like this breakdown is excessive for my purpose since the ATmega328P, ATmega32U4, and ATmega2560 peripherals are (largely?) compatible.

github.com/apcountryman/build-avr-gcc: a script for building avr-gcc

github.com/apcountryman/toolchain-avr-gcc: a CMake toolchain for cross compiling for the Atmel AVR family of microcontrollers

github.com/apcountryman/avr-libcpp: a partial implementation of the C++ standard library (C++17 only) for use with avr-gcc/avr-libc

github.com/apcountryman/picolibrary: a C++ microcontroller driver/utility library targeted for use with resource constrained microcontrollers

github.com/apcountryman/picolibrary-microchip-megaavr: picolibrary Hardware Interface Layer (HIL) for Microchip megaAVR microcontrollers

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


apcountryman wrote:
Can anyone point me to a good overview of what AVR families are available from a peripheral compatibility perspective (i.e. the SFRs that make up a peripheral use a standard in memory layout)?
maybe

AVR® Dx Additional Features | I/O Ports and Pinouts | Common Peripherals | Migration from the megaAVR® to AVR® Dx Microcontroller Families

apcountryman wrote:
... the differences between "classic" megaAVRs and the 0-series.
The AVR computer architectures :

Instruction Set Summary | AVR® Instruction Set Manual

...

...

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

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

Register layout, register names, bit layout and names are, for classic AVRs, more often different than same, seems to me.

 

The "new AVRs" (AVR0, AVR1, Tiny0, Tiny1, etc) are very similar. Registers mostly have the same names, bit names are consistent, mostly, and the locations (and function) are consistent, mostly.

 

HOWEVER, the header files tend to handle all those names and locations for you. What the header files DO NOT DO is to provide you with a clue about how they operate. 

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Yeah, I get what you're looking for.  It's less about the CPU, and more about which chips have USI vs "traditional register" I2C/SPI/UART/USART vs "xMega structure-based", and which Timers are more like/unlike other timers, and so on.

 

It LOOKS like Microchip is being much more careful about this in the newer chips (Mega0, Tiny0/1/2, etc) with their "Timer/Counter Type A/B/D" and similar, but I think the older chips are a bit of a mess.  ("An ATmega88 USART is MOSTLY (but not entirely) like an ATmega8 USART.")

I don't know of any such document.  I've often wondered just how many different types of timer are in existence.  Of all the peripherals I've seen, they seem to have the widest variety within and between vendors.

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

Until a design upgrade became necessary, I stuck with the M48/88/168/328 family. Peripherals are pretty much identical with a few changes going from non-P to P (PicoPower) versions and the to the PA version (only M328?) that adds a second UART and maybe a few other minor things. 

 

That has allowed me the time to learn the peripherals, the clock system, power management, and such. I would have been totally lost mucking around with more than one peripheral set. I simply do not have the mental inclination to tackle that. Or, the mental capacity!

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

westfw wrote:

It's less about the CPU, and more about which chips have USI vs "traditional register" I2C/SPI/UART/USART vs "xMega structure-based", and which Timers are more like/unlike other timers, and so on.

 

Exactly. At this point I'm just trying to identify and name the "families" for which at least a decent subset of the peripherals (such as the GPIO, USART, SPI, and TWI peripherals) are largely standardized. I had hoped that I would only need to use code generation to name and place instances of the "family" specific peripheral abstraction classes that I'm creating (e.g. the ATmega2560 has an instances of the megaAVR USART class named USART0, USART1, USART2, and USART3 located at 0x00C0, 0x00C8, 0x00D0, and 0x0130), but it looks like I may need to use code generation to create chip specific versions of the classes.

github.com/apcountryman/build-avr-gcc: a script for building avr-gcc

github.com/apcountryman/toolchain-avr-gcc: a CMake toolchain for cross compiling for the Atmel AVR family of microcontrollers

github.com/apcountryman/avr-libcpp: a partial implementation of the C++ standard library (C++17 only) for use with avr-gcc/avr-libc

github.com/apcountryman/picolibrary: a C++ microcontroller driver/utility library targeted for use with resource constrained microcontrollers

github.com/apcountryman/picolibrary-microchip-megaavr: picolibrary Hardware Interface Layer (HIL) for Microchip megaAVR microcontrollers

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

apcountryman wrote:
the "families" for which at least a decent subset of the peripherals (such as the GPIO, USART, SPI, and TWI peripherals) are largely standardized.
Yoiu will look long and hard - such standardization does not really exist. If you take "old school" mega AVRs then sure mega48/88/168/328 form a kind of "family" where pretty much everything is equal but even this has exceptions (the mega48 is not big enough to have bootloader support for example). Another "family" is made up by mega164P/mega324P/mega644P/mega1284P. If you develop code for one of these it should work on all four. I guess mega16/mega32 are very similar to each other too. Same for mega64/mega128. Also the mega1280/1281/2560/2561 could be considered a "group" too.

 

When Atmel brought out the Xmega range (starting with ATxmega128a1) they did folks a kind of favour as all the early Xmegas were homogenous. They all had the same set of peripherals at the same IO addresses with the same structure and all that differed between Xmega-A, Xmega-B, Xmega-C, Xmega-D were which subset of the peripherals were actually populated. In theory that means that if you wrote code to support UART0 on one of them it would work for UART0 on all and, because all Xmega UARTs use the same register block the same code could be used for UART1, UART2, UART3 etc simply by adjusting the base address of the structure that defined the register block.

 

But then things started to go wrong when Atmel brought out Xmega-E. You might think that after A, B, C and D that E would just be "more of the same" but this had a quite different layout and set of peripherals so it kind of broke the mould.

 

Since Microchip have taken over all recent chips release have basically been Xmega's (with some bits of A/B/C/D and some of E and some new stuff). For reasons no one on earth can probably explain they decided to call these things "tiny" and "mega" when they are really all Xmega derivatives. There have been a number of ranges like AVR-0, AVR-1, AVR-Dx and so on. Each bring different things to the party.

 

So the idea of having a common codebase that could simply adapt to any "family" is something of a pipe-dream. You really need to look at the proposed application then pick a device/family to match and then you may be able to trade up/down flash size within that family but that is about it.

 

In terms of "bang for buck" the ranges just seem to keep getting better and better. The AVR-D's are probably the current "sweet spot" and maybe worth considering first. HOWEVER they are "new silicon" and it often takes a few years for all the problems to be ironed out (if anyone adopted the Xmega when the atxmega128A1 first appeared) will know just how bad some chip ranges can be at first. Thankfully within a couple of years 128A1 was removed from the market an replaced by 128A1U.

 

If you want a bit more stability then perhaps fall back from AVR-Dx to AVR-0/AVR-1 which have had more time to stabilize.

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

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

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

clawson wrote:
Thankfully within a couple of years 128A1 was removed from the market an replaced by 128A1U.
It's NRND; there's a bit of XMEGA EOL (removal of some 105C)

 

ATxmega128A1 - 8-bit AVR Microcontrollers

LIAL-04MITI054 | Product Change Notification | Microchip due to How to search for Microchip PCNs (enter XMEGA, select EOL in the pulldown)

 

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