Getting Started with Raspberry Pi Pico using MicroPython and C

Raspberry Pi Pico Getting Started Guide

Raspberry Pi Pico board was just launched last Thursday, but thanks to Cytron I received a sample a few hours after the announcement, and I’ve now had time to play with the board using MicroPython and C programming language.

I went to the official documentation to get started, but I had to look around to achieve what I wanted to do, namely blinking some LEDs, so I’ll document my experience with my own getting started guide for Raspberry Pi Pico using a computer running Ubuntu 20.04 operating system. The instructions will be similar for Windows and Mac OS.

Preparing the hardware

In theory, we could just get started with the board alone, but since I got some headers with my board, I also took the opportunity to try out Pine64 Pinecil soldering iron powered by MINIX NEO P2 USB-C power supply.

Pinecil Soldering Iron RPi Pico

The soldering iron worked great for about one minute, and then I started to have problems with soldering… Looking a the screen I could see Zzzz and the temperature dropped. I did not move the soldering enough so it failed to detect any activity and entered into sleep. Changing the motion sensitivity or sleep timeout can easily fix this issue, and I could complete the task at hand.

Raspberry Pi Pico Headers Soldered

It would be a shame not to use those headers so I inserted Raspberry Pi Pico into a breadboard and added an LED with the accompanying circuitry.

Raspberry Pi Pico Breadboard

5V is connected to VBUS (pin 40), GND to pin 38, and I decide to use the GPIO the closest to the LED namely GP15 (pin 20). The GPIO markings on Raspberry Pi Pico are only shown on the bottom of the board, so when the board is connected to a breadboard a pinout diagram helps.

Raspberry Pi Pico Pinout DiagramThe hardware setup is now complete, and all I need is a Micro USB to USB-A cable to connect the board to my laptop.

MicroPython on Raspberry Pi Pico

We should first copy MicroPython firmware to the board. To do so we can download the latest firmware from the getting started guide (pico_micropython_20210121.uf2 at the time of the review), then press the BOOTSEL key on the board while connecting to a computer with a USB port, and release the key after connection. I did so, but nothing happened. That’s because I used my bicycle headlight’s USB cable that lacks the data line… So I went to select a proper micro USB to USB-Type-A cable, and Raspberry Pi Pico was properly recognized on my laptop:


.. and mounted as RPI-RP2 mass storage device.

Raspberry Pi Pico RPI-RP2 mass storageAfter copying pico_micropython_20210121.uf2 file to the drive, it automatically unmounts and the Pico board reboots as a serial device:


At this point, the getting started guide on Raspberry Pi website is not very useful, and we have to switch the Python SDK documentation (PDF).

The documentation uses minicom for the serial console, but now I prefer Bootterm since it’s easier to use. In any case, if you program the board in Linux, make sure your current user is added to the dialout group, or you’ll need to run all programs as root:


Bootterm properly detected ttyACM0 port, so I just ran “bt” to access MicroPython REPL interface, and type some MicroPython commands.


I could turn on the onboard LED (GP25), but when I did the same for the LED on the breadboard (GP15), it did not work. I rechecked my circuit, and used a multimeter to check the voltage levels, and found out GP25 was still pulled low. A web search showed GP15 was disabled in CircuitPython because it would interfere with the USB interface.

This is on purpose, GP15 should not be used, it is used by the internal USB peripheral

Ah… I suppose it’s the same for MicroPython, so I switch to the neighboring pin (GP14, pin 19):


Raspberry Pi Pico Blink LED

and sure enough, it worked! If you want to learn more about the MicroPyton API, press Ctrl+B and type help():


We can exit bootterm with “Ctrl+]” followed by “q”. But what if we want to save our Python program on the board and run it automatically? Unless, I missed there’s nothing about that in the Python SDK documentation, so I had to jump to a third guide to find out the best way is to use Thonny.

Ubuntu 20.04 does have Thonny 3.2.7 in its repository, which we can install with sudo apt install thonny, but it does not support Raspberry Pi Pico, so instead I installed the latest version of the program (v3.3.3) with pip3:


