Raspberry PI has released their first MCU platform:
It is a dual core ARM mcu. It also has PIO (programmable IO state machines), which remind me of the PRUs in the AM35xx processors (I’ve never used either, so not sure how similar).
The PIOs seem like a very basic version of the PRUs. PRUs are very powerful, full on 200MHz RISC CPUs, arguably possibly more capable than the main Cortex-M0 cores found in the RP2040.
I don’t understand why the Raspberry Pi Foundation decided they needed their own microcontroller SoC. There’s already plenty of similar capability boards out there for comparable pricing. You can’t run Linux on a Cortex-M0 (at least not easily). And for just $1 more you get a full blown Linux board.
I read this https://www.tomshardware.com/news/raspberry-pi-pico-machine-learning-next-chip#xenforo-comments-3691610 and I see
- pico is quite successful since its launch
- Some ML accelarators are in store ( may be RISCV based MCUs ? remains to be seen)
Interesting – rPI has quite a brand – anything they do seems popular.
This podcast has some interesting insights into this product:
Some notes:
- the main driver for this product was cost.
- initial idea with PIO is to do more with less pins (again, less cost)
- focus on user tooling experience
- MicroPython seems to be getting very popular in MCU world
Some more notes about the RP2040 …
- You can actually get it – Digi-key and Mouser have stock and Mouser lists lead time as 5 weeks.
- Flash memory is off-chip in QSPI memory. They have an XIP cache, but having memory off-chip may affect RT latency in some applications if there are cache misses.
- Their SDK is a Git clone, uses submodules, CMake, and is command-line first – this is the right way to do things rather than having everything locked up in an IDE.
- Linux is the first class development system – Windows and MacOS are listed as the “Other” systems.
- Documentation seems first class.
There is a lot I like about this. Somebody at rPI gets it.
RP2040 shows up as USB mass storage device:
UF2 is a file format suitable for flashing microcontrollers. I’ve encountered this before with the microbit where the MCU shows up as a mass storage device and you simply drop a new firmware image into this “drive” to program new firmware.
We’ll see how PR2040 works …
Setting up the SDK:
[cbrake@ceres rpi]$ git clone -b master https://github.com/raspberrypi/pico-sdk
Cloning into 'pico-sdk'...
remote: Enumerating objects: 5331, done.
remote: Counting objects: 100% (390/390), done.
remote: Compressing objects: 100% (260/260), done.
remote: Total 5331 (delta 131), reused 288 (delta 85), pack-reused 4941
Receiving objects: 100% (5331/5331), 2.62 MiB | 3.57 MiB/s, done.
Resolving deltas: 100% (2600/2600), done.
[cbrake@ceres rpi]$ cd pico-sdk/
[cbrake@ceres pico-sdk]$ git submodule init
Submodule 'lib/cyw43-driver' (https://github.com/georgerobotics/cyw43-driver.git) registered for path 'lib/cyw43-driver'
Submodule 'lib/lwip' (https://github.com/lwip-tcpip/lwip.git) registered for path 'lib/lwip'
Submodule 'tinyusb' (https://github.com/hathach/tinyusb.git) registered for path 'lib/tinyusb'
[cbrake@ceres pico-sdk]$ git submodule update --init
Cloning into '/scratch/rpi/pico-sdk/lib/cyw43-driver'...
Cloning into '/scratch/rpi/pico-sdk/lib/lwip'...
Cloning into '/scratch/rpi/pico-sdk/lib/tinyusb'...
Submodule path 'lib/cyw43-driver': checked out '195dfcc10bb6f379e3dea45147590db2203d3c7b'
Submodule path 'lib/lwip': checked out '239918ccc173cb2c2a62f41a40fd893f57faf1d6'
Submodule path 'lib/tinyusb': checked out '4bfab30c02279a0530e1a56f4a7c539f2d35a293'
[cbrake@ceres pico-sdk]$
Uses LWIP and tinyusb …
contents of .gitmodules:
[submodule "tinyusb"]
path = lib/tinyusb
url = https://github.com/hathach/tinyusb.git
[submodule "lib/cyw43-driver"]
path = lib/cyw43-driver
url = https://github.com/georgerobotics/cyw43-driver.git
[submodule "lib/lwip"]
path = lib/lwip
url = https://github.com/lwip-tcpip/lwip.git
I think tried to build the blink example as described in the getting started guild and got:
[cbrake@ceres build]$ cd blink/
[cbrake@ceres blink]$ make -j4
Scanning dependencies of target bs2_default
[ 0%] Creating directories for 'ELF2UF2Build'
[ 0%] Building ASM object pico-sdk/src/rp2_common/boot_stage2/CMakeFiles/bs2_default.dir/compile_time_choice.S.obj
[ 0%] No download step for 'ELF2UF2Build'
[ 0%] Linking ASM executable bs2_default.elf
arm-none-eabi-gcc: fatal error: cannot read spec file 'nosys.specs': No such file or directory
compilation terminated.
make[2]: *** [pico-sdk/src/rp2_common/boot_stage2/CMakeFiles/bs2_default.dir/build.make:97: pico-sdk/src/rp2_common/boot_stage2/bs2_default.elf] Error 1
make[1]: *** [CMakeFiles/Makefile2:4217: pico-sdk/src/rp2_common/boot_stage2/CMakeFiles/bs2_default.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 0%] No update step for 'ELF2UF2Build'
[ 0%] No patch step for 'ELF2UF2Build'
[ 0%] Performing configure step for 'ELF2UF2Build'
-- The C compiler identification is GNU 12.1.0
-- The CXX compiler identification is GNU 12.1.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /scratch/rpi/pico-examples/build/elf2uf2
[ 0%] Performing build step for 'ELF2UF2Build'
[ 50%] Building CXX object CMakeFiles/elf2uf2.dir/main.cpp.o
[100%] Linking CXX executable elf2uf2
[100%] Built target elf2uf2
[ 0%] No install step for 'ELF2UF2Build'
[ 0%] Completed 'ELF2UF2Build'
[ 0%] Built target ELF2UF2Build
make: *** [Makefile:91: all] Error 2
Then checked if there is any pico stuff in Arch AUR – found:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pico-sdk
Although I had ARM GCC installed already, I then installed the rest of the packages listed in the AUR PKGBUILD:
pacman -S arm-none-eabi-binutils arm-none-eabi-newlib arm-none-eabi-gdb
Yay, blink builds now.
Supposedly, installing firmware is as simple as dropping the UF2 file on the mass storage device:
cp blink.uf2 /run/media/cbrake/RPI-RP2/
But, nothing happened …
This is a very interesting build setup. I like things like git submodules, cmake, etc – this is refreshing compared to the bloated IDEs that most MCU vendors supply – rPI appears to be targeting SW developers instead of HW developers.
Stay tuned for the next exciting adventure with the RP2040 …
Software focus is key difference to other IMO but the fact that sdk did not work out of box is a bit of let down and also the cool flashing technique is still to be tested but so far reading your progress I agree it seems to be set up nicely
CAN support has been implemented in the RP2040 PIO:
This is a great example of how versatile this chip is.
A project implementing a logic analyzer using the RP2040 PIOs:
I learned that the W model wires an output from the WiFi radio to the LED, not a MCU GPIO, so that is why I did not see the LED toggling – all is well 
The PIO ASM code for the CAN implementation on the RP2040:
The thing which most amazes me about the RP2040 right now is that it’s only $1 in any quantity from Digi-Key and they have like 94,000 of them in stock. That’s just amazing!
https://www.digikey.com/en/products/detail/raspberry-pi/SC0908-7/14306009
I’ve been thinking about some hobby projects which might use a microcontroller and although I have a personal disdain for RasPis, for $1 I can get over it pretty quick.
2 Likes
for $5 we have next-gen of Pico which has option to use arm cortex-m33 or risc-v cores.
and optional wifi for another $2
will remain in production till Jan 2040, wow !