MegaDB vs MegaDA vs Mega0 ?

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

Greetings Freaks -

 

I'm having a bit of a hard time sorting this out. About 9 months ago, I started prototyping on a new iteration of a product that I make. The prototype uses Mega4809. In that time, the DA series has come out followed by DBs. 

 

When I look at the DA/DB devices, my head spins. Part of this is that I am not even really comfortable with the 4809 yet - can't really make it "sing and dance" like I can with a Mega328. Part, a big part, of the uncertainty is understanding the differences. Numbers of peripherals isn't hard (e.g. number of UART/SPI modules).

 

However, I get the feeling that there is a bit more to differences than this. For example, I am having a hard time figuring out if RTC modules are the "same" or if they handle a 32KHz crystal in the same way. In this context, same means control registers with same names and with control bits in those registers with the same names and functions. Other than going through the documents, page by page, register by register, I don't know how to compare. For example, I have just seen a thread about TWI on a DB (or DA?) device compared to Mega4809; the thread alluded to some register naming differences. 

 

In other words, I can see where one family or device has more or fewer of some peripheral compared to a different family or device. But, at the next level "deeper", I run into problems.

 

So ... I wonder if anyone has a general observation or summary, something a bit more that MattRW's really nice register lists (I like! - Thank You). Something like "DA series is just like Mega4809 except for ... " or "the big difference between DA and DB is ... but watch out for ... ". I'm not looking for a detailed A-B-C comparison, but some general principles. I think that such a summary would also help others who are trying to sort out these new devices.

 

Many thanks, for everyone's help.

 

Jim

http://www.orelectronics.net

 

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

 

 

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

IIRC, the DB can use an External Xtal, the DA can't...

 

For many projects that alone points one in a certain direction.

 

JC

 

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

The DA is not like the last things I tinkered with (m324pb, m328pb). The most recent pain was EEPROM, but some from ADC is lingering. UART was easy, I2C ported from m4809 was easy. Not looked at SPI. Timers are over my head, I ended up looking at DxCore, where I discovered strange ISR vectors (TCA0_HUNF_vect) that work when TCA0 is split into 8-bit timers, and presto, a familiar timer was at hand.

 

https://github.com/SpenceKonde/DxCore/blob/master/megaavr/cores/dxcore/wiring.c#L130

 

TCB and TCD, I can tell, will be interesting.

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

DA DB mega0 are all new core series, you must clear ISR flags yourself now! When an ISR fires. Or the isr will loop forever! An unwelcome carryover from Microchip engineers PIC way of thinking. They do have nice peripherals though. But lots of errata! Read the errata when using those chips.

Last Edited: Wed. Jan 20, 2021 - 04:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My summary would be this: 

The AVR Dx devices are basically the same as megaAVR 0 but with generally more memory, sometimes more pins, and a richer feature set. They are also newer, with in some cases lead to newer versions of the different peripherals.

 

For the feature differences, the main ones to point out would be that the AVR DA has a Peripheral Touch Controller (PTC) with many input channels, while the AVR DB does not have PTC, but has up to 3 integrated opamps with internal resistor networks, high frequency crystal oscillator, and multi-voltage I/O (which I think is really cool).

Other than that, AVR Dx has the same peripherals as megaAVR 0, but generally more instances and sometimes newer versions.

Best regards,
Amund Aune
Applications Engineer @ Microchip Norway
(The postings on this site are my own and don’t necessarily represent Microchip’s positions, strategies, or opinions. For official Microchip Support, please visit https://microchipsupport.force.com/s/)

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


Hi Jim,

 

sounds like we are both in the same situation at the same time.

 

My go-to chips have been the '328, the '1284 if I need more SRAM, and the tiny4313 if I needed a smaller chip. Standardising on those meant I could buy in quantity for production and keep decent amounts in stock (looks like I have over 200 4313s at the moment).

 

For some while I have been mulling over making a change but never really got around to doing something serious about it until now.

 

I really like the AVR core, but for some time have not been happy with what goes around it. Take the '328. 28 pins so a nice size until you look at pins you can't really use...

 

28 pins...

less 4 for power...

less 1 for Aref...

less 1 for reset, yes you can use it for IO but it does rather paint you into a corner...

less 2 for a crystal if you want serial comms, which I always do...

plus restrictions on 3 shared with programming duties...

 

So you're down to 20 pins, 3 of which have restrictions.

 

And don't get me started on debugwire!

 

Over Xmas I came across a back issue of Silicon Chip and an article on the tiny816. In it they made the claim that, bar fewer IO pins, it was actually more powerful than the '328. It got me thinking. So this week has been about datasheet reading, purchasing a few bits, and building stuff...

 

 

A couple of Curiosity Nano boards, used as nEDBG programmer/debuggers, broken out to bare metal chips. LEDs for 'blinky' plus a USART connection to the Nano for serial comms back to the PC via the onboard CDC link. Plenty there to get started with bare metal programming.

 

My thoughts...

 

1) Forget the 4809 and similar. It's a dead-end range.