I then went to Run->Select interpreter… to select “MicroPython (Raspberry Pi Pico)“.

Thonny Raspberry Pi Pico

From the user interface, I could type some code to turn off the onboard LED:

Thonny Raspberry Pi Pico Sample

In order to alternatively blink the onboard LED and breadboard LED with a one-second interval, I copied and modified some code from the Python SDK documentation:


I save the file as blink.py on my PC, and it ran fine. But if you’d like to run the code without a PC, it’s possible to save it to Raspberry Pi Pico. Click on File->Save copy, then on “Raspberry Pi Pico” button,

MicroPython Save to Computer or Raspberry Pi Pico

and save the program as main.py. You can now run the program automatically by connecting your board to any USB power source.

C/C++ on Raspberry Pi Pico

Let’s try the “C/C++ SDK” that is basically all C language, except some tools written in C++. We can go back to the official Getting Started documentation, where we are asked to copy blink.uf2 to Raspberry Pi Pico while in boot mode, and it does blink the onboard LED. It works, and it’s super easy, as the binary is pre-built, but what we really want to do is modify the source code, and build our own binary to blink both the internal and external LED.

So we’ll have to install the C/C++ SDK, dependencies, and samples as follows:


We can have a look at the blink example in pico-examples/blink/blink.c:


Good. Before modifying it, we should try to build it by first export the SDK path, and configuring the build:


We can now enter the blink directory (a new one, generated by cmake), and run make:


We now have a bunch of files:


The most important ones are blink.uf2 that we can copy to Raspberry Pi Pico to run the program, and blink.elf that can be used by the debugger (OpenOCD + GDB), but that is out of the scope of this getting started guide.

Now that we know how to compile a C program for the Pico board, let’s modify the blink.c example to alternatively turn on and off the onboard LED and external LED connected to pin 14:


and build the program again:


Then enter boot mode and copy blink.uf2 to the board, and success!

Raspberry Pi Pico LED Blink

We can achieve the same results with either a C or Python program. We’ll have a look at RP2040’s PIO (Programmable IO) interface in an upcoming post, as AFAICT it’s what differentiates Raspberry Pi RP2040 most from other microcontrollers.

I’d like to thank Cytron for sending Raspberry Pi Pico for review. If you are based in ASEAN, you can purchase the board on their store for $4.98, or if you have some time there are offering a $5 carrier board for Raspberry Pi Pico for the same price with the board already soldered that’s expected to ship on February 10th, and available worldwide, not only in ASEAN.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK 5 ITX RK3588 mini-ITX motherboard

