New book: Get Started with MicroPython on Raspberry Pi Pico
So, you’ve got a brand new Raspberry Pi Pico and want to know how to get started with this tiny but powerful microcontroller? We’ve got just the book for you.
In Get Started with MicroPython on Raspberry Pi Pico, you’ll learn how to use the beginner-friendly language MicroPython to write programs and connect hardware to make your Raspberry Pi Pico interact with the world around it. Using these skills, you can create your own electro-mechanical projects, whether for fun or to make your life easier.
After taking you on a guided tour of Pico, the books shows you how to get it up and running with a step-by-step illustrated guide to soldering pin headers to the board and installing the MicroPython firmware via a computer.
Next, we take you through the basics of programming in MicroPython, a Python-based programming language developed specifically for microcontrollers such as Pico. From there, we explore the wonderful world of physical computing and connect a variety of electronic components to Pico using a breadboard. Controlling LEDs and reading input from push buttons, you’ll start by creating a pedestrian crossing simulation, before moving on to projects such as a reaction game, burglar alarm, temperature gauge, and data logger.
Raspberry Pi Pico also supports the I2C and SPI protocols for communicating with devices, which we explore by connecting it up to an LCD display. You can even use MicroPython to take advantage of one of Pico’s most powerful features, Programmable I/O (PIO), which we explore by controlling NeoPixel LED strips.
Get your copy today!
You can buy Get Started with MicroPython on Raspberry Pi Pico
now really soon, the moment the second print edition is available, from the Raspberry Pi Press online store. If you don’t need the lovely new book, with its new-book smell, in your hands in real life, you can download a PDF version for free (or a small voluntary contribution).
STOP PRESS: we’ve spotted an error in the first print run of the book, affecting the code examples in Chapters 4 to 7. We’re sorry! Fortunately it’s easy for readers to correct in their own code; see here for everything you need to know.
We’ve corrected this in the PDF version, and we’re producing a corrected second print edition, which will be on sale soon.
What if I already bought a copy?
If you bought the first print edition from the Raspberry Pi Press Store or one of our fantastic Raspberry Pi Approved Resellers, a copy of the second edition will be on its way to you free of charge as soon as it’s available.
Lovely book, Pimoroni delivered mine yesterday. My 8 year old daughter has promptly usurped it so I’m reading the PDF now.
I received my copy today that I was going to give as a present, I was quite happy with it until I just found out about the errors in it. Now I am mildly miffed to say the least.
It’s almost impossible to spot every error in a technical book until a lot of people have tested it, and the Raspberry Pi foundation have published details (and a fix) as soon as the problem was found.
W. H. Heydt
Or any book, actually.
In one of my wife’s books, she made a reference to “big endian vs. little endian” and the copy editor changed it to “big Indian vs. little Indian”. Fortunately my wife caught it in the proofs, corrected it (back) and added a marginal note, “See, J. Swift”. Since the book heavily involved virtual reality (sort of cyberpunk…without the punk), after the fact I pointed out to her the computer architecture argument that goes by the same name.
That sounds intriguing, what’s the title?
W. H. Heydt
“A Point of Honor”
Since it’s out of print, it’s downloadable from her web site… http://www.kithrup.com/~djheydt
Raspberry Pi Press needs to do the right thing and offer a _full refund_ to any customer who bought this book. I mean, it is not a small error at all, not when entire chapters are rendered effectively useless by this mistake. This is akin to a defective product and as such needs a product recall. Not offering a full refund would mean punishing those who choose to support Raspberry Pi Press by buying physical copies and instead reward those who just download the free PDF version.
I bought a copy of this book but now that I know it has errors in it that affect Chapters 4-7 of the code examples, I want to return it for a full refund. I don’t mind if I have to pay a small restocking fee, as long as I get my money back.
Raspberry Pi Staff Ashley Whittaker
We’re looking at how to get people a corrected copy and I’ll post a proper update about how we’ve decided to do this as soon as I can.
I think I’ll keep mine, 1st edition, minor error, could be valuable! ;-)
TBH if you do have the physical book, why not just print out the errata and stick it in the front of the book then go through the example code and put a mark beside the bit that needs to have the “, machine.Pin.PULL_DOWN” fragment inserted? Its not difficult!
I bought the book. Lovely presentation and content. I have paid £80+ pounds, in the past for technical books with masses of errors leading to hours wasted. I have sent corrections back to authors, without any acknowledgement or response, including where newer editions have had the same fundamental errors. These guys are trying to correct any errors and are responding to the correspondence. I paid for the book to support their work. I now have no problem downloading a corrected version and adding errata. I spent 10 years working on Digital VAX/VMS, where errata were sent out by the bucket load and didn’t see any problems with updating the huge number of volumes. Get this in perspective. These guys are trying to get it right and have responded almost immediately, contrast that with most other publishers, who take your money and run.
Another way to fix the error without changing the book is to update MicroPython for Pico so that machine.Pin.PULL_DOWN is the default value for the third argument (pull) of machine.Pin(pin, direction, pull). After all this is the machine module that you decide over. This would have the advantage of less typing.
Apologies if this is not the right place to post this. Firstly, thank you for writing this book! I’m hoping to re-do all the projects in C++ to learn that platform as well.
I’m currently on the traffic lights chapter. I think it would be useful to initialize the LEDs (at least green and amber) and the buzzer before entering the loop. For some reason, it seems that the pins can give a random output voltage unless the output is set. There were a couple of times where red and green were on at the same time before the code went through one cycle of the loop. Either that, or there’s something wrong with my board. I did connect 3V3_EN to the button instead of 3V3 in the previous project by mistake. Not sure if that did something. :( It also helps initialize the buzzer to 0 in case you press STOP while the buzzer is beeping. You can then quickly hit RUN to make it stop (say, is there a way to run a some code whenever STOP is pressed to do clean up such as this? Like when a thread receives a SIGTERM?)
Next, there are times when the shell section in thonny shows the following error:
Unhandled exception in thread started by
Traceback (most recent call last):
File “”, line 19, in button_reader_thread
NameError: name ‘button’ isn’t defined
After a lot of attempts, I think I’ve been able to repeat this deterministically – keep hitting the push button repeatedly when the light switches from green to amber. There’s something between those events that triggers this. I’ve pasted the code here: https://pastebin.com/sFPQWf2m. It’s slightly different because I connected my LEDs in the wrong order and a “software workaround” was faster :-)
Quick clarification: By “events” I mean the switch from amber to red, not from green to amber.
Alright, I think I figured out what’s happening. We have two threads trying to write to the same variable under certain circumstances which can be replicated as explained in my main comment. I remembered my RTOS class from about ten years ago and recalled learning about semaphores and mutexes. With a bit of reading, I saw that _thread has a lock object (Documentation for anyone looking: https://docs.python.org/3/library/_thread.html). Adding a lock to the code helped solve this – at least it looks that way. I’m unable to reproduce the issue now. This is what my code looks like now: https://pastebin.com/hmH3L8Xh
Is this a better solution than that suggested in the errata (which just inserts a delay in the button_reader_thread )?
Surely the delay just reduces the probability of a clash in varaible access, and would not prevent it?
Ashwith Jerome Rego
I’m not sure, I don’t have enough knowledge to answer that. What you’ve said makes sense. If the error is indeed because two threads are trying to write to the same variable then a mechanism like a semaphore, a mutex, or, in this case, a lock, is the only way that I know of to fix it. Having said that, my guess is introducing this would probably detract from what the authors intended to explain in the chapter? Maybe an updated appendix or a part 2 of the book would cover concepts like this?
I have created a repo for my own Micropython scripts. At the moment it only contains 1 script which reads the temperature and humidity from an SHT21/HTU21 sensor. The repository is here:
I welcome new scripts for displays and sensors.
Raspberry Pi Staff Ashley Whittaker
FYI: In case you missed the update at the bottom of the blog – for those of you who bought the first print edition from the Raspberry Pi Press Store or one of our Approved Resellers, a copy of the second edition will be on its way to you free of charge as soon as it’s available.
Disappointed with the Get Started with Micropython on Raspberry Pi Pico, when it comes to the i2c LCD, it does not make it clear that not all i2c LCD’s are the same, and more thank likely you will need to import a 3rd party which so far, I have not found will work with a pi pico on microPython. This chapter needs rewriting explaining that unless you are using the sparkfun LCD, it just will not work. Because of the difficulty finding out this information and length of time it too to find out why it would not work, they have started to lose interest in learning python.
Hi, you can use comon Arduino LCD displays with an I2C backpack. I have created an example here:
There is a link to the type of display I am using:
You can ask me questions via the discussions tab, post a link to the display you have:
The data logging example is misleading as on page 113 of the book it imples the logged values can be read after it has run on battery and then plugged back into the computer. In practice it siply wipes the results and start a new file. To keep the log accessible when plugging back into a PC extra code will be needed to start and stop logging, or else the line to save to file should use file append “a” instead of write “w”:
sensor_temp = machine.ADC(machine.ADC.CORE_TEMP)
conversion_factor = 3.3 / (65535)
file = open(“temps.txt” , “a”)
reading=sensor_temp.read_u16() * conversion_factor
temperature = 27 – (reading – 0.706)/0.001721
file.write(str(temperature) + “\n”)
Nice catch! I found the same error. After a bit or research regarding Python File Handling I arrived at the same solution and used “a” append as the solution. Funny, I even added file.write(“Starting\n”) before the while True loop to see where past logging ends and new logging begins.
*** Can’t compile blink – MISSING machine LIBRARY ***.
Having worked with Arduinos for several years I was looking forward to getting to know the Pico with this book. The early examples which did not involve hardware were simple enough, and that ‘Blink’ code looks pretty straightforward, but my Win10 system doesn’t hold the ‘machine’ library and I get error:..Traceback (most recent call last): File “”, line 1, in ModuleNotFoundError: No module named ‘machine’
I have searched everywhere for the Pico library. How does one obtain it and where to install it?
Any advice gratefully received.
Are the words “file.close()” at the bottom of page 119
just before HEXADECIMAL a typographical error ?