Raspberry Pi Pico

A claimed reason for the pico is that linux (used on their other models) isn't good at real-time I/O. But all they had to do to fix that was change the OS to leave one core completely untouched by linux and so available for bare-metal programming.

No doubt that MCUs and the firmware that runs on them needs to get more serious about reliability and security.

While I find dual core technically interesting, for most applications, 266 Mhz is better than 2x 133 Mhz.
 
266 Mhz is better than 2x 133 Mhz.
+1. and 600MHz T4 is even better :D

Interesting. How large are these buffers, and how many?
There is detailed chart on page 180 of reference manual for F401.
FIFO has four 32-bit words that can act as 16 bytes or 8 half-words (16-bit).
 
And it is 5 times as useful :) Seriously. I am making project that requires LOT of horse power and will probably use 5 or more Teensy 4s. And I need bare metal,
so Linux based things like Raspberry Pi are not an option. And their Pico is so pico-powered. I would love to use 1GHz Teensy, but it is not there yet.
 
You can try to overclock the T4 - with a good cooling, it can do more than 600MHZ - but at some point it will become unstable.
 
Maybe you don't need to overclock it all the time? You can adjust the speed at runtime.
Sorry, wrong thread here.
 
Instead there is only 8 PWM outputs each with the inverse output also available

Each of the 8 PWM slices have two channels for output. They share a divisor so they'll share frequency but have separate compare registers. So, 16 is fair I think.

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.

I've had a couple RP2040s for a month or so and we have preliminary CircuitPython support (merged today!) You can get it here: https://circuitpython.org/board/raspberry_pi_pico/

My takeaway is that it's a very cool chip for doing really real-time communication easily. CircuitPython will be the coordinator of DMA and PIO basically. I agree with Paul that this is most competitive with the SAMD21.
 
https://www.raspberrypi.org/products/raspberry-pi-pico/

I will be switching because I absolutely hate working with the Arduino IDE on the Teensy 3.X and haven't been able to rig up my own ARM command line dev environment. I find it sad that PJRC hasn't been able to rig up a simple dev environment for power C / C++ users that's wholly seperate from the Arduino IDE.

The only thing the Pico lacks is an I2S interface which I need for a digital music player I've been wanting to build, but for all other uses the Pico is a perfect drop in replacement and much cheaper than Teensy.

Visual Source Code doesn't work for you?
 
I would guess that there would be a lot of value in teensy wrapper libraries that are compatible with the pico libraries. Ie, an easy migration path for users who start on the low cost pico and want to upgrade to the much faster Teensy 4.
 
I would guess that there would be a lot of value in teensy wrapper libraries that are compatible with the pico libraries.

Looks like this should be fairly straightforward.

I've learned the hard way (many more times than I'd like to admit) about putting too much work into supporting a new platform or new tech before it really offers genuine value. So I think it's best to wait at least a little while and see how this new chip & board develops before pouring a lot of work into API compatibility. I'm especially thinking of the mid-1990s when Sun Microsystems created enormous hype around Java, and several early books (real paper back then) were published, only to become completely useless months later when they almost completely rewrote the Java APIs between the late betas and JDK 1.0. Not that Raspberry Pi would do anything like that, but still, probably good to consider supporting an API after it's been in use by a substantial user base where incompatible changes become much less likely.
 
Is CircuitPython supporting use of both M0 processors? How is (or will) concurrency and synchronization managed?

Right now we only use one core. MicroPython does allow both through the thread api I think.

I’m thinking about treating the second core more like a pio state machine. Plenty to do before we use the second core.
 
probably good to consider supporting an API after it's been in use by a substantial user base where incompatible changes become much less likely.

+1.
That is my sentiment too. I have seen such hype so many times in the past. Don't waste time on platform that is not bringing anything new.
M0 is old tech, underpowered, lacking crucial features like FPU. The only advantage is somewhat low price ($4), but there are lower priced ($2.50) and more powerful boards (vide F401).
 
That's not the point.

The Raspberry is old tech, too. And the first Raspi was old tech, too.
They sold 40 or 50 million.
 
That's not the point.

"That's" a bit vague? Is the point that starting support ASAP make Teensy the natural alternative?

There is already at least one book published on the PICO - changing those things would be counter productive to a good rollout - unless they made fatal errors.
Code:
We’ve put together a whole book to help you get started with your new Raspberry Pi Pico. From installing MicroPython to getting to grips with PIO, Get Started with MicroPython on Raspberry Pi Pico is your essential guide.

Buy the book

For backward compatibility only 32 bit support and no 64 bit build went on for how long after the release of more capable boards? Still?

Also post #43 has this link to multiple articles on use - and you can download the issue PDF for free :: hackspace.raspberrypi.org/articles/what-is-programmable-i-o-on-raspberry-pi-pico
 