2) I love the pin compatibility across a given pin size. Need more memory? Drop in a different chip.

3) Peripherals galore.

4) Cheaper

5) More memory

6) Flexible(ish) pin mapping

 

I realised early on that I was over-thinking the comparison. Think of them as a totally different chip that just happens to use your current IDE.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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


BTW, I particularly like that Microchip are now launching well-rounded families...

 

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

12oclocker wrote:
DA DB mega0 are all new core series, you must clear ISR flags yourself now! When an ISR fires. Or the isr will loop forever! An unwelcome carryover from Microchip engineers PIC way of thinking. They do have nice peripherals though. But lots of errata! Read the errata when using those chips.

 

My thought was to attribute the user-must-clear-interrupt-flag attribute to functional safety in the presence of multiple interrupt priorities.  Somehow it seems more robust to have the event flag cleared by the handler.

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

The following needs a grain of salt since my exploring is incomplete at best. On the DA and DB, I can not brick the part with UPDI since UPDI can just erase everything for a redo. I only did that once on a 328p, which is still hanging on the wall waiting for me to set up an HV programmer. It has always concerned me that I could send a board to someone, and they could do that to it, which was one of the things that motivated me to use a bootloader.

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

ron_sutherland wrote:

On the DA and DB, I can not brick the part with UPDI...

 

I too believe that to be the case. Coming out of reset the chip is running on either the 4MHz internal rc or the 32k internal rc. To run on anything else is a software command and the switch only takes place if the new source is actually running.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Brian Fairchild wrote:
Coming out of reset the chip is running on either the 4MHz internal rc or the 32k internal rc.
... and the UPDI PHY oscillator (UPDI auto-bauds)

AVR128DB28/32/48/64 Data Sheet

[bottom of page 566]

37.2.2 Clocks

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

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

Thanks, folks!

 

Do not need op-amps, for sure (99.7% certainty). Pretty sure PTC is not needed (94.63% certainty). 

 

Other than that, AVR Dx has the same peripherals as megaAVR 0, but generally more instances and sometimes newer versions.

Scares me a little, now just slightly familiar with 4809 and the challenge of now learning about small differences that are certain to trip me up. 

 

That said, I like more memory, more pins, more choices, and apple pie! I do get uneasy about TWI and about Bootloader.

 

Guess I need to look at the Dx more carefully. 

 

Thanks, all, and if anyone else has something new to add, please chime in.

 

Jim

 

James Wagner

Oregon Research Electronics

 

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

 

 

Last Edited: Thu. Jan 21, 2021 - 12:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
...I am not even really comfortable with the 4809 yet - can't really make it "sing and dance" like I can with a Mega328...

 

I wonder if some of that is down to the changes in the preferred way to access peripheral registers and how that jars with how we read?

 

Which feels more natural...

 

Quote:

TCA0.SINGLE.CNT = 0x00;

 

...or...

 

Quote:

TCNT0 = 0x00;

 

...?

 

In the first example we have to read, and process, three words to derive the context, in the second just one. Now add in some bit masks...

 

Quote:

TCA0.SINGLE.INTCTRL= (1<<TCA_SINGLE_OVF_bp)+(0<<TCA_SINGLE_CMP0_bp)+(0<<TCA_SINGLE_CMP1_bp)+(0<<TCA_SINGLE_CMP2_bp);

 

Quote:

TCCR0A=(1<<COM0A1) | (0<<COM0A0) | (0<<COM0B1) | (0<<COM0B0) | (1<<WGM01) | (1<<WGM00);

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

That does not bother me. It is the difference in timer peripheral architecture, have not got my head around double-buffered UART, the different TWI structure, the differences in what timers can and can't do and how you control them, the pin multiplexing and the event system, the differences in the clock system - all that great new stuff that takes new learning.

 

Jim

 

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

 

 

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

I like more memory

Except...  The 4809 about maxed out the program memory that could fit in the same 16bit address space as RAM and all of the peripherals.

That's no longer the case with the DA and DB chips with more memory, so accessing flash and eeprom gets more complicated. :-(

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

Timer summary...

 

TCA - it's all about the outputs, and PWM ones at that

TCB - it's all about the inputs, measuring them and timing them

TCD - it's all about power, bridges and dead-bands

 

