Open SpenceKonde opened 1 year ago
Note that there are no plans to change this on jtag2updi; it is considered obsolete.
There is an AVR library to do UPDI programming in the works; that is my replacement for JTAG2UPDI, which was awful to work with. It will be implemented alongside a librarification of ArduinoAsISP, and a python upload script, and the hardware I'm designing for is an AVR-DB (has to have MVIO to do the standalone programming unless the target is required to run at 3.3V - since that's what flash chips run at, you need either the flash chip at 3.3 on MVIO, or the chip + flash at 3.3V and target on MVIO. (I chose the latter), the 128k version not because I anticipate a shortage of code space, but because I think that having massive buffers will be key to killing off USB latency, hence the 16k of ram is the attraction there. Based on tests with SerialUPDI, that method falls significantly short of the write speeds the hardware is capable of, particularly on tinyAVR and megaAVR parts, where pages are small, write times per page are short, and with the baud rate cranked way up, programming time is more latency than anything else. But if I could buffer multiple pages, and simultaneously be receiving a later page while writing and earlier one, it might be possible to reach near-theoretical speeds. Dx would see smaller improvements (their pages are larger and their overhead is smaller in both bytes and round trips (latency-periods). Would be sweet to have that ready and waiting for the DU's, which would be an even more attractive platform, even with half the RAM. In any event, the idea is to be able to store a library of sketches on the flash chip (8mbyte or so), and have a simple GUI to use for standalone programming. Index will be stored on an EEPROM chip (greater rewrite endurance). Obviously this will include xeroxing unlocked chips into it's flash too.
But that's a ways off
In the near term I need to make serialupdi work.
I wanted to test some code on the EA series, so as a temporary workaround I tried using DxCore with an AVR64EA48 Curiosity Nano board with the Programmer option set to Curiosity Nano (nEDBG, debug chip :ATSAMD21E18).
However, that failed with:
avrdude: Version 6.3-20201216
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/Users/david/Library/Arduino15/packages/DxCore/hardware/megaavr/1.5.11/avrdude.conf"
User configuration file is "/Users/david/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
avrdude: AVR Part "avr64ea48" not found.
Any suggestions? Thanks, David
I'm not sure if/how avrdude 6.3 support the AVR64EA ... actual is 7.3: https://github.com/avrdudes/avrdude/releases/tag/v7.3 and there were some issues in 7.2 ...
I'm not sure if/how avrdude 6.3 support the AVR64EA ... actual is 7.3: https://github.com/avrdudes/avrdude/releases/tag/v7.3 and there were some issues in 7.2 ...
Yes in order to better support serialupdi and new chips, it is better to upgrade to avrdude 7.3.
Reference: https://github.com/avrdudes/avrdude/blob/main/NEWS
At least now I can compile for EA!