The “Raspberry Pi PICO” trades on the name “Raspberry Pi” which many of us find to be a cost-effective home -automation hub, thankfully widely supported by lots of third parties even though the Raspberry Pi Foundation is sticking with their “for educational use” mantra. I wrote this when the PICO first came out and at August 29, 2021 I’m still worried about the price but the PICO is certainly fun to play with and I’m learning a lot.

The PICO is NOT a Raspberry Pi – it is a small controller more like an Arduino – i.e. WiFi-less – the price touted on the Raspberry Pi website is $4 – REALLY? I recently received three of them and paid €5.20 DUTY alone on them here in Spain where everyone including the postal service is latching onto the new protectionist racket.

RPi Pico board
RPi Pico

ESP32-C3 Development board
ESP32-C3 Dev

I initially took a look at the three available suppliers in Spain (just as an example). The cheapest was over €5 plus connectors. Meanwhile, an ESP32 board from AliExpress costs far less than that, delivered. (August 2021 – did I imagine it or is Amazon.es actually charging 13 Euros for a single PICO – are they KIDDING?) UK pricing seems better but then given recent general price hikes in the UK (including electricity) I guess a cheap microcontroller is not of much comfort.

The PICO has 2MB Flash, 26 IO pins and these are early days for library support. ESP-32-based boards have 4MB of Flash, a large user base, lots of software already, along with 39 usable pins, 34 of which are GPIO, the rest are inputs. The new ESP32-C3 board with BT5 and WiFi could make the PICO even less attractive once the price and availability stabilises. However, only one way to see how good or otherwise these things are – read on…

I nearly fell for the need to have the latest gadget when the disappointing Raspberry Pi Zero came out but when that turned out to be far less useful than RPi2 and even less powerful than than the many low-cost RPI clones out there, I gave it a miss after actually getting one at the claimed $5 while on holiday in the USA. Ultimately, It ended up as a door-stop. I’m not the only one who gave up on that particular unit.

Back to the PICO. I read the online introduction PDF which contained such exciting stuff as “Blinking a LED in C” and “Saying hello world in C”. I’ve gone a LITTLE further than that below…

Let’s take a closer look: This new device is trading on the name “Raspberry Pi”. It is however a CONTROLLER using a P2040 chip designed by Raspberry Pi. It is not and never will be a stripped down RPi4. So if you get one of these you are starting from scratch with a not-particularly cheap board which MAY increase in popularity and prove useful or MAY sink and regardless, you will pay more than a typical ESP8266 or ESP32-based board by some way.

ESP8266

RPi Pico board from Seeed Studio
PICO boards from SEEED Studios

For an example of a popular controller that is cheap no matter where you live, consider ESP8266-based boards such as the Node-MCU-like boards I reviewed here – indeed for €29.05 (July 2021) INCLUDING EU taxes, get TEN of them – drop in the free and supported Tasmota firmware who’s installation is trivial and within minutes you can be running any of dozens of supported sensors, any of several OLED or LCD displays, updating via OTA (over-the-air), talking to the device by webUI, MQTT or serial (or all three), running a shedload of serial RGB LEDs in real time (high speed RGB sequencing and fading), toggling several relays at once and far more.

So each board is half the cost of the Pico and WAY more powerful though the ESP8266 and ESP32 DO consume more power and hence are GENERALLY not ideal for long-duration battery use.

On my desk I have one of the above ESP8266-based boards running a LED, a RELAY, a 60-LED clock which demands high speed real time processing (I have recently added in an SSD1306 128*32 i2c OLED to that mix), an ultrasonic sensor and a DHT22 sensor all at the same time – all using Tasmota commands – I didn’t write a line of code. When it comes to doing something useful with the above, I’ll drop a few simple commands into Node-Red including the MQTT commands (my choice).

If extra power and IO is that important, for the same €20 you could consider FOUR ESP-32-based boards with almost the same support as the ESP8266 boards and way more powerful I/O.

