Raspberry Pi Pico

As expected there is not 16PWM channels
(marketing bs)
Instead there is only 8 PWM outputs each with the inverse output also available
 
I see no encyption, too, but that does not mean that they can't add it in a future revision.
And maybe there are MCUs with encryption in the pipeline (or already available?), for industrial use.
RP2040, where the 0 stands for CORTEX-M0.
Soon we will see RP24xx or RP27xx. Just wait two years.


EDIT: or, encryption is possible, and the datasheet does not mention it.
 
Last edited:
Didn't see any mention of config fuses or internal flash. Maybe there's some way to do security without internal storage of a secret key or hash of a public key?
 
I didn't see any mention of flash encryption, firmware authentication, or other code security features. Kinda makes me wonder if they'll be able to sell these microcontrollers to traditional commercial users, or if it's just going to be for the hobby electronics market?

EDIT: as you can imagine... I've been thinking quite a lot these last couple weeks about how Teensy 4 will eventually support these security features while working on the stand-alone bootloader chip release.

How about bootloader firmware which checks the digital signature of the flash upload? Or isn't that secure enough?
 
I think its possible to generate the MCLK as there is 4 state machines in each PIO.

Post #21
I think its really good as now they are coming closer to FPGA tech.
 
The secure feature is mostly used to make it impossible to read back the content of the chip, not the other way around.
 
How about bootloader firmware which checks the digital signature of the flash upload?

To check a digital signature, you need the public key associated with the private key which was used to generate the signature. The public key isn't secret. You can put a copy of it into the firmware image. The bootloader can check that it matches. But without some way to know if that particular key is authorized, anyone can just self-sign any code and have it pass the test.

NXP's secure boot stores a SHA256 hash of the public key inside the chip, in one-time-programmable fuse memory. So the process checks the firmware against it's own key, but also checks that the supplied key matches the hash stored internally.

That's only for authentication. For encryption that provides confidentiality, while the key management isn't identical, it does ultimately depend upon a secret key stored inside the chip's non-volatile memory.

Maybe there's some way to do all this without internal storage of keys, but that's beyond my knowledge and imagination.
 
To do a conclusion about the size

by the real picture on their front page

it's actually 0.7inch instead of 0.6inch(standard for most of wide DIL)

So it's actually symmetrical.
 
I2S without masterclock limits the number of DACs you can connect to those that don't need MCLK. Also since this PIO seems to be implementing I2S in software
the question arises about clock jitter and availability (or lack of) of FIFO buffer that is typically offered by fixed function I2S hardware to prevent buffer underruns.
A much cheaper STM32F401 (black pill for $2.50) offers two hardware full-duplex I2S with MCLK and FIFO buffers each and audio class PLL clock accuracy.
 
It looks like the RP2040 PIO have FIFO
RP2040_PIO_BLOCK.png

Loose taken from the datasheet:

The four state machines execute from a shared instruction memory.
System software loads programs into this memory,
configures the state machines and IO mapping, and then sets the state machines running.
PIO programs come from
various sources: assembled directly by the user, drawn from the PIO library,
or generated programmatically by user
software.


PIO state machines execute short, binary programs.
Programs for common interfaces, such as UART, SPI, or I2C, are available in the PIO library, so in many cases, it is not
necessary to write PIO programs. However, the PIO is much more flexible when programmed directly, supporting a wide
variety of interfaces which may not have been foreseen by its designers.

Though the PIO only has a total of nine instructions, it would be difficult to edit PIO program binaries by hand. PIO
assembly is a textual format, describing a PIO program, where each command corresponds to one instruction in the
output binary.

The PIO Assembler parses a PIO source file and outputs the assembled version ready for inclusion in an RP2040
application


So by the looks of it there is high customization
 
can or must?

I'm not sure where this GPIO comes from.. its noted as a feature of the PIO statemachine. No mention of GPIO.
I don't know if that counts as software, and it says nothing about jitter. But I know it's not cool ;)


@Paul, yes the flash uses a cache.

There is a interpolation-thing in Hardware, too.
 
General Purpose Input/Output (GPIO)
is used by the
Programmable I/O (PIO)

It don't mention any FIFO for the I2S module @ STM32F401
and it also send data in 16bit frames

Reference manual:
https://www.st.com/resource/en/refe...ed-armbased-32bit-mcus-stmicroelectronics.pdf

STM32F401xD STM32F401xE datasheet:
https://www.st.com/resource/en/datasheet/stm32f401re.pdf

the RP2040 in the other hand
have 4 word (32bit) FIFO which can be written to using DMA
https://hackspace.raspberrypi.org/articles/what-is-programmable-i-o-on-raspberry-pi-pico