(Yes I know that they can all do other things but those are clearly the areas aimed at.)

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

westfw wrote:
The 4809 about maxed out the program memory that could fit in the same 16bit address space as RAM and all of the peripherals.

That's no longer the case with the DA and DB chips with more memory, so accessing flash and eeprom gets more complicated. :-( 

When you get to the point of fighting architectural limitations like this, I feel it may be time to consider a different architecture ...

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

westfw wrote:

Except...  The 4809 about maxed out the program memory that could fit in the same 16bit address space as RAM and all of the peripherals.

That's no longer the case with the DA and DB chips with more memory, so accessing flash and eeprom gets more complicated. :-(

 

This. If you want to save that extra bit of memory for constants, PROGMEM is back. Except for the Dx with 32k flash, those can still fit constants in the flat address space without PROGMEM.

And yes, using EEPROM will be a problem, current avr-libc libraries are not compatible with the Dx series yet, AFAIK. There was this recent thread mentioning this problem... here it is https://www.avrfreaks.net/forum/...

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

@Jim,

 

I'm in a similar situation except I never got as far at the 4809 series. The timelines of current and future products never matched up with the release. I too have been trying to get to grips with the differences between 'classic' and 'new' peripherals. Over the last couple of days I have realised...

 

1) I am over-thinking it

2) Anything a classic peripheral can do a new peripheral can do, and more besides as I learn them

3) Given 2) I don't need to know how every peripheral works in detail.

4) A typical product uses maybe 25% of the peripherals of a chosen chip

4) Given 3) and 4) I only need to understand a peripheral when I want to use it

5) As I need to use a new peripheral I am going to write an 'interface layer' to use it.

 

I haven't yet decided on the overall look of my interface layer but it'll take one of these forms...

 

*) void init_usart0_baud_9600 (void)

*) void init_usart0 (9600_8N1)

*) void init_usart_0 (uint16_t baud, uint8_t bits, uint8_t parity, uint8_t stop)

*) void init_usart ( uint8_t usart, uint16_t baud, uint8_t bits, uint8_t parity, uint8_t stop)

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

now that it seems that they got the external xtal osc to work on the new(er) setup perhaps they will start make real 324p and 328p (ikke pb versionerne).

 

 

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


...and going back to comparing the DA with the 4809 and trying to find changes without ploughing through the datasheets. How about doing a DIFF on the headers. For example, the RTC module...

 

 

...so no material changes here, just a few style tweaks. And the actual bits...

 

...nope, still the same. Just a few additions to the DA...

 

 

So now we only need to check out the error correction function of the RTC in the DA series.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

sparrow2 wrote:

now that it seems that they got the external xtal osc to work on the new(er) setup perhaps they will start make real 324p and 328p (ikke pb versionerne).

 

Why? The new chips will everything the old chips will do.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

My big problem is still that registers aren't memory mapped. I don't need more but was hoping for cheaper. (but perhaps the chips are pad limited).

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

>On the DA and DB, I can not brick the part with UPDI

 

The mega0 also has a dedicated updi pin. When you get up in pin count, may as well.

 

>This. If you want to save that extra bit of memory for constants, PROGMEM is back. Except for the Dx with 32k flash, those can still fit constants in the flat address space without PROGMEM.

 

There is a simple solution to the above 'problem' if you will never use more than ~32k (less vector table size) of const data- move the .rodata section to just after .vectors (basically the .progmem location, which is not used/needed). Normally, .rodata is located after the end of code which is a moving target and could end up in any 32k segment which means using __memx to access it (and the resulting 24bit setup/function call every read of a const). But if using const like avr0/1 it will end up in .rodata which will then be in the first 32k where it is already data mapped by default and the compiler will produce access to these 16bit data mapped flash addresses like the avr0/1. At least that is what I would do, and I think is a good solution for most cases. I wouldn't otherwise want to deal with const data in a __memx way or anything that requires something other than a simple 'const' use.

 

The eeprom read/write can also become simple with another linker script change. The resulting use would just require enabling/disabling ee erase/write before/after use-

EEMEM char eevar = 1;

int main(){

  eeUnlock();

  eevar++;

  eeLock();

}

 

The 8bit mcu gets less interesting when you run out of address space.

 

 

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

Yeah, moving .rodata seems to be a decent workaround. Regarding EEPROM, I'll just take your word it works.

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

I've started playing around with the 4808 1-2 months ago, and the AVR128DB32 a few days ago. They're very similar or the same regarding the registers I use (e.g. sleep).

 

