Programming using pyupdi with 4k7 resistor

[HannesBulk]

in the Spencekonde AtmegaTiny core it is possible to program the Attiny0,1 and 2 Series with PYupdi just using a serial adapter and a single resistor. This words fine, even for the DX cores. It should also work withe the mega0 series (at4809 etc), however these processors are not included in his project. since the program protocol is the same protocol as used for the TinyMega Cores, it should also work with the Mega0 series. My request is to add this pyupdi with a 4k7 resistor programming protocol, to allow programming with a simple usb-serial converter.

[MCUdude]

This is something that's doable, and as you pointed out, DxCore and megaTinyCore has it already. @SpenceKonde is it OK if I borrow your implementation? 🙂

[MCUdude]

I copied the pymcuprog implementation (pyupdi compatible) from megaTinyCore to try it out with MegaCoreX. It works great! The only thing I had to tweak was the resistor value. For some reason, a 1k resistor was too high for an ATmega3208. A 470R did the trick.

I made a tiny 2x3 pin adapter for this test, so I could use a standard USB to serial adapter. And this got me thinking, it should actually be possible to create a tiny "Pyupdi board" that could automatically switch between UPDI and serial mode!

The screenshot below shows a pyupdi/pymcuprog UPDI init sequence. It starts with a DTR toggle (yellow trace), followed by some data being sent on the Tx pin on the USB to serial adapter. The data is echoed back to the Rx pin through the resistor.

On a custom board, a DTR toggle could switch in the resistor, and if traffic occurred on the Tx pin within ~5ms, stay in UPDI mode until traffic ends or we get another DTR pulse. Else, if no traffic occurs on the Tx pin within 5ms after a DTR pulse, switch to UART mode. I think this could actually work, maybe with just simple digital logic! it would also fit the "microUPDI" pinout quite nicely! Any thoughts @HannesBulk and @SpenceKonde?

[MCUdude]

This is a mockup schematic of what I think might work. The logic happens inside the ATtiny404/414 and switches the RX/TX pins based on what's happening on the RTS and UART TX line:

[SpenceKonde]

