I’ve seen a lot of criticism for the new Pico, usually around price versus features/power. An often-preferred solution is the Espressif ESP-32 or one of its variants. It weighs in at approximately the same price as a Pico, but comes with WiFi and bluetooth.
The ESP-32 is certainly impressive, and it’s easy to see why it is popular with makers. I, myself, even figured that these guys would sweep all the competition before them.
Wi-Fi is not the be-all and end-all of everything, though. The ESP-32 development boards are a little too chunky to be convenient. You have to straddle two breadboards to plug them in. I’ve also become somewhat disillusioned with WiFi. WiFi adds additional complexity to a project, and is often unreliable.
My conclusion: are you sure, really sure, that your project needs WiFi?
And I’ll tell you this: I’ve had enough hassle setting up my own network infrastructure – something over which I have complete control – to ever trust some third-party device.
Espressif does offer a nice SDK, with examples, and it’s clear that they’re willing to put effort into providing a pleasant environment for developers.
STM8S chips are worthy of consideration. They never really caught on in the maker market, which I think is a bit of a shame. What I like about them is their simplicity, price and a small form factor that nevertheless offers plenty of pins.
To program them I use my own custom code that I built from the ground up. I use the free sdcc compiler. It’s not without its quirks, but it’s good enough for my purposes.
STM32 chips are also pretty good. A lot more effort is required compared to an STM8S. I use my own custom code for the STM32 too, and it’s a lot more work!
Which brings me to … I hate their own development ecosystem. It’s not exclusive to STM32, not by a long shot. There is plenty of scorn to be poured of vendor-supplied developer systems.
The general problem is that they tend to be over-bloated. They’ll often be based on Eclipse, a big fat hog of an development environment . They often suffer from what I call the “Microsoft Disease”: big bloated, complicated systems that spew files all over the place where it’s a complete mystery knowing what they do or why they’re doing it.
Anecdote time: I was working for the then-Logica back in the late 90’s. Most of my development work was done on Sun Solaris systems. I loved those systems. I went on a project for a few months that was based on MS Visual C++. As my project manager observed: “What do all these files ‘do’?” He was a big fan of Lisp, BTW.
I have somewhat relented on my scorn for all things Microsoft when I saw their latest version of Visual Studio for Linux. It was much lighter weight than I was expecting. I tried it, and it seemed like a reasonable offering to me. I can see why people would be interested in it. VS and Eclipse seem like strong competitors in the IDE space, with VS edging ahead in terms of popularity.
VS is something I’m prepared to investigate again. I’m still a fan of the combo of vim and a makefile, though. Incidentally, I was talking to an old chum of mine who made it really big as an IT officer in the investment industry. He said that vim is the generally-preferred solution. Back in the 90’s when I was doing my PhD one of the research guys there was a huge fan of vi, which I often mocked him for. My preferred “IDE” at the time was notepad. Hmm, OK.
I’m not a fan of ST’s HAL (Hardware Abstraction Layer), either. I ended up thinking that this kind of stuff adds complexity, rather than removing it. I’m not a huge fan of their CubeMX thing, either. Ostensibly it simplifies configuring a chip. In practise, I find it presents a bewildering array of bells, whistles, dials and buttons, a veritable cockpit of instruments set before you. The problem is that it lacks focus for whittling down what I’m trying to achieve.
I’m not much of a fan of mbed, either. This is a kind of SDK/OS developed by ARM. I’ve tried to like it, but ultimately failed to do so. It’s a nice idea, but falls short in accessibility. It’s what I call an “Alphabet Soup”: all the letters are there somewhere, they’ve just been put into a big pot and stirred. There’s no coherency, it’s all a big mish-mash. ARM seems to offer a selection of kits to choose from. Mbed, which I presume to be the one ring to rule them all, seems to have it’s own variants, too, with plenty of examples that is deprecated. As a newcomer to their platform, it is exceedingly off-putting. It smacks of being an immature platform to me, although I’m sure that ARM has put a lot of effort into it and would vigorously deny that assessment.
So, where I’m coming from, I have a bias to rolling my own stuff. There’s advantages and disadvantages to that, of course. The big disadvantage is that it’s heavy-going. I often look at forums and YouTube for guidance, as there is usually some fundamental twist that needs to be used in order to get something to work. There are quite a few advantages, however. The results is vastly simpler, vastly more compact, and vastly easier to understand. It’s usually way quicker to compile, too, because I’m compiling for that project, for that chip.
I don’t think there’s anything wrong with the chips, mind. I never met a MCU (microcontroller) that I didn’t like.
Arduino Unos, what about them? Well, actually, I think it’s easy to see why they are popular. Sure the IDE is somewhat slow and imperfect, but it works. There’s arduino-cli for people like me who think that stuff made out of Java isn’t such a great idea.
The thing about Arduino is that they’ve thought long and hard about what they’re trying to achieve. I can upload code to the MCU easily, the chips are nice and simple, and they’ve tried hard to make a good SDK. There’s a mature ecosystem of third-party software and hardware support surrounding them, too.
The Atmel documentation also looks pretty good, too. You know, people bad-mouth Arduinos as being too simplistic, but there’s nothing to stop an avid explorer peering under the hood and doing things at the register level.
Although the Arduinos are not without their limitations, and they’re certainly not cheap for what they are, I would still recommend them as excellent devices for people wanting to get into microcontrollers.
OK, but what does all this have to do with the Pico, I hear you ask? Well, it’s not just word-padding to meet minimum content-length, you understand. It’s a backdrop from which to assess the Pico as an offering. Chips have to be assessed as a complete package with a number of intangibles – their “pleasantness” – rather than just a count of the number of pins or the speed of the CPU.
The first thing I liked about the Pico is that it uses a standard compiler toolchain. Being an ARM processor certainly helps here. ARM is a first-class citizen of the GNU toolchain. Extremely well-supported. I can install the compiler from my Linux distribution. No need to download some vendors offering, or their bizarre IDE.
Building a project requires cmake, which I don’t particularly like, but is tolerable. Like I said before, I’m a bit old school: give me vim, Makefile and a library. I’m not a fan of building the world from scratch. I need to cut some slack here, though. Pico’s SDK allows you to custom-compile features like exception-handling, so a generic library might not be feasible. It’s all pretty quick to compile though, which mitigates some of the disappointment.
Next I’d say is that the Pi Foundation, like Arduino, seem to have a clear vision as to what it is they’re trying to accomplish.
The documentation for their SDK is excellent. The SDK is top-notch, too. Unlike other processors like STM32s, I’m not tempted to write my own code from scratch. Just use the SDK. It is fairly easy to set up, too.
Their engineers seem to patrol the forums, too, and I’ve had valuable tips from them.
Their dedication to producing the highest quality documentation is admirable, too. I have submitted a couple of suggestions as to how it could be improved, and they’ve duly obliged.
As with all things engineering, you get what you design for. The Pi team has designed for hardware that is relatively easy to understand. They’ve put heavy emphasis on documenting it, too. Because, let’s face it, at the end of the day, it doesn’t matter how sophisticated the hardware is, if it’s use is unfathomable to mere mortals, then it might as well not exist.
So, the Pico is very “maker” friendly. It is bound to attract a huge following. I knew when I read the Pi’s announcement that it was a chip worth investigating. So, yeah, despite the naysayers, it is rapidly growing on me a chip that is very pleasant to work with.
Downsides? I was slightly surprised at the way they chose to program the chip. Arduinos work better in this respect. I’d like to see serial communication work more seamlessly, too. Thinner chips would be nice, too. And definitely, definitely, pin labelling on the top of the chip rather than the underside. I’ll leave it as an exercise for the designers as to how they can make the chips thinner and label the pins on the topside. 😉
I am also curious as to what direction the foundation is going with respect to their new chip. Like the Cyclons, perhaps. They have a plan, but they’re just not telling us. Their chips are being incorporated into other vendors: Adafruit, Arduino, Pimoroni, and undoubtedly others of whom I am unaware.
Could this be an entree into a much bigger idea? Like leading ARM into some kind of consistent infrastructure, kind-of like what made Intel so useful as a system. Or maybe some kind of Pi/Pico hybrid? Like, all the goodness of a system on a chip with all the simplicity of a microcontroller. Hmmm. I wonder where all this is taking us. Maybe nowhere. Maybe Eben Upton has some big masterplan, maybe he doesn’t, and maybe this will take us to places that no-one has even imagined yet.
So, anyway, that’s me, a big fan of the Pico, a chip that tries to be maker-friendly.