The main difference why I won't design any more 4808 circuits is that on the AVR128DB32 the clock speed can be 24MHz at 1.8V, and it has a builtin level shifter (MVIO). MVIO can also be used to measure battery voltage without a voltage divider. At least if the battery voltage isn't higher than 5.5V. Though the 4808 can also measure voltage up to 4.3V without a voltage divider.

Last Edited: Thu. Jan 21, 2021 - 09:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Miraculix wrote:
I wonder why no one mentioned MVIO yet.

 

It was bait... ha.. welcome.

 

 

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

>Though the 4808 can also measure voltage up to 4.3V without a voltage divider.

 

Then you are doing something wrong. You set the adc reference to vdd and measure the fixed vref voltage (1v1). The only requirement is vdd has to be greater than the vref voltage. The known voltage is somewhere below vdd, and the adc value tells you where vdd has to be. If the adc value is exactly at the halfway mark (512), and the known voltage being measured is 1.10v, that means vdd must be double (~2.20v) because you know the halfway point is 1.10v.

 

Using 1v1 as the vref voltage, as there is no reason not to and covers down to the mcu minimum of 1.8v, you get a range of adc values from 625/1.80v to 204/5.50v with enough resolution to get buried in rest of the errors that will be present.

 

Vdd*100 = 1023*Vbg*100 / adcval

Vdd*100 = 1023*1.1*100 / 625 = 180 = 1.80v

Vdd*100 = 1023*1.1*100 / 204 = 551 = 5.51v

 

edit- maybe I misunderstood and the battery to be measured is not vdd, but you can still measure up to vdd after you determine what vdd is using the vref (or battery connected to vrefa pin). 

 

Last Edited: Fri. Jan 22, 2021 - 01:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:
Which feels more natural...
I fear you may be biasing the jury? Surely in this:

Brian Fairchild wrote:

Quote:

TCA0.SINGLE.INTCTRL= (1<<TCA_SINGLE_OVF_bp)+(0<<TCA_SINGLE_CMP0_bp)+(0<<TCA_SINGLE_CMP1_bp)+(0<<TCA_SINGLE_CMP2_bp);

Quote:

TCCR0A=(1<<COM0A1) | (0<<COM0A0) | (0<<COM0B1) | (0<<COM0B0) | (1<<WGM01) | (1<<WGM00);

one further point of the "new headers" is that there aren't just _bp's (bit "positions" which now probably will almost never be used) but there are _bm's (bit "masks") which are far preferable as they already encompass the (1 << n) in the definition. So it's really:

TCA0.SINGLE.INTCTRL= TCA_SINGLE_OVF_bm;

Also is the "three part name" really such a bad thing anyway? It very specifically identifies the target to the reader. It's a bit like C versus C++. In C I might have some anonymous looking code:

rate = 120;

where "rate" could be just about anything. Whereas the equivalent in C++ (or even just well structured C using struct{} heavily) might be:

Synth.Arpeggiator.rate = 120;

which tells the reader a whole lot more about where this anonymous "120" is really going.

 

Perhaps folks are afraid of typing? (but modern IDEs will auto-complete most of this stuff for you as you type anyway)

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

clawson wrote:

...Also is the "three part name" really such a bad thing anyway?..

 

Not on it's own. Although it looks very clumsy in ALL CAPS.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

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

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

What a hack, they use old mega32 etc as reference and not 324 or 328 so the naming reference will be convert from mega328 to mega32  so you have a change to find out what the name would be on the newer chips.

 

I guess :

Why make it hard to use, when you can make it useless 

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

Thank you for the explanation.

 

But yes, typically VDD is not the same as battery voltage in my circuits, as I'm using MCP1700 voltage regulators. Though that may change with the AVR128DB32, as I'll probably start building circuits without voltage regulators around 2 AA batteries, to power MCU, NRF24L01+ and sensors.

Last Edited: Fri. Jan 22, 2021 - 04:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Miraculix wrote:
... as I'll probably start building circuits around 2 AA batteries, ... Just not sure how I'll deal with sensors requiring 3.3V yet.
2S NiZn cells would cover that range (2.6V approx 100% DoD .. 3.2V nominal .. 3.8V CV) though has some discharge.

AVR DB's op amp has reasonable PSRR.

 

P.S.

Miraculix wrote:
... AVR128DB32 ...
Am thankful AVR12DB28 can be in PDIP.

 


AVR128DB32 - 8-bit Microcontrollers

Conrad energy HR06 AA battery (rechargeable) NiZn 1500 mAh 1.6 V 4 pc(s) | Conrad.com

OPAMP Specifications | AVR® DB Family

 

edit : crossed paths wink

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

Last Edited: Fri. Jan 22, 2021 - 04:37 PM