Half assing AVR-DA without a Dragon - Page 1
Forum section: electronics / general

author: T3sl4co1l
author_rank: Super Contributor
timestamp: October 26, 2021, 04:20:58 pm
content: So this thing exists,https://github.com/mraardvark/pyupdiBut there doesn't seem to be a compiled/configured/ready-to-go version of it. Guess I have to install Python (which I've managed to avoid for a surprisingly, perhaps embarrassingly, long time).Ok, download 3.8 (last version supporting Win7), install it. Installer didn't seem to set paths, or maybe it expects to be used from own current directory; which would be strange, but it's under AppData, so I guess it doesn'treallymatter? Easy enough to set up myself. Also set a path to Scripts, since I guess I need pip to work.Run the pip command, it does indeed find the repo, puts it in /Lib/site-packages I see. Ok.Emits some warning about pip having a newer version. Seems good. Run pip update directly (note, it said to do it via python). Hmm, the pip EXEs all updated, and all of them generate runtime errors. Well that's not good. Look up how to fix it. Ah, run ensurepip. Fixes it. Run the correct python pip update command. Seems fine. Why would it be able to brick itself though?Ok. Have Python, have pyupdi installed. Is it... just a module? No, it doesn't execute. Seems like I could put in a __main__ very easily myself, but is there some reason it's not there already? Without knowing the reason I'd rather not screw with it. How, then, to invoke it? If I enter a path it'll just look for the path, not relative. That's no good. Surely I'm not supposed topython C:\Users\<me>\AppData\Local\Programs\Python\Python38\Lib\site-packages\updi\pyupdi.pyevery fucking time I want to run this thing. Right? ...Right?Poke around a bit, find I can invoke it bypython -m updi.pyupdi. It emits a warning about finding it in sys.modules after import of package. But it seems to run. Safe to ignore? No one else mentions having warnings. Well, of the two or three websites I've found using this tool, no idea about chats/forums, those don't exist on the internet anymore. 👀 But they also don't mention anything else either, this is just automatic and expected...Anyway, wired up a AVR64DA32, with the resistor and a MAX232 and USB serial dongle (I don't happen to have any TTL-level dongles around, oddly enough), runningpython -m updi.pyupdi -d avr64da32 -c <COM port> -i, from anywhere with the paths set up, seems to detect the device, yay (signature '1E9614' as expected).Like, is this supposed to be this awkward? Is it my fault for being on Windows? (Yes, but still. There's always some traditional working environment. Did I just guess wrong, which kind here?) If I was 10 again I have no doubt I'd understand the intricacies of a Python distro in no time, but alas it didn't exist back then, all I had was QBASIC to poison my mind..Anyway, now onto the GCC toolchain...Tim