I'm planning something much simpler based on the fact that most serial consoles hold DTR and RTS low. We have control over how RTS/DTR are used by pymcuprog, unlike everything else. I would just have a serial chip and 74HC4053, RTS tied to S1, S2 (plus it's brought out to the DTR/RTS header) to be connected to target reset through the cap.1Z, 2Z to adapter Tx, adapter Rx. 1Y0, 2Y0 to Rx, Tx of target, so when RTS is held low, it's talking to target serial, and the falling edge can be used to autoreset if desired and it's something that can have reset enabled without needing HV programing. 1Y1 (adapter Rx) to UPDI direct, 2Y1 tied to UPDI via some combination of resistor and/or schottky diode (I don't know if you saw the other thread bringing up the fact that a smaller series resistor and schottky signal diode should be better), so when RTS isn't held low because it['s pymcuprog acting on the port, it's pointed at UPDI. (target serial is the thing that shuould happen by default, And generally speaking, RTS and DTR get driven low unless you explicitly ask for them not to be)

And yeah, while typing this, I decided to put it on the scope to check how close the voltages actually were to thge liumiuts (was playing with it earlier anyway. I noticed that the voltage on the USB bus was drooping a bit (not unusual VUsb voltage droops when not using external power adapter for the miserable excuse for a knockoff USB hub that I have.. Plugged the wall adapter into the USB hub, now the voltage was a nice healthy 5v, Suddenly updi programming didn't work over a serial port anymore. Unplug the adapter's USB power again, and it worked. and I could see on the scope, that with it on the higher voltage, only one side was able to get the pin low enough for the other to respond. it wasn't driving the pin low enough through the resistor. So yeah, I think I need to recommend the diode configuration... goddaaaaamn...Even a silicon diode was a huge improvement; a small schotky should be even better.. .

On Thu, Apr 8, 2021 at 5:17 AM Hans @.***> wrote:

This is a mockup schematic of what I think might work. The logic happens inside the ATtiny404/414 and switches the RX/TX pins based on what's happening on the RTS and UART TX line:

[image: image] https://user-images.githubusercontent.com/3238730/114001036-dc46b780-985b-11eb-9fd5-3047311c99c9.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MCUdude/MegaCoreX/issues/119#issuecomment-815599567, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEWYIVIJCJREOYRCJL7LTHVYDLANCNFSM42Q3BMMA .

--

---

Spence Konde Azzy’S Electronics

New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore https://github.com/SpenceKonde/ATTinyCore: Arduino support for all pre-2016 tinyAVR with >2k flash! megaTinyCore https://github.com/SpenceKonde/megaTinyCore: Arduino support for all post-2016 tinyAVR parts! DxCore https://github.com/SpenceKonde/DxCore: Arduino support for the AVR Dx-series parts, the latest and greatest from Microchip! Contact: @.***

[MCUdude]

I'm planning something much simpler based on the fact that most serial consoles hold DTR and RTS low.

Wow, I didn't think of this! this means that we can stay in "regular" UARTmode when DTR/RTS is low, and UPDI mode when high. Brilliant! It seems like Avrdude does the same thing with the DTR/RTS pin, so this means the board could also be used to program optiboot-compatible boards. Neat!

About that diode, is it going in serial or parallel with the resistor. If I'm going to create a board around this I'll probably use the BAT54S, my go-to Schottky diode for everything signal-related. BTW, which value do you usually use for the resistor?

Oh, but is it OK for you if I borrow your pymcuprog implementation?

[SpenceKonde]

I think it should be; I want to just check in with Quentin who did a lot of the development work on it. Will let you know,

[SpenceKonde]

I'd go with 470 ohm. heh, that's the same diode I'm using, in the SOT-23 package because I can't stand the SOD signal diode packages. Resistor in series with diode. The real question is what serial adapter IC; there are no perfect choices... they all suffer disappointing transfer rates due to USB latency - at least the ones I have tried, and I haven't found any I'm fully happy with yet for this sort of programming - CH340's are fine for tinies mostly, but they are mad slow when you start uploading large sketches over UPDI - and even not-so-large ones can be.... really slow. That's another thing I;'m going raise in an email to the the team actually, since I took some data last night that put numbers to my sense of disappointment.

[MCUdude]

Regarding the Pyupdi programmer, I think the 47HC4053 has a bit too high internal resistance to be a good choice in this application. The 74LVC1G3157 has only 10 ohms, which is an order of magnitude better than the 4053.

I don't have much experience with Pyupdi in general, so I can't say too much about upload speed. But the CH330N/CH340G have been reasonably quick for "regular" Optiboot uploads. Not as fast as the Silabs CP2102, but good enough. I believe UPDI will be much slower since it is a half-duplex protocol.

How about something like this?

[SpenceKonde]

I have the PCBs on hand so as soon as I have time to assemble some I'll try it out

But yeah for general programming, you want to grab what's in /megaavr/tools from DxCore (megatinycore is functionally the same, but if there's a readme in tools, its a sentence or two instead of a longform essay with ASCII-art schematics of every plausible configuration and tables of speed recorded as well as the relevant parts of platform.txt and programmers.txt (and note the editing of platform.txt my release scripts have to do to deal with the path to python being different for board manager vs normal installs), and you'll need to have it pull in python in the board manager json tool.

The adapter IC question has been rendered largely a moot issue with software improvements. No matter what adapter you use, even @ 460800baud, reads aren't far below the wire speed! and with nvm v0 w/128b pages, writes are the same bulk speed as a 32k tinyAVR, that is 7.5k/s or so with ch340 at 230400, 10k/s @ 460800. those numbers are 10k and 15k on FT232RL (with the correct setting as noted in that readme - the default is for it to use a 16-ms latency timer which results in it spending less than 15% of the time communicating, and the rest sitting around in latency waiting for the next USB transaction). But yeah. you;'re looking at full write+verify time of 9s @230400 or 7@460800 w/ch340, or like 8 and 5 w/ft232 for full 48k flash, which I think is pretty good. Way better than jtag2updi will do. For equal baud rate, Optiboot should win narrowly (largely because optiboot uses no parity and 1 stop bit, while UPDI has parity and 2 stop bits, and hence is 20% slower for a given baud even if everything went at the speed of the wire.

[SpenceKonde]

To compare, prior rto this optimization round, the times for a CH340 class would be like... 600b/s write 6.5k/s read @ 115200 baud, so you;d have been looking at like 8 sec for verify and maybe 80-90 to write... so like 90-100 seconds total? I hope you now understand why I was advocating you hold off getting this into MegaCore X

[MCUdude]

@SpenceKonde I finally have the time to pick this up. I'd like to be able to use Pymcuprog with the MPLAB Snap and PICkit4 from withing Arduino IDE, but when I try to do anything with these programmers, I get the following error:

Connecting to any snap
Traceback (most recent call last):
  File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pyedbglib/hidtransport/cyhidapi.py", line 4, in <module>
    import hid
ModuleNotFoundError: No module named 'hid'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 266, in <module>
    main()
  File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 121, in main
    return_code = pymcuprog_basic(args, fuses_dict)
  File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 163, in pymcuprog_basic
    backend.connect_to_tool(toolconnection)
  File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pymcuprog/backend.py", line 150, in connect_to_tool
    self.transport = hid_transport()
  File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pyedbglib/hidtransport/hidtransportfactory.py", line 46, in hid_transport
    from .cyhidapi import CyHidApiTransport
  File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pyedbglib/hidtransport/cyhidapi.py", line 9, in <module>
    raise ImportError(MSG)
ImportError: This transport class requires cython and hidapi to be installed:
> pip install cython
> pip install hidapi

Do you know if there is possible (and how) to bundle the cython and hidapi packages with the Pymcuprog installation?

[MCUdude]

I tried to install cython and hidapi manually, just to see if it would work or not. Got this error with the MPLAB SNAP:

ersion 1.1.0 - May 2021
Using serial port  at 115200 baud.
Target: atmega4809
Set fuses: ['0:0x00', '1:0x54', '2:0x01', '4:0x00', '5:0xC9', '6:0x06', '7:0x00', '8:0x00']
Action: write
File: /var/folders/6l/ypg6qbw172v1s4vtt6g990tw0000gn/T/arduino_build_1089/Blink.ino.hex
Connecting to any snap
Pinging device...
Ping response: 1E9651
Setting fuse 0x0=0x0
Writing literal values...
Verifying literal values...
Action took 0.02s
Setting fuse 0x1=0x54
Writing literal values...
Verifying literal values...
Action took 0.03s
Setting fuse 0x2=0x1
Writing literal values...
Verifying literal values...
Action took 0.02s
Setting fuse 0x4=0x0
Writing literal values...
Verifying literal values...
Action took 0.02s
Setting fuse 0x5=0xc9
Writing literal values...
Verifying literal values...
Action took 0.02s
Setting fuse 0x6=0x6
Writing literal values...
Verifying literal values...
Action took 0.02s
Setting fuse 0x7=0x0
Writing literal values...
Verifying literal values...
Action took 0.02s
Setting fuse 0x8=0x0
Writing literal values...
Verifying literal values...
Action took 0.02s
Finished writing fuses.
Chip/Bulk erase,
Memory type eeprom is conditionally erased (depending upon EESAVE fuse setting)
Memory type flash is always erased
Memory type internal_sram is always erased
Memory type lockbits is always erased
...
Erased.
Action took 0.01s
Writing from hex file...
Writing flash...
Traceback (most recent call last):
  File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 266, in <module>
    main()
  File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 121, in main
    return_code = pymcuprog_basic(args, fuses_dict)
  File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 234, in pymcuprog_basic
    run_pymcu_action(pymcu._action_write, backend,
  File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 131, in run_pymcu_action
    status = func(backend, *args, args_pymcu)
  File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pymcuprog/pymcuprog_main.py", line 341, in _action_write
    _write_memory_segments(backend, result, args.verify, blocksize=args.blocksize)
  File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pymcuprog/pymcuprog_main.py", line 392, in _write_memory_segments
    backend.write_memory(segment.data, memory_name, segment.offset, blocksize=blocksize)
  File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pymcuprog/backend.py", line 526, in write_memory
    self.programmer.write_memory(data=data, memory_name=memory_name, offset=offset_byte, blocksize=blocksize)
  File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pymcuprog/programmer.py", line 190, in write_memory
    self.device_model.write(memory, offset, data, blocksize=blocksize)
An error occurred while uploading the sketch
TypeError: write() got an unexpected keyword argument 'blocksize'

[SpenceKonde]

That might be possible with the full unmodified pymcuprog, and while we still have vestigal parts of the support for other programmers, they are neither tested nor do we have any expectations either way for them working in light of the changes we have made. Because of the requirements. We are concerned ONLY with the uart functionality (hence why it's being called SerialUPDI) ; Quentin indicated that adding support for that would be a big deal and I was like "Okay forget I mentioned that, let's stick to avrdude for the rest of the programmers I had originally hoped to be able to use this to replace avrdude other places, but we chose to limit this to the use case that really mattered, which was turning any 50 cent serial adapter into a high performing UPDI programer.

On Sun, May 23, 2021 at 4:20 PM Hans @.***> wrote:

@SpenceKonde https://github.com/SpenceKonde I finally have the time to pick this up. I'd like to be able to use Pymcuprog with the MPLAB Snap and PICkit4 from withing Arduino IDE, but when I try to do anything with these programmers, I get the following error:

Connecting to any snap Traceback (most recent call last): File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pyedbglib/hidtransport/cyhidapi.py", line 4, in import hid ModuleNotFoundError: No module named 'hid'

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 266, in main() File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 121, in main return_code = pymcuprog_basic(args, fuses_dict) File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 163, in pymcuprog_basic backend.connect_to_tool(toolconnection) File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pymcuprog/backend.py", line 150, in connect_to_tool self.transport = hid_transport() File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pyedbglib/hidtransport/hidtransportfactory.py", line 46, in hid_transport from .cyhidapi import CyHidApiTransport File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pyedbglib/hidtransport/cyhidapi.py", line 9, in raise ImportError(MSG) ImportError: This transport class requires cython and hidapi to be installed:

pip install cython pip install hidapi

Do you know if there is possible (and how) to bundle the cython and hidapi packages with the Pymcuprog installation?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MCUdude/MegaCoreX/issues/119#issuecomment-846619229, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW7Y35SMHB6T57MS3CLTPFPSTANCNFSM42Q3BMMA .

--

---

Spence Konde Azzy’S Electronics

New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore https://github.com/SpenceKonde/ATTinyCore: Arduino support for all pre-2016 tinyAVR with >2k flash! megaTinyCore https://github.com/SpenceKonde/megaTinyCore: Arduino support for all post-2016 tinyAVR parts! DxCore https://github.com/SpenceKonde/DxCore: Arduino support for the AVR Dx-series parts, the latest and greatest from Microchip! Contact: @.***

[SpenceKonde]

Wh well that answers whether it works or not. The changes made to support performant writes via the simple serial port method are breaking other parts of it, blocksize is one of the new parameters that we have to push around to get from the top level of the code all the way down to the lowest level. I can check with quentin, but I don't think keeping compatibility with the official programmers was a design goal. it certainly wasn't when I was hacking it up (when that blocksize was added)

On Sun, May 23, 2021 at 4:43 PM Hans @.***> wrote:

I tried to install cython and hidapi manually, just to see if it would work or not. Got this error with the MPLAB SNAP:

ersion 1.1.0 - May 2021 Using serial port at 115200 baud. Target: atmega4809 Set fuses: ['0:0x00', '1:0x54', '2:0x01', '4:0x00', '5:0xC9', '6:0x06', '7:0x00', '8:0x00'] Action: write File: /var/folders/6l/ypg6qbw172v1s4vtt6g990tw0000gn/T/arduino_build_1089/Blink.ino.hex Connecting to any snap Pinging device... Ping response: 1E9651 Setting fuse 0x0=0x0 Writing literal values... Verifying literal values... Action took 0.02s Setting fuse 0x1=0x54 Writing literal values... Verifying literal values... Action took 0.03s Setting fuse 0x2=0x1 Writing literal values... Verifying literal values... Action took 0.02s Setting fuse 0x4=0x0 Writing literal values... Verifying literal values... Action took 0.02s Setting fuse 0x5=0xc9 Writing literal values... Verifying literal values... Action took 0.02s Setting fuse 0x6=0x6 Writing literal values... Verifying literal values... Action took 0.02s Setting fuse 0x7=0x0 Writing literal values... Verifying literal values... Action took 0.02s Setting fuse 0x8=0x0 Writing literal values... Verifying literal values... Action took 0.02s Finished writing fuses. Chip/Bulk erase, Memory type eeprom is conditionally erased (depending upon EESAVE fuse setting) Memory type flash is always erased Memory type internal_sram is always erased Memory type lockbits is always erased ... Erased. Action took 0.01s Writing from hex file... Writing flash... Traceback (most recent call last): File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 266, in main() File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 121, in main return_code = pymcuprog_basic(args, fuses_dict) File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 234, in pymcuprog_basic run_pymcu_action(pymcu._action_write, backend, File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 131, in run_pymcu_action status = func(backend, *args, args_pymcu) File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pymcuprog/pymcuprog_main.py", line 341, in _action_write _write_memory_segments(backend, result, args.verify, blocksize=args.blocksize) File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pymcuprog/pymcuprog_main.py", line 392, in _write_memory_segments backend.write_memory(segment.data, memory_name, segment.offset, blocksize=blocksize) File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pymcuprog/backend.py", line 526, in write_memory self.programmer.write_memory(data=data, memory_name=memory_name, offset=offset_byte, blocksize=blocksize) File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pymcuprog/programmer.py", line 190, in write_memory self.device_model.write(memory, offset, data, blocksize=blocksize) An error occurred while uploading the sketch TypeError: write() got an unexpected keyword argument 'blocksize'

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MCUdude/MegaCoreX/issues/119#issuecomment-846621947, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW4JWJMHBJNEGGHLIM3TPFSILANCNFSM42Q3BMMA .

--

---

Spence Konde Azzy’S Electronics

New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore https://github.com/SpenceKonde/ATTinyCore: Arduino support for all pre-2016 tinyAVR with >2k flash! megaTinyCore https://github.com/SpenceKonde/megaTinyCore: Arduino support for all post-2016 tinyAVR parts! DxCore https://github.com/SpenceKonde/DxCore: Arduino support for the AVR Dx-series parts, the latest and greatest from Microchip! Contact: @.***

[SpenceKonde]

Quentin said to open an issue in the repo once we make it public (which will be really soon now)

On Sun, May 23, 2021 at 4:43 PM Hans @.***> wrote:

I tried to install cython and hidapi manually, just to see if it would work or not. Got this error with the MPLAB SNAP:

ersion 1.1.0 - May 2021 Using serial port at 115200 baud. Target: atmega4809 Set fuses: ['0:0x00', '1:0x54', '2:0x01', '4:0x00', '5:0xC9', '6:0x06', '7:0x00', '8:0x00'] Action: write File: /var/folders/6l/ypg6qbw172v1s4vtt6g990tw0000gn/T/arduino_build_1089/Blink.ino.hex Connecting to any snap Pinging device... Ping response: 1E9651 Setting fuse 0x0=0x0 Writing literal values... Verifying literal values... Action took 0.02s Setting fuse 0x1=0x54 Writing literal values... Verifying literal values... Action took 0.03s Setting fuse 0x2=0x1 Writing literal values... Verifying literal values... Action took 0.02s Setting fuse 0x4=0x0 Writing literal values... Verifying literal values... Action took 0.02s Setting fuse 0x5=0xc9 Writing literal values... Verifying literal values... Action took 0.02s Setting fuse 0x6=0x6 Writing literal values... Verifying literal values... Action took 0.02s Setting fuse 0x7=0x0 Writing literal values... Verifying literal values... Action took 0.02s Setting fuse 0x8=0x0 Writing literal values... Verifying literal values... Action took 0.02s Finished writing fuses. Chip/Bulk erase, Memory type eeprom is conditionally erased (depending upon EESAVE fuse setting) Memory type flash is always erased Memory type internal_sram is always erased Memory type lockbits is always erased ... Erased. Action took 0.01s Writing from hex file... Writing flash... Traceback (most recent call last): File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 266, in main() File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 121, in main return_code = pymcuprog_basic(args, fuses_dict) File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 234, in pymcuprog_basic run_pymcu_action(pymcu._action_write, backend, File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/prog.py", line 131, in run_pymcu_action status = func(backend, *args, args_pymcu) File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pymcuprog/pymcuprog_main.py", line 341, in _action_write _write_memory_segments(backend, result, args.verify, blocksize=args.blocksize) File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pymcuprog/pymcuprog_main.py", line 392, in _write_memory_segments backend.write_memory(segment.data, memory_name, segment.offset, blocksize=blocksize) File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pymcuprog/backend.py", line 526, in write_memory self.programmer.write_memory(data=data, memory_name=memory_name, offset=offset_byte, blocksize=blocksize) File "/Users/hans/Documents/Arduino/hardware/MegaCoreX/megaavr/tools/libs/pymcuprog/programmer.py", line 190, in write_memory self.device_model.write(memory, offset, data, blocksize=blocksize) An error occurred while uploading the sketch TypeError: write() got an unexpected keyword argument 'blocksize'

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MCUdude/MegaCoreX/issues/119#issuecomment-846621947, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW4JWJMHBJNEGGHLIM3TPFSILANCNFSM42Q3BMMA .

--

---

Spence Konde Azzy’S Electronics

New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore https://github.com/SpenceKonde/ATTinyCore: Arduino support for all pre-2016 tinyAVR with >2k flash! megaTinyCore https://github.com/SpenceKonde/megaTinyCore: Arduino support for all post-2016 tinyAVR parts! DxCore https://github.com/SpenceKonde/DxCore: Arduino support for the AVR Dx-series parts, the latest and greatest from Microchip! Contact: @.***

[MCUdude]

Quentin said to open an issue in the repo once we make it public

Which repo? You mean the Pymcuprog repo here? https://github.com/microchip-pic-avr-tools/pymcuprog

Just for fun I also installed "the real" Pymcuprog from Pip, but I couldn't get it to do anything (burn fuses, write hex). It seems like it has different flags than your prog.py script has, and it's difficult to figure out how to really use Pymcuprog since there is no user manual like Avrdude has.

[SpenceKonde]

No the repo that is currrently a private repo under his control that we will announce when it is made public

[MCUdude]

No the repo that is currently a private repo under his control that we will announce when it is made public

So what is the difference between his repo and Pymcuprog/Pyupdi? And what is it that his program can do that Pymcuprog/Pyupdi can't?

[SpenceKonde]

he wrote the wrapper that lets you pass all the information that you need to in one command from platform.txt, and I aggressively optimized for performance over a serial port to make it upload fast rather than mindnumblingly slowly

[MCUdude]

It looks like Avrdude is getting pyupdi/SerialUPDI style programming!

A bunch of patches and bug fixes has been applied to Avrdude recently, and SerialUPDI is being worked on. Screw pymcuprog, I'm waiting for the Avrdude implementation!

https://savannah.nongnu.org/bugs/?61624

[SpenceKonde]

But it's built on avrdude, which is a total dumpster fire

---

Spence Konde Azzy’S Electronics

New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: @.***

On Mon, Dec 6, 2021, 09:43 Hans @.***> wrote:

It looks like Avrdude is getting pyupdi/SerialUPDI style programming!

A bunch of patches and bug fixes has been applied to Avrdude recently, and SerialUPDI is being worked on. Screw pymcuprog, I'm waiting for the Avrdude implementation!

https://savannah.nongnu.org/bugs/?61624

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MCUdude/MegaCoreX/issues/119#issuecomment-986840487, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW5LBEUSQ35MKFUWHJDUPTDZNANCNFSM42Q3BMMA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[SpenceKonde]

And to expand on that point - in my view, the possibly the best thing about SerialUPDI was that it didn't involve avrdude. I wanted to get the Microchip USB programming tools moved over to it, and am planning to look for python replacements for stk500/arduino protocols so we could have them give people sensible messages instead of displaying values foir oparameters with no basis in reality, and telling people who softbrick their chip by setting it to use a non-present clock source that -f might fix it... That's a 5 minute fix. Nobody has done it in over a decade I could do it - but I don;'t have the build environments needed to compile it for all 6-7 platforms that it would need to be compiled for.... There is a huge barrier to entry with patching or modifying something like that, because ti do anything with it, you need to make a shitload of versions of it. I don't know how to crosscompile for windows, much less darwin/mac. but a fixed version doesn;t mean shit if people can't use it.

Avrdude suffers from one of the worst cases of kitchensinkism I have seen, Every dumbass programming method ever combined into one giant, poorly organized mess.

If I had more time to work on this, I would strip out every trace of avrdude from my cores. It is an abomination.

[MCUdude]

I wanted to get the Microchip USB programming tools moved over to it, and am planning to look for python replacements for stk500/arduino protocols so we could have them give people sensible messages instead of displaying values foir oparameters with no basis in reality, and telling people who softbrick their chip by setting it to use a non-present clock source that -f might fix it... That's a 5 minute fix. Nobody has done it in over a decade I could do it

Really, is these error messages the reason why you want to ditch Avrdude? So submit an issue then! There are developers working on it right now, use your opportunity!

Avrdude suffers from one of the worst cases of kitchensinkism I have seen, Every dumbass programming method ever combined into one giant, poorly organized mess.

I have no idea what kitchensinkism means, but I don't really care what the source code looks like as long as I have a binary that works and is reliable. And I have yet to experience Avrdude as unreliable for the programmers I use with it.

[SpenceKonde]

It means that they have thrown "everything but the kitchen sink" in, haphazardly and without a coherent plan, the documentation is terse at best, and comprehensive documentation (the source code, often the only documentation there is) is awful. Despite it having such a proliferation of options, we still end up telling it that our bootloaders are an stk500 programmer (out of production for got only knows how long) so it sends back bogus information that would have made sense if it were an stk500 programmer.
And there's a barrier to entry for building and distributing it because you need to be able to generate binaries for multiple platforms - The arduino packages support 6 platforms. With python, you just distribute it, and there's a ready made package you can point to to get the python interpreter. With avrdude you need to set up a build environment that can cross-compile for 32-bit arm linux, 64-bit arm linux, 32-bit x86 linux, x64 linux, windows, and mac.... So even if you get through the impenetrable code, and make the changes you need to, that doesn't get you a binary to test with (I imagine it's fairly easy to build on x64 linux, but I run windows, and every time I've been involved in something beingbuilt for windows it's been a mess). So there's a level of exclusivity around it that isn't an issue with with python tooling.

[SpenceKonde]

Well, because I must have been doing something wrong when I was trying to do it with references, and once I made it work with pointers, I didn't go backl to references and try to figure out why it wasn't working for me., and I just didn't think of testing them directly.

I think in the case of the TCB'sthe sort of trickery I use could reduce code size a tiny bit, but I'm not certain, and for the parts that care (which only have 2 TCBs at most), it won't save space.

But yeah, that alternative never crossed my mind. If that works and is the same or smaller compiled, than by all means!

If that works, then the best implementation I think would be this - no part-specific knowledge is needed whatsoever. All it needs to know is if AC0, AC1 and AC2 exist, and the only assumption it makes is that for ACn, n < 3 and there is an ACn-1 and so on.

gen::generator_t Event::gen_from_peripheral(AC_t& comp)
{
#if defined(AC0)
  #if defined(AC1) ||  defined(AC2)
    if (&comp == &AC0) 
  #endif
    return gen::ac0_out;
  else 
  #if defined(AC1)
    if (&comp == &AC1) 
  #endif
    return gen::ac1_out;
  else 
  #if defined(AC2)
    if(&comp == &AC2)
      return gen::ac2_out;
  #endif
  else 
#endif
    return (gen::generator_t) -1; //is there a better way to indicate something that will be rejected by anything that takes a generayor?
}

[m12lrpv]

I copied the pymcuprog implementation (pyupdi compatible) from megaTinyCore to try it out with MegaCoreX. It works great! The only thing I had to tweak was the resistor value. For some reason, a 1k resistor was too high for an ATmega3208. A 470R did the trick

Is there any progress on this.

Given you have said that you were able to copy the implementation and it worked... How do the rest of us do the same.

I'm trying to program using your core and choosing the megaTinyCore SerialUPDI as the programmer and getting errors...

I'm presently updating arduino to the megaTinyCore recommended version and will try again but i'm asking now in case there's something arduino ide requires that i'm not aware of or alternatively if there's a manual way to do the programming.

[MCUdude]

Avrdude 7.0 will soon be released and has native support for SerialUPDI, including the speed optimizations megaTinyCore and DxCore has. Avrdude 7.0 will be bundled with MegaCoreX as soon as it has been released.

https://github.com/avrdudes/avrdude

[m12lrpv]

Thanks. But I got it working. To anyone else... Copy the 2 tools folders from megaTinyCore to MegaCoreX

Arduino 1.8.13 megaTinyCore 2.5.11 MegaCoreX 1.0.10

Add these to your boards.txt for any chips you want to program. In my case it was the 4809

# SerialUPDI hack
4809.upload.workaround=
4809.upload.prog_interlock=

Add this to MegaCoreX programmers.txt

serialupdi57k.name=SerialUPDI - SLOW: 57600 baud, any platform, any voltage, any adapter.
serialupdi57k.protocol=uart
serialupdi57k.program.extra_params=-u {serial.port} -b 57600
serialupdi57k.program.protocol=uart
serialupdi57k.program.tool=serialupdi
serialupdi57k.bootloader.tool=serialupdi

Add this to the MegaCoreX platform.txt

##############################################################
# Serial UPDI - UPDI uploads using a serial adapter directly #
##############################################################
# Board manager installations have the python executable in  #
# different location than a manual installation. The package #
# build script deletes the line starting with                #
# tools.serialupdi.cmd                                       #
# and the #REMOVE#, leaving the correct path.                #
##############################################################

#tools.serialupdi.cmd={runtime.platform.path}/tools/python3/python3
tools.serialupdi.cmd={runtime.tools.python3.path}/python3

## Unused Parameters.
# SerialUPDI has only one level of verbosity.
# There's an *actual* internal verbose mode, but it is WAY too verbose and results >500kb log files which are mostly useless.
# Verification is not optional as there are no guardrails against unsuccessful uploads other than protocol failures
# Upload is only for uploading through a bootloader, and erase is not used anywhere.
tools.serialupdi.bootloader.params.noverify=
tools.serialupdi.bootloader.params.quiet=
tools.serialupdi.bootloader.params.verbose= -v
tools.serialupdi.bootloader.verify=
tools.serialupdi.erase.params.quiet=
tools.serialupdi.erase.params.verbose= -v
tools.serialupdi.erase.pattern=
tools.serialupdi.program.params.noverify=
tools.serialupdi.program.params.quiet=
tools.serialupdi.program.params.verbose= -v
tools.serialupdi.program.verify=
tools.serialupdi.upload.params.noverify=
tools.serialupdi.upload.params.quiet=
tools.serialupdi.upload.params.verbose= -v
tools.serialupdi.upload.verify=
tools.serialupdi.upload.pattern=echo "This can't happen, but has to be here or automated tests fail"

## Tools -> Burn Bootloader pattern
# write fuses 0, 1, 2, 4 (1-series only), 5, 6, 7, 8.
# If fuse 4 (TCD0CFG) is written, it is always written to 0

tools.serialupdi.bootloader.pattern="{cmd}" -u "{runtime.platform.path}/tools/prog.py"  -t {protocol} {program.extra_params} -d {build.mcu}{upload.workaround} --fuses 0:{bootloader.WDTCFG} 1:{bootloader.BODCFG} 2:{bootloader.OSCCFG} {bootloader.TCD0CFG_serialupdi} 5:{bootloader.SYSCFG0} 6:{bootloader.SYSCFG1} 7:{bootloader.APPEND} 8:{bootloader.BOOTEND} {bootloader.serialupdistring} {bootloader.verbose}

## Program pattern (all uploads through SerialUPDI)
# Program will set fuses 2, 6 and 8 only. Fuses 0 and 4 are not written because the core never configures that.
# If a user went and set that themselvesm we shouldn't undo it.
# Fuse 1 is the BOD configuration, which could "brick" the chip if set for a higher voltage than the power rail.
# Fuse 5 is SYSCFG0 which could disable UPDI and leave the board programmable without HV programming.
# That leaves OSCCFG to choose 16 vs 20 MHz clock, and SYSCFG1 (for startup time and stuff) and BOOTEND,
# ensuring that a part previously set to use a bootloader will be unbootloaded cleanly, instead of the
# bootloader being erased but no sketches working)

tools.serialupdi.program.pattern={upload.prog_interlock}"{cmd}" -u "{runtime.platform.path}/tools/prog.py"  -t {protocol} {program.extra_params} -d {build.mcu}{upload.workaround} --fuses 2:{bootloader.OSCCFG} 6:{bootloader.SYSCFG1} 8:{bootloader.BOOTEND} "-f{build.path}/{build.project_name}.hex" -a write {program.verbose}

##############################################################
# Serial UPDI - UPDI uploads using a serial adapter directly #
##############################################################
# Board manager installations have the python executable in  #
# different location than a manual installation. The package #
# build script deletes the line starting with                #
# tools.serialupdi.cmd                                       #
# and the #REMOVE#, leaving the correct path.                #
##############################################################

#tools.serialupdi.cmd={runtime.platform.path}/tools/python3/python3
tools.serialupdi.cmd={runtime.tools.python3.path}/python3

## Unused Parameters.
# SerialUPDI has only one level of verbosity.
# There's an *actual* internal verbose mode, but it is WAY too verbose and results >500kb log files which are mostly useless.
# Verification is not optional as there are no guardrails against unsuccessful uploads other than protocol failures
# Upload is only for uploading through a bootloader, and erase is not used anywhere.
tools.serialupdi.bootloader.params.noverify=
tools.serialupdi.bootloader.params.quiet=
tools.serialupdi.bootloader.params.verbose= -v
tools.serialupdi.bootloader.verify=
tools.serialupdi.erase.params.quiet=
tools.serialupdi.erase.params.verbose= -v
tools.serialupdi.erase.pattern=
tools.serialupdi.program.params.noverify=
tools.serialupdi.program.params.quiet=
tools.serialupdi.program.params.verbose= -v
tools.serialupdi.program.verify=
tools.serialupdi.upload.params.noverify=
tools.serialupdi.upload.params.quiet=
tools.serialupdi.upload.params.verbose= -v
tools.serialupdi.upload.verify=
tools.serialupdi.upload.pattern=echo "This can't happen, but has to be here or automated tests fail"

## Tools -> Burn Bootloader pattern
# write fuses 0, 1, 2, 4 (1-series only), 5, 6, 7, 8.
# If fuse 4 (TCD0CFG) is written, it is always written to 0

tools.serialupdi.bootloader.pattern="{cmd}" -u "{runtime.platform.path}/tools/prog.py"  -t {protocol} {program.extra_params} -d {build.mcu}{upload.workaround} --fuses 0:{bootloader.WDTCFG} 1:{bootloader.BODCFG} 2:{bootloader.OSCCFG} {bootloader.TCD0CFG_serialupdi} 5:{bootloader.SYSCFG0} 6:{bootloader.SYSCFG1} 7:{bootloader.APPEND} 8:{bootloader.BOOTEND} {bootloader.serialupdistring} {bootloader.verbose}

## Program pattern (all uploads through SerialUPDI)
# Program will set fuses 2, 6 and 8 only. Fuses 0 and 4 are not written because the core never configures that.
# If a user went and set that themselvesm we shouldn't undo it.
# Fuse 1 is the BOD configuration, which could "brick" the chip if set for a higher voltage than the power rail.
# Fuse 5 is SYSCFG0 which could disable UPDI and leave the board programmable without HV programming.
# That leaves OSCCFG to choose 16 vs 20 MHz clock, and SYSCFG1 (for startup time and stuff) and BOOTEND,
# ensuring that a part previously set to use a bootloader will be unbootloaded cleanly, instead of the
# bootloader being erased but no sketches working)

tools.serialupdi.program.pattern={upload.prog_interlock}"{cmd}" -u "{runtime.platform.path}/tools/prog.py"  -t {protocol} {program.extra_params} -d {build.mcu}{upload.workaround} --fuses 2:{bootloader.OSCCFG} 6:{bootloader.SYSCFG1} 8:{bootloader.BOOTEND} "-f{build.path}/{build.project_name}.hex" -a write {program.verbose}

Now commit them to your own repo so that when they get overwritten by an update you can diff them and restore the change.

Happy programming everyone.

[MCUdude]

SerialUPDI is now supported in the latest boards manager release thanks to Avrdude 7.0!