to see if there is any jitter it's easier to test it.
 
Like everyone else I have been wasting the morning grubbing though the Pico docs and ordering (and pre-ordering) various bits and pieces.

Early impressions: Dual M0s - meh. Real Documentation! It's kind of a "Green Pill" but with the certainty of a consistent implementation - the blue and black pills will go away as soon as they introduce an M3 or M4 version. Real Debugabillity (please, please, please, Paul...). Real Docs! Dual processor - Wifi coming soon? Espressif threat? Castellations for SM, nice. Real Docs!

Did I mention Real Documentation?
 
I don't understand what this means? Didn't see anything like that in the datasheet.

The SWD does have a feature to allow more than 1 (perhaps up to 7) of these chips to be accessed on the same SWD signals.

As noted it is 'code' and indicated by FrankB - from raspberrypi.org/documentation/pico/getting-started/
Debugging using another Raspberry Pi Pico

It is possible to use one Raspberry Pi Pico to debug another Pico. This is possible via picoprobe, an application that allows a Pico to act as a USB → SWD and UART converter. This makes it easy to use a Pico on non-Raspberry Pi platforms such as Windows, Mac, and Linux computers where you don’t have GPIOs to connect directly to your Pico. Full instructions on how to use Picoprobe to do this are available in our 'getting started' documentation.
 
Though given the price, I wonder if we are going to have the same problem that we have with the Pi Zero? Namely, you can only order them in limited quantities, and the sellers had times when they had no stock to sell.

My local MicroCenter does have a bunch of Pi Zero W's for sale now, but their pricing is $9.99 for quantity one, $12.99 for quantities 2-10, and $14.99 for 11 or more. They still have a bunch of Pi Zero's without the W (i.e. no network) for $5 unit 1 price ($10/pi for multiples).

When it was announced, I wondered if the original Pi Zero (at $5) was actually actually costing the Pi Foundation more to build than it cost (or at least was break even). I believe it was created to further the Raspberry Pi foundation educational goals to reduce the cost of entry for hackers. This is a noble goal, but it can have issues if it is successful, and people outside of the niche want to use it. I believe this happened with the bitcoiners that wanted to buy bunches of them. However, at that price point, few of the commercial sellers (Newark/Element 14, etc.) could carry it, since there was no margin. The hobby companies (Adafruit, Sparkfun, Pi Supply, ModMyPi, etc.) would sell it in hopes that you buy accessories that have greater profit margins, but they often had limits like 1/customer. That is great for the hacker alone in his/her bedroom, but not as great for people wanting to use it in bigger projects.

It uses micro Python instead of Circuit Python. I wonder if micro Python will become as fleshed out as CP has become in the Adafruit world.

So it will be interesting to see if it succeeds.
 
SFE will sell you 100 at $4/each
Though given the price, I wonder if we are going to have the same problem that we have with the Pi Zero? Namely, you can only order them in limited quantities, and the sellers had times when they had no stock to sell.

My local MicroCenter does have a bunch of Pi Zero W's for sale now, but their pricing is $9.99 for quantity one, $12.99 for quantities 2-10, and $14.99 for 11 or more. They still have a bunch of Pi Zero's without the W (i.e. no network) for $5 unit 1 price ($10/pi for multiples).

When it was announced, I wondered if the original Pi Zero (at $5) was actually actually costing the Pi Foundation more to build than it cost (or at least was break even). I believe it was created to further the Raspberry Pi foundation educational goals to reduce the cost of entry for hackers. This is a noble goal, but it can have issues if it is successful, and people outside of the niche want to use it. I believe this happened with the bitcoiners that wanted to buy bunches of them. However, at that price point, few of the commercial sellers (Newark/Element 14, etc.) could carry it, since there was no margin. The hobby companies (Adafruit, Sparkfun, Pi Supply, ModMyPi, etc.) would sell it in hopes that you buy accessories that have greater profit margins, but they often had limits like 1/customer. That is great for the hacker alone in his/her bedroom, but not as great for people wanting to use it in bigger projects.

It uses micro Python instead of Circuit Python. I wonder if micro Python will become as fleshed out as CP has become in the Adafruit world.

So it will be interesting to see if it succeeds.
 
It don't mention any FIFO for the I2S module @ STM32F401

It does. Page 166 and page 180 of STM32F401 Reference manual: "Four-word depth 32 first-in, first-out memory buffers (FIFOs) per stream."
FIFO in STM32F401 is universal that handles not only I2S but ALL streams. Stream can be i2C, serial, SPI, I2S, memory, whatever.
 
Last edited:
Back
Top