author: Siwastaja
author_rank: Super Contributor
timestamp: October 26, 2021, 06:05:57 pm
content: Completely normal python experience. You missed the usual step that nowhere it's described which language it is (there is no such thing as "Python"; there are Python2 and Python3) so you try to run it on the wrong Python, it kinda works, you kinda get all the gazillion libraries and dependencies installed after fixing a few cryptic errors, on that wrong Python, and finally you figure out that D'oh, should have used pip2/pip3/python2/python3 instead, and you download and install the correct Python and pip and start over, again fixing different cryptic errors and dependencies.With all this, I wonder how Python seemingly is so popular, even among individuals I know are otherwise completely sane, rational and capable.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: October 26, 2021, 08:38:19 pm
content: Well, that would be a problem, I suppose. Fortunately this specifies Python 3.It's fantastically compact compared to most distributions: I've also got a copy of Cygwin64 (650MB), mingw32 (300MB), mingw64 (460MB), and assorted other stuff, so just POSIX/GCC environment(s) totaling 1.5GB. I've got Ruby 2.7 (for one thing I tried out) taking a cool 1.1GB, and PHP 7.1 and 7.3 (for one other thing) totaling 320MB.Of those, Ruby I know very little about, PHP7 isn't as much of an embarrassment as its earlier predecessors were (but, I think, still has some notorious cruft in the library functions?), and the GNU stuff is all over the place as usual (either it Just Works(TM), or you'll encounter a zillion inscrutable errors that only a kernel debugging could solve). Python and PHP are the most compact by far, and as far as I know, the most usable, just sit down in an interpreter and play. Copy some lines into a script file and save, now you have something to build on.Software in general, my impression isn't that it's the fault of any particular distribution; most of them, that are extremely popular and well maintained, are that way for a reason, and are easy to use on any similarly mainstream system/configuration. (Heck, MicroPython is even supported on modest MCUs. It's no BASIC, but it's probably the closest thing today, and as powerful as one expects of languages these days.) It's when you stray off that path, or use something less easy-to-use / well-documented, or something completely arbitrary like most any corporate codebase, that you get into the land of inscrutable bullshit.Also expectation, to a certain extent. Free projects are, by and large, put out there for convenience, and are worth precisely what you paid for it, if you know what I mean. Like, the stuff I posted on Github, is only confirmed as meaningful to me, and maybe someone's found snippets, or the whole things, useful in some way, but it's also doubtful that anyone else has built the exact projects, without changes, drop in and go. (Well, aside from the HTML+CSS+JS projects, that's kind of trivial, heh.) Particularly where hardware is involved, and if that should differ, it could be a little bit to a huge pile of work to port it over.So, that said, I expect Python to work, and it does seem to be quite easy to install, compact, and I'll likely give it some use for easy scripty things over the JS or other things I've been using. The pyupdi thing, however, is just a personal project AFAIK, and clearly doesn't have any intention of being... necessarily usable, out of the box? I mean the readme just barely says what it is, and says nothing about how to use it. The author knows what they're doing, that's good enough for them, right?Tim

author: westfw
author_rank: Super Contributor
timestamp: October 26, 2021, 11:07:03 pm
content: QuoteI don't think so. When I tried it, I got a pyupdi.exe inC:\Users\billw\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\local-packages\Python38\Scripts\pyupdi.exeThat's a very weird place to put executable, and it wasn't in my path either, but if it were, a lot of the subsequent difficulties OP describe would not have happened.(Windows in general seems to have a problem with "apps" that can install other applications. You're lucky it doesn't consider python a a virus.)

author: mraardvark
author_rank: Newbie
timestamp: October 27, 2021, 05:20:50 am
content: Yes, Python has its issues...at least you can drop pyupdi and just go for pymcuprogif you have a py35-39 installed, and selected the "add scripts to path" when you installed, then you can just install using:pip install pymcuprogand then run it using:pymcuprog --helpnot _that_ bad, is it?

author: fchk
author_rank: Frequent Contributor
timestamp: October 27, 2021, 09:42:05 am
content: Microchip MPLABX plus a Snap or PICKIT4 does not work for you? It's all there, ready to use.fchk

author: T3sl4co1l
author_rank: Super Contributor
timestamp: October 27, 2021, 01:40:20 pm
content: Quote from: mraardvark on October 27, 2021, 05:20:50 amHi, welcome! Also, thanks!Yeah but it's just a script, isn't that missing something?Waaaaait, it grabbed an EXE too, put under Scripts. Unexpected, but a welcome surprise.Is pymcuprog the preferred, or better maintained or more usable or etc. package then? I mean, it's mentioned on the README, but it's not exactly a firm instruction to go use it instead.It's a shame that pyupdi is exactly what I'm searching for (i.e., something to run UPDI), so of course it shows up first in results...Quote from: fchk on October 27, 2021, 09:42:05 amI would've used AVR Studio but once they migrated to VS it bloated from a casual 500MB or whatever it was, to literally five gigs, two of whichmustbe installed on the C: drive. WTF? And MPLABX is just the evolution of that, then?Tim

author: oPossum
author_rank: Super Contributor
timestamp: October 27, 2021, 03:27:50 pm
content: MPLAB X is Netbeans, not VS. It is ~600 MB for the IDE. Compilers are separate.There is also a standalone programming utility (MPLAB IPE) if you just want to do programming using a SNAP or PICkit4.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: October 27, 2021, 03:38:04 pm
content: Ok so I've got the toolchain building, or nearly so, albeit with -B and a jank ass path to the device-specs file that GCC doesn't know about by default (does it not just search everything under its path? I don't quite get it..). Not sure if I just put these files in the wrong place again, or what. (I could stand to upgrade from GCC 8.1 to, what's out now, 11? And I see someone's forked and improved(?) to a libc3, though it still doesn't have includes for the latest devices. But I kind of don't want to, as it'll probably break old projects. Ugh, dependencies.)So there's one thing remaining. I see quite clearly, the specs file contains this line,Code:*link_data_start:-Tdata 0x806000and the linker generates this error,ld.exe: address 0x806000 of Debug\DA_Test.elf section `.data' is not within region `data'and, I don't think there's device-specific linker scripts or anything? These are pretty simple devices relative to others, and in any case the datasheet clearly says SRAM starting at 0x4000, length 0x4000.Also, from searching the label, it sounds like a linker script won't override this anyway.So, uh, one: why is this line apparently wrong, and, is it okay to just change it?Should I, Idunno, pull request to the MCP repo I downloaded it from? Surely they know better...??!Tim

author: T3sl4co1l
author_rank: Super Contributor
timestamp: October 27, 2021, 04:46:00 pm
content: Scratch that, the datasheet diagram is misleading. The model I'm using has SRAM at 0x6000 to 0x7fff.So the spec is correct, and the link scripts are bad?https://www.avrfreaks.net/comment/2905251#comment-2905251This seems to suggest so. And changing the .x* files (or, uh, most of them, I don't know which one it's using I just changed until it worked) as suggested, seems to fix it.By god, it's not actually me this time? What the hell!Tim

author: mraardvark
author_rank: Newbie
timestamp: October 27, 2021, 08:39:25 pm
content: Quote from: T3sl4co1l on October 27, 2021, 01:40:20 pmpymcuprog is maintained by Microchip, so- new devices are released regularly- it has more features- its in a CICD system, so its known to work (in theory- its released to pypi and github (snapshot)The catch is that its actually intended primarily for using with EDBG/nEDBG/Atmel-ICE etc... but the pyupdi ("serialupdi") implementation slots in nicely inside the same wrapper and also get the same test coverage, almost for free.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: October 27, 2021, 09:57:51 pm
content: Sounds nice, but uh, is there any actual... documentation?There's this, which looks to be "the" official thing,https://microchip-pic-avr-tools.github.io/pymcuprog/index.htmland,- Overviewright, I get that- Library usagefine for those that need it- Support, Dependenciesokay sure but...- Indexthere's... there's command line parameters in here, right?They're documented, right?I would love totryit, I think I've got more or less the right magic incantation, but.. it doesn't even say the most basic things like what file formats it uses, or what literally any of the options do (beyond their obvious meanings, when applicable), let alone what values they can take (other than the -v and -H options, whatever those do, and wherever the "action"? word is supposed to fit in).Like, just offhand, pyupdi takes some oddly verbose/literal fuse format, which I can write a converter for I suppose; while this... maybe takes binary? I can't even tell, I literally have to read the source to puzzle it out.Interestingly, flashing a bin file seems to work. Bin fuse doesn't though.On the pyupdi, speaking of -- it talks but doesn't program. Maybe I fed it the wrong data (which... again...), but it just sits in an infinite loop while, I think merely maintaining keepalive on the bus (I'm watching UPDI on the scope, not for any particular purpose just out of curiosity).Tim

author: westfw
author_rank: Super Contributor
timestamp: October 28, 2021, 01:37:00 am
content: USER documentation? In a FILE? That you can read before you install it? Inconceivable!It does mention "pymcuprog --help", if you dig a bit...Code:pymcuprog --helpusage: pymcuprog [-h] [-d DEVICE] [-p PACKPATH] [-t TOOL] [-s SERIALNUMBER][-m MEMORY] [-o OFFSET] [-b BYTES] [-l LITERAL [LITERAL ...]][-f FILENAME] [-c CLK] [-u UART] [-i INTERFACE][-v {debug,info,warning,error,critical}] [-V] [-R] [--verify][-x][-H {tool-toggle-power,user-toggle-power,simple-unsafe-pulse}][-U] [-C]{ping,erase,read,write,verify,getvoltage,getsupplyvoltage,reboot-debugger,setsupplyvoltage,getusbvoltage,reset}Generic programmer of selected AVR, PIC and SAM devicesBasic actions:- ping: reads the device ID or signature- read: read NVM- write: write NVM- erase: erase NVMpositional arguments:{ping,erase,read,write,verify,getvoltage,getsupplyvoltage,reboot-debugger,setsupplyvoltage,getusbvoltage,reset}action to performoptional arguments:-h, --help show this help message and exit-d DEVICE, --device DEVICEdevice to program-p PACKPATH, --packpath PACKPATHpath to pack-t TOOL, --tool TOOL tool to connect to-s SERIALNUMBER, --serialnumber SERIALNUMBERUSB serial number of the unit to use-m MEMORY, --memory MEMORYmemory area to access: all, 'calibration_row','config_words', 'eeprom', 'flash', 'fuses', 'icd','internal_sram', 'lockbits', 'signatures', 'user_id','user_row'-o OFFSET, --offset OFFSETmemory byte offset to access-b BYTES, --bytes BYTESnumber of bytes to access-l LITERAL [LITERAL ...], --literal LITERAL [LITERAL ...]literal values to write-f FILENAME, --filename FILENAMEfile to write / read. Note that when reading to hexfile only eeprom, flash, fuses, config_words, user_rowmemories will be written to the hex file-c CLK, --clk CLK clock frequency in Hz (bps) for programming interface.(eg: '-c 32768' or '-c 115k' or '-c 1M')-u UART, --uart UART UART to use for UPDI-i INTERFACE, --interface INTERFACEInterface to use-v {debug,info,warning,error,critical}, --verbose {debug,info,warning,error,critical}Logging verbosity level-V, --version Print pymcuprog version number and exit-R, --release-info Print pymcuprog release details and exit--verify verify after write from file-x, --timing add timing output-H {tool-toggle-power,user-toggle-power,simple-unsafe-pulse}, --high-voltage {tool-toggle-power,user-toggle-power,simple-unsafe-pulse}UPDI high-voltage activation mode-U, --user-row-locked-deviceWrites the User Row on a locked device (UPDI devicesonly)-C, --chip-erase-locked-deviceExecute a Chip Erase on a locked device (UPDI devicesonly)Usage examples:Ping a device on-board a kit:- pymcuprog.py pingPing a device using Atmel-ICE- pymcuprog.py -t atmelice -d atmega4809 -i updi pingRead the some bytes of flash:- pymcuprog.py read -m flash -o 0x80 -b 64Erase an UPDI device:- pymcuprog.py eraseErase a locked UPDI device:- pymcuprog.py erase --chip-erase-locked-deviceSet target supply voltage on a kit:- pymcuprog.py setsupplyvoltage -l 3.3

author: westfw
author_rank: Super Contributor
timestamp: October 28, 2021, 01:38:53 am
content: (the help examples are wrong, mostly. At least with my install, you won't want to specify the ".py" on the command line. Sigh.)But .. it's GOOD, overall. I wish more vendors would provide source code to program their chips via assorted programmers, that you could build your own apps around. Even if the documentation IS a bit behind their "preferred vendor-proprietary tools.

author: mraardvark
author_rank: Newbie
timestamp: October 28, 2021, 06:32:26 am
content: You know, you could always log a bug (or even a feature request) on the github repo.Or just complain amongst yourselves here...

author: fchk
author_rank: Frequent Contributor
timestamp: October 28, 2021, 07:31:05 am
content: Quote from: T3sl4co1l on October 27, 2021, 01:40:20 pmAVR Studio is from Atmel for AVR and got to Microchip by buying Atmel. Windows only It's basically a dead end, along with the former Atmel tools.MPLABX is from Microchip and was originally deleloped for PICs. After the Atmel purchase it got support for Atmel chips - along with the PICKIT tools. PICKIT4 and ICD4 got two more IO lines in order to support the ATMEL chips in addition to PIC ICSP. This is where Microchip puts its efforts into.MPLABX is multi-platform (Windows, Linux, MacOSX).fchk

author: westfw
author_rank: Super Contributor
timestamp: October 28, 2021, 08:17:13 am
content: QuoteDone:https://github.com/microchip-pic-avr-tools/pymcuprog/issues/7

author: T3sl4co1l
author_rank: Super Contributor
timestamp: October 28, 2021, 02:44:31 pm
content: Quote from: westfw on October 28, 2021, 01:37:00 amYeah I saw that, also on the docs. This one (technically from a 3rd party, I think? but linked from the other page),https://pypi.org/project/pymcuprog/at least goes into a little actual detail about the options. But still not a peep about file formats, no list of supported tools. And an example is given with a .hex file, which seems suspicious as hell to me; does it actually check extension, then? Or what?So I've managed to get successful flashing, sometimes.pyupdi is inconsistent. It's not clear to me why, but sometimes it goes into an apparent loop. This was confirmed with -v, at least as far as what I can see flipping past. Though it looks different by the end, but I think I've already hit CTRL+C by then so I don't know if that's exit code or what. Then it fails in a TypeError stack trace.Here's the case when it fails out by itself:pyupdi -d avr64da32 -c com11 -v -f "\Debug\DA_Test.hex"Code:INFO:phy send 5 bytesINFO:phy data: : [0x55, 0x8, 0x2, 0x10, 0x0]INFO:phy receive : INFO:link LD from 0x001002INFO:phy send 5 bytesINFO:phy data: : [0x55, 0x8, 0x2, 0x10, 0x0]INFO:phy receive : INFO:link LD from 0x001002INFO:phy send 5 bytesINFO:phy data: : [0x55, 0x8, 0x2, 0x10, 0x0]INFO:phy receive : INFO:nvm Padding to blocksize 256 with 0xFFINFO:nvm Paging into 256 byte blocksINFO:nvm Writing page at 0x800000Traceback (most recent call last):File "C:\Users\Tim Williams\AppData\Local\Programs\Python\Python38\Scripts\pyupdi-script.py", line 33, in <module>sys.exit(load_entry_point('pyupdi==0.0.0', 'console_scripts', 'pyupdi')())File "c:\users\tim williams\appdata\local\programs\python\python38\lib\site-packages\updi\pyupdi.py", line 111, in _mainif not _process(nvm, args):File "c:\users\tim williams\appdata\local\programs\python\python38\lib\site-packages\updi\pyupdi.py", line 136, in _processreturn _flash_file(nvm, args.flash)File "c:\users\tim williams\appdata\local\programs\python\python38\lib\site-packages\updi\pyupdi.py", line 151, in _flash_filenvm.write_flash(start_address, data)File "c:\users\tim williams\appdata\local\programs\python\python38\lib\site-packages\updi\nvm.py", line 111, in write_flashreturn self._write_mem(address, data, self.device.flash_pagesize, use_word_access=True)File "c:\users\tim williams\appdata\local\programs\python\python38\lib\site-packages\updi\nvm.py", line 133, in _write_memself.application.write_nvm(address, page, use_word_access=use_word_access)TypeError: write_nvm_v1() got an unexpected keyword argument 'use_word_access'INFO:phy Closing port 'com11'It seems to erase, well enough:pyupdi -d avr64da32 -c com11 -e -vI may have to CTRL+C this (infinite? loop) then run it again, and that seems to make it work.It seems like I can attempt a flash write, then erase, then a slightly different flash write (I've commented out some stuff in the program and compiled again to cause this change), and this causes it to loop. (The "Device is locked" line appears more or less when I CTRL+C.)Code:...INFO:phy send 2 bytesINFO:phy data: : [0x55, 0x8b]INFO:phy receive : INFO:app Wait for NVMPROGINFO:link LDCS from 0x0BINFO:phy send 2 bytesINFO:phy data: : [0x55, 0x8b]INFO:phy receive : INFO:app Wait for NVMPROGINFO:link LDCS from 0x0BINFO:phy send 2 bytesINFO:phy data: : [0x55, 0x8b]Device is locked. Performing unlock with chip erase.INFO:link Writing keyINFO:phy send 2 bytesINFO:phy data: : [0x55, 0xe0]INFO:phy send 8 bytesINFO:phy data: : [0x65, 0x73, 0x61, 0x72, 0x45, 0x4d, 0x56, 0x4e]INFO:link LDCS from 0x07INFO:phy send 2 bytesINFO:phy data: : [0x55, 0x87]INFO:phy receive : INFO:app Key status = 0x08INFO:link LDCS from 0x0BINFO:phy send 2 bytesINFO:phy data: : [0x55, 0x8b]INFO:phy receive : INFO:app Entering NVM programming modeINFO:link Writing keyINFO:phy send 2 bytesINFO:phy data: : [0x55, 0xe0]INFO:phy send 8 bytesINFO:phy data: : [0x20, 0x67, 0x6f, 0x72, 0x50, 0x4d, 0x56, 0x4e]INFO:link LDCS from 0x07INFO:phy send 2 bytesINFO:phy data: : [0x55, 0x87]INFO:phy receive : INFO:app Key status = 0x18INFO:app Apply resetINFO:link STCS 0x59 to 0x08INFO:phy send 3 bytesINFO:phy data: : [0x55, 0xc8, 0x59]INFO:app Check resetINFO:link LDCS from 0x0BINFO:phy send 2 bytesINFO:phy data: : [0x55, 0x8b]INFO:phy receive : INFO:app Release resetINFO:link STCS 0x00 to 0x08INFO:phy send 3 bytesINFO:phy data: : [0x55, 0xc8, 0x0]INFO:app Wait for !resetINFO:link LDCS from 0x0BINFO:phy send 2 bytesINFO:phy data: : [0x55, 0x8b]INFO:phy receive : INFO:app Wait for !resetINFO:link LDCS from 0x0BINFO:phy send 2 bytesINFO:phy data: : [0x55, 0x8b]INFO:phy receive : INFO:link LDCS from 0x0BINFO:phy send 2 bytesINFO:phy data: : [0x55, 0x8b]INFO:phy receive : INFO:nvm Reading device infoINFO:phy send 2 bytesINFO:phy data: : [0x55, 0xe5]INFO:app SIB read out as: bytearray(b'AVR P:2D:1-3')INFO:app Device family ID: 'AVR'INFO:app NVM interface: 'P:2'INFO:app Using PDI v2INFO:link Using 24-bit updiINFO:app Debug interface: 'D:1'INFO:app PDI oscillator: '3MHz'INFO:link LDCS from 0x00INFO:phy send 2 bytesINFO:phy data: : [0x55, 0x80]INFO:phy receive : INFO:app PDI revision = 0x3INFO:link LDCS from 0x0BINFO:phy send 2 bytesINFO:phy data: : [0x55, 0x8b]INFO:phy receive : INFO:app Reading 3 bytes from 0x1100INFO:link ST to ptrINFO:phy send 5 bytesINFO:phy data: : [0x55, 0x6a, 0x0, 0x11, 0x0]INFO:phy receive : INFO:link Repeat 3INFO:phy send 3 bytesINFO:phy data: : [0x55, 0xa0, 0x2]INFO:link LD8 from ptr++INFO:phy send 2 bytesINFO:phy data: : [0x55, 0x24]INFO:phy receive : [0x1e, 0x96, 0x14]INFO:app Device ID = '1E9614'INFO:app Reading 1 bytes from 0x0F01INFO:link ST to ptrINFO:phy send 5 bytesINFO:phy data: : [0x55, 0x6a, 0x1, 0xf, 0x0]INFO:phy receive : INFO:link LD8 from ptr++INFO:phy send 2 bytesINFO:phy data: : [0x55, 0x24]INFO:phy receive : INFO:app Device rev = '1.3'Device info: {'family': 'AVR', 'nvm': 'P:2', 'ocd': 'D:1', 'osc': '3', 'device_id': '1E9614', 'device_rev': '1.3'}INFO:nvm Loading from hexfile 'Debug\DA_Test.hex'INFO:nvm Loaded 8312 bytes from ihex starting at address 0x0000INFO:nvm Adjusting offset to address 0x800000INFO:app Chip erase using NVM CTRLINFO:app Wait flash readyINFO:link LD from 0x001002INFO:phy send 5 bytesINFO:phy data: : [0x55, 0x8, 0x2, 0x10, 0x0]INFO:phy receive : INFO:app NVMCMD 32 executingINFO:link ST to 0x001000INFO:phy send 5 bytesINFO:phy data: : [0x55, 0x48, 0x0, 0x10, 0x0]INFO:phy receive : INFO:phy send 1 bytesINFO:phy data: : INFO:phy receive : INFO:app Wait flash readyINFO:link LD from 0x001002INFO:phy send 5 bytesINFO:phy data: : [0x55, 0x8, 0x2, 0x10, 0x0]INFO:phy receive : INFO:link LD from 0x001002INFO:phy send 5 bytesINFO:phy data: : [0x55, 0x8, 0x2, 0x10, 0x0]INFO:phy receive : INFO:link LD from 0x001002INFO:phy send 5 bytesINFO:phy data: : [0x55, 0x8, 0x2, 0x10, 0x0]INFO:phy receive : INFO:link LD from 0x001002INFO:phy send 5 bytesINFO:phy data: : [0x55, 0x8, 0x2, 0x10, 0x0]INFO:phy receive : INFO:nvm Padding to blocksize 256 with 0xFFINFO:nvm Paging into 256 byte blocksINFO:nvm Writing page at 0x800000Traceback (most recent call last):File "C:\Users\Tim Williams\AppData\Local\Programs\Python\Python38\Scripts\pyupdi-script.py", line 33, in <module>sys.exit(load_entry_point('pyupdi==0.0.0', 'console_scripts', 'pyupdi')())File "c:\users\tim williams\appdata\local\programs\python\python38\lib\site-packages\updi\pyupdi.py", line 111, in _mainif not _process(nvm, args):File "c:\users\tim williams\appdata\local\programs\python\python38\lib\site-packages\updi\pyupdi.py", line 136, in _processreturn _flash_file(nvm, args.flash)File "c:\users\tim williams\appdata\local\programs\python\python38\lib\site-packages\updi\pyupdi.py", line 151, in _flash_filenvm.write_flash(start_address, data)File "c:\users\tim williams\appdata\local\programs\python\python38\lib\site-packages\updi\nvm.py", line 111, in write_flashreturn self._write_mem(address, data, self.device.flash_pagesize, use_word_access=True)File "c:\users\tim williams\appdata\local\programs\python\python38\lib\site-packages\updi\nvm.py", line 133, in _write_memself.application.write_nvm(address, page, use_word_access=use_word_access)TypeError: write_nvm_v1() got an unexpected keyword argument 'use_word_access'INFO:phy Closing port 'com11'With pymcuprog, it seems more consistent in operation, but inconsistent in result. I think I've determined the device must be erased prior to flashing. Does it... not just do this automatically? Even when verifying? (Mind, I don't think --verify actually changes anything about execution, seems just adding the extra step at the end. Just covering for the possibility that it could. Again, I don't know what's in this thing yet.) And there's only space for the one "action", so Ihave torun two separate commands just to get actual working code on a thing? And no, this particular issue isn't a semantic problem, there is a way to get there -- I can toss that in a batch file, fine, so be it. But surely this one thing, this one little thing, must be so blatantly obvious, how could it possibly be overlooked? I mean, I'd love to have something that just drops in, like, avrdude I've never had trouble with (though I do have an official, if dated, dongle for it (AVRISPMKII), no hackery involved there).Still not sure what I need to do fuses. It tells me,Code:pymcuprog.pymcuprog_main - ERROR - Operation failed with IndexError: bytearray index out of rangewhen I specify a binary file, orCode:pymcuprog.pymcuprog_main - ERROR - Operation failed with ValueError: 44 bytes of data at offset 0 is outside the boundaries of 'fuses' with size 16when giving hex (looks like it's reading it literally in this case, not checking if it's hex; inconsistent?).Ireallydon't know what it thinks it's doing as the device only has the 9 bytes of fuses. And even then, of which two don't exist.Tim

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 28, 2021, 07:24:50 pm
content: Quote from: Siwastaja on October 26, 2021, 06:05:57 pmHey!In my defense: on the Linux distributions I use, Python and most Python libraries (well, all that I use, anyway) are provided via the package manager and not PyPi, and are properly versioned, so all that mess is blissfully completely avoided. The only thing is to remember to usepython3/pydoc3instead ofpython/pydocwhen using Python3.So no, I would not accept that kind of mess in using Python-based tools myself, either.I do prefer C for this kind of system-level tool, and usually use eitheravrdude(for non-Teensy AVRs) or Teensy Loader (the GUI version provided in Teensyduino, or thecommand-lineGPL 3 version) for programming my microcontrollers; and didn't know these Python-based versions even existed.I also use shell scripts to launch Python applications by explictly invoking the interpreter, and recommend doing so, when asked.(Usingexec python3 ...in a Bash/dash/sh shell script the shell process is replaced by the python interpreter, so no extra shell remains in memory while the Python code runs. If the Python environment requires additions/changes to work on a specific distribution or even user, it is trivial to do that in the shell script. Another variant I sometimes use in such a launcher shell script is( setsid python3 ... & ) </dev/null 2>/dev/null >/dev/nullwhich starts the Python in a new session, detached from the current controlling terminal, and in the "background": the shell script returns immediately, but the Python code continues running, and is not killed even when the terminal it was started from is closed. No extra shell process then either. Very useful if you want to run stuff over e.g. SSH that won't get killed if you exit that particular SSH connection, or want to launch GUI applications from a terminal.)

author: westfw
author_rank: Super Contributor
timestamp: October 28, 2021, 11:59:25 pm
content: QuoteWell, because of stuff like:Code:from intelhex import IntelHexih = IntelHex()ih.loadhex(filename)data = ih.tobinarray()("That was easy!")

author: nctnico
author_rank: Super Contributor
timestamp: October 29, 2021, 12:27:53 am
content: Quote from: westfw on October 28, 2021, 11:59:25 pmFor the programmer maybe but for someone who wants to install the program getting the matching library versions it is a hell. One of my customers has a program developed in Python but getting it installed takes a good part of a day (and no guarantee it actually can be installed) due to the many Python libraries it needs which may not be compatible with the current Linux distributions. I very much regret not pushing that customer to just write the software in C++ and link it statically to the libraries it needs. For a reasonably complex Python program the easiest way is to distribute it as a VM image

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 29, 2021, 01:32:40 am
content: Quote from: nctnico on October 29, 2021, 12:27:53 amAssuming distributing it is not possible as a .deb and/or .rpm package with the Python libraries as dependencies, the next best solution is to include the libraries it needs as a set, inos-arch/lib/pythonversion/relative to suitable base directory, and use a wrapper script to execute a Python interpreter. The wrapper sets PYTHONHOME and any other PYTHON* environment variables needed to use the included modules instead of system ones when executing the Python code. It can be useful to include the Python interpreter binary itself, too, making it self-contained.It's not really a Python issue, nor a Linux issue. These people just do not know how to correctly/practically distribute stuff. Instead, they make a half-assed tarball or ZIP of their script files, and tell others to copy those somewhere "and they'll hopefully work"... Horrible pain ensues, with "worksforme" and shrugs from the original devs.I've often wondered how to help with this. Putting stuff on the net isn't going to make a difference, unless that stuff is promoted by Authority Figures, but playing that sort of social games pisses me off.

author: nctnico
author_rank: Super Contributor
timestamp: October 29, 2021, 04:46:15 pm
content: Quote from: Nominal Animal on October 29, 2021, 01:32:40 amIt is not that simple. There are also incompatibilities between system libraries and Python packages so you'd have to include all the system libraries that the Python packages use as well. Most commercial Linux software already does that but it is a pain to assemble such a software package. A statically linked executable OTOH is easy to distribute.

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 29, 2021, 06:22:46 pm
content: Quote from: nctnico on October 29, 2021, 04:46:15 pmYes, I did mean including the native libraries the Python packages (and Python interpreter itself – expat, zlib, and standard C library).Quote from: nctnico on October 29, 2021, 04:46:15 pmI disagree with "pain", but yes: statically linked binaries are easy.You see, I use a set of scripts that uselddto track the full set of native libraries, recursively. (Since I currently use Debian derivatives, I also dodpkg-query -Spath-to-libraryto obtain the set of packages they correspond to.) This handles the dependencies among native libraries.The ones it does NOT discover, are those that are loaded at run time vialibdl(<dlfcn.h>), i.e.dlopen()anddlsym().Another approach that does detect those too, and works better for Python stuff, is to run the application under strace, specificallystrace -f -y -e open,openat -ologfilepython3application[args...], logging everything the process or its children open tologfile. The issue in this approach is that one must then perform typical actions in the application to be sure to capture all libraries accessed during a normal session; and tends to involvemorehuman effort than the above. So, effort yes, but no pain/annoyment per se, in my opinion.(Basically another script takes the logfile, determines which of those opened files are libraries and which Python files, and uses ldd determine the set of native libraries needed. Many of the opened files are extra, including translations and even some native libraries like the resolver. The Python files list is then compared against the documentation or source, to see if the logged test use covered all the Python modules mentioned in the source; I let a human do this part.)For native libraries in Linux, one can set the LD_LIBRARY_PATH environment variable to set the (primary) location where libraries are looked at.So, if you start with a skeleton where the wrapper script is/usr/bin/appname, and the rest of the application resides in say/usr/lib/appname/or/usr/share/appnamewith a Python-compatible subtree under there (lib/pythonversion/) and libraries in sayos-arch/lib/, it really should not be painful; you should be able to do this in less than a day for a typical Python application. Theos-archprefix (obtained using sayuname -sm | tr ' A-Z' '-a-z') lets the exact same package work across not just Linux distributions on different hardware, but on *BSD variants as well.(Obviously, the "installer" could omit the unneededos-archsubtrees, to save disk space.)Yes, it is not trivial, and it does take time, but packaging a project always takes some time, unless you explicitly keep track of the dependencies during development and automate (for the current OS and hardware architecture) the project-packaging using that dependency list.In other words, what I am saying, is that the packaging does not have to be annoying/painful. If you (plural you, meaning anyone who has distributed software) haven't done this before, I recommend trying it this way (using strace, and then ldd recursively on the native libraries to determine the full set of native libraries needed) before condemning it as too painful or requiring too much effort to consider.

author: westfw
author_rank: Super Contributor
timestamp: October 29, 2021, 11:55:14 pm
content: QuoteI hate to tell you, but I have the same problem with C and C++ code (and presumably other languages.) "dependency hell." Especially if you have a host environment that is somewhat behind the latest OSSW tools - life got a lot easier for me after I figured out that I should have a separate build environment (gcc and libraries) for OSSW that I wanted to install (with various package managers), vs the "standard build environment" that got installed with Apple's XCode environment :-( (I'm pretty sure a lot of it was bogus - automake or whatever claiming that it needed "version N" of some library because that was what the OP built it with, when practically any version WOULD have worked. But I couldn't figure it our.)At least with Python, there's more chance that it will work on Mac or PC even if the OP used linux (or ... switch those around.)

author: nctnico
author_rank: Super Contributor
timestamp: October 30, 2021, 12:28:00 am
content: Quote from: westfw on October 29, 2021, 11:55:14 pmThe easy solution to that is to link everything in statically and -as Nominal Animal already noted- include any libraries inside the binary distribution package that can't be linked statically. Been there, done that. Python OTOH creates an extra dimension by not only needing specific packages (with their own dependencies) but also depending on specific versions of system libraries.

author: MarkR42
author_rank: Regular Contributor
timestamp: November 02, 2021, 09:02:35 am
content: What I would do, e.g. on Windows, is:1. Install "Anaconda python" (A Python 3 version)2. Open up a shell (cmd or powershell, or something else)3. "pip" should be in the path, sopip install pymcuprog... various install-y things happen4. the "pymcuprog" command should now be in the path, use it with whatever parameters you need.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: March 29, 2022, 02:24:00 am
content: Toolchain update:pymcuprog is rather slow, at least it is on my configuration. Probably lots of hangups between IO calls and buffers purging? Guessing Python isn't very performant here. It works at all; just not very fast. (Circa > 1min to flash a 64k part.)avrdude however has ported and integrated the same functionality. It's not yet in a release, but it's in the repo:https://github.com/avrdudes/avrdudeNaturally, I had an adventure building it*... but I do have a working build now. It works much faster, has the familiar, powerful, one-stop interface -- and reads ELF, not just hex!(*Because, who would want to build it in Cygwin, right? Well, it's more or less supported according to their wiki, and I already had GCC 11.2 installed there. So I figured why not. Apparently, this isn't tested very often. The required packages were not fully named in the docs/cmake script, and one of them has a naming conflict with another default package file. Smart. Not sure who's fault that is, but a rename fixed it. Somehow, I doubt renaming files from packages is a good thing, but there you have it...)Tim

author: rstofer
author_rank: Super Contributor
timestamp: March 29, 2022, 03:57:06 pm
content: Side issue: Micropython is a very neat way to generate uC code. At the end, the code is readable and perhaps more understandable than C. Yes, it's slow in comparison to native code but that might not be an issue for things like robot toys and such.Visual Studio Code makes a full-featured IDE (after installing a few Extensions) and runs on all OSs but the easy way to start is with Thonny. Especially on Windows where it just works.Yes, there are only certain uCs for which the interpreter has been built but that list is growing daily. A nice platform is the Pi Pico. And, yes, the interpreter supports the dual cores with threading.Python is a lot easier to use on Linux. Windows path lengths get insane. I want the source in a subdirectory of my home directory and I don't care where the Python bits are located as long as Linux can find them and, with my limited exposure, that hasn't been a problem.

author: HwAoRrDk
author_rank: Super Contributor
timestamp: March 29, 2022, 05:55:42 pm
content: Oh, avrdude supports UPDI now? Sweet.Shame about the lack of Windows builds.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: March 30, 2022, 12:38:18 am
content: Should be okay to share, everything's GPL right? Give this a go, maybe:https://github.com/T3sl4co1l/avrdude_cygwinTim

author: T3sl4co1l
author_rank: Super Contributor
timestamp: April 25, 2022, 08:44:39 am
content: Ah, and a better(?) version is here:https://github.com/mariusgreuel/avrdudeThough it doesn't seem to recognize my COM port(s), not sure what's going on there?Ohhh, weird. Needs the full DOS device path\\.\COMneven though it's only one digit, I thought that was only needed forCOMxx. Nevermind, everything seems in order.Tim