Structure of the Bus Pirate logic analyzer system.
Follow along is fully integrated with all the protocol modes. On mode change the fala base frequency is updated to match the mode frequency. Then, a multiplier (8 by default) sets the oversample rate.
New feature: -0 and -1 flags set the characters for the low and high on the logic graph. Experiment to find something that looks ok. I’m currently liking _#.
There are still bugs and I need to go through each mode one-by-one. SPI works great, but most other modes are buggy/not capturing samples at all. Possible reasons to investigate:
- Things are generally not working on RP2350? Bugs related to that
- Logic analyzer isn’t quite implemented right
- Modes are exiting early due to buffering/FIFO in PIO, so we don’t capture anything
- I did a huge rework of the modes struct, maybe I botched it
Remaining todo, aside from the bugs:
- 8 sample delay before and after capture, to be implemented in fala_start and fala_stop
- TAB key to jump to/exit logic graph
- Test/debug on hardware <6
ETA: ah, I figured it out. I blew out all the PIO configurations with the logic analyzer The SDK has a new function to find a PIO and SM that will fit a given program, I will update everything to use that, it needs to be done anyways.
This is merged into main and applied to all hardware versions. I’ll add a warning for <6, but you can try logic on any hardware version now
Ah, 12 days later and we can finally return to the thing that kicked off the descent into E9 madness
The logic
command has a new -b
flag that sets the base pin. This pin, and the next 7 consecutive pins, will be captured by the logic analyzer:
- 0 - gpio 0…7 control the IO buffer direction (input/output). Capturing here helps debug internal signals that control open drain bus types.
- 8 - gpio 8…15 control the IO buffer direction (when buffer output) or track the IO pin input (when buffer input). Bus Pirate 5/5XL can get some idea what is happening on the bus through these pins, but it is by no means 100% accurate under all circumstances because we see the back of the buffer.
- 20 - gpio 20…27 on Bus Pirate 6 are the second buffered connection to the IO pins. This reflects what is actually happening on the IO pins in the real world.
These are just the most useful ranges. The base pin can be set arbitrarily to watch any 8 internal signals, such as the SPI bus shared by the NAND, LCD, and 595 chips.
It would be very nice to have a sample setup/demo we can reproduce. I’m not that clear on the setup.
Docs are drafted, there’s a bunch to push, I’ll do it asap.
Once the PIO program is in place for the FALA, can it run multiple instances on different pins? e.g., both base pin 0 and base pin 20, using two state machines on that one PIO?
For oneWire (or other bi-directional protocols), it would seem of interest to track both direction and data simultaneously. Just wondering … not asking for this to be implemented.
That may be hard on 2040. I believe almost all the DMA bus fabric is used for the single la. Expanding it to 16 or 32 bits is doable though, but I tore that out of the pio and support software I guess rp2350 has new dma methods that should make it much simpler, but I haven’t gotten that far yet.
There are four new pages of documentation for sigrok/PulseView, the logic
command and the follow along logic analyzer interface.
I REALLY need to check out GusmanB’s latest logic client. It was kind of weird to deal with in the early days, but it seems to have come a long ways. He even has a way if supporting all the sigrok protocol decoders!
Anyone else have a look? I downloaded it but won’t get to it for a while yet.
The client already supports async captures, so it would work with the FALA. I’ve previously looked at the protocol and it’s simple and elegant. I would replace the FALA thing I prototyped above with the GusmanB protocol.
I tried the logic analyzer but it just starts with the logo and then abruptly ends before loading.
Solution to the GusmanB logic analyzer issue:
Try to delete the file “%AppData%\LogicAnalyzer\AppConfig.json” and check if this solves the problem.
With the latest fix to Bus Pirate SPI mode and the patched PulseView FALA is starting to come together.
The next step is to go through each mode and create a new function that confirms when a transaction is 100% complete and the bus is totally idle. There’s a lot of buffering going on that causes FALA to end capture too soon.
1-Wire appears to be FALA “compatible” now.
However, yesterday it got into a state where there were extra garbage samples at the end of every trace. I can’t reproduce that now, but something to keep an eye on.
My plan to is progress through the modes in order of the menu options. When I arrive at INFRARED I’ll finish out that mode. Then, I plan to review and document anything to do with scripts (button, scripting, tutorials, macros). At that point I believe we should (purely symbolically) declare v1.0
Does it make sense to have, in the github repo, little “scripts” to test some example devices? Your web site has a few, but a repo would allow others to contribute easier.
I like the idea, but think the official ones should live within the bpv5 repo. Just my opinion. Interested in others.
This has come up in the past and I did make a repo for scripts, but it didn’t seem to catch on.
Maybe I need to find a lower barrier way to submit/browse scripts? I’ll think it over when I’m doing the scripts docs.
I must have missed it. Where was it? It would be nice to have a simple script that documents the wiring, preconditions (which pins must be hi/low, sample bus injection commands. You had some examples in the forum as well as some sample parts in Device Demos | Bus Pirate 5 Firmware
I was thinking, if nothing else, that it could be a subdirectory in the firmware repo. And people could send in push requests.
True, it’s not properly firmware, but it is the main repo to get updates.
I’m not a github expert, but could you have another repo - just with sample scripts - as a sub-module to the firmware?
You are totally right, it would be great to have official scripts/tutorials for all the demos in the manual. Adding them as a submodule would keep the firmware repo clean.
Here’s the repo I made, it is very unloved
It’s empty… Perhaps that’s why?
Let’s see if we can get some people to contribute.