People sometimes dismiss the Pico in comparison to an ESP32 or other ESP-based devices (even the newer Pico W, which has wireless capabilities, with Bluetooth LE potentially added via software update in the future), but I've seen Picos running as N64 flash carts, logic analyzers, signal generators, etc. in places where formerly only more expensive FPGAs or low power ARM SoCs (not on the microcontroller level) were used before. It's not punching too much above it's weight, but the PIO does seem to be a very useful feature.
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.
> but the PIO does seem to be a very useful feature.
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 PRUs were really hard to use. I think if they had invested in dev tools with a shallow learning curve, like Arduino support for the PRUs, they might have gained critical mass.
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.)
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.
There's a possibly-DOA project called BeagleV to produce a modern 1 GHz-class board running a RISC V system.
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.
I remember a lot of fanfare around the BeagleBone models, that was in the time in my career I was focused mainly on software / webdev. I remember there was even a $10 model, but IIRC there were some fulfillment issues?
Yes, there are still fulfillment issues, the Octavo SoC is nowhere to be found. As a product, the PocketBeagle is better and lower energy consumption than the Pi Zero. You could both power it and access it from USB, it has two CAN bus ports and 4 UARTs. I couldn't ethernet + power over a single USB cable to work on the Pi Zero, yes on the PocketBeagle it works out of the box. But then the Pi Zero added WiFi, the mode powerful and energy hungry Pi Zero 2 W, while the PocketBeagle continued to have fullfillment issues and it has probably gone past $50.
Since the start of chip shortage I have been defaulting to RP2040 for my hobby/learning projects. The PIO has been useful for some applications:
* 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).
Oooh, built-in Zigbee support would be amazing, especially if the core could properly sleep to get minimal power usage. I'd love to create my own Zigbee devices easily.
That's impressive. I was suspicious until I saw the quad-byte DMA ringbuffer with the super small PIO program. He's overclocking to 200 MHz (!!!) and the framing protocol does have bugs (see comments), but impressive all the same. Also the message buffer is pretty small but now I'm just being picky: streaming to UART while sampling wouldn't be possible without giving up some channels and slowing down the sample rate.
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!
Software-wise, there's also Sigrok, which is open, and the corresponding Pulseview UI.
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.
Sigrok is decent too, very powerful, but Logic’s UX and workflow is just so much nicer, at least in my opinion anyway. It’s protocol decoder API is quite a bit easier to use, though I did not go anywhere near as deep in that with Sigrok, to be fair.
There is a driver and firmware for sigrok for using the PI Pico that was posted to Hackaday a while back. It hasn't been merged upstream yet but I got it up and running today just fine building it from source. https://github.com/pico-coder/sigrok-pico
I found the sigrok website hard to navigate, and never found these examples. I'd love to learn more, as I just threw a decent fast ADC together for fun.
I recently tried to run Sigrok on a Windows 11 PC with the Salea clone and I could not find a version that did not crash on the second capture. It seems to run fine on my Mac. So I was flashing the board Windows (due to the new serial to USB chips not being supported under Monterey).
If you run Win11 it might be worth writing a small fast native dedicated capture and display application like this.
It seems like the author is only aware of "OLS, OpenBench Logic Analyzer", as they mention not liking that as their reasoning for writing their own app.
The Pico's PIO peripheral is actually a really innovative feature in a microcontroller. It plugs the gap where you need some sort of fast custom I/O but you don't want to go to the complexity and cost of an FPGA. I'd love to see more mainstream vendors offer something similar.
> But hey, put 'Raspberry' or 'Arduino' label on it and suddenly it's so new and innovative it makes me sick.
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?
For one thing, the PRUs require TI’s bloated mess called CCS and knowing C whereas the PIO assembly can be written in Python. What’s really innovative is the ability to get PRU-like functionality on a literal $1 IC. Sure, you only get 32 instructions per state machine, but not everyone needs full blown ARM cores for real-time.
They don't require it. When I used it, everything was just written in assembly (you get a few more instructions but you're still basically doing bitbanging with cycle counting, so using C is a bit awkward anyway). The PIOs are a pretty neat trimmed down version of the idea though, clearly someone put a fair amount of effort into making them as flexible as they are for how minimalist they are.
I think C is a trap, honestly. I have used the PRUs before and wrote my code in C. 99% of the time, I was just reading the assembly outputs trying to figure out how many instructions some C statement actually compiles to. Should have just written raw assembly for the timing-sensitive parts.
Bit of a difference between a cheap microcontroller board and a BeagleBone Black.
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.
Or, more like TI locked you in to their garbage IDE that cost quite a lot of money to unlock fairly standard debugging and compilation features. They entirely shot themselves in the foot with that one.
I would love a version of Pico PIO with analog out (along with a limited integer ALU, or perhaps just shifts and some logical ops). A fast DAC should be cheap in silicon, right?
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.
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've previously used an Arduino mega as an ad hoc logic analyzer. Can anyone chime in with how the IO performance of the RP2040 differs from the ATMega range?
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!
The RP2040 has a programmable IO subsystem. This lets you define a simple state machine that manages the IO pins and can transfer data to/from memory.
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.
You can hardly compare the atmega series CPUs with 32-bit ARM SoCs running at 10+ times the clock speed, much more memory, and many more advanced features. The RP2040 (the SoC on the pico) is very much a generation beyond the atmegas, if not more.
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.
I'm asking for them to be compared in terms of IO features, not absolute performance. The ATMega has it's own range of hardware driven input features and that's specifically what I'm asking for a comparison to.
Not really sure what you mean by i/o features, but I generally don't get why people don't look up the specifications if they have questions like that. They do exist for a reason.
I'd really recommend an fx2 logic analyzer. Basically anything called logic analyzer on Amazon or Aliexpress with 24 MHz sample rate, 8 channels and for less than 15 bucks.
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.
Nice! Looks like the protocol between the Pico and the Windows software is quite simple. Porting it to another OS shouldn't too hard.
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:
> 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).
Why even use that, might as well use the Pico W and regular HTTP(S). Web Serial is a bad idea...
I quite like using USB-connected microcontrollers and Web Serial. I'm working on a MIDI controller, so WiFi isn't a good idea due to the latency. (Not to mention the running a web server on a Pico would probably get in the way of real time stuff.)
Firmware programming is a small niche, but it's been useful and I hope other browsers support Web Serial eventually.
People sometimes dismiss the Pico in comparison to an ESP32 or other ESP-based devices (even the newer Pico W, which has wireless capabilities, with Bluetooth LE potentially added via software update in the future), but I've seen Picos running as N64 flash carts, logic analyzers, signal generators, etc. in places where formerly only more expensive FPGAs or low power ARM SoCs (not on the microcontroller level) were used before. It's not punching too much above it's weight, but the PIO does seem to be a very useful feature.
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.
> but the PIO does seem to be a very useful feature.
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 PRUs were really hard to use. I think if they had invested in dev tools with a shallow learning curve, like Arduino support for the PRUs, they might have gained critical mass.
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.)
Indeed. Ken Shirriff wrote about using the Beaglebone's PRUs:
https://www.righto.com/2016/08/pru-tips-understanding-beagle...
This is great. Is there some tutorial of this caliber for Pico's PIOs?
Check official documentation of the RP2040 and see if you like that. It's chapter 3.
https://www.raspberrypi.com/documentation/microcontrollers/
Some interesting excerpts:
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.
The Pico’s official documentation seems leagues better than what the PRU’s offer(ed).
There's a possibly-DOA project called BeagleV to produce a modern 1 GHz-class board running a RISC V system.
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.
The BeagleBone is the basis for some really cool audio tech - https://shop.bela.io/
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.
The best part of the BeagleBones, in my opinion, was the onboard eMMC. Soooo much more reliable than running from sd cards at "scale".
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.
A project similar to this one for the Beaglebone Black:
http://beaglelogic.github.io/
I remember a lot of fanfare around the BeagleBone models, that was in the time in my career I was focused mainly on software / webdev. I remember there was even a $10 model, but IIRC there were some fulfillment issues?
Yes, there are still fulfillment issues, the Octavo SoC is nowhere to be found. As a product, the PocketBeagle is better and lower energy consumption than the Pi Zero. You could both power it and access it from USB, it has two CAN bus ports and 4 UARTs. I couldn't ethernet + power over a single USB cable to work on the Pi Zero, yes on the PocketBeagle it works out of the box. But then the Pi Zero added WiFi, the mode powerful and energy hungry Pi Zero 2 W, while the PocketBeagle continued to have fullfillment issues and it has probably gone past $50.
Since the start of chip shortage I have been defaulting to RP2040 for my hobby/learning projects. The PIO has been useful for some applications:
* 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).
The mentioned N64 cartridge is most likely this project:
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
And on a similar note is the PicoBoot, a Pico-based modchip for the Gamecube (https://www.tomshardware.com/news/raspberry-pi-pico-gamecube...).
That’s literally super cool.
Oooh, built-in Zigbee support would be amazing, especially if the core could properly sleep to get minimal power usage. I'd love to create my own Zigbee devices easily.
How is the Pico W & lwIP stack in terms of security and robustness?
That's impressive. I was suspicious until I saw the quad-byte DMA ringbuffer with the super small PIO program. He's overclocking to 200 MHz (!!!) and the framing protocol does have bugs (see comments), but impressive all the same. Also the message buffer is pretty small but now I'm just being picky: streaming to UART while sampling wouldn't be possible without giving up some channels and slowing down the sample rate.
Very cool stuff!
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!
Software-wise, there's also Sigrok, which is open, and the corresponding Pulseview UI.
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.
Sigrok is decent too, very powerful, but Logic’s UX and workflow is just so much nicer, at least in my opinion anyway. It’s protocol decoder API is quite a bit easier to use, though I did not go anywhere near as deep in that with Sigrok, to be fair.
fx2lafw*, I blame autocorrect
Looks great, only question is why invent your own software when sigrok exists?
There is a driver and firmware for sigrok for using the PI Pico that was posted to Hackaday a while back. It hasn't been merged upstream yet but I got it up and running today just fine building it from source. https://github.com/pico-coder/sigrok-pico
Why build your own logic analyzer when you can buy one Banggood?
This. I own a shitty one from Aliexpress. That and sigrok are better than my old full 4U HP crate I had.
But if you want to build one, why not?
For one thing, the author could have avoided all the work of creating a GUI and lots of protocol analyzers, and thus got his project working faster.
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.
I found the sigrok website hard to navigate, and never found these examples. I'd love to learn more, as I just threw a decent fast ADC together for fun.
https://sigrok.org/wiki/Developers#Development_guidelines
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...
>But if you want to build one, why not?
That was my point: it's fun to create stuff.
Is Sigrok better than Saleae Logic?
Sigrok is software. Saleae makes hardware.
Saleae Logic is software: https://www.saleae.com/downloads/
I recently tried to run Sigrok on a Windows 11 PC with the Salea clone and I could not find a version that did not crash on the second capture. It seems to run fine on my Mac. So I was flashing the board Windows (due to the new serial to USB chips not being supported under Monterey).
If you run Win11 it might be worth writing a small fast native dedicated capture and display application like this.
Maybe author doesn't like sigrok?
It seems like the author is only aware of "OLS, OpenBench Logic Analyzer", as they mention not liking that as their reasoning for writing their own app.
They added a note to the readme on sigrok crashing. To be fair, I only ever used it on Linux.
The Pico's PIO peripheral is actually a really innovative feature in a microcontroller. It plugs the gap where you need some sort of fast custom I/O but you don't want to go to the complexity and cost of an FPGA. I'd love to see more mainstream vendors offer something similar.
It has been a feature of many TI microcontrollers ( and CPUs ) for quite a while under the name “PRU”
Also, PSoC-s from Cypress.
https://en.wikipedia.org/wiki/Cypress_PSoC
I thought the PRU was only available on their ARM A-series SoCs? I'm more referring to a bare metal microcontroller class part.
Exactly. And people have been also using them for this exact purpose. https://hackaday.com/2015/02/19/turn-your-beagleboneblack-in...
But hey, put 'Raspberry' or 'Arduino' label on it and suddenly it's so new and innovative it makes me sick.
> But hey, put 'Raspberry' or 'Arduino' label on it and suddenly it's so new and innovative it makes me sick.
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?
My reaction was only meant as a response to @Sanzig calling PIOs innovative.
The logic analyzer itself, even the usage of cheap Pico in it is very cool.
Well dammit, now I'm the a*hole. ;)
For one thing, the PRUs require TI’s bloated mess called CCS and knowing C whereas the PIO assembly can be written in Python. What’s really innovative is the ability to get PRU-like functionality on a literal $1 IC. Sure, you only get 32 instructions per state machine, but not everyone needs full blown ARM cores for real-time.
They don't require it. When I used it, everything was just written in assembly (you get a few more instructions but you're still basically doing bitbanging with cycle counting, so using C is a bit awkward anyway). The PIOs are a pretty neat trimmed down version of the idea though, clearly someone put a fair amount of effort into making them as flexible as they are for how minimalist they are.
I think C is a trap, honestly. I have used the PRUs before and wrote my code in C. 99% of the time, I was just reading the assembly outputs trying to figure out how many instructions some C statement actually compiles to. Should have just written raw assembly for the timing-sensitive parts.
It's getting better: https://simppru.readthedocs.io/en/latest/
Bit of a difference between a cheap microcontroller board and a BeagleBone Black.
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.
Programmable Real-Time Unit Subsystem and Industrial Communication Subsystem (PRUICSS).
Documentation: Pages 198-521 out of this 5118 page PDF:
https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf
Or, more like TI locked you in to their garbage IDE that cost quite a lot of money to unlock fairly standard debugging and compilation features. They entirely shot themselves in the foot with that one.
Maybe because the primary markets for TI and Raspberry are different.
And let's not forget poor XMOS.
Vendors won't offer that capability cheaply. That's against their business model of "differentiating" on peripherials and extracting value from that.
So it would be interesting how this will affect the mcu market, long term.
I would love a version of Pico PIO with analog out (along with a limited integer ALU, or perhaps just shifts and some logical ops). A fast DAC should be cheap in silicon, right?
The pimoroni servo2040 uses the PIOs to PWM 18 servo channels: https://shop.pimoroni.com/products/servo-2040?variant=398005...
I'm annoyed at the power arrangement on the board but they're fun to play with.
That's a nice usecase. Servos are slow mechanical things.
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.
Have you seen gbs-control?[1] It's not exactly what you're trying to do, but maybe close enough?
[1] https://github.com/ramapcsx2/gbs-control
(Very late, sorry.)
I hadn't. That does look very interesting. Thanks!
This kind of project is really nice, there is a great design document which talks about issues building logic analyzers out of Cortex-M boards here: https://sysprogs.com/w/how-we-turned-8-popular-stm32-boards-... which you may find helpful as well.
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.
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.
That would be a good hack.
I've previously used an Arduino mega as an ad hoc logic analyzer. Can anyone chime in with how the IO performance of the RP2040 differs from the ATMega range?
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!
The RP2040 has a programmable IO subsystem. This lets you define a simple state machine that manages the IO pins and can transfer data to/from memory.
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.
You can hardly compare the atmega series CPUs with 32-bit ARM SoCs running at 10+ times the clock speed, much more memory, and many more advanced features. The RP2040 (the SoC on the pico) is very much a generation beyond the atmegas, if not more.
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.
I'm asking for them to be compared in terms of IO features, not absolute performance. The ATMega has it's own range of hardware driven input features and that's specifically what I'm asking for a comparison to.
Not really sure what you mean by i/o features, but I generally don't get why people don't look up the specifications if they have questions like that. They do exist for a reason.
I'd really recommend an fx2 logic analyzer. Basically anything called logic analyzer on Amazon or Aliexpress with 24 MHz sample rate, 8 channels and for less than 15 bucks.
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.
You can do better with an FX3 dev kit - https://community.infineon.com/t5/Knowledge-Base-Articles/EZ...
Except there is currently no fx3 driver in sigrok mainline. It's not a compatible chip to the FX2.
At $50-$100, the FX3 development kit is roughly 10x the price of an FX2 board.
Nice! Looks like the protocol between the Pico and the Windows software is quite simple. Porting it to another OS shouldn't too hard.
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:
https://github.com/skybrian/serialviz
> 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).
Why even use that, might as well use the Pico W and regular HTTP(S). Web Serial is a bad idea...
I quite like using USB-connected microcontrollers and Web Serial. I'm working on a MIDI controller, so WiFi isn't a good idea due to the latency. (Not to mention the running a web server on a Pico would probably get in the way of real time stuff.)
Firmware programming is a small niche, but it's been useful and I hope other browsers support Web Serial eventually.
I've been wanting to do something like this, looks great.
Time to pull the low cost Lighthouse V1 tracker project back from the shelf. This is what I needed for one!
Who will be the hero that will port this from .NET to Python?