megaAVR 0-Series ATMEGA4809 and ATMEGA4808 makes me feel like I am starting over - Page 1
Forum section: electronics / general

author: rx8pilot
author_rank: Super Contributor
timestamp: September 13, 2019, 02:30:30 am
content: I designed a dev PCB with the new-ish ATMEGA4809 8bit AVR MCU. The specs and new features look pretty nice, but I totally underestimated how much the new architecture would impact firmware development. I have completed many dozens of ATMEGA projects over the past 5-6 years and compiled a lot of easily re-usable code. This new MCU has a very different way of handling peripherals and the required code is totally different.The first challenge I am trying to get through is a TWI / I2C driver and then move onto the ADC's. I have spent a day so far on the I2C and that is really only enough for me to have learned I need to start from scratch.Is anyone aware of some app notes, examples, videos, or libraries to help get I2C Master implemented on the ATMEGA4808 0-Series? This MCU can only be awesome if I can program it, lol.

author: magic
author_rank: Super Contributor
timestamp: September 13, 2019, 07:00:47 am
content: Seems related to ATtiny 1-series and a lot of the tech inside of them is supposedly borrowed from the Xmega line. Maybe this will be of some help.Sorry, can't say much more. I have bought a few for the new features but haven't used them yet.

author: westfw
author_rank: Super Contributor
timestamp: September 13, 2019, 07:14:47 am
content: Heh. Well, there's the Arduino code (which seems to have been written by Microchip (Atmel?)):https://github.com/arduino/ArduinoCore-megaavr/blob/master/libraries/Wire/src/utility/twi.cI've been doing stuff with the UART. It's not THAT different, aside from the whole structure-based access. (Though the things I'm doing with the UART are much simpler than I2C tends to be...)The NVM Controller is pretty sweet, compared to the things you had to do for the same goals on an old AVR.

author: richardman
author_rank: Frequent Contributor
timestamp: September 13, 2019, 09:08:07 am
content: It's similar to the XMega's, unfortunately the XMega is not as popular as it could be, so....

author: iMo
author_rank: Super Contributor
timestamp: September 13, 2019, 12:00:56 pm
content: Who is the targeted audience with this new series?

author: magic
author_rank: Super Contributor
timestamp: September 13, 2019, 02:29:17 pm
content: <tinfoil hat mode ON>Maybe they started to sell Xmegas under the old brands to slowly migrate everybody onto XmegasTruth be told, at least on paper, these new models appear to be superior chips. More peripherals, one pin programming interface realized with UART, memory-mapped flash, the event system...And they even tend to be cheaper, like the 8-pin ATtiny212 which beats the old ATtiny13A on price and specs.One obvious disadvantage is more registers which means few useful ones are accessible in 1 clock cycle anymore.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 13, 2019, 02:45:35 pm
content: Quote from: magic on September 13, 2019, 02:29:17 pmWell, compared to the older models, yes. But outside of this context, "superior chips" would be a bit of a stretch.

author: rx8pilot
author_rank: Super Contributor
timestamp: September 13, 2019, 03:28:51 pm
content: Quote from: magic on September 13, 2019, 02:29:17 pmI feel that they are hoping to avoid scaring customers with a new name, although these new chips are really a new family and should be treated as such.Relative to the older ATMEGAS, they are definitely superior. Lot's of welcome improvements, but sadly at the cost of having to refactor code after going through the initial learning curve that was not immediately obvious. I should have looked closer for sure while I was initially choosing these, but in the end, I think the new features will outweigh the code updates.The price is definitely nice on these. My first project is fairly priced sensitive so that is a bonus, but really I chose it for the apparent improvements in real-time control I am expecting with the control independent peripherals . That feature will offload some pressure for me to have super-tight code to accomplish time-sensitive tasks.Anyway....guessing I will spend the next couple of days becoming friends with these little chips. I need solid I2C, ADC, and UART modules right off the bat. Everything else can be learned as needed. Surprised how little information there is after a year on the market. I was quite spoiled with the massive resources for developing the older ATMEGA AVR's. It was so easy to find discussions and examples for just about anything.

