Microchip seems to be planning a Dx family AVR with native USB.
It sounds intriguing.
AVR DU Product Brief
DIP28 package is still included in the plan... 
1 Like
About time!
First couple of pages look good. 16 endpoint addresses and each with in and out, then multi-packet transfer, several package sizes. Yes please! More memory and better USB hardware.
But,
- Does it support the ICSP programming protocol?
- Is avrgcc support there or not?
- How good will its USB device firmware stack and library be?
- What kind of hardware buffer does it have on UART, one byte, 16 bytes, any flow control (soft/hard)?
No, It use UPDI for program.
Yes, avrgcc support this.
I think nothing has been published yet.
The detailed datasheets has not been released yet, but I think that it probably has the same UART as the DA series.
1 Like
Thanks for the response! I'll read up on UPDI. One of my projects has an ESP32 and I've been using ESP32 to flash firmware to AVR chips via ICSP. Wrote my own code to read binary firmware and flash them to AVRs quite nicely. Here's what I'm thinking. If the UART has larger buffers, then there will be less interrupts at high baud rate that interferes with the rest of the code such as USB code. Could you give me a sample part number of a DA series MCU so I can read about its UART? I'm not familiar with this series.
The AVR DA Series and AVR DB Series is here.
They are already manufactured and sold.
For example, AVR128DB28 in DIP28 package.
https://www.microchip.com/en-us/product/AVR128DB28
There is also an Arduino core made by @DrAzzy called DxCore.
1 Like
I was reading AVR32DA32. It seems that RXDATA can be double-buffered, which sounds like 2 bytes of buffer. It's not much different from AVR328 etc. that have a single buffer.
Yep, surely the hardware FIFO is small available.
They are unlike xmega, it also doesn't have DMA. 
I was googling the UPDI but didn't find any place that explains this protocol. Maybe only spec sheets or white paper exists. Is it a microchip thing? How widely is it adopted in AVRs, in your opinion?
Random thought. I use ESP32 for projects. They have 16 byte hardware buffers. The software I use is ESP-IDF, which is what ESP-Arduino is based off. The document says installing UART driver is not required but speeds up things. I wonder if the difference between installing UART driver or not on an ESP32 dev board is using interrupt/DMA to transfer 16 bytes of the hardware buffer at a time or interrupt at every byte received.
The detailed protocol is specified in the datasheets of any chip that uses UPDI.
Yes.
I think all recently released or foretold AVRs use UPDI.
- mega0 series (Yeah, It include ATmega4809, It's Nano Every's brain.)
- tiny0 series
- tiny1 series
- tiny2 series
- DA series
- DB series
- DD series
- EA series
- DU series
They are all uses UPDI to program.
1 Like
UPDI is used in all parts released since the 2016 AVR revolution, and is likely to be used on all future parts for the foreseeable future.
It is essentially UART over a single wire, the target uses a sync character to autobaud, and you can use a serial adapter with either a resistor or schottky diode between Rx and Tx. Protocol is pretty simple and all the datasheets describe it, the only "trick" that isn't properly described in the datasheet is that direct addressing for 24 bit parts must use 24 bit addressses, if you use 16-bit addresses, it will use the most recent pointer high byte for the address (ie, the first write will work, then when you try to write to 0x1000 to manipulate nvmctrl.ctrla, you'll instead write to 0x801000 scribbling over address 0x1000 of the flash. That took me over a week to figure out when I was updating jtag2updi (an avrdude-compatible version that uses a mega328 or similar as a go-between, at considerable cost of speed.)
jtag2updi was the main way people in Arduino-land programmed these prior to development of an arduino-compatible serial-adapter-as-updi upload tool based on pymcuprog and used in megaTinyCore and DxCore for the appropriate programmer options (they pull in a portable python installation when installed via board manager, like the ESP cores do - in fact, the same exact one - we didn't even bother rehosting it 
). SerialUPDI pointed at the Dx-series at 345600 baud writes at just below the maximum speed that the hardware is capable of writing to flash.
And yes, RX data is double buffered and that's it. The serial implementation Arduino uses, including in my cores, is pretty shitty as far as I can tell' I am not gonna deny that. they should probably be rewritten in assembly, looking at the generated assembly is painful; there is no reason that the TX or RX isr's need to be the monstrosities that they are, but making them good requires getting ones hands dirtier than Arduino cores normally do. It's on my list (It's way more interesting than most of that list, but less critical - I have to fix a couple of really hot issues in each of the cores, then finish ATTinyCore 2.0.0, then I get to do the fun stuff)
1 Like
Great! Thanks @DrAzzy
So a one-wire serial, sounds like SDI-12 that I deal with. Without reading the spec sheets yet I'll bet on either 55 or AA as the sync character 
Hopefully ATMEGA MCUs like 32U4 and 328P have no danger of losing ICSP feature soon so my learning of the UPDI won't be hard-pressed and deadline driven. I suppose you can write fuse values via UPDI and could lock yourself out if you end up disabling it. Maybe high voltage programming is need to unbrick? I've not read Arduino UART code too many times to start complaining yet 
I do tend to complain Arduino USB code. It's pretty bad. Besides the bad choices of function and variable names the program flow is just bad. There's also no interrupt driven endpoints to buffer and send data so if you say send a series of key presses with Leonardo, your main code traps until all the key presses are sent. If you are sending a short packet of UART data, at least you are off the hook once your data are moved to the UART TX ring buffer because the actual send is done in ISR (I think).
Yeah 0x55 for sync,
Oh no, they won;'t change existinfg parts. There are no parallels for how it would work on the old parts. That would be a godawful shitshow.
UPDI can be disabled on tinyAVR 0/1/2 series, they need an HV pulse on UPDI/Reset to reenable it - IIRC there was some wierdness where some parts just need the pulse, while others require you to send UPDI command shortly after for it to work. 2-series with 20/24 pins can move reset to PB4 instead of PA0 to let you sacrifice two pins to have both UPDI and reset pins.
DA and DB can't disable UPDI via fuse, and if reset is disabled it's input only. No HV anything. DD will be able to both disable reset and/or UPDI, and likely DU as well, When I was talking to Microchip folks about how it would work there, they indicated that the HV pulse would go to the input only reset (this avoids the problem with code that sets reset as output and drives it low on tinys, for which you need to power cycle it and then immediately give the HV pulse - but also raises some questions. There is still no datasheet available for the DD-series; it seems to be getting delayed like the 2-series was. And if that's the price we pay for chips with less errata, I'm 100% fine with it (they almost released the 2-series tinies months earlier than they did... even went so far as posting the errata, some of which were really nasty, then someone with some good sense made the call to delay it, they fixed those issues, and the result is a chip with hardly any silicon bugs, which is a very welcome change. The 0/1-series, DA and DB have tons of silicon bugs. I don't know if it;s just because they have the luxury of all production for the next 50 weeks already spoken for, or whether they made a strategic decision to not let so many known issues out the door, but i like how the 2 series actually does what the datasheet says)
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.