Bus Pirate 6 uses the RP2350B which has a few extra pins. Some of those make a secondary connection to the IO pins through a buffer chip (U2) to GPIO20…27.
The first step is just to get it going on the new pins with sigrok - In logicanalyzer.c in logic_analyzer_arm: modify the no trigger program to use either the current base of IO0, or the new secondary GPIO connection.
Which brings up a good question. Is there any point to actually switch between the two methods of IOs? 6 can always look through the secondary buffer. It makes sense to change the setup function to accept a base GPIO and number of consecutive GPIOs to include in the LA.
For use from modes (follow along)
A setup function that adjusts the capture speed to eg 4x 8x 16x the protocol bit speed
A arm/initi function that doesn’t start the capture
A start function to call from the syntax compiler just before output to the bus
Stop function to end the capture when output is complete, before the buffer is filled.
A function to dump the capture plus empty sample until there is software capable of understanding variable length captures
A global logic command that configures the logic analyzer manually (eg you don’t like the auto settings)
Software thoughts:
There’s no software support for asynchronous data dumps in sigrok
A simple header with each sample dump should contain: channels, capture speed, samples that follow, etc.
An auto mode that updates every 30 seconds if no triggers have been detected (like a scope in auto mode)
GusmanB has software that may support this, it does periodic updates. I’m more fond of sigrok though because of all the decoders and such
ASCII logic graph:
At the top of logicanalyzer.c there’s a messy attempt I made to have a scroll-able logic graph in the terminal. Now that the core opt-args stuff is sorted, that will be a lot easier to clean up.
This is probably a horrible but also right time to rework the terminal toolbar. The toolbar should be moved into a clean “toolbox” module. The logic graph will also be a toolbox module. There will be some kind of system for enabling various toolbars that all play well together with the space available in the terminal.
I’ve got a lot of in-progress stuff, but I need to get the first two chunks done this week. When boards start arriving there should be firmware support for anyone interesting in hacking at software.
Setup logic analyzer before syntax is output to the bus, start capture
Send the bus output as normal
Halt the logic analyzer
Display output as normal
Query logic analyzer for number of samples
A quick reality check of the last 80 samples (backwards…)
Looks to be coming along. I’m going to push this to an rp2350 branch for the time being.
Protocol
I’m going to add a new binmode with asynchronous “follow along” logic analyzer output. It’s kind of like working with GPS NMEA messages, so my first though is something like that, with all values in ASCII text (or just a binary packet?):
Most languages can easily parse CSV. Aside from the trigger pins and mask it shouldn’t be hard to handle.
Then, the client can respond + to dump the current samples as a binary blob.
The trigger stuff isn’t important yet, but it’ll be straight forward to add triggers for more advanced debugging directly from the Bus Pirate terminal. It might be neat if the client can update the triggers on the graph. Adding infrastructure to sigrok for that would be a big undertaking though.
From an educational perspective, I find this incredibly cool. I’ll use it in my bootcamps to teach students. Thx for this @ian
For it to be truly useful for work, the key is being able to use third-party software to apply high-level protocol filters, take measurements, and do all those things that make a logic analyzer really useful and productive—a good software is essential for that.
Ideally, we could use the Bus Pirate while simultaneously monitoring what’s happening in real-time with software like Logic-Saleae or similar, being able to pause, take measurements, etc.
My goal is to make the experience comparable to when I explain Bus Pirate commands and simultaneously connect the Saleae with an SMD IC clip so students can see what’s happening at a low level for each action (in an intuitive software, with cool features, and easy to use).
If we can’t have real-time monitoring, Please, just use a standard export-format that can be directly imported into PulseView, Saleae (.sal), or similar software to easily analyze the data. If it can’t all be done from the firmware, we could create a Python script or something similar to handle it.
You’re right that integration with PulseView / Sigrok / other software analysis tools multiplies the value. You also mentioned Saleae …
In the past, my understanding was that Saleae did not support importing traces from any other format, and that their own .sal format was closed/proprietary. At the time, this appeared to be core to preventing their hard work (intuitive software) from being used with clone devices. Has this changed? Or, more specifically, is it now possible to create .sal files that can be imported into the current versions of Saleae’s viewer/analyzer (even if some limitations exist)?
This was quite literally the only thing holding me back from picking up one of their devices on an RFID-related project about a year ago … so very interested if their position has changed and the format is now open (or any import capability was added, frankly).
Hum, sorry for rapid fire posts, things are moving fast this morning.
I’m going to enable the fala for all hardware versions. There is no reason 5 and 5XL can’t have the feature, but with the huge caveat that what you see is not always what you get. Without that extra buffer high impedance bus (I2C, 1Wire, HDUART, 2Wire) capture will often be incorrect, and any glitches or pull-up issues won’t be visible. However, it keeps everything simple and gives a taste of what’s possible with the new RP2350B chip.
Excited and Curious … how will you enable this on the BP5 (RP2040)?
If it’s not reliable, I would caution against enabling it without at least some warning. While it’s fresh in our minds now from your message above, in six months I won’t remember that it’s not reliable on the BP5. If I then spend hours or days tracking a phantom bug (or not seeing a real one), that would be worse than just not working.
So… maybe show a warning on BP5/BP5XL, with a parameter / switch that bypasses the warning? That would be a good compromise, allowing the cool functionality if wanted, while keeping expectations realistic?
We don’t officially share information about our *.sal capture file format and we’re not ready to commit to keeping that documentation up to date. In addition, we want to avoid making breaking changes to the format which could affect 3rd party integrations.
@henrygab you are right about .sal format… But as a reverser, I don’t see it as a problem haha
Currently, setup the fala before entering a mode. the fala capture speed setup is hooked into the mode change for now.
Enter mode
HiZ> m 6
Use previous settings?
SPI speed: 10 kHz
Data bits: 8
Clock polarity: Idle LOW
Clock phase: LEADING edge
Chip select: Active LOW (/CS)
y/n, x to exit (Y) >
Actual speed: 10kHz
Follow Along Logic Analyzer capture: 40000Hz (4x oversampling)
Use the 'logic' command to change capture settings.
Mode: SPI
SPI>
Entering SPI mode. By default the fala oversamples mode speed by 4x. The mode change hook is used to display the speed and hint to use the logic command (which is not yet implemented).
Only SPI mode is currently playing nice with the fala
Added 500us delay on either side to get a better look. I’m concerned about that CS pin coming up early during the last clock (remember it’s backwards at the moment). Don’t know if that’s an RP2350 thing and we need to be watching for another bit to clear before transmission is considered complete. Hum.
Here’s a firmware that could in theory be used to develop client software It can capture, it reports FALADATA packets through the second serial port, and it dumps data in response to the + command.
Is it better to have a set of functions to access variables from within a “class” (C file), or expose a struct to access directly? I guess with the functions you don’t have to drag a struct def all around any source that needs one define from the file.
IMHO, unless you find a perf blocker, use well-named functions. This will allow you more flexibility to change things (with smaller code changes), simplify finding callers, etc. Some (all) functions will be inherently read-only, which is also really helpful when later wanting to change things around…
I’ve started a simple system of hooks to notify code when certain things happen, like mode changes, pre-post syntax runs, etc.
Using this, both the binary port of the follow along logic analyzer and the VT100 interactive logic graph live in harmony. I’m still in the process of fleshing it out a bit.
Going to see if we can use TAB key to switch focus from command line to the logic graph for navigation.
The logic command is also coming together, hopefully in a way that makes sense.
May add an adjustable delay, based on current capture speed, to get a nicer logic graph as well. Maybe 10 ticks or so?