I just received my BP6. When I plugged it in, everything looked fine. I updated it with the latest main build, bus_pirate6.uf2 from ci-buspirate-main-8b2e29b, from the forum, and now it’s just blank. The computer recognizes it (drive appears, no port assigned though)when I plug it in, but the display is blank, and no LEDs light up. I repeated the update procedure, and it’s still blank.
1 Like
Wow glad it arrived. I’ll look into it.
2 Likes
bus_pirate6_rev1-manuf.zip (198.3 KB)
Here is the manufacturing firmware until I can debug this issue.
4 Likes
That fixed it, thank you.
2 Likes
Can confirm that the latest auto build for BP6 results in a loop where it always starts up in bootloader mode. Hum.
2 Likes
Oh man, it’s that issue again: windows builds work ok, ubuntu builds fail. What’s weird is that I did the manufacturing firmware under ubuntu on WSL because the pico tool wasn’t compilable at the time under windows.
1 Like
The latest auto build fixes this issue on my Bus Priate 6. It seems like the CMakeLists cache wasn’t getting cleaned enough.
3 Likes
My BP6 just arrived (South Korea, boondocks) literally minutes ago.
(1) the firmware builds for 6 are in the 5 repo? Looking to avoid the experience of user KD7EIR above.
(2) it looks identical (physically) to the BP5, as expected. But I’m gonna get them mixed up in my toolbox. Is there any subtle difference between the two? I’m assuming the CAD files are available so in theory I could print a new case in a different color. Hmmm, let’s see, 6 is blue, 5 is green.
(3) why are there so many and different colored push button switch caps in the tiny ziplock bag containing the allen wrench and two flathead machine screws?
(4) I smelled the factory floor paint color this time! But alas, I ripped the sticker in half in my haste to open the bag.
2 Likes
Hi @thestumbler ,
https://forum.buspirate.com/t/bus-pirate-5-auto-build-main-branch/20/99999
Latest builds are available here. I fixed the issue with the build server cache not clearing properly, it should work now.
The PCBs are different but yes the outside is identical. You could for example use a different button color to differentiate them. I use silver for 5, blue for 5-2gbit, yellow for 5XL, and red for 6.
We had fun dying and hydro dipping button caps. I believe 5XL and 6 now include a clear cap, we did a custom run but haven’t written anything about it yet. It’s just for customization.
4 Likes
I’ve tried a few things to distinguish mine, beyond the button color:
- On the left is my 1Gbit BP5. Here, I scratched the outside of the case with
GND,SWDIO, andSWCLK, and then carefully tapped a fine-point sharpie to fill the scratches. Legible, but only barely. - On the right is my 2Gbit BP5. Here, I wrote the “2G” in reverse on the inside of the case in red sharpie, and then gave higher contrast with a black box of sharpie … being careful not to overlap with the red. This worked out fairly well, being visible when looking for it, but not impacting overall aesthetics.
- Also on the right, I wrote the
GND,SWDIO, andSWCLKon the inside of the case. The resulting visibility is poor, so I do not recommended this method for thin marks like this … only the large-markings like the2G.
Although not shown, I also find the following to have excellent results:
- laser-etch (or scratch / engrave) text or other marking
- heat a crayon of contrasting color (soft/glossy, not dripping)
- apply heated wax onto the etched area
- vigorously rub with a paper towel (over trash to catch wax flakes)
This effectively removes the wax outside the etching, and the wax in the etched area remains very stubbornly within. With laser etching, the wax looks surprisingly professional. With my box cutter chicken-scratchings, it’s still the most visible / readable result.
2 Likes
Okay, I’m dense. I updated to the latest FW branch. After making the build directory, I don’t see any pirate6 targets in the Makefile. Tried the RP2350 branch, same results. All the target names are for bus_pirate5, none for pirate6. But there are more than a dozen branches, maybe I’m missing something obvious.
cmake … -DBP_PICO_PLATFORM=rp2350
cmake and specify the platform. I couldn’t figure out any other way because the chip has to be specified before importing the SDK.
2 Likes
Okay, that set me along the path to success. I now can build and install on my BP6. I was slowed down by the fact that I had the Pico SDK in a different location than default, and I needed to update it to the latest (DOH). I couldn’t get rid of some CMAKE error about FetchContents being deprecated, so I put a -Wno-dev. Here’s my quick and dirty script I used to figure out how to build.
Edit: Oh, I also figured out I shouldn’t be checking out the R2350 branch… that code had already been merged back into MAIN.
-Chris
#!/bin/bash
# you may want to add the flags
# if you want to use pico-sdk that is in your local path.
# -DPICO_SDK_FETCH_FROM_GIT=TRUE \
# -DPICO_SDK_PATH=/files/tools/pico/pico-sdk \
function init_things {
cmake -S . -B build \
-DPICO_SDK_FETCH_FROM_GIT=FALSE \
-DPICO_SDK_PATH=/files/tools/pico/pico-sdk \
-DPICOTOOL_FETCH_FROM_GIT_PATH=/files/tools/picotool \
-DBP_PICO_PLATFORM=rp2350 \
-Wno-dev
}
# init first time...
if [ $# -gt 0 ] ; then
if [ "$1" = "init" ]; then
echo "INIT"
init_things
fi
else
# subsequent times
# --target bus_pirate5_rev10
echo "DOIT"
cmake --build ./build \
--target bus_pirate6
fi
2 Likes
Glad you got it. If you move to main, it might be best to start at fb2b68c because I accidentally pushed test code to main.
2 Likes
So, in another thread on this forum, user @lersi brought up the naming convention. After trying to wrap my head around the firmware builds, I kind of see his point. Here we have what is essentially a single firmware base being used on three variations of a basic hardware design. The firmware has so much in common between BP5, BP5XL, and BP6, the status quo of all three firmware in a single repo makes perfect sense. The mental stumbling block, for me, was that the firmware repo is named BP5. That clearly includes BP5 and BP5XL, but the BP6 build is an oddball.
The hardware naming is an interesting one to me, who has a decades-long love/hate relationship with engineering drawings, part numbers and such. These modules are somewhat more than minor PCB assembly options, like different memory sizes for example. The main MCU changes between 5 and 5XL/6, and major new functionality is possible with 6 only. I can see the argument for the initial, 10-minute naming convention as well as the @lersi naming scheme. I don’t have a strong opinion either way, other than to say…
- If you keep the current naming scheme, the I think it would make sense to rename the repository to something like
firmware-rp2. - If you go with the 5/5A/5B scheme, the existing firmware repo name is just fine.
As for final documentation down the road, could you put something in the Makefile or readme to show a list of boards and targets, like a help option? If you put something in the Makefile, it can be done so that it is basically self-updating when you add targets / boards. But you need to know the target in order to run cmake which creates the Makefile. Putting it in the readme solves this problem, but you have to manually update it whenever there are changes.
I offer these comments not as actual recommendations, but just as food for thought as the 5XL/6 becomes official and not just beta. Rereading what @Ian wrote last week puts these 5XL/6 hiccups into a better perspective as well:
5 (rp2040) is absolutely the “main” bus pirate for the foreseeable future. We haven’t run into resource or speed limits with the RP2040, and it’s a well proven chip…No one should feel like their 5 is obsolete, it’s what I currently use and develop on myself.
3 Likes
Hopefully, someone will be able to convince CMake that we actually have two projects (one for rp2040 boards, one for rp2350 boards), and recursively call into those two projects. But, that is something beyond my current knowledge … likely a low-difficulty changes for someone familiar with CMake?
As for the naming, I might recommend moving both RP2350 boards to be under the BP6 name:
BP5remains as-isBP5XLgets renamed toBP6S(for “standard”)- In essence,
BP6*would be for early-access hardware; Essentially saying these boards might not be ready for production use … which isn’t too big a stretch, given the multiple major errata for the A2 revision. - Maybe when A3 released, or A2 is worked around and stable, or … whenever Ian decides…
BP6Sgets renamed toBP7BP6gets renamed toBP7XL
Maybe this is a tip-o-the-hat/ack of how, historically, odd-numbered versions of major operating systems seemed … more polished … than the even-numbered major versions. 
1 Like
@henrygab I like this idea. And if it is an object you are 3D printing yourself from translucent material, then you could put it in the CAD directly.
For an existing item, I had the (not-so-bright) idea of getting a set of those steel lettering punches used on thin metal labels, leather, etc. Turned out they weren’t too expensive, either. But then it hit me, I’d need them to be reverse letters. So I gave up on that idea for now.
2 Likes
I like the different color buttons for for each variant.
Maybe try heating the punches and leaving the impression or brand the enclosure?
Maybe a handheld mini inkjet?
If you have a 3d printer with auto bed detection, you can literally print on the case with a high contrast color.
Print a solid color insert that allows the leds to shine through the cover, highlighting the text? I might try this today.
TPU cover works well also.
Or, when all else fails, brady label maker. To be fair, not all brady label makers print on material ideal for the situation. I’m fortunate enough to have one that fits the bill.
Jist a few i have tried and some ideas that came to mind. Which reminded me, my old ender 3 is needing to be put to use. Going shoping for a laser now.