Raspberry Pi Pico - Review

Table of contents

RoadTest: Raspberry Pi Pico

Author: dougw

Creation date:

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: Cypress - InfinionTechnologies PSoC 4200M CY8CKIT-043 has a higher price and lower performance - because the Raspberry Pi Pico sets a new standard for performance at its low price point. Other companies such as Adafruit, Sparkfun, SeeedStudio and Arduino use the same MCU in some of their products, but they add extra features to their modules and have correspondingly a higher price. The Espressif ESP32 is also a good competitor in this low cost microcontroller market.

What were the biggest problems encountered?: The only problem for me so far has been obtaining a Raspberry Pi Pico, but this road test supplies one, so it isn't an issue for this road test.

Detailed Review:


Background - Why Am I Doing This Road Test?

I applied for this road test because I think the Raspberry Pi Pico is the most exciting Raspberry Pi so far, and I had not been able to get my hands on one. I have about a dozen Raspberry Pi computer modules spanning a half dozen different models, but they are all computer modules with HDMI and USB. My activities are much more focused on small microcontrollers and the Raspberry Pi Pico brings a new level of performance at a nice low price point to the application space where I spend most of my time. I fully expect to use more Pico's than any other model of Raspberry Pi.

Just because they are smaller than previous Raspberry Pi models, does not mean they aren't powerful. Here is a quick apples-to-oranges comparison with the original IBM PC:

SpecificationIBM PCRaspberry Pi Pico
CPUIntel 8088 (8/16 bit single core)RP2040 (32 bit dual core ARM Cortex M0+)
CPU speed4.77 MHz133 MHz
RAM16 - 64 KB264 KB
Mass Storage5.25 floppy disk drives 160/320 KB2 MB FLASH
Price$1565 (16K RAM)~$4

Some of the things I like most about the Raspberry Pi Pico are its speed, the amount of memory, the form factor, the interface suite and the price.

