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,

2 Likes

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

1 Like

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.

1 Like

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.

2 Likes

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:

2 Likes

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

3 Likes