Raspberry Pi PICO – would you bother?

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 32x32 bytearray
buffer = bytearray(b"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00|?\x00\x01\x86@\x80\x01\x01\x80\x80\x01\x11\x88\x80\x01\x05\xa0\x80\x00\x83\xc1\x00\x00C\xe3\x00\x00~\xfc\x00\x00L'\x00\x00\x9c\x11\x00\x00\xbf\xfd\x00\x00\xe1\x87\x00\x01\xc1\x83\x80\x02A\x82@\x02A\x82@\x02\xc1\xc2@\x02\xf6>\xc0\x01\xfc=\x80\x01\x18\x18\x80\x01\x88\x10\x80\x00\x8c!\x00\x00\x87\xf1\x00\x00\x7f\xf6\x00\x008\x1c\x00\x00\x0c \x00\x00\x03\xc0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00")

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 32x32)
    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

67 thoughts on “Raspberry Pi PICO – would you bother?

  1. You missed the biggest difference – ESP has wifi. It can communicate, adding a whole new dimension of possibilities.

    I’m distinctly underwhelmed by the Pico.

    1. Good grief, Gregg – how did I miss that? No WiFi? So the Pico is kind of like an Arduino – but a lot more expensive than the clones we routinely used to use before ESP8266 and ESP32 – if I had any doubts that I was thinking in the right direction – you’ve just clarified that for me. I’ll generally stick with ESPxx for controllers and the Pi4 for central control – that works 🙂 Why Pi4 instead of a cheaper device? I’ve discussed that to death elsewhere in the blog – VERY easy cloning with rpi-clone has saved my bacon many times.

        1. Goodness, have I opened a can of worms or what? Ok, well, I guess we could be generous and forgive missing Bluetooth at that price (or not) – but missing WiFi – erm, no. Though ESP32 comes with WiFi AND BT low energy and classic. If the PICO had jumped the gun and added 5Ghz WiFi, they might have had a tenuous claim to SOME superiority over the ESPxx – but no. That won’t stop vested interests pushing like hell to promote the Pico along with those who perhaps have not fully seen what the ESPxx devices can do – especially with firmware like Tasmota (or if you are into huge strings of serial LEDs, WLED) not to mention earlier attempts at custom firmware including my own…but this could get long, very quickly)… and we have what for the Pico? Not a lot it seems?

    2. Yes, I’d bother with it. It’s fascinating how advanced this little guy is. There is something very elegant about just dropping your code in. And the storage is respectable, not to mention the timely speed of the processors. Hoping time will change your outlook.

      1. I’m more than happy to use my time range to keep learning about esp32 and Tasmota. I wasted lots of time on the original (SLOW) Pi and the Zero and “Zero W” not to mention several clones that ultimately didn’t cut the mustard (several months in all). As I now life in the sun and probably won’t live forever, I have to be a little selective:-)

        1. Couldn’t agree more! I get their about education but, come on! The esp8266 had been out for quite some time before this and they decided to release a mcu with no wifi or BT? Now and the future is IOT. I think someone at rpi really dropped the ball on this one. They could have atheist made two versions. The current stripped down one and one with at least wifi…

  2. It’s exciting on one level to see the Pi folks get into this arena, but I can’t help thinking that the Pi Zero offered a good platform for this — just create and support a real-time OS (piece of cake, right? 😉 ) I’m actually a big fan of the Zero W for IOT projects, but it pretty much means you’ve got to have mains power available.
    It they put out a Pico W with wifi (and BT if possible) at this price point, they’d set the world on fire. Go one step further and provide Tasmota support for the device, and now you’d have something that pretty much everyone would want. But it’s got to be at or near that price point for it to really justify getting them instead of the ESPxx boards.

    1. what could add tasmota to such a thing? Tasmota already supports the 2 cheapest and most used platforms, esp82xx and esp32… what does it have this thing that’s missing in espxx?
      in a way, i’d much prefer a firmware like Kevin Darrah’s one, for his boards… you can easily create sensors and actuators via a well thought web gui… search for his videos on youtube, it seems i cannot add links to comments on blog, today, Pete’s looking on why this happens…

      1. Easier to use a real debugger instead of print statements with the rPi at least.

        Lots more code being executed and therefore more to go wrong though compared to a dedicated micro-controller.

        Good to have options.

        1. In this case, having spent more hours than I care to think about on microcontrollers and SBCs that ultimately went no further than niche products – I’m more than happy to let others beat me to the post on this one – but if any of you DO find an actual, cost-effective real world application that doesn’t require hundreds of learning hours – do let us know in here… meanwhile I just found another use for the venerable ESP8266 – they just keep coming.

          1. I am at a loss as to what veneral (ie pertaining to sexually transmitted diseases) uses you have associated with the ESP8266 so I assume it was meant to be venerable. A flexible device but perhaps that not widely applicable

            1. There’s always someone…. spelling corrected… 🙂

              I do believe from the entries in here that someone, somewhere will find a practical use for the Pico – but will it ever start to approach the usefulness of ESP8266 which is available as a dirt cheap SMT chip, almost as cheaply as a simple board (ESP-12 – I have lots lying around) or at around the same price but IMHO more usefully at ready-to-use board level with regulator, serial connector etc i.e. Wemos D1 or nodeMCU (and others who’s names don’t quickly come to mind, most of which I’ve had at one time) to name but a few, then there are the countless lamps, plug-in-the-wall smart sockets, with-neutral or without-neutral wall switches, blinds controllers and countless other gadgets that use ESP8266 🙂

              And last but not least the new, up and possibly-coming CRICKET board from the UK – and I keep forgetting about the boards that combine actual Arduino (i.e. Atmel) with ESP8266 – something for everyone, really 🙂

              Oh and then there are the ESP8266 boards that come in a clear blue case and accept anything up to 26v or thereabouts… and drive a relay (one version) or MOSFET (another version)…

              I should start a book on ESP8266 variations – but that’s likely already been done many times.

    2. But I think I’m right in saying the Pico is based on their own chip (either my eyesight is going or the chip on mine has nothing more than a raspberry icon) – no way the very versatile Tasmota is going to work on that…. somehow I don’t see them adding in the WiFi at that price – when they upgraded the Pi Zero to Pi Zero W it doubled the price, for a still hopelessly stripped down Pi. I gave up supporting it with “The Script” a long time ago. For IOT end gadgets – there’s a reason for the massive number of products using the ESP8266…

      1. But the script isn’t everything.

        Never used it and always rolled my own, so I’ve had no problems with the Zero W – it works – if you only put on what out need – out on the edge.

        1. It isn’t everything, no script is, but for me and the people who have contributed to it and the many more who use it, The Script is a fairly essential start to an RPi installation. I of course owned and tried Pi Zero W but for me, just not powerful enough to run NR with a load of nodes, MQTT, a web server and DB – things I take for granted will be available. If I’d had a support team I’d have made different versions for different chips – but I don’t. Again if I want something less powerful to do grunt work, I’d be heading down the ESP8266/ESP32 route. Everyone’s requirements are different of course.

        2. I have several Raspberry Pi Zero W in my house, connected with several GPIO sensors using RPIEasy IoT app – they have more than enough processing power (even for a Domoticz+ MQTT server).
          Furthermore the 5V 110mA consumption and its ~35Celsius core temperature with passive cooling makes them perfect for IoT usecases. Of course the SD card is a weak spot.

          Honestly i am also using ESP8266 sensors in some places,i believe that every task has a proper CPU. 🙂

          This new RPI Pico seems a little odd, i can imagine more than 2MB flash for start, but more HW versions will arise soon. Lack of wifi may be replaced by SPI LAN modules, such as a W5500, at least i hope.

      2. I guess my point was that it takes an immense amount of work to develop new silicon; if they can do that, it seems to me that the Pi folks could sink real resources into porting Tasmota over to their new platform (I will admit that I am by no means an expert in this topic, so there may be insurmountable obstacles to doing this that are above my level of knowledge — I dunno). I’m still quite new with IOT technology, but my experiences with Tasmota have been great; once you get the hang of it, you just load it up and you’re off to the races.
        I do get the sense that the “programmable state machine” feature has real power for developing the platform into the future, but again a real understanding of how that works is a bit over my head.

        1. My first thought on this Steve – there are new chips out for real world products and we’re not seeing ports of Tasmota for them so don’t hold your breath – secondly as the Pi people seem hell-bent on this enducational route and as Tasmota is oriented to controlling real-world devices – I don’t see the match there – finally if Tsamota WAS to be ported to the new Pi, there is still the issue that to use Tasmota on a Pi would be a little weird as both the ESP8266 and ESP32 are cheaper in practice.. now if Trump were still in office and he convinced the west to avoid China, all of that could change but he’s not so he won’t 🙂

          If you’rer new to Tasmota on ESP8266 and/or ESP32 there are no shortage of people with experience to call on – I can say that with confidence as I ask dumb questions consatantly – ask Antonio. I’ve also done my bit to share knowledge. A brand new product even if it WAS cost effective – there’s a different matter.

          My second thoughts – rightly or wrongly – am I right in saying that Tasmota has “ONLY” been ported to the closely related ESP8266 and ESP32 (and variations)…

          Now that the subject of boot reliability has been brought up – off on another tangent but we COULD get into a discussion about ESP8266 reliability – there I have a lot of experience ranging from DIY through working with others on a UK government contract using LOTS of them. I have used many, many hundreds of ESP8266 and in the early days I used to get the odd failure. To the last one it was down to not understanding peak current requirements. These days they just work for me. Tasmota has a “feature” allowing reset to defaults after multiple quick power cycles and that can catch people out, but there is an SO (SET OPTION) command to turn that off.

    3. Agree on the Zero W front – I’ve got a whole house wifi system running with these as room controllers. Couldn’t do this with ESP boards. And I’m sure there are lots of other applications where you simply want to replicate some opensource linuxy things to do stuff with. I have open energy monitor s/w running on one for example.

      And there’s no way I’d be replacing my ESP based controllers with an Pi Pico – it’s hamstrung with no wireless comms. And there are plenty of other v low power consumption controllers around if that’s what you need – but who really needs that?

      So for me I’ll continue with Pi’s with wireless on board and ESP controllers.

      Simon

        1. Yup, been watching cricket with interest.

          But on the low pawer thing, I can’t think of an application around our place where I’d need that, there’s always power close by. And we’re not talking kWs of power – it’s really low level.

          Maybe we need houses wired up with 5V or 12V instead of 230V for everything but the mains appliances.

          Simon

            1. Before anyone starts to consider running a 12v power loop bear in mind that it is current draw that determines cable thickness not voltage. At my desk I am drawing over 10A at 240 V to power various low voltage devices. To achieve that at 12V I would need to draw 200A to achieve the same 2.5KW even allowing for losses in the transformers. Even 4mm2 power cable drops 11mv per metre per amp allowing a cable length of less than 1m before the 12 V is unusable. Unless you fancy rewiring the house with 25mm2 cable or running multiple dedicated wires per device from your transformer I would suggest sticking with mains power. POE is an alternative at a “safe” 50V but with relatively low current draw requirements

      1. Simon – you didn’t what the PiZero W units are achieving that could not be done with ESP – so I can’t start an argument 🙂

        Lest anyone has looked in quickly and mistakes me for an anti-Pi person – my main central home hubs use RPi4 – and I would not be without them.

  3. I ordered one, fully aware that I’ll probably be underwhelmed.
    Sure is a bummer not to have WiFi – what were they thinking?
    I’ll check it out, give it a chance – then it’ll probably end up in the unused bin, next to the Zero, the STM32xx, the Mega… in contrast to even the bananas and oranges that have found their niche applications.

    1. It arrived and I played a little… found another “what were they thinking” – why would they put the pin # numbers on the side that you can´t see when plugged into a breadboard??

      1. Not the first time someone’s done that. My nodeMCUs have the ports marked on the top only so when you are actually pushing wires onto the pins you have to turn the board over frequently. My other pet peeve is.. why do they think everyone wants these boards to look like overgrown Arduinos? The pins are marked D1, D2 etc.. which means I have to try to remember which GPIO is D1 etc. You would think ink was expensive.

  4. the rp2040 is a new “open” standard, adopted by many other manufacturer, Arduino itself included: THEIR version of the board include wifi and a bunch of addon sensors… doubt it’s still at 4$, though… look for details on CNX site…

    about pi4, i’d like to see improvements in “alternative” booting methods… in particular, FULL ssd boot COULD still be problematic, many people in home assistant forums are complaining that in some occasion, a normal reboot will NOT bring back your device, so they suggest to have the /boot on normal microsd (used ONLY in the initial boot seconds, so no wearing) and the full system on SSD…

    an other GOOD addon would be the NET boot… so you can have a nas or an other sbc or whatever serving both bootp and pxe (and dhcp…) and have you rpi4 booting with NO storage AT ALL attached… you can have many of them, all booting a different image from the network, 1 fails? Buy a new one and just plug eth+pow, done… oh, if even POE was added: a single cable to do it all… and way easier to backup, all your data is on a remote device, you can automate them to be copied on other network devices or even in some cloud storage…

      1. Morning Tim and Antonio – we’re off on a tangent here guys but my RPi4s boot from USB perfectrly every single time to SSD. If I could only control WHICH USB I’d be even happier. When making a backup/clone I still have to turn the second SSD on and turn it off when done – which means doing that operation remotely is a non-starter.

        Call me slow, but… RonR’s script – link? More info?

        1. ronr’s script: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=196778

          unfortunately for you both, YOUR specific (positive) experience means nothing more that YOUR specific setup works… there are a LOT of people complaining on home assistant forums and elsewhere, where they report that a simple reboot, randomly, will not bring back device until power cycle… ALL the ones that suffered this, solved by just using the sdcard for the boot partition and the ssd for all the other stuff…

        1. Antonio
          Two things:

          1. Power up with SSD, as you can imagine I’ve spoken to LOTS of people who’ve had no issues with rebooting – maybe it’s down to which USB to SSD adaptors? I have 3 different ones – all work.

          2. RPi3 – thanks for the clarification. I remain interested in having the Pi boot from a specific USB so the other can remain live for cloning purposes without fear that after a power cut or deliberate reboot, it may end up coming up at boot by mistake. All of this just bolsters my feeling that Raspberry Pi designers should be focussing on getting the current product right instead of re-inventing the Nano wheel with yet another crippled product with the RPi brand.

          1. Tim – thank you for those resources. I took a look – am I right in saying there is nothing in there about WHICH USB to boot from if booting from USB3 on RPi4? To date I’ve found nothing to show how to do that – and as someone who’s invested a lot of time and effort in my code, not having the simple rpi-clone method is a non-starter. Right now I’m running from one SSD and backing-up/cloning to a second SSD (I do that sometimes several times a week). I have to manually turn them on and off depending on which one I want to boot to. I’m fairly confident that isn’t in those or any other available links but I’d never recover from missing the solution standing in front of me 🙂

            1. No idea about choosing which USB to boot from; never needed to look int othat.
              I backup to a remote machine using ‘duplicity’, and that machine gets backed up with TimeMachine etc.

              1. Hi Tim

                I checked that out here https://codeandunicorns.com/duplicity-scpssh-backup-raspberry-pi/

                Data only? I need to just backup the lot for instant use in case of a failure or messed up install/update.

                As someone who gets into Linux code only as a necessity, Duplicity looks like the kind of reason I chose rpi-clone. No extra installs, no keys – just a one-liner to make an exact duplicate on another SD or SSD with enough size to store whatever part of the SD or SSD etc is used. Fully detailed here. So typically starting eith one working SD or SD (or even USB stick or hard disk) – it’s a one-liner to replicate onto something else. That’s about my level of interest in (unfortunately necessary backups and the reason I use RPi4 rather than Orange Pi or any of the other “Pi” clones, many of which I’ve used and written about in here in the past but all of which demanded setting aside some time to crack how to do backup clones and pretty much none of which would do what rpi-clone does with the same combined power and simplicity.

                I’d say the solution was perfect were it not for this one issue of being unable to determine which USB device the Pi boots from.

                Looking at the RAID SATA hat – all suppliers ouyt of stock except for one German supplier who has doubled the price.

  5. I have bought one of each of the “Pi” devices on their first release. I hope that ultimately early purchases will add to future development costs. I’m British and also like to support British industry. I had ordered the Pico before I realised it had no WiFi or BT. I’m happy with the ‘investment’ in the ‘Pi Foundation’ but don’t see it being of much use at the moment beyond using it to experiment with MicroPython

    1. Hi Tony. I’m from the Northeast of England and I support British industry if it is competitive but not just for the sake of it. Yup, lack of WiFi definitely puts it out of my interest area. Also since Brexit, it is going to be harder to promote any but unique UK products in Europe if customs charges kick in. What I don’t really understand is the consistently lower pricing in the USA when the Pi is British…

      Erm, just in case you are not aware:
      microPython..
      On the ESP8266 – https://docs.micropython.org/en/latest/esp8266/tutorial/intro.html
      On the ESP32 – https://docs.micropython.org/en/latest/esp32/tutorial/intro.html

      I’ve not personally use these as I’m happy spending hours trying to make best use of Tasmota.

  6. Its important to remember that the Raspberry Pi foundation is an educational charity and that we as makers are “accidental” consumers of their products and not their primary audience. I see this product being positioned as a souped-up nano intended for sound and light style embedded installations in the same way that the original arduino project was conceived. Personally I would have no use for a non connected device and do wonder why anyone would use this instead of an esp8266 even if you don’t want wifi. But they have a good track record of knowing their primary audience and so wait to see if this has an educational niche

    1. Thank you Steve – I completely agree that the Pico is positioned as a education extension to the Raspberry Pi ecosystem. Not a commercial product aimed at the likes of ESP32 et al. I consider it an evaluation board more that anything else.

      What I did take note of is the processor chip – the RP2040. The extensive PDF documentation started with the interesting explanation of the name — and leads me to believe this processor is just the start in a line of ARM based chips. Additionally, the “PIO” environment is the most interesting aspect of this new chip – time will tell is this is a positive.

      Bottom line — it’s all good in the long run — but obviously not your “cup of tea” – which is good too!

      Keep up the good work Pete. Always an interesting read.

    2. Hi Steve 🙂

      I do know sadly that they remain focussed on education. Just as two examples of my pet peeves – RPi4 still being unable to select which USB port to boot from (if it could, that would then let us boot from one SSD while having the second SSD available for cloning) and the still awful power supply section of the Pi4 which requires a narrow range of input voltage – surely they can’t be THAT time consuming to fix by those who designed the product.

      It would not surprise me, knowing how broke British schools typically are, that those of us NOT in education make up a significant, if not THE most significant user base. Anyway to the new product: lack of WiFi or Bluetooth makes for an awfully expensive Nano, even a souped up one if by Nano we mean typical AliExpress Nano-compatible devices. Yes, the Pico does score over the ESP8266 on IO pins – but that’s why we have the ESP32 of course and as I mentioned THOSE boards are now also cheaper than the Pico – so I’m not seeing the point. I realise people have to have new things to write about and I could probably gain a few subscribers by pretending to take an interest – but I’d be lying if I said there is any chance of this device grabbing my attention for the reasons I outlined in the blog.

  7. Having seen a large chunk of the YouTube videos heralding the release of the latest, greatest new standard in microcontrollers, I struggled to understand what is so amazing about the RPPico. I googled around and found this blog – all the comments above pretty much perfectly encapsulate my thoughts…..

    No connectivity.
    Beyond das BlinkenLED, I can’t see any real need for the device that isn’t already met by other, more established, MCUs. Forgetting home hobbyists and thinking of education – what pupil is going to get enthused about being able to display the temperature on an LCD without actually being able to actually do something meaningful with that data? The IoT is real and this device ignores it.
    The cynic in me thinks that not including WiFi/Ethernet was a deliberate decision taken in order to protect the revenue stream from the Pi products – why would a school spend £50+ on a Pi, case and PSU to teach Python when they could do the same with a $4(ish) device?
    I could understand, perhaps, how WiFi could be a bit much, but a simple nRF based radio (and accompanying RPi module) would be just as useful – perhaps even more so in some cases.

    Memory.
    “But this new Pico has loads of memory, Arduinos don’t have so much, the Pico must be better”. Python is hungry. The only reason the Pico has so much storage is because it’s needed – it’s not a luxury, it’s a necessity.

    Programmable state machines.
    Are these really needed for education – surely the ability to flash those BlinkenLED strings is something a pupil would more easily achieve on, say, an ESPx? This looks more like RP’s positioning the MCU as an Arduino replacement for hobbyists and perhaps even industry and certainly not for primarily education use.

    Power.
    Who needs that much grunt? I guess this is tied back to storage – a requirement of the Python environment.

    I’m sure it’ll be great for some people, but for the moment I’ll stick with ESPx’s (driving WS2812 LEDs just works) and Teensy’s (Ethernet on the 4.1 is rock solid). That having been said, if I can easily get a RPPico working with a £1 NRF24L01 module, it might be fun to play with…

    1. I’m with you 99% of the way Nicholas – but as someone who wasted MONTHS with the NRF24L01 crippled radios, never again on that final bit. In fact it was the NRF24L01 that single-handedly made me take the plunge and move to WiFi and ESP8266 🙂

      1. I think I have been very lucky with the nRFs – I know people who’ve had all sorts of problems, but the ones I’ve had have just worked – maybe I got one of the good batches and hit on the one right configuration. It probably also helps that we’re in the middle of nowhere with very little RF interference from neighbours!

        1. I have to think back a long way now butI seem to recall my NRF24L01 (I typed that without looking up – so embedded in my head is that name) peeves included lack of ability to read back signal strength…

  8. I’ve used Pi’s and Arduinos especially the ESP32 and earlier 329s. The Pico will be a great interface board talking I2C, SPI and UART to micro-computers and also bit-bang protocols to clever sensors, and not so clever with ADC.
    There is a tradeoff between unit price and support, where I don’t need the support I can go for cheaper components but the community and support for this will help more people actually use a microcontroller.

    This may also have industrial applications which is where Raspberry Trading are making money for the Foundations educational aims. The chip on Adafruit and Arduino boards will be really competitive and really useful, aligning to those large and active ecosystems.
    An open bootrom also means you can programme it to lead other components on connecting. I welcome the diversity and will be looking to connect it to a SIM800 module for cellular standalone applications especially art+tech.

    1. Worth pointing out that ESP8266 and I2c, UART, SPI work GREAT, hindered only by limited I/O pins to do anything else with… ESP32 of course overcomes that last hurdle. Support.. Espressif who make the ESPs are good with support – their blog gets lots of attention. I guess it depends on your needs, I’ve always had more useful answers from Espressif than RPi – when I was developing ESP-GO, I was regularly asking dumb questions constantly and getting decent responses.

      I could see this developing into another TRS-80 versus Apple scenario in time 🙂

      1. “I could see this developing into another TRS-80 versus Apple scenario in time”

        Wow! It’s only us ‘oldies’ that would even know what that meant!! 🙂

        1. I thought of that after I wrote it. I was secretary of the local computer club when war broke out, on the left you had TRS-80, NASCOM and other Z80 people – on the right you had the Apple mob. Split the club into two. I still to this date don’t touch Apple though I did have a brief love affair with iPhone 3.5 and 4, then iPad 1 and 2 when Apple were still innovating 🙂 There you are I’ve started another row. But now I’m trying to get a Tasmota’d Zigbee bridge to control an Ikea lamp so any new war will have to wait 🙂

  9. Got one a few days back and its pretty cool.
    It’s a mistake to discount this by pins and wifi only.
    If you accept it for what it was designed to achieve, the only problem with it is the supply limit of 1 per customer

    Its ideal for the education market and it looks just about powerful enough for a lot of AI edge device applications

  10. Have been playing with RP2040 – Must admit, “Thonny” in Win10 is nice and efficient.
    You just cut and paste the code you want into the IDE, then press save – thats it!

    N.B. You can download some books from here for free
    https://hackspace.raspberrypi.org/books

    From the look of the pictures of the RP2040 book, it’s clearly aimed at kids and thats a good thing. The last section on the PIO is useful though

    Tech is becoming so accessable now

  11. So many kids are going to enjoy learning with this – plugging in this to that and tweaking template programs
    https://shop.pimoroni.com/collections/pico

    One draw for kids could be vintage games in colour with sound output – Like Elite on a BBC micro.
    https://www.youtube.com/watch?v=vusGo64sDFk&t=1s
    …..or maybe Scramble?
    https://www.youtube.com/watch?v=3Gn_RgDVuko

    Is this really about which chip is better? What they all can offer is amazing – We really do live in fun times and all of us have a front seat seeing in this new tech stuff.

  12. Price in the US, you ask? I got mine for $2 at Microcenter. And they asked me how many I wanted. It all depends on what you want to use it for. For my application, it’s perfect. I don’t need WiFi or Bluetooth.

  13. One good thing about the Pico is that it has two PIO controllers with 4 machine states. So you can interface with anything!

  14. I am asking myself why Raspberry Foundation came up with Pico.
    I might have a look if WIFI is included in future Raspberry PI Pico.

    1. https://thepihut.com/products/dip-pi-piot-for-raspberry-pi-pico?mc_cid=b56eaab675&mc_eid=4a0615b74d

      The DiP-Pi PIoT is an advanced Internet of Things (IoT) add-on board for the Raspberry Pi Pico offering a wide range of power input options, onboard LiPo/Li-Ion battery charging, ESP8266 WiFi connectivity, MicroSD card slot, sensor interfaces, a reset button and more!

      It’s everything a Raspberry Pi Pico IoT project could need (and more)! DiP-Pi PIoT – Dual In-line Package Powered IoT!

      There are currently two other versions of the DiP-Pi available in the range – the DiP-Pi Power Master and the DiP-Pi WiFi Master

Leave a Reply

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

Leave the field below empty!

This site uses Akismet to reduce spam. Learn how your comment data is processed.