45 Replies to “Getting Started with Raspberry Pi Pico using MicroPython and C”

  1. I’m asking myself which technic has employed raspberry foundation to oblige all redactors in the world to make a try of their crappy expensive board…

    1. Easy. You get a recognizable brand, and send free samples. I haven’t gotten that one directly from Raspberry Pi though.

      Plus when Google algorithm sees “Raspberry Pi” it gets all excited and sends plenty of traffic, especially to larger websites.

      1. Sorry I like very much your content and in a way I’m happy to see how this board works, thanks for that but I’m a little disappointed to see it everywhere, even on not right places (here it’s ok, but on ETA Prime it’s strange…).

        But I don’t like prices of raspberry, everybody say that it is cheap but it’s not : the price announced are always not right (or may be they should educate their distributors like their users) and for this kind of chip/boards these are expensive and very rentable for the manufacturer.

        But in dispite of this, like everyone I like these boards and more than that I like what the community has done with these slow boards ?

        1. Creating a hype seems to be an art as well.

          Honestly dont see why there is no existing uC of a reputed manufacturer that rpi could have used… But well that would have been so much 2010…

          1. I explained what I believe to be the rationale for the new MCU in the announcement post:

            But why create a custom MCU? I’m pretty sure they could have found an existing microcontroller that does the job. But in my humble opinion, they did so to avoid having people copy the hardware too easily and use their software. They’ve probably seen what happens with the Arduino clones, and the Raspberry Pi Foundation has made it clear they do NOT allow other Broadcom BCMxxxx boards to run Raspberry Pi software in the past. As we’ve seen with STM32 fakes and clones, it’s still possible to copy the chip, but it’s much more difficult than just making another PCB.

            Another reason is that they can now sell RP2040 microcontroller to makers creating their own projects/products, and this will happen as they provide a document called “Hardware design with the RP2040” to help people design their own boards and products around the microcontroller.

          2. What a shitty company/foundation. People should copy the devices. This is how this industry innovates. Take an existing design and improve it. They probably also learned from other designs. They already make a lot of money. Why do they need to increase the profits? They are not Apple or fucking Google.

          3. It depends what they do with the money. If they fund the Raspberry Pi Foundation to provide free boards and/or sponsor STEM teachers then maybe it’s not too bad.

          4. I don’t think so. If you make money in the questionable way, but use it for the greater good, you still made money in this way. Where do you draw the line then? If they are already willing do to this, where do they draw the line? We have seen this with Google as well. The removed their “don’t be evil” ethical standard. And look at them now. Working with the military, firing people, because they openly discussed their opinion etc. etc. Not actively providing free software is already a big problem. But having your own MCU design to make it harder to copy your hardware. That is a big no no.

          5. 100% agree the this was purposely done to maintain their monopoly.

            And why are Arduino clones bad? The closed Apple model with 300% margins on hardware or the PC model with thousands of choices at many different price points. Which world do you want?

          6. The programmable IO (PIO) feature seems innovative and powerful to me. Apart from the ESP32 ULP coprocessor, are there other microcontrollers with similar features?

          7. The chips used in the beagle boards do. Cypress PSoC. If you want to go really back, Motorola had chips with a real time controller peripherial that seems eerily similar. That would be the 68K’s and some of the Power chips, IIRC. Every CPLD, FPGA, PLA ever.

          8. Lloyd Seaton

            Kendryte K210 has a powerful FPIOA functionality:

            FPIOA allows users to map 255 internal functions to 48 free IOs (pins) on the chip.
            This allows code to connect the internal UARTS, I2C, GPIOs, their clocks, chip/slave selects, and put it out to a hardware pin of your choice.

            • Programmable IO function selection
            • 8 drive strength options for outputs
            • Selectable internal pull-up resistors
            • Selectable internal pull-down resistors
            • Schmitt trigger option for inputs
            • Slew rate control for outputs
            • Selectable internal input level
            • etc…

          9. Yeah, but the difference in price is insane! It has nothing to do with the RP2040 in any way shape or form, ;-(

          10. Yep. I guess they wanted to get some experience with making their own microcontroller. I read some people on fb etc. got excited about this MCU. I don’t understand them. I guess they don’t have an idea about the topic itself and just want to tinker a bit. But a STM32F1 would be also suitable for it. It’s also cheaper. At that price point the rpi foundation could have gone with a nrf52832 like pine64 did. Or why didn’t they go with the BL602 as well? Yes, a bit risky, but making your own MCU is also very risky.

          11. Well, Raspberry products have excellent community support and open source SDKs. I know some people who’ve used ESP8266 and ESP32. The SDK is pretty awful, maintained by some amateurish group of Chinese hackers. Can’t really recommend. If you want Olimex or Linaro style good support, you’d need to buy western MCUs. Same thing when buying DC converters etc. Adafruit and Pololu simply rule. The Chinese clones suck.

          12. Thank you for demonstrating the quality of the Raspberry Pi ‘community’. Toxic, ill informed, and ignorant.

          13. The ESP32 is awesome! Best thing out there. The SDK is not awful at all. The ESP32 is in more consumer products than most others. I think your comments are based not by YOU using it but other noobs that you know

  2. I successfully installed the SDK. Next, I ran the following as stated in your guide:
    export PICO_SDK_PATH=../../pico-sdk
    cmake ..
    What directory should I be in when executing those? I was in the “/home/<username>/pico-examples/blink” folder, and the results were as you listed above.
    However, the existing blink.C and CMakeLists.txt files were moved back a level into “/home/<username>/pico-examples”
    Is this expected? should I move the blink.C and CMakeLists.txt files back into the newly created “/blink” folder? Your guide says at this point to make modifications to the blink.C file, and to build the new changes you go back to the blink folder and run the make command again.
    Is the source C file supposed to be outside of the blink folder?

    I’m just a bit confused on file locations. Otherwise, thank you for taking the time to put this guide together.

    1. in pico-examples/blink. I’ve just added the command to avoid confusion.
      I only have blink.c in pico-examples/blink, no “blink.c” in pico-examples even after building the program. Not sure how your file got moved.

      I ran make in pico-examples/blink/blink each time.

  3. Not that I support anyone using this board, but if you want to see the labels, just solder the headers on the other way around so that the ‘bottom’ is up when plugged in. It’s not like it uses some standard footprint that you need to ensure compatability, so flipping it doesn’t hurt anything. Sure it makes the onboard LED a little harder to see, but meh.

    1. Helpful hint… Instead of flipping the board to see pin lables, just print out the Pico pin map. It’s much more informative than the board labels showing all the alternative pin functions. Bonus…the Boot Select button will be accessible. ?

    1. There’s a menu on Pinecil display. I just used the buttons to enter and navigation the menu, and changed the settings accordingly.

  4. You get a nrf52832 for a similar price. A good old and well supported microcontroller. I don’t understand why anyone should use this MCU. Having a Dual-Core just introduces unnecessary complexity. Even the SDK doesn’t support the Dual-Core at the moment.

      1. That too, true. That doesn’t make sense at all. Maybe Jean-Luc is right with his point and they just introduce complexity to make it harder to copy their hardware. I already shared this with the RIOT OS core contributors. I don’t think I will even take a look this MCU. I don’t support this kind of behaviour. I actually like the fact this industry is going more into the direction of RISC-V etc. That should be the future.

    1. >Having a Dual-Core just introduces unnecessary complexity

      It has to be dual core otherwise it would look even more silly against a < 50 cent GigaDevice chip.

  5. For some reason, cmsis-dap + openocd (from raspberrypi) simply don’t work for me. I always get

    Error: Sequence 3 not supported.

    Error: Sequence 4 not supported.

    Replacing cmsis-dap with ST-Link still do not help. This makes me feel that there is still much more to do for RPi foundation to make this a really hacker friendly board.

  6. I clearly see that you all have a ton more competence and experience than myself, but I’ll tell you what I like with this board.
    My background: Hobby coder for some home projects for fun (building an electric self-driving tractor for a cooperative farm)

    1. Seems easy enough to get started with the support of Thonny and Micro Python.
    2. Enough PINOUTS for most simple DYI projects that I can think of
    3. Low enough power usage so it could run from a small power bank with integrated solar panel.
    4. I guess there will be many people sharing projects and ideas that I can learn from.

    I don’t really care if it’s the best chip etc, as long as it’s easy to get it running for my amateur projects.
    Having said that, I do miss a wifi function on it.

    Do you have some experience with the WiPy 3.0?
    is it worth checking out or would you judge it the crap as well?

    btw. thanks for a great post!

    1. No experience with WiPy 3.0, but I think Pycom has got decent support.

      It’s an ESP32-based platform. You could also probably use any of the available ESP8266/ESP32 boards with Arduino or MicroPython. Many such boards cost the same as Raspberry Pi Pico, and even less after taking into account taxes and shipping.

  7. I guess the main reason for using this other than for education and projects shared by community is that it will use eventually use a fully open source stack with no binary blobs?

    1. MicroPython and the venerable community support would be good arguments. People also want a safe way to connect MCUs and SBCs. Having the same brand helps when choosing the best products for your use case. One of the real world problems is, people used to buy full board RPIs for flashing LEDs when they’d only require a MCU. The problem is, there were tons of MCUs to choose from. It’s just that no brand was officially supported. For example Arduino is famous but most Arduino boards are crappy clones with bad onboard regulators (don’t support up to 15V only 12V), crappy USB interfaces (chinese, need 3rd party unsigned binary drivers for Mac).

Leave a Reply

Your email address will not be published. Required fields are marked *

Boardcon Rockchip and Allwinner SoM and SBC products
Boardcon Rockchip and Allwinner SoM and SBC products