Half assing AVR-DA without a Dragon

[nctnico]

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

The 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.

[MarkR42]

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, so

pip install pymcuprog

... various install-y things happen

4. the "pymcuprog" command should now be in the path, use it with whatever parameters you need.

[T3sl4co1l]

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/avrdude

Naturally, 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

[rstofer]

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.

[HwAoRrDk]

Oh, avrdude supports UPDI now? Sweet.

Shame about the lack of Windows builds.

[T3sl4co1l]

Should be okay to share, everything's GPL right?  Give this a go, maybe:
https://github.com/T3sl4co1l/avrdude_cygwin

Tim

[T3sl4co1l]

Ah, and a better(?) version is here:
https://github.com/mariusgreuel/avrdude

Though 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 \\.\COMn even though it's only one digit, I thought that was only needed for COMxx.  Nevermind, everything seems in order.

Tim