Tell me what sounds like more fun or “bang for the buck” as our many USA subscribers might say. I’d be happier to see Raspberry Pi Foundation sticking to improving what they already have (as an example, control over which RPi4 USB port to boot from would be a big deal for SSD and SSD backup) but of course that’s not at all a priority for them – it isn’t new and sexy.

August 2021 Update – Seeed Studio sent some RPi PICOs to play with

Ok, I’m open to ideas. In my now fairly defunct ESP-GO (because Tasmota has come so far for ESP8266 and ESP32 use) I added code to talk to an Arduino Nano rip-off to get some extra IO out of the ESP8266, which, when faced with SPI display drivers in particular, rapidly runs out of I/O. SO, I have in front of me a PICO which has REAMS of I/O.

I’m thinking – would it be worthwhile to run I2c on the Tasmota-driven ESP8266 or serial… and talk to the PICO to then make use of all of that I/O?

The PICO of course has no WiFi and hence typically you talk to it via USB. 26 multi-function GPIO pins have to be useful for something? Ok, here it is – 16 PWM pins… that’s 5 of my RGB LED STRIPS…. or maybe offload the ILI9341 onto the PICO and some more I/O ? My thanks to Seeed for the chance to “have a play” as they also sent their “GROVE shield for PICO” – I have the shield and a few PICOs here… come to think about it – I found some pins in my various boxes for the PICO (they don’t come with pins, sadly) that will make life easy for experimenting. Typically an Arduino look-alike or ESP8266 arrives from China with pins.

Photo below minus pins – granted the PICO and Grove shield WORK better when I actually put some pins in – see below video link as I just got a new soldering iron (August 2021).. but this LOOKS neat – and the “chip ID” IS on the top after all! Anyway I’m having a play with the PICO on that SEEED “baseboard” or shield – I also checked with another company but the cost of their baseboard plus postage (they insist on using DHL – WHY?) is beyond reason.

The same company just pointed me to a European distributor and the total cost of the baseboard is €22 – seems to me that some of these guys have lost the pricing plot. Let’s see what pricing on the SEEED unit ends up as over here in Europe (€13 for the PICO + €22 for the shield would be out of the question compared to alternatives).

Ok, well, of course, once I got the PICO soldered and cleaned up with isopropyl alcohol, I had to do SOMETHING with it.

I’m not into using the GUI on my headless RPi boards so I grabbed “Thonny” editor for PC as well as the Python interpreter for the PICO which began flashing its internal LED all by itself – easy – but then, fairly useless too. There’s a very long web page here for those who want to grab the Python interpreter and put it on the PICO, then grab the simple Thonny” editor which has Python built in and can run a program locally on the PC or on the PICO. Essentially once you are running, you need a Python program to be called main.py on the PICO – such a file will run automatically at boot on the PICO. Simple start… yes that light below is flashing – you have to start somewhere… then I did some LED PWM testing and now…

Pi PICO flashing a LED

Firstly here is the PICO running high speed PWM on an external LED, the PWM output as viewed on my Owon TAO3104 tablet scope… I knew that would come in handy some day… of interest the 14-bit TAO3104 is a 100Mhz, 1GSa/S 8″ (800*600) LCD tablet-style scope.

Owon TAO3104 Tablet Scope ckecking out the RPi Pico

Next, I had a play with I2C and an SSD1306 display. The display code was lifted from this project which in turned uses this Micropython library. That’s where I started and then I added some extra code as I went along. As for the display below, that’s an old FriendlyElec (see Sonoff in this blog) Bakebit OLED display which was intended for use with FriendlyElec’s own boards at 5v- but it is of course just a standard SSD1306 display and as you can see, runs just fine at 3v3. It even has the right connector lead. Well, that was easy – but of course once again, nothing here that I’ve not done many times on the less expensive ESP8266 + Tasmota.

To make this permanent, one would name the Python script that is producing this output, main.py and have it run stand-alone. In the video below, I added a couple of alternating LEDs and made use of all four PICO ADCs.

