Bus Pirate firmware auto build: main branch

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

Build time: 41.86 seconds

Git pull log @5a65ab2:
Updating df6761b…5a65ab2
Fast-forward
CMakeLists.txt | 2 +
lib/picorvd/PicoSWIO.cpp | 179 +++
lib/picorvd/ch32vswio.pio | 92 ++
lib/picorvd/debug_defines.h | 3120 +++++++++++++++++++++++++++++++++++++++++++
lib/picorvd/picoswio.c | 186 +++
lib/picorvd/picoswio.h | 3 +
6 files changed, 3582 insertions(+)
create mode 100644 lib/picorvd/PicoSWIO.cpp
create mode 100644 lib/picorvd/ch32vswio.pio
create mode 100644 lib/picorvd/debug_defines.h
create mode 100644 lib/picorvd/picoswio.c
create mode 100644 lib/picorvd/picoswio.h

Here’s a fresh compile from ‘main’: “swap ch32v003 swio get/put functions with PIO implementation. Not currently working.”
ci-buspirate5-main-ef8449d.zip

Build time: 43.49 seconds

Git pull log @ef8449d:
Updating 5a65ab2…ef8449d
Fast-forward
lib/arduino-ch32v003-swio/arduino_ch32v003.c | 15 ++++++±—
lib/picorvd/picoswio.c | 37 +++++++++++++++++±---------
2 files changed, 34 insertions(+), 18 deletions(-)

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

ci-buspirate-main-233c3b1.zip

Build time: 105.62 seconds

Git pull log @233c3b1:
Updating bbcff78…233c3b1
Fast-forward
binmode/logicanalyzer.c | 54 +++++++++++++++++++++++++±---------------
commands/uart/simcard.c | 8 ++±—
lib/pico_ir_nec/nec_transmit.c | 30 +++++++++++++++±------
mode/hwled.c | 25 +++++++++++±------
pio_config.h | 1 +
pirate.h | 13 ++++++++++
pirate/hw1wire_pio.c | 12 ++++++±–
pirate/hw2wire_pio.c | 13 ++++++±–
pirate/hwi2c_pio.c | 14 ++++++±—
pirate/hwuart_pio.c | 26 ++++++++++++++±----
pirate/rgb.c | 12 +++++±—
11 files changed, 146 insertions(+), 62 deletions(-)

Here’s a fresh compile from ‘main’: “revert PIO changes for bp6”

ci-buspirate-main-f596eef.zip

Build time: 103.47 seconds

Git pull log @f596eef:
Updating 233c3b1…f596eef
Fast-forward
pirate/hw1wire.pio | 9 +±------
1 file changed, 2 insertions(+), 7 deletions(-)

Here’s a fresh compile from ‘main’: “correct PIO GPIO func assignment in rgb. However, i think this is now doen in the pio code.”

ci-buspirate-main-8b9fd7e.zip

Build time: 102.21 seconds

Git pull log @8b9fd7e:
Updating f596eef…8b9fd7e
Fast-forward
pirate/rgb.c | 4 ++±
1 file changed, 3 insertions(+), 1 deletion(-)

Here’s a fresh compile from ‘main’: “1-wire test”

ci-buspirate-main-e232d6b.zip

Build time: 106.91 seconds

Git pull log @e232d6b:
Updating 8b9fd7e…e232d6b
Fast-forward
mode/hw1wire.c | 2 ±
pirate.h | 2 ±
pirate/hw1wire.pio | 20 +++++++++±---------
pirate/hw1wire_pio.c | 1 +
4 files changed, 13 insertions(+), 12 deletions(-)

Here’s a fresh compile from ‘main’: “1-Wire working on Rp2040/Bus Pirate 5”

ci-buspirate-main-1041c67.zip

Build time: 104.46 seconds

Git pull log @1041c67:
Updating e232d6b…1041c67
Fast-forward
pirate/hw1wire.pio | 18 +++++++++±-------
pirate/hw1wire_pio.c | 2 ±
2 files changed, 11 insertions(+), 9 deletions(-)

I’m out of date with the firmware. I tried to build from source, and had this error.

[100%] Built target pioasm
[  1%] No install step for 'PioasmBuild'
[  1%] Completed 'PioasmBuild'
[  2%] Built target PioasmBuild
[  2%] Built target bus_pirate5_rev8_hw2wire_pio_h
[  2%] Built target bus_pirate5_rev8_hwi2c_pio_h
[  2%] Generating ws2812.pio.h
/home/grymoire/Git/BusPirate5-firmware/pirate/ws2812.pio:6.1-12: unknown directive .pio_version
    6 | .pio_version 0 // only requires PIO version 0
      | ^~~~~~~~~~~~
make[2]: *** [CMakeFiles/bus_pirate5_rev8_ws2812_pio_h.dir/build.make:73: ws2812.pio.h] Error 1
make[1]: *** [CMakeFiles/Makefile2:1697: CMakeFiles/bus_pirate5_rev8_ws2812_pio_h.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

Any suggestions on what I am doing wrong?

1 Like

you need the new 2.0 SDK fr compile

2 Likes

I see the problem. In CMakeLists.txt it has

if(WIN32)
set(sdkVersion 2.0.0)
set(toolchainVersion 13_2_Rel1)
set(picotoolVersion 2.0.0)
include(${USERHOME}/.pico-sdk/cmake/pico-vscode.cmake)
endif()

and I am on Linux,

1 Like

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.

This I assume is related to not having Pico SDK 2.0 in your cmake paths, either hard coded or exporting an environmental variable.

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

set(PICO_SDK_PATH "/home/grymoire/Git/pico-sdk")

I’m not using vscode currently.

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.

I don’t have picotool. There’s a github repo. I can build it from there.

picotool replaces elf2uf2 or something as the multipurpose firmware convert/load/disassemble tool, I guess.

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

Anyhow - that fixed the problem.

1 Like

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

1 Like

Sometimes the best thing to do is to move things around and see what breaks. :slight_smile:

2 Likes