I had a brief look at the c/c++ API. Having a documented API is just wonderful. Looks like they actually use CMAKE as build system? On one hand this is great since it doesn't tie you to any IDE (and I really like this) but I have a hard time to imagine average Arduino users writing cmakelists.txt files to set up their projects. Did anyone see some tools usable for the standard Arduino user?

The Raspberry is old tech, too. And the first Raspi was old tech, too.
They sold 40 or 50 million.

Not to speak of 30EUR ATMEGA_328 boards which still sell like hotcakes :)
 
Last edited:
I had a brief look at the c/c++ API. Having a documented API is just wonderful. Looks like they actually use CMAKE as build system. On one hand is great since it doesn't tie you to any IDE (and I really like this) but I have a hard time to imagine average Arduino users writing cmakelists.txt files to set up their projects. Did anyone see some tools usable for the standard Arduino user?
...

And another FREE PDF MAG :: raspberrypi.org/articles/programming-raspberry-pi-pico-with-python-and-micropython {nothing PICO in this issue - Opps or the blog}
Code:
Raspberry Pi Pico is programmed using either C/C++ or MicroPython and [B]there is IDE support for Visual Studio Code and Eclipse[/B]. Adding a program to Pico is as easy as dragging and dropping a file while Raspberry Pi Pico is in boot mode.

And AdaFruit Blog:: blog.adafruit.com/2020/11/24/new-guide-visual-studio-code-for-the-raspberry-pi-adafruitlearningsystem-adafruit-circuitpython-adafruit-raspberry_pi-microsoft/
Code:
In this guide, you’ll learn how to install and use Microsoft’s Visual Studio Code on the Raspberry Pi. Visual Studio Code, often shortened to VSCode, is an integrated development environment (IDE) that has a bunch of handy features that make writing code more straightforward, such as syntax highlighting, code completion, easier refactoring, and git built-in.
<edit> link was to std pi
 
Last edited:
+1.
That is my sentiment too. I have seen such hype so many times in the past. Don't waste time on platform that is not bringing anything new.
M0 is old tech, underpowered, lacking crucial features like FPU. The only advantage is somewhat low price ($4), but there are lower priced ($2.50) and more powerful boards (vide F401).
And people still use 8-bit 16 MHz Arduino Nanos by the boat load.

If you are just shopping on price then the Black and Blue Pills are what you should be using. Race to the bottom, Bro. However, the Pills are highly inconsistent. You never know what you are going to get. The Blues are the worst with something like 6 different counterfeit STM32F103s having been identified. But beyond the fraudulent processors, there isn't an authority for the design so variations creep in. And they are sold by people that simply don't care or know what they are selling so even if you get a good one from vendor A, you never know if you will get the same good one from him or her the next time. One advantage of the Teensys is they are 100% consistent. Your 101st Teensy 4.1 is exactly the same as your 1st.

This is an advantage that the Raspberry Foundation is also bringing. If it is just you hacking around, the Pills may be fine. But if you are making a product or giving project instructions to some one else, consistency is critical. I don't think it possible to overestimate the value of that for building an infrastructure. Look at what it did for the Arduino. Look at what it did for the Teensy.

Also, I think it is worth noting that the RasPi foundation kept evolving the Pi. I don't think it much of a stretch to expect them to do the same with the Pico.

And for what it's worth, Paul is right to conserve his scarce development resources. Waiting 3-6-9 months likely won't make a huge difference in the outcome. There is always some shiny new toy...
 
I just say, if you don't do it now,

a) others will be faster
b) the longer you wait, the harder will it be - the api will grow.
Then,
c) its a selling point
d) its worth the risk :)
 
Last edited:
I find it disappointing that while there was a pre-existing usable and popular API (Arduino), the RasPi foundation went off and created yet another API. But as I mentioned above, they didn't need yet another board to teach bare metal programming or do real-time I/O either (the Zero or a dual core Zero would work).

History has shown that they sell a lot of boards. So worth thinking about compatibility. Is there an advantage to being the first mover with a compatibility library - maybe.
 
Do you find it disappointing too, that several manufacturers of cars, washing-machines, and tv-sets exist?

No, it's good. Without competition, there is no progress.
Arduino stands still for too long now.
And I'm courious. If it turns out to better usable, I'll change. My Picos will arrive next week.
Lol, maybe I add my own "Teensy Pie", if nobody else does it. Open source, but not MIT.
And probably NOT a wrapper as I can forsee problems.
 
The Raspberry is old tech, too. And the first Raspi was old tech, too.
Cortex M0 was introduced in 2009. So it is 12 year old tech.
CPU in Raspberry PI 1 wasn't 12 years old.

Several manufacturers of cars, washing-machines, and tv-sets exist?
But typical user does not program (majority of) them using APIs (yet), of course except washing machines ;-)

Lots of incompatible APIs is not necessarily developer's dream.
 
Last edited:
Back
Top