As you can see, right now I’m doing this on my Windows 10 PC via USB (3 but only because the socket was handy) as I learn more about this device – also as I learn more, the display info is increasing to the limit of what you can sensibly get out of one page of 218*64 display – see photo at the end which matches the source code shown below – more so than in the video and this first photo below.

# Display image & text (including 12-bit ADC values)
# on an I2C-driven SEEED ssd1306 OLED display while
# reading the three usable ADCs and the internal temperature sensor
# while alternating a couple of LEDs.
# Developed and expanded from various tutorials including:
# https://electronoobs.com/eng_arduino_tut138.php

from machine import Pin, I2C
from ssd1306 import SSD1306_I2C
import framebuf
import machine
import utime

led1=Pin(20,Pin.OUT)
led2=Pin(21,Pin.OUT)

sensor_temp = machine.ADC(4)
sensor_adc1 = machine.ADC(26)
sensor_adc2 = machine.ADC(27)
sensor_adc3 = machine.ADC(28)
conversion_factor = 3.3 / (65535)

WIDTH = 128 # oled display width
HEIGHT = 64 # oled display height

i2c = I2C(0, scl=Pin(9), sda=Pin(8), freq=200000) # Init I2C using pins GP8 & GP9 (default I2C0 pins)
print(“I2C Address : “+hex(i2c.scan()[0]).upper()) # Display device address
print(“I2C Configuration: “+str(i2c)) # Display I2C config

oled = SSD1306_I2C(WIDTH, HEIGHT, i2c) # Init oled display

# Raspberry Pi logo as 32×32 bytearray
buffer = bytearray(b”x00x00x00x00x00x00x00x00x00x00x00x00x00|[email protected]0Cxe3x00x00~xfcx00x00L’[email protected][email protected]@x02xf6>xc0x01xfc=x80x01x18x18x80x01x88x10x80x00x8c!x00x00x87xf1x00x00x7fxf6x00x008x1cx00x00x0c x00x00x03xc0x00x00x00x00x00x00x00x00x00x00x00x00x00”)

led1.off()
led2.on()

while True:
led1.toggle()
led2.toggle()
temperature_unconverted = sensor_temp.read_u16() * conversion_factor
adc1 = sensor_adc1.read_u16() * conversion_factor
adc2= sensor_adc2.read_u16() * conversion_factor
adc3 = sensor_adc3.read_u16() * conversion_factor
temperature = 27 – (temperature_unconverted – 0.706)/0.001721
# Load the raspberry pi logo into the framebuffer (the image is 32×32)
fb = framebuf.FrameBuffer(buffer, 32, 32, framebuf.MONO_HLSB)
# Clear the oled display.
oled.fill(0)

# Blit the image from the framebuffer to the OLED display
oled.blit(fb, 96, 0)

# Add text and readings
oled.text(“SSD1306:”+hex(i2c.scan()[0]).upper(),1,6)
oled.text(“August 2021”,1,15)
oled.text(“Pico=”,1,24)
oled.text(“Thonny – Windows”,1,33)

# a little micropython formatting for the temp and ADCs
oled.text(“%.1f” % temperature + “c”,50,24)
oled.text(“%.2f” % adc1,1,42)
oled.text(“%.2f” % adc2,40,42)
oled.text(“%.2f” % adc3,80,42)
oled.text(“LED 1 and 2: ” + str(led1.value()) + ” ” + str(led2.value()),1,51)

# Finally update the OLED display so the image & text are displayed
oled.show()
utime.sleep(0.5)

THEN of course, I realised the PICO has FOUR 12-bit ADCs, 3 of which can be used for general purpose ADC on GPIOs 26, 27 and 28 – and the 4th is used as an internal temperature sensor – one would hope this will show a COOL value – actually it IS cool – it is around 22c at desk height in my office and that is what the sensor is reading. No way I’d get that out of an ESP8266 :-). And why am I using 0.5 seconds between iterations at the end of the above source code? Because any faster is painful to the eye – but I tried (for no particular reason) 0.01 seconds and the updates appeared to keep up with that – so no shortage of power there. Not sure about storage yet. I wonder how much Python code + libraries you can squeeze into 2MB.

