Raspberry Pico-based 100-Msps logic analyzer
github.com
github.com
I know there are still other advantages of the ESP32 (especially in some of the newer revisions, like upcoming Matter/Zigbee support built in), but I think some people are too quick to dismiss the Pico's RP2040 as overpriced compared to the alternatives.
https://github.com/kbeckmann/PicoCart64/
The creator tweets about it frequently [0], in particular this thread [1].
[0] https://twitter.com/kbeckmann/
[1] https://twitter.com/kbeckmann/status/1538634588020424708
Back in the early days of RasPi there was a competitor, the BeagleBone Black. It was similar to the Pi in many ways, but included embedded MCUs that were meant in much the same ways as the Pico's PIO. You could use them to bitbang protocols that would be difficult/impossible/unreliable to run on the SoC itself.
I thought it was a brilliant idea, but the BeagleBones never got the same level of support that the Pi did. The few times I tried using my Black, I ran into numerous deal breaking bugs.
It's great to see the spirit of this idea is still alive and well. I've got my fingers crossed that they somehow convince Broadcom to build PIO into their SoCs.
The Beaglebone Black was pretty nice compared to contemporary Pi's for embedded work: way more GPIO pins, with female headers rather than male (lower chance of accidental short circuits; easier to just jam components or wires in there like it's a breadboard.)
https://www.righto.com/2016/08/pru-tips-understanding-beagle...
There are two PIO blocks with four state machines each.
Each state machine, along with its supporting hardware, occupies approximately the same silicon area as a standard serial interface block, such as an SPI or I2C controller.
Making state machines programmable in a software-like manner, rather than a fully configurable logic fabric like a CPLD, allows more hardware interfaces to be offered in the same cost and power envelope. This also presents a more familiar programming model, and simpler tool flow, to those who wish to exploit PIO’s full flexibility by programming it directly, rather than using a premade interface from the PIO library.
I'm sad that the beaglebone didn't "win" versus the raspberry pi. I have several Beaglebone Blacks and they're great little devices, even if the PRU is a little hard to use.
Bela includes a xenomai based linux distribution which gives you a hard realtime OS for audio whilst normal linux running as a xenomai task, so you get all the normal productivity and development tools, but your audio is able to run at really low latencies compared to 'normal' OS support.
The Black is low power by todays standards, a single core @ 1Ghz I believe, but it's plenty of power for many audio apps, and boots within seconds, so ideal for embedded applications.
In a former life, we had around 1k BB Blacks and 2k BB Greens deployed in greenhouse automation devices before that startup went bankrupt.
The processors were rather under-powered compared, but generally up to the task. Great little devices.
* 13 bit 8M baud UART receiver for Digipan x-ray sensor. Alternative would have been a small FPGA, but then I would have to deal with several systems. Still had to reduce bit depth of output data, as I couldn't reliably stream data out over USB1.1.
* Sequence and read out the data from EPC901 line sensor for a crude spectrometer- while it might have been done with SPI, bitbanging the control lines and bit-twiddling the read data, I felt that the PIO solution was much more elegant- just launch the statemachine and wait for DMA transfer to finish.
On the other hand, I tried but couldn't really figure out a way to implement stepper motor control with speed ramping in PIO and resorted to porting AccelStepper to RP2040 (which worked out great in the end).
I recently bought a cheap-ish “Zaleae [sic] Logic 16” knock-off from eBay, but it’s still a lot more expensive than most of the other cheap ones out there.
I was stoked to see it works perfectly with Saleae’s latest Logic software, and it ended up with my boss buying us all a set of real Logic Pro 8’s for work.
Their software is by far the gold standard for logic probe capture and analysis, I wonder if it would be possible to hack on this project to get it to output to Logic?
Being able to whip up quick protocol decoders in Python (which then get baked into our actual firmware as a driver by porting it to Nim in about 10 minutes of work) for some of the obscure protocols and peripherals we have to connect to has been fantastic, and Saleae’s software makes it super easy.
Would be great to get the benefits of both cheap hardware and great software but aside from the knock off in front of me showing it can be done, I’ve no idea how you’d even begin to do it!
I've been very happy with it, together with cheap Saleae ex2law-based clones, but I have never tried Saleae's software, so I lack a point of reference.
But if you want to build one, why not?
This could have been as simple as writing a sigrok driver, a process which is very easy thanks to some helper scripts and lots of examples.
It's all there, and linked from the wiki's main page, it's just that there's so much of it.
Examples: http://sigrok.org/gitweb/?p=libsigrok.git;a=tree;f=src/hardw...
That was my point: it's fun to create stuff.
If you run Win11 it might be worth writing a small fast native dedicated capture and display application like this.
But hey, put 'Raspberry' or 'Arduino' label on it and suddenly it's so new and innovative it makes me sick.
Documentation: Pages 198-521 out of this 5118 page PDF:
I get why you feel that way. I think that's the nature of the huge internet and younger folk learning every day. I totally get pissy every time I see someone repost a "discovery" that is 20~30 years old and I've seen many times, just to farm clicks, karma, or whatever internet points their platform rewards. But I think that's just life now: everything is "look at me!" tiktok-ified, even engineering.
But the dude really is pushing the limits of the PICO here, always nice to see someone doing something other than blinking LEDs and jizzing about it on reddit, right?
The logic analyzer itself, even the usage of cheap Pico in it is very cool.
Superficially the PRU and the PIO do indeed look similar. Look more closely and you'll see the PRU is both more complex and more capable than the PIO. It's a small CPU core in its own right with predictable timing. PIO is significantly simpler, almost more of a programmable state machine than a proper CPU. So yes less capable but also integrated into a cheap micro-controller rather than a Linux booting SoC with all the complexity and cost that brings.
That really is why the PIO is interesting, it's the significant capabilities they bring combined with the low price point and simple chip.
I'm annoyed at the power arrangement on the board but they're fun to play with.
I wanted to make a CGA/EGA-to-VGA converter, possibly combined with a scandoubler. Maybe it's still possible using resistor arrays on the output side.
I hadn't. That does look very interesting. Thanks!
So it would be interesting how this will affect the mcu market, long term.
Of note, the Teensy-4.1 uses the Cortex-M7 which is even more impressive than the Pico in terms of raw computer.
A long time ago there was a company called "boulder creek engineering" which made a very clever logic analyzer where the trigger pattern was downloaded into an FPGA which made for a easier code (the FPGA would set a 'trigger' bit and software could use it as the store/don't store flag).
The HP Logic Dart had a feature which I've yet to see reproduced on any logic analzer (even the multi thousand $$ ones) which is you could set the Vhigh and Vlow thresholds over a wide range which would let you work with everything from TTL to LVDS signaling all in the same instrument. Sadly I don't think anyone makes the 100MHz comparator pairs that would be needed for this.
A differential input is a comparator, in a sense, and an FPGA has plenty of those that are useful to 100 MHz+. A trimpot might be used to scale the voltage threshold as needed.
I'm an amateur so can't really justify a real logic analyzer, but my hacked up sketches and python scripts for the Arduino have nothing on this level of polish so definitely going to give it a try next time!
They work with the open source sigrok software and basically just DMA the io to the host, thus the sampling rate and the cost, but can record for dozens of minutes.
Here's what the project's README says:
So, how the heck the pico is able to achieve this? Well, the key are the PIO units, these units are a wonder, they are coprocessors explicitly dessigned to handle IO, it uses a very restricted and deterministic assembler (only nine instructions that each take a single cycle to execuet) but extremely efficient, so efficient that with only two instructions is possible to create a loop that captures GPIO data up to 30 bits and redirects the program flow based in the status of one of these GPIOs.
Notably the PIO feature on the RP2040 is used to avoid having to sample input pins using the ARM CPU (which would make it slow and undeterministic). The sampling is effectively hardware-assisted using the PIO feature. The github page in the link goes into some detail about it.
Here's an unusual approach to portability for this kind of software: since Chrome supports Web Serial, a web app could do the UI and then it would be portable across operating systems (though still Chromium specific) with no software to install (assuming you already have Chrome or Edge).
Along those lines, I wrote a little web app that plots CSV data from a microcontroller board (which happens to be a Pico). There's not a lot to it, but I like it better than the Arduino plotter and it might be useful as an example:
Why even use that, might as well use the Pico W and regular HTTP(S). Web Serial is a bad idea...
Firmware programming is a small niche, but it's been useful and I hope other browsers support Web Serial eventually.