Even though I tend to use small microcontrollers in my projects, I have been looking for a little more capability for those projects that need it. For example, I would like to start using more Python in my projects but Python really needs more memory than what is in the microcontrollers I have been using. Python may run a bit slower than other languages, so the increased speed of this MCU will be useful to keep performance up. I am hoping the move to python will decrease development time and increase project productivity.
In summary the Raspberry Pi Pico has the potential to both reduce the cost of my projects and reduce the time it takes to complete them. These are the two most important factors in any project (beyond the  technical objectives). (Fortunately, I don't need any help with technical objectives.) This will allow me to tackle more projects, because of the low cost, as well as slightly bigger projects, because of the reduced development time, and these are the main reasons I am so excited about this product.


Pico Features Overview

  • Dual-core Arm Cortex-M0+ @ 133 MHz
    • The RP2040 MCU achieves this high clock rate by using a 40 nm semiconductor process instead of the 90 nm process typical of many ARM Cortex M0 devices.
  • 264 KB of on-chip RAM
    • A large RAM space is very useful when running Python and of course for user program variables and data or graphics
  • Support for up to 16 MB of off-chip Flash memory via dedicated QSPI bus
    • This is large enough to store some graphics and fonts as well as a nice big program
  • DMA controller
    • Between the DMA controller and the dual core architecture, one core of the processor should be able to dedicate most of its time to the user's program
  • Interpolator and integer divider peripherals
  • 30 GPIO pins (4 can be analog inputs)
  • 4 channel ADC, 0.5 MSa/s, 12-bit conversion
  • 12 bit Temperature sensor
  • 2 × UARTs, 2 × SPI controllers, and 2 × I2C controllers
    • Lots of serial ports are important in modern design since so many peripherals require serial ports for data transfer
  • 16 × PWM channels
  • 1 × Micro USB 1.1 controller and PHY, with host and device support
    • USB is a great feature that allows drag-and-drop Python programming, USB mass storage and HID emulation
  • 8 × Programmable I/O (PIO) state machines for custom peripheral support
  • BOOTSEL button
  • User LED
  • 1x Timer with 4x alarms
  • RTC
  • Onboard regulator
  • Flexible power supply 2V – 5V DC via VSYS pin
  • 2x 20-pin 2.54mm pitch header and castellated holes
  • SWD Debug interface

This list of features is well thought out to provide a very flexible platform to address modern microcontroller applications.

Block Diagram of the RP2040 MCU used in the Pi Pico

The Road Test Plan

When I do a road test I like to go beyond simply regurgitating the manufacturer's  datasheet and show real applications of how the product is used. In this case the Raspberry Pi Foundation seems to have excellent documentation to get started with a brand new product, so showing product features and specifications has been easy and I can provide links to anything I don't cover explicitly.

My overall objective with this road test is to develop work flows with the Raspberry Pi Pico that will streamline development projects that incorporate this module.

To do this I will develop some real applications and explore how the features of this product can be leveraged efficiently to reduce the amount of work, make development easier and generally improve development performance.

The Raspberry Pi  Pico can be plugged into a breadboard but it was also clearly designed to be mounted on a PCB, so I want to show that aspect of it.

In order to make a product into an efficient development tool, requires that we build up reusable IP that we can apply to any future project. This takes the form of libraries and functional blocks both for the CAD interfaces and corresponding software.

  • I am going to start doing this by developing a PCB and associated CAD library components to implement some standard interfaces.
  • I will then work out methods of bringing the PCB hardware up to functional status.
  • Then I will explore how to develop firmware and get it running, first with Python, and then with the Arduino IDE.
  • Finally I will attempt to demonstrate a functional application of the hardware and firmware.

One of the neat little twists with the Pico module is its connection interface. It uses both castellated connection points, for surface-mount soldering at its edges, and through-hole vias for standard headers. I want to use both of these connection methods to minimize problems in the development process. In the first stages of powering up a new design, I want to use the through-holes as a temporary socket to test functionality before soldering the Pico to a PCB. It is possible the castellated connections will be better for this than the though-holes, it depends on the diameter of the through-holes. I will design the PCB for both eventualities and show how it works in this blog. Some pins in the "socket" can be removed if that part of the circuit could cause problems, or if those pins only need to be tested later.

The PCB footprint for the Pico will have both though-holes and SMD pads so the Pico can be mounted on headers, sockets, or surface mounted.


Application Features

The PCB I am developing will have the following features:

  • Raspberry Pi Pico with all pins connected and used
  • SD card
  • Resistive touch pad
  • User switches
  • UART connector - can connect to a Bluetooth module
  • SPI connector - can connect to an audio interface module
  • External power connector


In this road test I will focus on trying to get the display working, but I want to use all pins in the design so that the PCB can be used for a wider range of future projects.


Schematic Design

In order to design a schematic that implements the features above, we need to decide which pins on the Pico will perform which functions.

Here is a nice graphic showing the Pico pinout:


I find pinout diagrams like this very handy when choosing pins, but I always make a spreadsheet that has pins for each interface to ensure the connections are consistent with device documentation.

The reusable spreadsheet makes it quick to build variants with different features and interfaces by adding columns for new interfaces and selecting which columns will be included.


Once I have entered the various new components into the CAD library, the connection spreadsheet can rapidly be converted into a schematic - like this:


The VS connector is intended to connect to an audio module that also has a mSD card interface - in a future project, but it can also be used to connect any SPI peripheral module.

The BT connector is intended to connect a Bluetooth module in a future project, but it can also be used to connect any serial port peripheral module.

The display connectors include both an LCD display and another mSD card interface.

This gives the Pico access to 2 mSD cards at the same time, opening up the possibility of it being used to clone mSD cards.


PCB Design

I use Eagle so I can design the layout on one screen while designing the schematic on another screen with forward and backward annotation occurring in real time.

For this design I want to put the display, touch screen and buttons on one side of the card and Pico and everything else on the other side like this:


The power switch will be at one end so it can be accessed regardless of which side of the card is facing the user.

This card is simple enough that there are only a few vias.

Note the notch in the top to provide better access to the mSD card under the display.

After creating the Gerber artwork, I transferred a zip of the files to a PCB manufacturer. (PCBWAY)

Within 40 minutes, they had reviewed the artwork and pronounced it manufacturable.

I then paid them $5 to make 10 PCBs.

They emailed me back the next day indicating the build was complete and the cards had been shipped.

I had paid for a courier, so the cards were delivered 55 hours after uploading the files. (it might have been even faster, except it was over a weekend)

I still cannot believe how quick and low cost this whole process is, but it means making variations on the PCB will be quick, cheap and easy.


From left to right this image shows the touch screen, the QVGA LCD the display side of the PCB, the Pico side of the PCB and the Pi Pico

On top is the section of reel tape the the Pi Pico came in. This type of packaging is well suited for automated assembly, if an application were to transition into production..

Note the SMD pads (and through holes) on the Pico side of the PCB that  allow the Pico to be surface mounted or header mounted.

I had the LCD and touch screen in stock, which is important, because shipping issues these days could easily have made it problematic to obtain these parts in time to complete this review. Complete touch screen LCDs are available of course, but they are still pretty expensive compared to this solution.


Touch Screen

The touch screen is a replacement resistive touch screen for a Nintendo DS. It is big enough to cover the 2.6" LCD but I also put an extra connector for it on the other side in case I want to make a keyboard below the LCD, without using the display. I may do this for this first build since the flex ribbon connector is not long enough to reach the connector if I put the display in a socket.

For the first build I prefer to use a socket.

I wanted to show how a resistive touch screen can be interfaced to a Pico. The technical reason is that the screen can display a significant amount of text and it needs a cost effective way to enter text. The touch screen is just going to be used as a cheap keyboard.

A resistive touch screen has 2 transparent resistive layers. The top layer has conductive contact along the left and right edges. The bottom layer has conductive contacts along the top and bottom edges. This sketch shows how these contacts are driven differently depending on whether the X position is being read or the Y position is being read. One layer is being driven while one layer just reads the voltage at the touch point. The driven layer has voltage gradient across its resistance, similar to a potentiometer. Here the voltage gradient is shown as a color gradient from red (VCC) to black (GND). The entire layer that is not driven simply goes to whatever voltage is at the touch point.


The pins on the Pi Pico can supply enough current that they can drive these resistive sheets directly without external drivers.

One minor addition is needed, because if the input pins are left floating they could read a random position, so a weak pull-down resistor is applied to each pin, making its default input voltage zero. These pull down resistors are so weak, they have minimal effect on the voltage gradient when a touch occurs. The Pico inputs can be configured with internal pull-ups or pull-downs, but they are strong enough to have some influence on the reading, so I am using external pull-down resistors.

This touch screen is not intended for high speed touch typing or gesture control, it is just a way to add a lot of buttons inexpensively and without using a lot of pins.



MicroPython and CircuitPython are both  supported on Pi Pico as are other languages. See the links below for lots of in-depth resources. I tried using Mu, PyCharm and Thonny. All editors worked okay. I had used Mu before and still like it, Thonny is clean entry level editor that I found a bit simpler. The PyCharm link below is a very detailed and accurate step-by-step tutorial on getting PyCharm working properly.

I messed around with MicroPython and CircuitPython  for a week trying to get SPI working without much initial luck. When you are using trial-and-error because the documentation isn't clear and example snippets are incomplete and there are a bunch of unknowns, you end up with a n-dimensional matrix of test cases to run through. Compound that with careless inconsistency in the letter case and mistakes in indentation and everything grinds very slowly forward. Digole SPI is not exactly standard, and I couldn't find an example of driving a Digole using Python SPI, plus the variable types were misleading.

After many, many attempts with partial successes, I corrupted something and the Pico would not show up as a USB drive in CircuitPython. Fortunately Adafruit provides a flash_nuke.uf2 utility that recovers from this condition.

Now it is the weekend and I can make a more concerted effort to understand what is going on ... and finally have the SPI display running from CircuitPython:


The code is not pretty, but at least some of the bones are now understood.

# Raspberry Pi Pico CircuitPython Test
# by Doug Wong

import board
import busio
import time
import digitalio
import microcontroller
from digitalio import DigitalInOut, Direction

print ("Init start")
led = DigitalInOut(board.LED)
led.direction = digitalio.Direction.OUTPUT

MOSI = board.GP11
MISO = board.GP12
SCK = board.GP10
lcdcs = digitalio.DigitalInOut(board.GP14)
lcdcs.direction = digitalio.Direction.OUTPUT
lcdcs.value = True

# set spi pins & configure

while not spi.try_lock():

spi.configure(baudrate=1000000, phase=0, polarity=0)
lcdcs.value = False
spi.write(" Raspberry PI PICO ")
spi.write(".   CircuitPython  .")
lcdcs.value = True

while True:
    led.value = True
    led.value = False


I am attempting to use MicroPython to read the resistive touch screen and display text on the LCD. So far it looks like I have a problem with being able to switch a pin from a digital output to an analog input on the fly. I was trying to save a couple of pins by doing this, but no luck so far - CircuitPython complains that the pin is already in use. I thought I had seen an arduino example where this was done, but will have to explore it later as I want to get something published. I could jumper in a couple of other pins to perform the digital output function, but they are all allocated. It only cost $5 to make a new card, so I will likely do that in the future. I might try to find a faster LCD while I am at it.


Arduino IDE

Fortunately the Arduino IDE already supports the Raspberry Pi Pico, so it uses the standard  Boards Manager and is just like adding any other board into the IDE.

The one little twist is that the category for the Raspberry Pi Pico is "Arduino Mbed OS RP2040 Boards", so look for this in the Boards Manager.

The USB port can be used for other purposes than uploading programs, so a method is needed to tell the Pico to enter its programmable mode. The method is to push the BOOTSEL button on the Pico at the same time as power is applied. Contrary to some other blogs, I had to do this pretty much every time I wanted to load a new C++ program.

This is a simple program to show that the Arduino IDE works fine with Pi Pico. The video of it working is in the demo section.


 * Pi Pico Demo by Doug Wong 2021
 *This demo uses a Raspberry Pi Pico to display text and graphics on a 2.6" Diigole Graphic LCD adapter via SPI
#define _Digole_Serial_SPI_  //To tell compiler compile the special communication only, 
//other interfaces available are:_Digole_Serial_UART_, _Digole_Serial_I2C_ and _Digole_Serial_SPI_
#include <DigoleSerial.h>

DigoleSerialDisp mydisp(11,10,14);  //SPI:Pin 11: data, 10:clock, 14: SS, you can assign 255 to SS, and hard ground SS pin on module
#define SC_W 240  //screen width in pixels
#define SC_H 320  //screen Hight in pixels
#include "e14RT1.h" // element14 Road Test splash screen image 240 x 320 262K colors
#include "Pico3.h"  // Pico module image  240 x 320 262K colors

void setup() {
  delay(8000);  //wait for the Digole display to go through it own boot and demo
  pinMode(LED_BUILTIN, OUTPUT);   //set up to flash the onboard LED
  digitalWrite(LED_BUILTIN, HIGH);  // turn LED on
  mydisp.setBackLight(70);  //set brightness of backlight as 70%
  mydisp.setPrintPos(10, 8, _TEXT_);  //locate text cursor near mid screen
  mydisp.println("element14");        // print some test text
  mydisp.setPrintPos(10, 10, _TEXT_);
  mydisp.println("Road Test");
  mydisp.setPrintPos(6, 12, _TEXT_);
  mydisp.println("Raspberry Pi Pico");
  mydisp.setPrintPos(0, 0, _TEXT_);
  delay(5000);   //wait 5 seconds 
  digitalWrite(LED_BUILTIN, LOW); // turn LED off

void loop() {      // this loop alternates between the roadtest image and the Pico image
  mydisp.setMode('C'); //set graphic Drawing Mode to COPY
  mydisp.drawBitmap262K(0,0,240,320,RTsplash);    //display roadtest image
  delay(5000);     //wait 5 seconds 
  mydisp.drawBitmap262K(0,0,240,320,picopic);   //display Pico image
  delay(5000);     //wait 5 seconds

The "Arduino" C++ demo program is actually very short, because all it does is display some text, flash an LED and display a couple of images.


Digole Development Utility

Digole provides a convenient online browser utility to create display content and simulate results.

Here is a quick video of how it works - at least the parts I used:

It will generate display content in a format that Digole displays can use directly, but I had a bit of trouble with it. For some reason the RGB output was shifted by 2 colors, so the RGB bytes were in GBR order. It may just be my misunderstanding about how to use the output file, but to fix this I had to insert a couple of extra color values at the beginning of each image. (2/3 of a pixel)


Hardware Build

The PCB made the hardware build pretty straightforward. I just soldered on a few connectors and switches and plugged everything together.




The main demonstration video shows the Pi Pico displaying text and graphics on an LCD.


Here is the video demo....

Note the slow rate of transferring an image to the LCD. This is due to a couple of reasons:

  1. The Digole SPI driver throttles the data rate to 1 Mbit/sec so the display can keep up
  2. The Digole image format used here is RGB with 4 ASCII bytes per color, per pixel; so 12 bytes per pixel.
    • 320 x 240 x 12 = 921,600 bytes or 7.4 Mbits, so it is no wonder it takes a few seconds to display an image
    • it doesn't take 7 seconds because an RGB pixel doesn't always need 12 bytes for example a pixel could be 64,8,15, which is only 8 bytes

This slow speed is disappointing, even though I never intended to use it for video - I used SPI mainly because it should be much faster than other serial standards. (The display supports I2C as well as UART)

I am not sure why these pictures didn't turn out as crisp and colorful as the display appears to the eye, but it definitely looks a lot better to the naked eye.



This road test included building the Raspberry Pi Pico into a little system, complete with a QVGA LCD. It may seem a little excessive for a $4 module road test, but the work, the libraries, the PCB and the code will all be re-usable as building blocks or a base platform for other projects and the learning curve will be invaluable in developing new applications.

I like the minimalist Pi Pico module that makes it easy to access all the features of the new MCU without pre-supposing what it will be used for. The small form factor and dual connection interface allows the module to be used in a wide range of applications. The faster speed and larger memory space (than older Cortex M0 modules) provide a lot of flexibility and capability to improve performance and tackle larger applications.

I do have one funny little quibble with the Pi Pico.... Since pico is normally a prefix, I think it just natural to call the module a PicoPi and I would have preferred that to be the name. I think I understand why they didn't use the normal convention, but it  somehow makes the name a bit awkward.

Overall, the Raspberry Pi Pico has a well thought out list of features to provide a very flexible platform, able to address a wide spectrum of modern microcontroller applications.

Hopefully this road test provides some insight into the great potential of this new MCU. I think Raspberry Pi Pico is well positioned in price and performance to enjoy wide popularity, which will translate into the availability of extensive  support for complementary software and hardware resources. Even at launch the product already has support for multiple design environments and the whole eco system is ramping up quickly. I am happy that that my CAD library part for the Pico has been validated and that the custom PCB worked well, and since I ordered a batch of 10 cards, it will serve as a platform for other projects. I have ordered more of Pico modules and expect to use them regularly. That is a pretty concrete endorsement of the potential I see for the Raspberry Pi Pico.



Relevant Links

Raspberry Pi Pico Road Test page


https://hackspace.raspberrypi.org/books/micropython-pico   Getting started with MicroPython on Raspberry Pi Pico - free book

https://thonny.org/ Python

https://www.youtube.com/watch?v=5l3W-brnO7E&ab_channel=NotEnoughTECHNotEnoughTECH MicroPython on Thonny



https://www.youtube.com/watch?v=QywUT3f-_7w&ab_channel=TheMachineShop PyCharm MicroPython installation



https://www.youtube.com/watch?v=5YOEauk9bLo&ab_channel=LearnEmbeddedSystems  How to use the Arduino IDE with Raspberry Pi Pico

https://www.youtube.com/watch?v=9vvobRfFOwk&ab_channel=LearnEmbeddedSystemsLearnEmbeddedSystems  Using 2 cores on the Pico

https://www.digole.com/tools/digole-emu.php Online tool to create content for Digole displays and simulate results

Raspberry Pi Pico - Review by Tony Goodhew

  • The best review ever!! Just 1 major complaint... You made me want one even more...


    Dale W

  • On some boards with CircuitPy such as the D51s it takes a whole megabyte for circuitPy, and if it's a lower end chip without that much flash, it still takes quite a bit.


    Certainly, there will be better, and cheaper chips. The RP2040 and many ARM offerings are very similar in cost to AVR chips which have minimal flash and slow clocks(relative). But there are also tradeoffs. If you're a beginner to electronics, it wouldn't be that hard to make a minimal 328P breadboard circuit.


    How would you make one with ARM? Mostly to the best of my knowledge, all DIP arm chips are EOL. Then, you need to flash the chip which is harder than AVR, etc.


    As technology progresses, it's harder to use the chip as well. Sure, it might be harder for your average hardware guy to learn C over python, but if he was to go on to do PCB design, would a 328P be easier, or a (random chip name in WLSCP)

  • I definitely agree with the points on the Pico, but I must disagree on the part where C isn't a way to program.


    I would never buy a device that didn't have support for C/C++(Usually, arduino IDE or mbed), unless if I specifically want a circuitpython board.


    I typically dislike CircuitPython- normally I just use the recommended text editor to edit. No debugger, if I screw up, that's on me, so I look in my code and spend 15 minutes figuring out what I did.


    I'm not too sure, but there has to be some sort of interpreter for circuitPy as it's realtime interpreting. Possibly made with C/C++.

  • Douglas, that is the top5 for non-microcontroller development.

  • Good points Jan.

    Efficient languages won't likely go away, but there are other factors that affect popularity, such as ease of learning and use.

    As hardware becomes cheaper and faster, factors such as development time and time-to-market often have higher importance than hardware cost. It is pretty common to see software become "bloated" because the hardware got faster and cheaper, so that the new software does not run any faster than the old software. Of course different products have different requirements, so many languages will be needed to address the different needs. And then there is inertia - programmers who have invested a lot of time to become experts in a language are smart to continue using it.

    There is lots of analysis about which languages are most popular overall and some differ in their ranking.

    Here is one for example of the top 5 languages in 2021:

    Rank      Language     Market Share

    1             Python            29.9 %

    2             Java               17.72 %

    3             JavaScript      8.31 %

    4             C#                  6.9 %

    5             C/C++             6.62 %

    Regardless of exactly where it is ranked, Python seems attractive to a large segment of the market. I am not yet a big fan of Python, but if I ever get good enough at it that my productivity improves, I will use it more, and I will play around with it to see if I can get better at it.

  •   wrote:




    Also, you make an excellent point about Python support!

    There's no way I would ever want to use any board requiring assembly language, and going forward I can see C going the same way.




    I don't think so. Because compiled languages cut resources. Cut money.

    Optimised compilers run faster than what most people (except a few heroes) can achieve in assembler.


    But optimised interpreters haven't taken over that realm yet. Java  has been able to achieve similar speed as compiled language in many cases, but not yet resource needs.

    Python (and pre-processed Python) and other interpreted languages also need an order of magnitude more resources.

    For volume products it matters. And yes, other languages may take over the current ones, in speed, clarity, maintainability, resource use.

    But I don't see interpreted languages taking over the space where you try to fit functionality in the cheapest solutions. Because no mere mortal can optimise better than an optimising compiler. Except a few golden brains.


    For products that have high sales margins, low volumes, or hardware with abundant resources, this does not apply. Or for the hobby circuit.

  • Great review, Douglas!

    I have only been half paying attention to the Pi Pico so far, but your review brought it to the forefront for me.


    The price definitely is a great feature, as well as the tiny size - that opens up a lot of possibilities for small projects.

    At $4, and with such a small footprint, it makes sense to use it even in place of the very limiting DigiSpark and ATTiny based boards.


    Also, you make an excellent point about Python support!

    There's no way I would ever want to use any board requiring assembly language, and going forward I can see C going the same way.

    I'm ok with C because I've lived with it my entire career, but I can see how Python could be easier to work with going forward. For my day job I now much prefer Swift over ObjC, also using the visual UI designers rather than hand-coding the UI.

    I'm also wondering, maybe hoping, if the next step might be visual programming with something like Scratch, or tools similar to what gets used with CodeBug or BBC Micro.


    I wonder though, about price and availability going forward. The Raspberry Pi Zero was only $5, but it was so hard to get a hold of for such a long time it felt like it was more of a marketing splash than a real product. Even now I notice resellers limiting them to 1 per order.


    Looks like the biggest competition for the Pi Pico will still be the Espressif modules - The 8266 modules are about the same price, and include WiFi. If you consider shipping, you can probably get an ESP-32 for about the same price+shipping as a Pi Pico (shipping from China is so cheap!).

    Maybe a WiFi version is the next step for the Pi Foundation image




  • I had forgotten to add a feature list for the PCB - so the review has been updated a bit. Also still working on the touch panel, so a further update is probable.

  • This is a really nice feature being able to power of a set of ubiquitous batteries, namely a pair of alkaline AA or AAA. Though at $4, I think I will still try moding one to include a supercap on the input to the DCDC.


    I am still trying to wrap my head around how I would bare metal program a dual core processor, something I have never done! This $4 dev board is certainly opening new horizons to me.

  • The RP2040 Pico certainly does feel like it lacks a lot of features, though that might be to reduce cost, it seems almost as if the Raspberry Pi foundation uses the pico as a general cheap dev board/ EV kit and giving the other people(sparkfun, adafruit, arduino, pimoroni) flexibility to make their own stuff(neopixel, RGB, battery, etc). Pico is quite minimal. I do know a lot of picos have been sold, fairly quickly, as well.