Raspberry Pi Pico

[NorthGuy]

I have read some docs. PIO are nice. They let you bit-bang practically anything and fast too.

[Rasz]

I have read some docs. PIO are nice. They let you bit-bang practically anything and fast too.

Not that fast actually 1/2 main clock, about 150MHz after heavy overclocking. Would be great to have at least a couple fast(1GHz) serdes blocks to do USB 2.0/MIPI in software etc.

[westfw]

So presumably we will see the next generation of Chinese MCUs to come with a PIO controller.

Ideally (in my mind) this will be a triple die SiP, with one RF SDR die, one die with dual core RV32/64GC and a PIO controller with some LUTs, and one external FLASH die to keep the cost down.   

So you haven't actually looked at how the PIO works on the RPi chip, right?

What you describe is similar to the CCL or CLC logic added to some existing chips, that offer small GAL-like functionality (3 input LUTs, one flipflop, connected to various peripheral-side signals (pins, timer status, "events", etc.)

The PIOs are significantly different, with dedicated 32bit-wide FIFO connections to a main AHB bus, and 2 32bit scratch registers for each State Machine (and there are 8 of them on the chip.)   That's MUCH more powerful than the AVR/PIC/SAMD versions.  It might be up there with the Cypress PSoC UDBs, but easier for SW types to manipulate, with "programs" rather than VHDL.)
(There were (briefly?) some PAL-like devices aimed at implementing state machines rather than normal logic; they had some significant internal state that wasn't connected to pins...)

You couldn't do what the RPi PIOs do by connecting an FPGA to a "conventional" ARM chip.

(OTOH, with only 32 instructions for each state machine, you also won't be able to use them very much as the sort of "general purpose co-processor" that some people have been talking about, either.)

[JPortici]

I haven't read the docs for the PIO but what you describe is simillar to the PTG on earlier dsPIC33E.
But that was veeery complex to program and most of the use cases (such as ADC trigger from PWM module conditions) were added as trigger signals from the peripheral themselves

[andersm]

(OTOH, with only 32 instructions for each state machine, you also won't be able to use them very much as the sort of "general purpose co-processor" that some people have been talking about, either.)

32 instructions per PIO block, shared between the four state machines.

I would liken the PIO units more to other specialized real-time coprocessors, like TI's PRU, or Freescale/NXP's (e)TPU, though obviously far more limited. For comparison, here's the documentation for the configurable logic implemented in some Microchip 16-bit MCUs.

[hamster_nz]

(OTOH, with only 32 instructions for each state machine, you also won't be able to use them very much as the sort of "general purpose co-processor" that some people have been talking about, either.)

32 instructions per PIO block, shared between the four state machines.

I would liken the PIO units more to other specialized real-time coprocessors, like TI's PRU, or Freescale/NXP's (e)TPU, though obviously far more limited. For comparison, here's the documentation for the configurable logic implemented in some Microchip 16-bit MCUs.

I am getting the feeling that those who say "Oh that Pi Pico PIO is new and offers exciting possibilities." actually means "Oh that Pi Pico PIO is new [to me] and offers exciting possibilities [because I haven't been exposed to this stuff much]."

[ataradov]

It is about a combination of things. I personally have zero interest in 16-bit (and 8-bit) devices, so even if they have the most excellent peripherals, I just don't care. The rest of it is not worth my time.

[andersm]

The datasheet makes a lot of deterministic timing, something which is nearly impossible to achieve with the Pis. So that's obviously the value proposition for their user base. I expect the next iteration of the Pi SoC to integrate if not a full microcontroller then at least some version of the PIO blocks. It won't fully solve all determinism issues, but would make the Pis a lot better at bit banging.

[aheid]

Would be great to have at least a couple fast(1GHz) serdes blocks to do USB 2.0/MIPI in software etc.

1GHz SERDES bolted to a 48MHz M0+ core... yeah that makes perfect sense.

[NorthGuy]

You couldn't do what the RPi PIOs do by connecting an FPGA to a "conventional" ARM chip.

PIO is a CPU, not logic - 32 16-bit words of instruction memory and lots of programmable configuration registers which affect what the commands do. There are 2 general registers (X and Y) and 8 (or 9?) instructions. There's no ALU, except for counters. It also has a set of FIFOs which can be used to communicate with the main cores. UART or SPI can be implemented with just a handful of instructions.

It wouldn't be hard to generate such core in FPGA, but it probably would be easier to do things directly in fabric.

[tszaboo]

(OTOH, with only 32 instructions for each state machine, you also won't be able to use them very much as the sort of "general purpose co-processor" that some people have been talking about, either.)

32 instructions per PIO block, shared between the four state machines.

I would liken the PIO units more to other specialized real-time coprocessors, like TI's PRU, or Freescale/NXP's (e)TPU, though obviously far more limited. For comparison, here's the documentation for the configurable logic implemented in some Microchip 16-bit MCUs.

I am getting the feeling that those who say "Oh that Pi Pico PIO is new and offers exciting possibilities." actually means "Oh that Pi Pico PIO is new [to me] and offers exciting possibilities [because I haven't been exposed to this stuff much]."

The microchip CLC is more like dedicating some GPIO pins to do core independent logic functions. For example, you can configure 3 pins to do make an OR gate. This one is more like creating unsupported communication ports. I believe some of the Beaglebones had this sort of functionality, but I never dived deep into those boards.
 For example, I2S is not supported, but a good programmer can write the functionality for 4 pins. Or that bastard WS2812 interface can be written, without bitbanging it, or using a timer. I like it, and it doesnt need to be revolutionary new technology.

[Tagli]

As far as I understand, PIO is similar to the GPIF hardware of Cypress FX2LP series. But Cypress provides some GUI based PC program instead of an assembly language. I think assembly is a better method for programing such a hardware.

[NorthGuy]

The microchip CLC is more like dedicating some GPIO pins to do core independent logic functions. For example, you can configure 3 pins to do make an OR gate. This one is more like creating unsupported communication ports.

The Microchips CLCs can be connected to just about any periphery, so you can create/process various custom signals. Say, you can OR a PWM with SPI and produce a waveform which is otherwise unobtainable. They also have flops, so you can produce delays, sync different signals etc. They can do a lot. It's just not that many of them, so the capabilities are limited. It's like a built-in nano CPLD/FPGA. Microchip has an app note with design which uses logic cells to drive WS2812 using a signal produced by the SPI module.

Perhaps, the purpose of PIO is the same as Microchip's CLC - to do something non-standard. However, the implementation is completely different. Also, PIO is certainly much more powerful.

[SiliconWizard]

As far as I understand, PIO is similar to the GPIF hardware of Cypress FX2LP series. But Cypress provides some GUI based PC program instead of an assembly language. I think assembly is a better method for programing such a hardware.

AFAIR, the GPIF in FX2 MCUs was essentially a programmable interface. Not nearly as versatile (but probably more efficient for what it did) as the RP's PIO.

Something closer to PIO would likely be found at Microchip:
https://www.microchip.com/design-centers/8-bit/pic-mcus/device-selection/pic18-q43-product-family

[brucehoult]

You couldn't do what the RPi PIOs do by connecting an FPGA to a "conventional" ARM chip.

PIO is a CPU, not logic - 32 16-bit words of instruction memory and lots of programmable configuration registers which affect what the commands do. There are 2 general registers (X and Y) and 8 (or 9?) instructions. There's no ALU, except for counters. It also has a set of FIFOs which can be used to communicate with the main cores. UART or SPI can be implemented with just a handful of instructions.

It wouldn't be hard to generate such core in FPGA, but it probably would be easier to do things directly in fabric.

What I don't get is if you're going as far as that, why *not* add a proper ALU and general purpose but simple instruction set?

[westfw]

There's no ALU, except for counters.

And shifters, right?

The Microchips CLCs can be connected to just about any periphery

But not to the data memory or bus.

why *not* add a proper ALU and general purpose but simple instruction set?

Why add that complexity?  They've already got two M0 cores...

Microchip has an app note with design which uses logic cells to drive WS2812 using a signal produced by the SPI module.

All you need is two (carefully selected from ~4) CLCs, the SPI interface, and a PWM timer.
Whereas the RPi chip can do it all with one PIO (of (~6 lines of code!), without sacrificing the other peripherals.

It wouldn't be hard to generate such core in FPGA

An FPGA implementation of a "simple" thing like this would be interesting to see; mid-way between trivial examples and full CPUs.  For each PIO, you'd need 32 words of "program memory", at least 8 words of FIFO (make expandable, for extra points), some bus to access them (and distinguish accessing the program mem vs the FIFOs), the "core", some sort of clock system, and a bunch of IO pins.  I'd think that in theory you could fit "a couple" on a relatively small FPGA, and "many" on a big FPGA.

[ataradov]

An FPGA implementation of a "simple" thing like this would be interesting to see; mid-way between trivial examples and full CPUs.

This is what Xilinx PicoBlaze is. It started as a state machine generated based on the "program" code. Then it evolved into a simple control and I/O core.

[westfw]

Oooh.  32 USB Endpoints!  That's nice.(Compares to 16 endpoints on SAMDxx, 7 endpoints on ATmega32u4)

I've never quite understood why there can't be a buffer bucket for "some other endpoint; deal with it in SW." (like IP "protocol" or TCP "port", or ethernet multicast...)

[ataradov]

Because USB controller has to respond immediately to request. Even if it is just a NAK. So you need to have hardware to support that.

It is not a lot of hardware, but it is not nothing.

[Nominal Animal]

Oooh.  32 USB Endpoints!  That's nice.(Compares to 16 endpoints on SAMDxx, 7 endpoints on ATmega32u4)

The more important question is, whether this is the first Raspberry Pi device that actually implements USB correctly.

Thus far, all Raspberry Pis have suffered from the Broadcom hardware bug, that in certain situations causes USB packets to be dropped on the floor.
This should never be allowed to happen.

They have tried to work around it in software, and I hear that "it works pretty well now", but until they actually implement a working USB hardware, I would not use a Pi for anything more important than controlling LEDs, or as a cheap-but-not-very-reliable webcam.

(Even then, knowing the Raspberry Pi Foundations' attitude towards Linux developers – much like Broadcom "you fuckers deserve nothing, and we'll just take this stuff, you ugly long-haired smelly hippies" – I would not be pushing any of my bugfixes etc. upstream.)

[ataradov]

This device has nothing to do with Broadcom. Why would it be affected by that issue.

Is it possible that there are some issues? Sure. But unlike with the situation where you buy readily available chips, that would be on RPi people to fix.

[Nominal Animal]

This device has nothing to do with Broadcom.

Eh? The Raspberry Pi Foundation is really just the PR arm of Broadcom, with Eben Upton the glue.

(In legalese: the Foundation is supported by Broadcom and the University of Cambridge Computer Laboratory.)

[hamster_nz]

This device has nothing to do with Broadcom.

Eh? The Raspberry Pi Foundation is really just the PR arm of Broadcom, with Eben Upton the glue.  (Not legally, sure, but in every other way.)

I've been following the Pi since before it was released, and to me it seems the truth is somewhere in the middle.

The relationship offers different things to each of the partner, and seems to achieve both of their goals.

The only people who a freeloaders seem to be the semi-professionals, who get the platform but give little to the wider ecosystem, then moan that the can't order in quantity and that broadcom doesn't offer technical support for free...

[Nominal Animal]

This device has nothing to do with Broadcom.

Eh? The Raspberry Pi Foundation is really just the PR arm of Broadcom, with Eben Upton the glue.  (Not legally, sure, but in every other way.)

I've been following the Pi since before it was released, and to me it seems the truth is somewhere in the middle.

The relationship offers different things to each of the partner, and seems to achieve both of their goals.

The only people who a freeloaders seem to be the semi-professionals, who get the platform but give little to the wider ecosystem, then moan that the can't order in quantity and that broadcom doesn't offer technical support for free...

Who are you referring to?  The Pi folks themselves are very loathe to interact with FOSS developers, and instead just grab whatever they use.  Isn't that exactly "getting the platform but giv[ing] little to the wider ecosystem"?

It's not like they provide basically anything back to Debian, despite their "Raspberry Pi OS" being derived from Debian, for example.

[hamster_nz]

This device has nothing to do with Broadcom.

Eh? The Raspberry Pi Foundation is really just the PR arm of Broadcom, with Eben Upton the glue.  (Not legally, sure, but in every other way.)

I've been following the Pi since before it was released, and to me it seems the truth is somewhere in the middle.

The relationship offers different things to each of the partner, and seems to achieve both of their goals.

The only people who a freeloaders seem to be the semi-professionals, who get the platform but give little to the wider ecosystem, then moan that the can't order in quantity and that broadcom doesn't offer technical support for free...

Who are you referring to?  The Pi folks themselves are very loathe to interact with FOSS developers, and instead just grab whatever they use.  Isn't that exactly "getting the platform but giv[ing] little to the wider ecosystem"?

It's not like they provide basically anything back to Debian, despite their "Raspberry Pi OS" being derived from Debian, for example.

The use of the RaspPi in commercial or semi-commercial products isn't of much interest to them, they are quite open that they would prefer to sell them such that they not only make money for Raspberry Pi, but also work towards the Foundation's aims. I can't blame them for that.

The original Raspberry Pi was the Raspberry Pi Foundation's attempt at a "Saved pocket Money/Birthday gift" computer, aimed at allowing keen people to experience and learn more of Computer Technology outside of the "This is Word, Excel, PowerPoint and Email on Windows XP" world of the school IT curriculum in the early-to-mid 2000s.

The Raspberry Pi Foundation is a UK charity, with the aim of:

The object of the charity is to further the advancement of education of adults and children, particularly in the field of Computers, Computer Science and related subjects

As a charity, I understand it is would be legally questionable if they were to donate their money or resources to others that is not directly supporting their efforts as a charity (e.g sponsoring the Debian project) - that's not how charities work.

And they are under no obligation to do so either. After all, aren't the freedoms of Free Software Definition:

Freedom 0 - the freedom to use the work

Freedom 1 - the freedom to study the work

Freedom 2 - the freedom to copy and share the work with others

Freedom 3 - the freedom to modify the work, and the freedom to distribute modified and therefore derivative works

An the GPU even includes such phases as:

freedom to distribute copies of free software (and charge for them if you wish).

The Pi foundation are doing exactly what Free Software is about. It is what authors sign up for when they give their code that license.

Now some might not like that they Pi's design isn't fully open (e.g. binary firmware blobs, no schematics) but the Pi never pretended to be an "open platform" nirvana, just a platform you could run software on, that a computer-mad kid could buy using pocket money.

I also think many do not know that a prototype for the Pi was an ATmega644 with 512K SRAM - it wasn't an Broadcom conspiracy from day 0, it was a case of the right people in the right place at the right time.