Next: My immediate reaction after playing with Python for a while – and the above display…. was to look to see if it is possible to use alternative environments for the PICO. Certainly on the surface of it – yes says this Instructables project. Ah, well, not so fast. I went to the arduino site and grabbed the board setup for the PICO then selected the PICO itself.

I then went to the Adafruit library for the SSD1306 – which says the display is on port 3D – wrong – it is on 3C so says the project I started with and so says the SSD1306 board.

Trivial to change, I know… but then the Adafruit library assumes I2C – which makes me wonder why they have a RESET GPIO – I’ve never used a reset line with an I2C board. Anyway I fixed all of that and after waiting minutes for a simple SSD1306 demo to compile, nothing. I do wish people would not claim that things are straight-forward when in fact they are not. For now I’m back to playing with Thonny and the Python code – thankfully swapping back was merely a case of plugging in the PICO with the BOOT SEL button pressed momentarily – just as I did when initially setting up Thonny and the PICO on the PC.

Next, I felt the need to try out the microPython library for the ILI9341 on PICO. No shortage of I/O so I figured I may as well use my favourite display board. And sure enough – this demo (apart from one missing variable called OFFSET_RE (which I took a chance and defined as 0) works (after loading into the PICO the files glcdfont.py and ili934xnew.py) a TREAT. I’ve even left my original SSD1306 display in place (though clearly not running.. .I see no reason why I could not run both at once with lots of GPIO to spare – except for speed).

Now, no-one is suggesting the Mandelbrot set demo was SPIFFY FAST…. but it WORKED. In that library is some kind of code to modify fonts – so I ran the demo for the M5STACK, making tiny (and now, to me, obvious) mods for the PICO – this library won’t win any awards for speed. That text, flat out took three seconds including a clear screen which took over 0.5 seconds in all – but again – it works… I had to load into the PICO the three extra font sets from the display library – took seconds 🙂

PICO and ILI9341 displaying fonts

Here’s the code for my modded text… warts and all

from machine import Pin, SPI, ADC
from ili934xnew import ILI9341, color565
import tt14
import glcdfont
import tt14
import tt24
import tt32

fonts = [glcdfont,tt14,tt24,tt32]

WIDTH=320
HEIGHT=240
ROTATION=1

#TFT pins are wired accordingly
TFT_CLK_PIN = const(10)
TFT_MOSI_PIN = const(11)
TFT_MISO_PIN = const(12)
TFT_CS_PIN = const(13)
TFT_RST_PIN = const(14)
TFT_DC_PIN = const(15)

def init_tft():
spi = SPI(1,baudrate=40000000,miso=Pin(TFT_MISO_PIN),mosi=Pin(TFT_MOSI_PIN),sck=Pin(TFT_CLK_PIN))
display = ILI9341(spi,cs=Pin(TFT_CS_PIN),dc=Pin(TFT_DC_PIN),rst=Pin(TFT_RST_PIN),w=WIDTH,h=HEIGHT,r=ROTATION)
display.erase()
return display

BLACK = color565(0,0,0)
WHITE = color565(255,255,255)
RED = color565(255,0,0)
GREEN = color565(0,255,0)
BLUE = color565(0,255,0)
YELLOW = color565(255,255,0)
CYAN = color565(0,255,255)
MAGENTA = color565(255,9,255)
colors = (WHITE,YELLOW,RED,GREEN,BLUE,CYAN,BLACK,MAGENTA)

display = init_tft();

text=”Now is the time for all good men to come to the aid of the party.”

display.erase()
display.set_color(GREEN,BLACK)
display.set_pos(0,0)
for ff in fonts:
if ff==tt24:
display.set_color(RED,BLACK)
if ff==tt14:
display.set_color(YELLOW,BLACK)
if ff==tt32:
display.set_color(MAGENTA,BLACK)
display.set_font(ff)
display.print(text)

Facebooktwitterpinterestlinkedin