Today I have to get things cleaned up and running smoothly:
Get Cmake to spit out multiple projects/versions
Unify the source for REV8 and REV10 back to main
Get the compile server to package everything up
Things I hope to get to:
Add Polish translation
Make an entry point for @dreg to do AVRdude compatibility layer
Pull Paul’s DSO into main
Dig around in the SUMP logic analyzer compatibility layer/
Test Pico Probe firmware on Bus Pirate
Update: Build server is now posting one .zip file with firmware for rev8 and rev9.
Things I’m thinking about:
I’m going over translations at the moment. an issue we have is that all translations have to be complete or there’s a compile error. that means developers have to update all translations with defaults all the time. we could use some precompiler magic, but it would be ugly (if I did it…)
I think a nice thing to do: all translations in jSON files. English is the default. other languages would be built by script and the defaults used to fill in missing defines with default values
the benefit of this is that a simple client side website could load translations and allow edit and submit from a browser
@AreYouLoco suggested weblate, which looks pretty amazing. I don’t have any experience integrating it though, but it’s probably better than rolling my own.
I consolidated my work on various branches, the first stage of binary IO mode (BBIO) is working again. sig-rok can enter SUMP mode and get the proper stats and setup a capture. When I was poking around I found a sump script that’s already RP2040-ized, so i think i’ll move over to that, but still use the gusmanB PIO program to do the actual triggers and captures because it’s more advanced.
ETA: there is no actual capture yet, I’m just getting the interface going. The capture part comes next, and I have some ideas about using it from the command line too.
There is an LA_rework branch that has a 50% working sig-rok compatible logic analyzer. I need to keep digging why it only captures on every-other run. The debug from the BP5 looks good, but sig-rok isn’t grabbing the data.
I also assembled the arbitrary waveform generator board I did a while back. Hope to bring that up later this week.
I’ve ported two projects, a continuous sampling LA that works with sig-rok, and a hardware capture LA that goes fast and works with a custom client. The firmware is posted somewhere around here, and the ports are in the repo on various branches.
I planned to port the second one to the Bus Pirate and adapt it to use SUMP protocol with sig-rok. Well, a few days ago I noticed it is GPL licensed, and we’re MIT licensed, so it’s kind of poor situation without the author’s express permission. I’ve talked to him on github before so maybe that’s possible. But, after digging a bit I’m not sure its the right implementation for BP because it focuses on multiple chained devices for massive parallel analysis. Still an AMAZING project.
I found this project, which is a DMA-based capture LA that already works with SUMP. I cannibalized the SUMP interface because it already "speaks rp2040’ and saved me a day porting the old ugly state machine from Bus Pirate 3. However, the speed is low and the triggers are in software. It makes up for it with a focus on RLE, which is cool. Unfortunately I absolutely cannot get it to work consistently, I believe there are DMA and interrupt conflicts messing with the state machine and debugging has been slow.
So, I’m going to refresh myself on RP2040 DMA by studying Paul’s DSO code again, and bringing up the little arbitrary wave generator board I made a while ago. Then I’ll dig into making a from scratch logic analyzer.
Logic analyzer thoughts
RP2040 DMA supports a ring buffer mode, but when I studied it before it lacked some important piece to easily make a logic analyzer. I need to remember why.
Using PIO for some kind of trigger mode and sample down-count and halt. GusmanB’s project has a lot of inspiration for this, but he also uses a 4 section ping pong buffer instead of a ring buffer.
ETA: When I was poking around PIO counters, I came upon this frequency counter. Is this something that might interest anyone?
I spent some time with the wave generator, and refreshing my understanding of the RP2040 DMA.
I’m sure there’s a reason this won’t work, but here’s my approach to the logic analyzer:
2 DMA channels chained together write to the same big buffer non-stop.
PIO matches trigger condition (level or edge? sig-rok SUMP only supports levels)
PIO begins deincrement of post-trigger sample count
PIO halts DMA when count = 0
Detect DMA stop and current address (hopefully), read out samples
Most of the other PICO LAs I’ve seen lean heavily on the example from the SDK (single PIO instruction, ping-pong DMA, software triggers). GusmanB’s makes heavy use of PIO, but for massive parallel triggers. I’m probably missing something key if everyone else does it differently.
The issue here is that one statemachine cannot halt another. There is an internal IRQ in the PIO but it only seems to be supported by the wait command. It would be nice to jump on IRQ.
It shouldn’t be a problem to do 62.5msps, but I’m kind of bummed we won’t get to 125msps. I see a way to do full speed, but the trigger point/end point will vary based on system interrupt latency which I’ve seen 100ish plus cycles.
Will continue tomorrow, I’m beyond ready to wrap this one up. Happy lunar new year Eve!
There is a new firmware (mainbranch, auto compiled) with a test of the logic analyzer design. With the latest build you can try the “la_test” command. Please test it out if you’d like, better to catch any hardware related corner cases while it is still easy to debug.
What it does:
PIO deincrements from 31 to 0 and shoves it in the outgoing fifo
DMA transfers fifo to a big circular capture buffer
Every second or so we cycle through the buffer and checks that values are correct
It also reports the active DMA channel (so we know the chain is still running.
This isn’t huge or impressive or even a great test. But, now we have all the ingredients for a logic analyzer:
SUMP protocol functions localized to the RP2040 clock structure and general way of doing things
PIO → DMA free running ring buffer with hardware trigger and pre/post trigger sample counting.
Now I just have to bake those ingredients into a cake. The PIO is a bit annoying because they seem to lack a way for one PIO to halt the execution of another (without one constantly checking for an interrupt, halving the top speed). However, with 200MHz overclocking it can still pull 100MSPS, which is impressive for the cost of the RP2040.
Really hope I can have this closed out tomorrow and move onto SPI mode for flashrom,etc. Then I’d like to spend the rest of spring festival finishing a huge cleanup and rework - before I’m back in hardware production mode next week. We’ll see what gets done.
Wishlist items:
Logic analyzer as a display mode on the LCD like the scope
Logic analyzer as a VT100 scroll/pan graph in the terminal, probably in the secondary screen buffer. I think it would be cool to adopt the command set of vi or nano with ^W jump to time, and similar. I’ll probably tackle this the next time I’m on a long flight, it sounds like a fun little project.
Tie scope/ADC into SUMP for external scope on sig-rok etc
I could use some testers for sig-rok/pulseview, especially under Linux.
It’s been several days of fighting with the logic analyzer, and I’m starting to think there’s an issue in sig-rok’s OLS/SUMP protocol support. I have tried nightlies and the latest release.
I used com port monitor to spy the traffic. Sig-rok sends the correct commands
Every other run, data is returned from the Bus Pirate
Every other run no data is returned, however the debug output in the terminal shows the data return is either A. handled correctly, or B. is interrupted by sig-rok.
Manual sending of the commands with realterm works 100% of the time, capture and return works perfectly.
Using sig-rok with an old Bus Pirate v3 works the first time, then fails and leaves the Bus Pirate in an unclean state.
Using sig-rok with another SUMP pico project fails 50% as well
I tried using Jawi’s OLS0.94.x.x but it is too out of date and dies opening a com port on windows 10
I don’t see any useful errors in sig-rok log with logging set to level 5
I am about to push a firmware to main. Could someone please test it with sigrok? Especially under linux to see if it might be a windows problem?
Got it going with the java client. I does appear that either sig-rok is doing something weird with flow control, or (windows) sig-rok has a bug in the OLS driver.
At this point I just fire 100 bytes back with I see the run command (0x01), and sig-rok just fails without error every other time. i can see in the com port spy that the sample bytes from the previous run are still in the USB buffer when the next run is successful.
Next: move it from usb to uart and see if that still fails. If so, probably a (windows) sigrok issue.
It would be great to have confirmation under linux.
I’m not sure how to reproduce the problem I am looking for. I started up pulseview, selected the BusPirate Device (and I see BusPirate with 8 channels, bit not always - sometimes pulseview doesn’t find it)I pressed Run and I get this:
Does the BP do anything after you type la_test? I get a prompt. Sometimes I can type the command again and sometimes it sits there and does not respond when I press return.
The “la_test” command is separate from the sig-rok compatibility layer and probably doesn’t work anymore at this point, I’ll remove it from the firmware today.
When sig-rok connects to the Bus Pirate, the Bus Pirate command line is disabled so that seems right.
I’m not sure about the buggy detection. Its great that it samples though. Were you able to run it multiple times?
For me, on windows, the first run works fine, the second run fails silently with no error (logic lines are blank). Third run works, fourth doesn’t, and so on. It works half the time, and half the time I get a blank graph like this.
Okay. i plugged the BP in, connected to it on /dev/ttyACM1, detected the device, and pressed run and got the screen above. I pressed run 10 times and each time I saw the same thing. The screen blanked, and then I got the above screen.
I pushed an update to the logic analyzer. It’s starting to work
Working:
Sample from IO pins (remember to power the buffer!!! I lost half a day to that, I should know better)
Sample count
RED leds when armed, Purple LEDs while dumping samples, return to previous setting when done.
Todo:
Set frequency
Set triggers
Going is a bit slow because sig-rok under windows seems to have some issues. I have been testing with the Java client but it has some quirks too, and doesn’t like when I spy on the COM port.
This should be done soon. The I2C bug reported tonight is my priority though, hopefully it’s minor.
Just installed the latest BP5 firmware and downloaded the PulseView nightly on Linux, and getting some odd results.
The BP5 is detected properly, and I can do a capture. But no matter what I have connected, 99% of the time I just get seven channels worth of…something. Each channel looks different, but I haven’t dug deeply into it (let me know if you want me to export this and upload it).
Every time I try to do another capture, it returns what appears to be identical data. Once I try to change the sample rate or number of samples, captures come up blank (even when connected to something known to be spitting out data).
Another interesting thing – it seems like no matter what combination of sample rate and size I pick, the capture always lasts slightly less than 1 second. So 100K samples at 10 Hz will take exactly the same time as 1 MHz.
Although maybe that’s just because PulseView is bailing when it sees something invalid? I could try playing around with the log level and see if something useful comes out, right now it just says “Acquisition took 0.54 s”.
Thank you so so much for testing and feedback. Some of that is expected - the sampling frequency isn’t set yet so everything runs at 62.5MSPS.
I’m not sure if it’s good or bad that you also experience some weirdness with linux/pulseview It definitely feels like there’s some bit rot in sig-roks SUMP driver, at least under windows. I solidly get 50% success, and the samples are from the previous run. I can spy on the USB driver with Device Monitoring Studio (free version with limited time) and see that sig-rok is doing something odd. I can send commands manually with realterm and it works consistently.
Unfortunately the ols java client also seems to need some updates to work on modern operating systems. I will continue tackling this later today.
It seems to be kind of working. It’s really important to connect a supply to VOUT/VREF, otherwise the IO buffers are unpowered and you won’t see anything.
I suggest we enable a 3.3volt supply in LA mode to avoid confusion. It even got me hung up for half a day yesterday, I and designed the thing.
I get garbage once in a while, which I assume is a pointer not being handled properly.
One thing that concerns me is this low point I see once in a while for one cycle. Hopefully it is related to the garbage and a pointer not wrapping correctly, but after the last glitch I’m super paranoid about hardware issues. I’m going to scope it now, then move on with debugging the firmware.
It definitely feels like there’s some bit rot in sig-roks SUMP driver, at least under windows. I solidly get 50% success, and the samples are from the previous run. I can spy on the USB driver with 
