Here’s a fresh compile from ‘main’: “port CH32V SWIO PIO program from picorvd project. TODO: install and test with buffered IO pins.” ci-buspirate5-main-5a65ab2.zip
Here’s a fresh compile from ‘main’: “swap ch32v003 swio get/put functions with PIO implementation. Not currently working.” ci-buspirate5-main-ef8449d.zip
Here’s a fresh compile from ‘main’: “revert to manual assignment of PIO resources fixes crashing and strangeness with new claim_pio and unclaim_pio functions.”
On arcolinux (arch derivative) it worked OOTB once you had the 2.0 SDK installed and the cmake include provided by it there. The windows ifdef is for using a different load mechanism
The windows ifdef is for blocking out the VScode Pico extension (which does not feel ready for prime time) under Linux. I’m stuck with it because it has a compiled picotool for Windows, on Linux picotool is easy to compile from source.
I’m missing a step. PICO_SDK_PATH is set to the latest github version, which is up to date. I created a new build directory in pico_sdk and did a “cmake …;make”. I’ve also added this to the BP CMakeLists.txt
I assume building pico sdk built/installed picotool?
Is it possible you have a PICO_SDK_PATH set as an environmental variable that is overriding the set()? I think you can echo or print it on the command line, I don’t know how off hand.
Heh. When I tried to build picotool, it told me that I was using sdk 1.5.1, yet it is pointing to the github repo for 2.0, which I just built. Okay - that tells me that even though I “built” the new sdk, it wasn’t being properly installed. So…
I removed my BP and sdk repos and built them from scratch. I built and installed picotool first. (The sdk hinted that I could also make everything driven from github.)
Glad it resolved. The build server is linux, and I just spin up new droplets and install from scratch. Modifying a linux setup once it is already going is a talent