pyUPDI

[DanSkareda]

I built several serial adapters "pyUPDI" with CH340N and built them into G1901G boxes. They look like USB drives and are so cute, even though I made them on a single-layer PCB at home. :-) They work without problems, I tried them on attiny414. However, I was surprised at how much information is written out during programming. Because they are red, they make me uneasy. Couldn't they be written in white or gray? And it even changes the fuses when programming! Why? JTAG2UPDI (I have it built in the same box) will do the same task quietly and possibly faster. At least for small projects. What makes pyUPDI better?

[SpenceKonde]

Are you using 2.3.2? That's when we switched to recommending it (and it's not quite pyupdi, it's a bridge between the Arduino IDE and Microchip's (now open source MIT license) pymcuprog tool, which itself received extensive modification at my hand over the past few weeks to optimize performance. As of 2.3.2 a few things have changed:

• Baud rates offered by megaTinyCore 57.6 for special applications, where faster speeds are unsuitable, 230400 baud for general use, and 460800 for CH340/FT232/other parts that support it for maximum speed.
• Performance vastly improved, such that it now absolutely destroys jtag2updi performance. jtag2updi was locked to only 115200 baud; we are faster at equal baud by almost 2 to 1 on Dx, similar speed with equal baud and 64 byte pages, 3, but we can default 230400, yielding speeds
• Verbose output mode disabled, even when verbose mode enabled in preferences (the verbose mode is just obscene - it's like half an MB when you debug the upload of a 128k hex... There is no universe in which that makes sense unless the user is, like.... me... and I'm engaged in development of the upload tool at the time (and I would not do that through the IDE,faster to test when you don't need to wait for a recompile,because fast so it no longer barfs up debug output of 5 times the size of the uploaded file (and that was on a success). Thus typical output regardless of whether verbose is on or not is on now. There was a level of internal debate about this that wasn't resolved clearly prior to release of this version, regarding how much to log in normal vs verbose mode. Currently, since I disabled verbose output because it was absurd, the logging is a bit of version stuff at the top, the output that comes from the pymcuprog code, and the pair of progress bars and times taken.

Since 2.2.0 we always write the fuses when programming over UPDI (all programming methods except through a bootloader) - we write what I classify as "safe" fuses - those that can never interfere with reprogramming, if set improperly, AND which are normally set by the tools menu options I present to the user. Thus:
OSCCFG is written. This was the real motivator, because prior to this, far and away the number one support issue and bug reported was that they changed from a 20MHz derived speed to a 16 MHz derived one on the menu, didn't do burn bootloader ("I'm not using a bootloader, why do I need to burn bootloader?" god am I sick of giving THAT speech) and complained that it was not running at the speed they selected
BOOTSIZE/BOOTEND is written.This means that when using updi on a board that was previously bootloaded with optiboot (or another bootloader), simply uploading a non-bootloaded sketch via UPDI works. (unlike most classic AVRs, and like a classic mega2560) prior to 2.2.0, if an upload was done on a bootloaded board for a non-bootloader configuration via a programmer, it would remove the bootloader, but the sketch would not be able to run correctly due to the old bootloader configuration set in the fuses. (specifically, if the BOOTSIZE/BOOTEND fuse is non-zero, it MUST match the size of the gap between flash address 0x0000 and the beginning of the sketch (the point at which the compiler was told that section start for .text is - because that's where the hardware will look for the interrupt vectors end of the bootloader on a modern AVR, because that area us
And we set the SYSCFG that controls SUT because it doesn't do anything potentially harmful ajd we jave a dropdown menu for SUT.
TCDCFG is not set because the core doesn't ever write that - hence if it has changed, we assume the user did that intentionally and we should leave it be. Same goes for APPEND (this is used for an alternate scheme to write to flash from user code. That approach can only write to a designated area of the flash, an area distinct from where the code is running from under normal circumstances in Arduino-land, but works without calling to the bootloader to achieve the writing top flash), but this is very tricky to present to the user through the IDE considering the limited freedom I have to control IDE behavior, so we went with the more widely compatible approach which we already had full implementation of this functionality for. But ( on these. On the AVR Dx-series, having radically different NVM controller which we did not have such app-write-from-flash written for us, a very different approach was taken which has the option to use the Dx equivalent of APPEND, CODESIZE)
BODCFG can't be touchedbecause it can soft-brick the board (because you could end up in a situation where hardware must be modified to use a higher voltage in order to get far enough to put the device into programming mode and write a new value to BODCFG to choose a compatible voltage.
And the fuse I haven't mentioned is is the one with EESAVE (which I wish I could set on all uploads), and the RSTPINCFG, which if set causes the part in question and hence clearly can only be set on bootloading with a big warning label on the menu :-P

Setting OSCCFG on uploads was a very frequently requested feature.... confusion over this behavior was... close to half of the communication I received in relation to megatinycore. From people who changed the menu option for clock speed, did not rebootload even though I had a reminder that you had to burn bootloader for that, couldn't figure out why it wasn't working,, and were confused for long enough that they emailed the developer before they figured it out). I thought about it and realized that the reasons that classic AVRs only set fuses when bootloader is burned not on every upload is because every one of the fuses on classic AVR will brick your board if set wrong - setting lfuse to clock source that's not there will require piping external clock to it to revive, 128k oscillator requires slowing down the ISP clock to undo, etc, the hfuse has the bits to disable ISP programming or reset, and the extended fuse typically controls whether the bootloader can write to the flash, and can impact a variety of other things, that's where they threw any sort of fusey setting that they didn't have anywhere else for).

The developer of a hardware package like my cores has no control over the colors the IDE uses for text. All output from the upload tool, as I understand it,is printed in that red-orange. If there is any way to specifically change on that, I do not know what it is.

So... I hope that clears things up on this front let me know if tyou have any further questions.