Electronics > Microcontrollers

Half assing AVR-DA without a Dragon

(1/6) > >>

T3sl4co1l:
So this thing exists,
https://github.com/mraardvark/pyupdi

But 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't really matter?  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 to python C:\Users\<me>\AppData\Local\Programs\Python\Python38\Lib\site-packages\updi\pyupdi.py every fucking time I want to run this thing.  Right?  ...Right?

Poke around a bit, find I can invoke it by python -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), running python -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.. :-DD

Anyway, now onto the GCC toolchain...

Tim

Siwastaja:
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.

T3sl4co1l:
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

westfw:

--- Quote ---is this supposed to be this awkward?
--- End quote ---
I don't think so.  When I tried it, I got a pyupdi.exe in
C:\Users\billw\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\local-packages\Python38\Scripts\pyupdi.exe


That'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.)

mraardvark:
Yes, Python has its issues...

at least you can drop pyupdi and just go for pymcuprog
if you have a py35-39 installed, and selected the "add scripts to path" when you installed, then you can just install using:
pip install pymcuprog
and then run it using:
pymcuprog --help

not _that_ bad, is it?

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version