Python wrapper for STLINK-V3-BRIDGE. Tested on macOS, Windows, and Linux. Uses libusb for straightforward cross-platform support.

Development on this project will only be for bug fixes and PRs due to being tied to proprietary hardware and ST's license. See https://github.com/dragonlock2/JABI for a true cross-hardware solution.

• SPI controller
• I2C controller
• GPIO
• CAN

First let's install a few dependencies.

• macOS
  • brew install git cmake libusb
• Linux
  • apt install git cmake libusb-1.0-0-dev
• Windows
  • Install Visual Studio C++ for its C++ compiler. It's also an IDE.
  • Use winget to install git and CMake.
  • Use vcpkg to install libusb under the right triplet (e.g. x64-windows).
  • Use Zadig to install the WinUSB driver on any STLINK-V3 devices.

Make sure to clone with submodules.

git clone --recursive https://github.com/dragonlock2/stbridge.git

Install locally using pip!

pip install ./stbridge

Optionally run the tests. There's a 5 second timeout for commands in case they're unsuccessful like if you try CAN without other nodes. If you don't want to use sudo on Linux, you can add 50-stlinkv3.rules to /etc/udev/rules.d.

python3 tests/all.py

Check out stbridge.cpp and stbridge.h as well as tests/ for function syntax.

• Not reading CAN messages fast enough can crash USB comms on the next CAN operation, even init. Should be detected as an overrun but isn't. Also looks like more messages than can be stored in the STLINK's FIFO's can be read back. I have a feeling what's happening is messages are stored on a separate FIFO on the STLINK and once it overruns, it crashes. This appears to be an ST issue.
• Received remote CAN frames are misidentified as data frames. Garbage data is returned in remote frames due to ST's driver. This appears to be an ST issue.
• Setting CAN filters for specific extended IDs throws a parameter error. Letting everything through still works.
• There's some (fixed size) libusb memory leaks on Windows.

This software is under ST's Ultimate Liberty License.