author: rx8pilot
author_rank: Super Contributor
timestamp: September 13, 2019, 03:33:14 pm
content: Quote from: SiliconWizard on September 13, 2019, 02:45:35 pmPerhaps excellent bang for the buck is a good way to describe these. They are cheap.

author: magic
author_rank: Super Contributor
timestamp: September 13, 2019, 03:51:54 pm
content: It also appears that ARM has nothing to offer in SOIC8 or SOT23, if that's your thing.As I said before, they are supposedly derived from Xmegas. So perhaps you can find some info/examples for those, and compare if it matches the datasheet of the new parts.Disclaimer: I have never even read anything about Xmegas, let alone program one

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 13, 2019, 04:02:46 pm
content: Quote from: magic on September 13, 2019, 03:51:54 pmOh, you would think that...https://www.cypress.com/part/cy8c4014sxi-420tAnd there are of course other lines of MCUs such as the PIC10F/12F.

author: up8051
author_rank: Frequent Contributor
timestamp: September 13, 2019, 06:42:30 pm
content: Cypress chips are rather expensive:Cypress Cy8C4014SXI 2,16$Microchip ATTINY402 0,41$

author: lucazader
author_rank: Regular Contributor
timestamp: September 14, 2019, 12:59:40 am
content: ST has some new much smaller packages in their new G0 lineup.Like the STM32G030J6 can be had for about $0.40 in volume and is an 8 pin soic package. (https://www.digikey.com/product-detail/en/stmicroelectronics/STM32G030J6M6/STM32G030J6M6-ND/10326687)Admittedly this is a very new part, and until more recently there have been very limited choices for very small pin count ARM based micros.I think this is going to change over the next little while as chip makers move production to smaller process nodes, enabling smaller cheaper processor die's for parts like the above.Also while the CY8C4014 migth be expensive. the CY8C4013 is much more affordable.$0.24 in single quantity on digikey (https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/CY8C4013SXI-410/2015-CY8C4013SXI-410-ND/9771769)

author: rx8pilot
author_rank: Super Contributor
timestamp: September 14, 2019, 03:20:04 am
content: I managed to get enough guidance from the online tool Atmel START:https://start.atmel.com/#dashboardAt first, I thought it was a gimmick, but it actually helped me build examples based on the device I have and the application. The code generated is a bit thick but every line is commented so I could easily follow and adapt it to what I was after. I am not a top-notch coder since I only code about 15% of my productive time - so this boost was a welcome time saver.

author: RES
author_rank: Regular Contributor
timestamp: September 14, 2019, 07:47:19 am
content: https://www.avrfreaks.net/forum/atmega4809-twi

author: magic
author_rank: Super Contributor
timestamp: September 14, 2019, 08:05:21 am
content: The STM32G0 looks like a viable upgrade indeed, with 32 bit core and more MHz. I wonder how it stacks up against AVRs in terms of I/O access latency? Can it run the peripherals at full 64MHz speed? How many clocks to set a pin or read some peripheral register?AFAIK a programming dongle is required to get anything done on STMs?Is there any equivalent of AVR's event system in the ARM world? Some things I would like to do and I believe can be done by the new AVRs:- sample and synchronize an external signal to the system clock, distribute it to multiple peripherals, guarantee arrival in the same clock cycle- distribute a strobe to multiple peripherals to perform actions simultaneously, like atomically capture the counts of multiple timers- cascade arbitrary number of timers, schedule input capture on timer A by timer B

author: jhpadjustable
author_rank: Frequent Contributor
timestamp: September 14, 2019, 10:35:11 pm
content: Quote from: magic on September 14, 2019, 08:05:21 amAny SWD pod would surely do. But STLink v2 clones are $2 on Aliexpress. AFAIK all STM32 chips have a bootloader in ROM that can accept commands to erase/program/verify/lock over async serial and usually other available interfaces.QuoteThe timers and peripherals in the ARM MCU world vary somewhat by vendor. Cypress' ARM PSoC 4100/4200 series appear to have extensive core independence and versatile internal signal routing. Some of them have FPGA-like logic blocks. I'm pretty sure your examples would be straightforward. ST's timers are complex in themselves and decently automatable, but the interface with the rest of the system is pretty traditional. Some of your examples might be possible, with caveats.

author: westfw
author_rank: Super Contributor
timestamp: September 15, 2019, 12:31:41 am
content: QuoteWell, the Atmel (Microchip) SAMD series have what looks to be the SAME event system as the new AVRs...Packages as small as SO14, and down around the $1 mark.

author: magic
author_rank: Super Contributor
timestamp: September 15, 2019, 01:29:48 pm
content: Very similar and more or less functionally equivalent though not exactly identical.Atmel clearly never cared about making their peripherals consistent between different MCU families

author: Kleinstein
author_rank: Super Contributor
timestamp: September 15, 2019, 03:11:59 pm
content: There are some natural differences between a 8 bit and 32 bit CPU. So things have to be different in some places (e.g. no extra buffer registers for atomic access needed with the ARM). Also the internal timing / maximum clock is different.I have not used the old Xmega series, but AFAIR the periphery was also more ARM like than like the old AVRs.Still the ADC is back to 10 Bits and maximum supply voltage to 5 V.

author: magic
author_rank: Super Contributor
timestamp: September 15, 2019, 07:00:02 pm
content: Quote from: westfw on September 13, 2019, 07:14:47 amI just stumbled upon this Arduino library too and realized it's the one you already linked. Their repo also has a driver for SPI.Apparently there are already a few Arduino boards using new AVRs. I guess this answers the question who is going to buy those chips. The Arduino crowd won't even notice a difference, unless they do but then it's too lateQuote from: Kleinstein on September 15, 2019, 03:11:59 pmOf course, but we are talking completely different peripherals with different feature sets and everything, not just small tweaks.

author: MarkR42
author_rank: Regular Contributor
timestamp: September 15, 2019, 09:38:29 pm
content: It seems that the atmega 4809 is available in a PDIP-40 package, old-school. Everything else in the range (and most others) is surface mount.The megaavr 0-series are a lot like the attiny 1-series which have been around a bit longer,https://jaycarlson.net/pf/atmel-microchip-tinyavr-1-series/I've been using the attiny1614 and its peripherals are very similar (there are slightly fewer of everything, but it's much the same).There are some useful examples of the attiny1614 herehttps://github.com/chromia/attiny1614examplewhich probably work unmodified or with few changes on the mega 4809.I'm most enjoying the way that they seem to have managed to standardise the peripherals on these new lines of MCUs, they're much more consistent and predictable than the older ones, every (enable-able) device has an enable bit, in its CTRLA register.I use the toolchainhttps://github.com/vladbelous/tinyAVR_gcc_setupbut I tried the atmel studio too, that's ok.Also the updi programming interface (just 1 wire!) is nicer than the thing that arduino etc use (3 wires?) - and the reset pin is not required for normal programming.

author: westfw
author_rank: Super Contributor
timestamp: September 16, 2019, 02:00:23 am
content: QuoteThey're cheap. The ATmega4809 looks to be the cheapest 40-pin DIP AVR you can get, at normal prices (Mouser, q1)(Digikey seems to be having a sale on m164 and m324...) And it's generally more powerful, too.And the 8-pin ATtiny4x2 chips put the existing low-end 8bit chips to shame. 4x the memory of an ATtiny13, and it's got peripherals, and it's half the price. About 1/3 the price of the ATtiny85 (which still doesn't have a UART or real I2C.)

author: amyk
author_rank: Super Contributor
timestamp: September 16, 2019, 02:50:55 am
content: That new Atmel logo still puts me off every time I see it on their parts... looks more like a cheap Chinese brand than the "serious" logo they had before:

author: techman-001
author_rank: Frequent Contributor
timestamp: September 16, 2019, 03:20:37 am
content: Quote from: westfw on September 16, 2019, 02:00:23 amI prefer my 40 pin 32 bit STM32 for $0.95 instead of a 8 bit ATmega4809 for $3.49

author: westfw
author_rank: Super Contributor
timestamp: September 16, 2019, 10:08:08 am
content: Where did you see 3.49? I see about $2.30 for the DIP, and $1.60 for Qfn or lqfp.But yeah, they’re just barely competitive with the low end cm0 chips...I wonder why the stm32f0xx chips haven’t shown up in any populat hobbyist form, yet...

author: techman-001
author_rank: Frequent Contributor
timestamp: September 16, 2019, 12:01:36 pm
content: Quote from: westfw on September 16, 2019, 10:08:08 amIt was a Google search for Mouser and ATmega4809 in 40 pin DIP from Australia, and the price was taken from the Mouser web site. I think they add extra for OZ. I should have stated $AUD, apologies.Perhaps stm32f0xx were never popular with hobbyists because Arduino is a Atmel shop ?Plus the ST free software development collection was a nightmare of broken complexity. I remember trying to create a Blinky with it in 2014 and failed utterly. I didn't remember C being that hard and complex after a 10 year hiatus from embedded. It was enough to drive a person to Forth!So STM32F0xx is hard, Arduino easy, it's a no brainer to see where hobbyists were attracted and why.Of course that bloody $2 "Blue Pill" had to get Arduinoized (to a degree), so hobbyists went straight to the old STM32F103 Cortex-M3, bypassing the much newer Cortex-M0 completely.Loosely related, but interesting:Now we have a new player that's going to cause quite a stir in the hobby market I think. It's a RISC-V core with STM32F103 peripherals. It's fast (108 MHz with zero Flash wait states !), cheap and fully open. It's the Chinese GD32VF103C. See this link for datasheets:http://dl.sipeed.com/LONGAN/Nano/DOC/How long before Arduino caters for the GD32VF103C do you think, tomorrow, a week, two weeks ?The Mecrisp-Stellaris creator, Matthias Koch already has separate releases for the Risc-V and the STM32F103 so it won't take long for him to include the GD32VF103C in his supported hardware list. He has some of the LONGAN Nano units in the post to him already.

author: rx8pilot
author_rank: Super Contributor
timestamp: September 16, 2019, 03:38:07 pm
content: The ATMEGA4809 [UQFN-48] is only $1.35 USD and the ATMEGA4808 [VQFN-32] is only $1.11 USD in qty:100.That is pretty good. I have been using AVR out of habit because I have so much code/understanding already developed so it is very easy for me to push out a low-volume product without much challenge. I am a bit scared of shopping for the lower-priced or slightly better specs at the expense of a learning curve and new development tools.Almost everything in my work can easily be accomplished just about any MCU out there. I am rarely, if ever, on the fringes of the available performance so I just go with the easy and predictable option.

author: magic
author_rank: Super Contributor
timestamp: September 16, 2019, 07:58:49 pm
content: Sadly ARM is not without its warts. I had a look at some of the micros mentioned here, a number of things jumped out.For starters, complexity. More registers to setup, thicker user manuals to comb through.You technically get 4x wider data bus, but it's interleaved with instruction fetches so only 2x more bandwidth in practice. Why?The above also affects instruction latency in all kinds of weird ways. I guess people rarely write cycle-accurate assembly these days, but I did it once on AVR, it was piece of cake.15 cycles interrupt latency? Are you kidding?Maybe the 16 bit PICs would be a viable compromise with more bits, more MHz but still a simple Harvard architecture. Too bad it's single-vendor and probably ultimately destined to extinction. Or is it doing well?

author: techman-001
author_rank: Frequent Contributor
timestamp: September 16, 2019, 11:36:18 pm
content: Quote from: magic on September 16, 2019, 07:58:49 pmI'm not sure more capability and the resultant increase in technical manual size is a reason for criticism. If that were true, the Motorola MC14500B one bit CPU would probably still be the most popular device around.Perhaps today's highly accurate cycle timing (and parallel processing) by FPGA's clocked at high speeds like 500 MHz has surpassed the need for cycle counting in MCU's?Some ARM Cortex-M have a DWT (Data Watchpoint and Trace) unit which counts the execution cycles and finally the Cortex-M instruction prefetch unit (PFU) may make cycle counting difficult depending on instruction flow ?15 cycle interrupt latency may be a result of having up to 93 on board peripherals with many interrupt trigger options for each peripheral. Then again when the clock is 200+ MHz those 15 cycles may not be quite the delay you expected ?I like 16 bit Pics and MSP430's myself. I have plenty of stock and Forths for them as well, I just find myself using Cortex-M0 all the time for some reason which I suspect is the low cost, 32 bits, speed, large flash size (64KB) and the huge number of on board peripherals. If I needed low power for a simple battery powered application, I'd probably use a MSP430.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 17, 2019, 01:30:20 am
content: Quote from: magic on September 16, 2019, 07:58:49 pmCuriously, interrupt latency is almost a constant. Even the mighty PC endures whole microseconds of context switching and cache flushing. (Pretty sure I'm exaggerating, but, in the end, overall IO latency still hasn't changed much over the last 3 decades; except for specially optimized architectures like Xcore, but that's not in PCs.)QuoteHm, Microchip isn't going anywhere, in the immediate future at least.If you need higher performance, there's always DSPs -- multiple buses, not just a separate instruction path but source and destination as well.Tim

author: westfw
author_rank: Super Contributor
timestamp: September 17, 2019, 10:39:51 am
content: QuoteNo, that's not quite accurate. Some of the ARM architectures are "modified Harvard" machines, which means separate buses for data and instructions, even though they share an address space. Flash is frequently front-ended by some sort of "accelerator" even on very low-end parts; the simplest being flash memory that is wider than 32bits. (and remember that most CM0 instructions are only 16bits wide.) And the buses tend to run faster than memory accesses, and RAM (data) tends to be pretty zippy - on the order of 32bits per 20ns rather than 8bits per 50ns.I think. It's pretty tough wading through separate documents on the CPU architecture vs the chip implementation.But then IO tends to be on the other side of some additional bus controller, which introducing more delay and strangeness.Unless is a chip with the optional "tightly coupled memory" and/or "single cycle IOBUS" port features.And yeah, writing cycle-accurate, deterministic code is quite difficult compared to the 8bit chips :-(QuoteAmen!!!

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 17, 2019, 01:47:01 pm
content: Quote from: T3sl4co1l on September 17, 2019, 01:30:20 amThis is not quite curious, as pipelines in modern CPUs have tended to grow longer and longer, which in turn usually makes interrupt latency longer.What could be seen as curious would be why we didn't care to work on that specifically, but since clock frequencies have also dramatically increased, interrupt latencies in cycles haven't mattered much except, as you said, in very specific domains, for which there are other solutions than general-purpose CPUs.Talking about that, I'm actually not sure how we could design a CPU with, say, a mere 1-cycle interrupt latency, if said CPU is pipelined. Unless maybe the interrupts were served on a separate, specialized core, which would make that not really an "interrupt" per se then.

author: Kleinstein
author_rank: Super Contributor
timestamp: September 17, 2019, 03:17:58 pm
content: Even with the AVRs interrupt latency is at least 6 cycles + the longest instruction (another 6 cycles for an RET AFAIK). In addition there is usually a jump from the table.AFAIK the ARMs have automatic saving of a few registers with the interrupt. So there will likely be quite some cycles for the interrupt to start with. The wider RAM can really help storing the data to a stack.The flash of the AVR is already 16 bit wide, and ARM fash often needs some wait states if a fast clock is used. This make clock accurate timing from code run time rather difficult. However for this purpose there are timers and the event handling system - so critical timing is usually done by the HW and not the code speed.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 17, 2019, 05:34:18 pm
content: Quote from: Kleinstein on September 17, 2019, 03:17:58 pmYep. In simpler MCUs, registers used in the ISR must be saved by hand (or automatically depending on your programming language and specific options/attributes), which can add significant overhead, so merely using a typical "interrupt latency" figure is kind of pointless, or at least can be misleading. That's always a best case.Quote from: Kleinstein on September 17, 2019, 03:17:58 pmYes and yes. And sure in some cases, you'd need to run the ARM MCU at an higher clock freq than the AVR. But does that matter in practice? If this is power draw that is your concern, think again. Some ULP ARM-based MCUs these days draw less power @80MHz than a typical AVR @16MHz for instance... As to performance, they are just light years ahead.Simple 8-bit MCUs have their uses of course, and I agree that simplicity is a nice feature in itself. But the points on interrupt latency and execution time predictability are often not a good enough reason (except for simplicity for the latter) to choose them IMO. Simplicity and cost can be. And of course, legacy. Many AVR users keep using AVR's, and are eyeing the new "AVR" entrants, mainly because they are very familiar with them, and thus there is no extra cost/time spent to switch to something else.

author: rx8pilot
author_rank: Super Contributor
timestamp: September 17, 2019, 07:00:22 pm
content: Quote from: SiliconWizard on September 17, 2019, 05:34:18 pmEvery time a new project comes through that needs an MCU not needed spectacular compute and latency power, I look at using new devices. After a little searching, I end up with an AVR design entirely based on the familiarity. My last project used four distributed AVR's instead of a more powerful 32bit option. It was actually kinda nice having the tasks and physical layout distributed by task and also made latency and compute performance easy to manage. The downside is that I have to manage 4 programming efforts.Perhaps I am too scared of change so I keep using the same family of MCU's. Learning curves are expensive.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 17, 2019, 07:48:13 pm
content: Quote from: rx8pilot on September 17, 2019, 07:00:22 pmThey sure are. And it adds uncertainty, something you may not be comfortable with: until you're proficient enough with a new architecture, you won't know for sure how to implement a given functionality, or if it's even possible, whereas you perfectly know how to with the architecture you're familiar with.So that's quite understandable.

author: iMo
author_rank: Super Contributor
timestamp: September 17, 2019, 10:06:27 pm
content: Quote from: SiliconWizard on September 17, 2019, 07:48:13 pmTherefore we still use

author: magic
author_rank: Super Contributor
timestamp: September 18, 2019, 02:02:52 pm
content: It all depends on application, I suppose. If you build a standalone product which needs some kind of "SoC" for data processing, an ARM may be a good choice. To me, "a microcontroller" is primarily about interface glue, perhaps a bit of bit-banging and shoving data in/out of a computer, which does any actual computations.You got me with the cost of CALL/RETURN on AVR, I wasn't aware it's so bad. Though actually it's only 4 cycles (and 5 on >128kB parts). If you forego procedure calls, all else is ≤3 cycles. And the only 3 cycle ones are JMP (not needed with ≤8kB flash), LPM and a few "conditional skip next instruction". Life isn't bad.Ironically, the more advanced ARM cores with 3-6 stage pipelines have more reasonable 12 cycle latency than M0/M0+. It's surprising, given that ARM supposedly doesn't even finish the pending instruction like AVR. Until further explanation is provided, I call it "the joys of using a stripped-down application processor for MCU"Even pushing a few registers on stack shouldn't take so long.You certainly cannot have 1 cycle latency in a pipelined core, unless you predict that an IRQ is going to hit you and prefetch it into the pipe in advance