WIP: SWIG Python wrapper for libavrdude #1714
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Config file handling and basic list handling is there.
|
This does not work under MSYS2 mingw64. Personally I always find Python bindings using swig to be problematic to build under Windows. I have never tried to use swig with MSVC either. Failed build log under MSYS2 mingw64 |
|
Thanks for testing. Kinda interesting, as my compile command is supposed to be the same as for standard avrdude itself … |
I will test under Linux and macOS as well. BTW, I was kind of the de-facto libftdi Windows binary packager last time. I always find it a bit troublesome to build the Python binding under Windows. So I myself actually use pyftdi (libusb/pyusb based) and pylibftdi (libftdi based). |
The CI runs already fail at MacOS, with what seems not finding the Python libraries. I guess it's merely something needed inside the CMake stuff for that. Linux and FreeBSD builds work fine, both in CI as well as physically for me. The more interesting part in your failure is that it's IMHO completely unrelated to SWIG or Python, as it happens in Code that is being compiled just like in the ordinary libavrdude/avrdude counterpart. |
|
I tried to push a quick fix for the macOS CI failure but it does not work -- it still uses the system installed Python and not Homebrew Python. |
|
I also pushed a commit to add the build test for MSYS2 mingw build and now should be able to see the errors under MSYS2 mingw builds from github action. |
|
No issues under Ubuntu 20.04 Linux. |
And I have the same linking issue under my Mac Mini M1 (macOS 14.3.1). It uses System Python and not Homebrew Python. The root cause is missing the link to the python library. I can manually fix the issue but I do not know how to do that properly in CMake. |
Basically we need to add the found github action run: |
Thanks for the analysis, very welcome! I'm almost illiterate regarding CMake. |
I tried a dirty fix but it does not work. Sorry I do not know how to fix this issue, but at least we know the root cause now for macOS build. |
No issues, same here -- not knowing much about CMake or SWIG myself... |
|
I only know libftdi SWIG Python bindings working under macOS. Not so sure if it will help or not. However, I can see that Homebrew libftdi formula actually disables the building of SWIG based Python binding. |
|
What's a little strange here: I'd have expected that the "REQUIRED" there would actually require a Python library … but on my Mac, there isn't one, and so I get the same linker error. |
|
Indeed it is strange. You can always leave the build isse aside first and concentrate on the code development first. If the build error is too distracting, you can temporarily remove the build from github action as well (macOS, Windows MSVC and Windows MSYS2 mingw build). |
Yes, that's probably what it's going to be by now. There's not much point spending time there as long as it isn't clear whether the entire result will be useful at all. |
This helps the SWIG wrapper to define them as well.
Some library functions might return AVRMEM* and AVRPART* as NULL pointers. Prevent them from being dereferenced, and return a Python None object instead.
|
Looking at the MSVC build errors, it seems to me it is due to missing extra Windows extra include files for the SWIG Python Wrapper build. https://github.com/avrdudes/avrdude/tree/main/src/msvc After manually corrected the include directories (basically copy the MSVC include directories of Then after manually adding the Python library, the build is actually successful. |
|
Then it seems to work even though I have to patch |
Adding the build directory to the module search path eases development by now.
Not really understood, but with level MSG_TRACE2, on a Curiosity Nano board, I get two instances of unicode decode errors within the trace messages. Trying to debug them did not yield any useful result, but catching the exception, and enforcing the type to be "str" appear to be able to continue. Maybe an internal bug of my Python interpreter, don't know.
These are debugging functions, and not supposed to print at MSG_INFO level.
Indeed this is quite strange.
Yes, It seems to me the following seems to always working under Windows. Example: Virtual Env Example: no Virtual Env |
|
I cannot find any workaround to build for virtual env other than the virtual env generated by the default version of python. You can see if keeps find the default Home Brew Python ( |
|
Okay, last resort works. I need to specify the Artifacts Specification To solve special cases, it is possible to specify directly the artifacts by setting the following variables: Python3_EXECUTABLE |
|
Hmm, now it does not work under Linux out of the box, no matter I use virtual environment or not. Strange. |
|
It seems to me only the default Python version is working (with or without virtual environment). Under Ubuntu 20.04, the default version is Python 3.8. |
That way, users can operate the GUI while the help window is displaying.
Some fuse settings on some devices may be dangerous, like disabling ISP, or changing the /RESET pin into a GPIO. This adds some warning examples. Still does not consider the actual programmer connection, but that could be added in future.
Remove obsolete avrdude_message(). Place inline comments at position 32.
Changes have been suggested by Stefan Rueger.
Make the combo box editable, and apply a QValidator subclass to it so the users can type partial device names.
The default of 10 entries is way too small.
While the combobox validator prevents "QValidator.Invalid" characters to be entered, the user could still get away with any string that is considered "QValidator.Intermediate". In that caes, disable the OK button of the button box so the (intermediate) result could not be passed on.
Turns out PySide2 doesn't have a setMarkdown() method for the text widgets, only setHtml().
50 seemed to be a bit too large for some displays.
While typing the combobox text, the validator adapts the contents of the dropdown menu to only those entries that match the text typed. So one can enter "64", and will only be presented all device that have a 64 in their name (which are a few more than just those with 64 KiB of flash).
This category triggers for all programmers that have PM_SPM set.
This offers the same feature as for the device selection: typing a partial programmer name filters the dropdown list to all possible matches for a programmer.
Was: Attribute Qt::AA_ShareOpenGLContexts must be set before QCoreApplication is created.
|
@dl8dtl @mcuee @MCUdude I have created 27 PRs, one for each programmer, to bring them up to speed for use in the GUI:
When you review new programmer code in future please remember to watch out for exit(), static or global variables etc. With serious libavrdude use these can no longer be here. Please, if you can, give those PRs a quick test. @mcuee already has tested quite a few (thanks!) but he doesn't have all gear. |
|
There are still quite a few other things to do once these PRs are merged: the new return code As to names (always the most tricky part of programming 😄): I'd like to use This must be allocated at the start of an application and only one global variable used: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The purpose of this branch / pull request is to eventually establish enough of a Python wrapper to allow a full feature-compatible Python version of AVRDUDE. This will allow it to be embedded in scripting frameworks, or to be used by something like a real GUI wrapper.