I’m getting this error now too. It seems the code the VScode extension adds kind of depends on the extension
Great news! My wife always asks me what she could get me for my birthday and usually I have no idea. This time it was a no-brainer. 
In case anyone else wonders, I found the BP 6 inside the BP 5 repository 
4 Likes
Thank you much for checking it out 
Happy Birthday!
Yes, I’m going to need to figure out what to do about all the BP5 naming, I regret leaning into it so much now
Nows the time to determine naming before too many are in the wild. 
Any thoughts on what direction you might head? Do you plan to simply continuing to roll the rev, or maybe a different naming scheme all together? 
1 Like
may be change the name of bus pirate 5 XL to Bus Pirate 5A and the name of bus pirate 6 to Bus Pirate 5B ?
Ah man! This is why I develop stuff out in the open. This is the answer.
It was such a flurry to develop this and keep everything else moving forward. We spent 10 minutes tossing numbering around and just went with it.
- 5XL because it’s exactly the same board as 5, but with the extra large chip
- 6 because it’s actually a different beast with an incremental jump in features
So far: we’re into a second batch of 6 and used the remainder of the chips we have. I think like 6 people got an XL, which is fair.
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.
6 satisfies a design, engineering and manufacturing “itch” - It just feels so satisfying to get those 74hc595s off the BOM and out of the code. The follow along logic analyzer I hope will also be a defining feature. When I first got it going with an FPGA and the Bus Terminal (forgive me) I did giggle with glee.
At the moment I’m waiting on pins and needles for the first wave of 6 to arrive to see what you think and what issues crop up. I’m not worried about the PCB, but I’m interested in what corner cases might happen with the first release of RP2350 and support in the SDK. We won’t make another batch until after there’s some real world vetting.
We’re going to take this slow and steady. No one should feel like their 5 is obsolete, it’s what I currently use and develop on myself.
2 Likes
Thanks!
I am glad that you like the idea
The main issue I see is that future projects will use the extra PIO, and it also overclocks better and has better performance for things impossible with the RP2040… I have the same dilemma in own projects, haha.
Example: Look up the logic analyzer project by Dr. Gusman.
In the things we do ourselves, we have control, but there will be third-party projects that will only work (or we can only adapt) for the more powerful Bus Pirate.
IMO, We will have to create some sort of table or something to show what works on each version so that the user can decide which one they are more interested in when making a purchase.
Being able to integrate the entire “hack-ecosystem” of PICO 2 and RP2350 that’s coming in Bus Pirate, I think, is an incredible added value as a product.
1 Like
The nice thing is the updated SDK does a search for available PIOs so we can handle it gracefully
I was referring to when they use all the PIOs (3) at once to achieve new things; we won’t be able to have that power with the RP2040. or 3 PIOs + 300MHz overclock etc.
That’s why I mentioned creating a table where the user can understand what each product offers. For example, with Bus Pirate 6, the logic analyzer/X project/… can go up to here versus the RP2040 version…
The idea would be to push each product to its limits to fully utilize each hardware and get the most out of it, right? Or are we only going to do things that work up to the RP2040 (limit)?
This decision is important to determine how we will write the firmware from now on… For example, something might work with the RP2040, but a certain extra-cool-feature requires 3 PIOs at once—what do we do then? etc.
For example, in the CLI DOC, options could be shown with an asterisk* or other indicators to show that certain features are only available in BP6… or something like that… And the same goes for binary modes… @ian
Or you could have the firmware only display help options based on the model? You could in addition have a way to show options other boards have. e.g. help, help5a help5b
I assume at some point that will happen, and we’ll need to document that clearly. One thing that might really benefit from the rp2350 is logic analyzer triggers. The updated PIO can (if I understand it) synchronize and interrupt between PIO state machines. The old one can’t, and that’s why GusmanB’s logic analyzer uses one GPIO pin to trigger between state machines. But, that’s some pretty esoteric massive parallel triggering stuff.
1 Like
Is the Bus pirate 6 going to be an official hardware release? I’m assuming that it is currently only available as a beta/development version? What kind of ETA is there for the OFFICIAL BP6 version. I think I read that there is another PICO 2 version yet to be released yet. Thanks.
It’s released, and the firmware targets all hardware released so far. I am taking it slow to see what issues crop up in the wild as the first wave arrives, but so far everything seems okay.
It’s maybe best to look at the Bus Pirate as a process, rather than a product. We’re constantly experimenting with new treatments, such as the clear soldermask and laser engraved & enamel filled printing on headers (instead of silkscreen). It’s never really “done” until everyone loses interest or we fill the flash.
The rest, no idea really. RPi gave us one reel of chips, and they are not currently available outside the beta program. We made a test batch which sold out immediately. Now we are using the rest of the reel, and that should ship, conservatively, by September 10th (maybe much sooner). That may be it for a while.
I don’t know how much the new chips cost or if they’re available in quantity even in the beta program. Then there’s the small issue of importing chips from the UK into China (because they’re not on the market) with exorbitant tariffs and regulations.
2 Likes
Yes, it does! As an appliance tech, I’m finally starting to learn electronics in my mid-thirties. I just placed an order for the BP6, and I hope it will be useful for learning about failure modes in washing machine control panels (among other things =)
4 Likes
For the XOSC startup delay, did you try setting PICO_XOSC_STARTUP_DELAY_MULTIPLIER to 64? On a small number of Adafruit boards when we started using the RP2040, we encountered this startup problem, and so added this delay multiplier and PR’d it back to pico-sdk.
3 Likes
Hey @dhalbert !
We also had that as a corner case with the rp2040 initial batch. Matt Mets at blinkinlabs suggested just that fix and it worked a treat.
The issue with RP2350 yield seems to be the test rig at the factory. Once we got them into the office we were able to pass most of the rejects.
I really hope RPi decides to do a revision on the final Rp2350 silicon because the pull down issue I found (e9) is kind of a bummer. I’ll know more tomorrow after a bit more testing.
Thank you for discovering the GPIO input latchup. I believe I am able to cause the RP2350-E9 issue even without enabling the internal pulldown. See RP2350-E9 Erratum: can get "stuck" at 2V state even without pulldown · Issue #401 · raspberrypi/pico-feedback · GitHub. Gadgetoid at Pimoroni has also seen that.
3 Likes
Interesting. Oh man though, I worry that explains my current issues with rp2350 
Here’s my comment on your github issue.
I added a bug command to the latest firmware that probes E9 in several ways.
m 8- enter a mode where IO 0 is free (DIO for example)W 5- setup some kind of voltagebug e9- probe the gpio several ways using various hardware on the Bus Pirate
Results
DIO> bug e9
Replicate bug E9
Test 1:
Pull-down disabled...
Disabling Bus Pirate pull-ups
Making IO0 buffer and GPIO input
Making IO0 buffer an output
GPIO pin should be 0: 0
Making IO0 buffer and GPIO input
Enabling Bus Pirate pull-ups
Making IO0 buffer an output
Disabling Bus Pirate pull-ups
GPIO pin should be 0: 1
GPIO is 1, E9 found
gpio_disable_pulls is run before testing for E9. E9 is cleared, and then found without gpio pin pull-down enabled.
Test 2:
Set pulls disabled...
Disabling Bus Pirate pull-ups
Making IO0 buffer and GPIO input
Making IO0 buffer an output
GPIO pin should be 0: 0
Making IO0 buffer and GPIO input
Enabling Bus Pirate pull-ups
Making IO0 buffer an output
Disabling Bus Pirate pull-ups
GPIO pin should be 0: 1
GPIO is 1, E9 found
gpio_set_pulls(bio2bufiopin[BIO0], false, false); is run. E9 is cleared and then detected without gpio pin pull-down enabled.
Test 3:
Disabling Bus Pirate pull-ups
Making IO0 buffer and GPIO input
Making IO0 buffer an output
GPIO pin should be 0: 0
Making IO0 buffer and GPIO input
Enabling Bus Pirate pull-ups
Making IO0 buffer an output
Disabling Bus Pirate pull-ups
GPIO pin should be 0: 1
GPIO is 1, E9 found
GPIO.IE = false...
GPIO pin should be 0: 0
Replicate E9, then disable GPIO.IE. When GPIO.IE is disabled, E9 is no longer detected.
Test 4:
Strong low test...
Disabling Bus Pirate pull-ups
Making IO0 buffer and GPIO input
Making IO0 buffer an output
GPIO pin should be 0: 0
Making IO0 buffer and GPIO input
Making IO0 buffer an output
Disabling Bus Pirate pull-ups
GPIO pin should be 0: 0
Hold pin strong low, DO NOT expose to a high level voltage (eg don’t latch up), then let float. E9 does not occur if the pin is not exposed to a high level voltage (obviously, but just to demonstrate).
Source code for the bug command.
Next Steps
I’ve reached out to my contact at Raspberry Pi, and there are active github issues and a thread in the Rpi forum. Rpi hasn’t responded to the new findings of @dhalbert and others, but it’s only been 2 days and they’re usually good at formulating a timely response.