Mmm, Pi — Homer Simpson
It all started with a Pi2 (Raspberry Pi 2). They were so cheap that I just had to buy one. I never intended to experiment with electronics on a Pi2 – in fact I never did – I saw it more of a Linux server. I used it as an email server, web server and as a development platform. When I was bored at work I used to log into it remotely via ssh and do some programming work.
Python was painfully slow. Go was better, but was quite laggy. When I pointed this out to Go advocates, I was treated with scorn. Actually, I found Gophers to be like Progressivists: full of contradictions, and always espousing the opposite view to the one I was presenting. “Go is a systems programming language”, “Of course Go is slow, it’s not a system programming language,” and so on. With the benefit of hindsight, we all now know that Go never was, nor never shall be, a systems programming language. Its garbage collection ensures that it won’t be.
Then I got a Pi3 because the Pi2 was really slow. It was still cheap, and I could do lots of programming stuff with it.
I still use the Pi2, where it is performing stalwart work as a git bare master, NAS server, and internal mirror of my github website. People might balk at the idea of using it for any of these purposes, but hey, it works for me. It connects to my network headless using a Wifi dongle. I try not to interfere with it too much, as I want it to work, I don’t want it going down. So don’t bash the little Pi2, it still has its uses.
I had the Pi3 for a long time before I tried my first bit of electronics via a Cam Edukit. I wouldn’t say it got me “hooked” onto electronics at the outset, it was more of a gradual descent into the world of electronics and microcontrollers.
I do not have a Pi4. I put an indefinite moritorium on buying new computers. My main desktop is a 2010 Dell, I have an ASUS Vivo as a test machine (originally purchased as a server), a Pi3, and Pi2. I figured that ought to be enough for anyone, despite the increasing age of the systems.
Eventually, I decided to play with MCUs. I went for the obvious choice: an Arduino Uno. In fact, I bought the Elegoo Basic Starter Kit. It contains a Uno clone, plus LEDs, resistors, breadboard, switches and other goodies for you to play with. All for the price of an official Uno. I heartily recommend such a kit for anyone looking to get into the world of MCUs. An Uno by itself is of little use. You need other gadgets to control: hence its name: microcontroller.
I personally prefer the Nanos to the Unos. The Nanos plug straight into a breadboard rather than forcing you to have wires trailing from the MCU to the breadboard. The Nano is a no-brainer in that respect.
The AVR micros are comparatively expensive, mind. It is possible to get vastly more powerful MCUs much cheaper than Unos. Arduinos pick up a lot of flak for this and their IDE. True, maybe, but I will say this: there is no better way to begin to explore the world of MCUs than through Arduino.
I have heard some commentators say that it really doesn’t matter which MCU you choose initially. My advice would be more definitive: choose an Arduino! More specifically: an Elegoo kit.
Arduinos are much more beginner-friendly than any other MCU might care to investigate. This is important! As is community support. I usually downplay the importance of support, but for things like Raspberry Pis and microcontrollers it is a significant bonus.
I also want to present counter-arguments to criticisms of Arduino’s IDE, and how it encourages the “perpetual beginner.” Although the Arduino programming environment does present a pleasant layer of abstraction over the hardware, is that really any of a “worse” interface that you get with more “professional” tools? I mean that you don’t see what goes on “under the hood” with the so-called pro tools any more than with the Arduino IDE.
Furthermore, it you really do want to peek under the hood, there’s nothing really stopping you with the Arduino. In fact, I argue that the Unos are a great learning resource if you want to take a deep dive into the workings of MCUs. This is for two reasons:
- Unos have a comparatively simple architecture, so they are a great way of learning the basics of how MCUs work. The datasheet even has some example C code.
- Community support, again. You’ll find more tutorials and Youtube videos explaining how to do things than with other MCUs.
Although the Arduino IDE might be a bit clunky for my, and many other people’s tastes, I find it to be less finnicky than the offerings by other vendors.
I’m old-school. I think that a “development environment” should consist of a set of headers, a library, vim, and a Makefile. There’s a project called avr-libc that seems in-line with this desire. It is available for Debian, and is likely available for All Good Distros. If not, then you can download it and compile it yourself. I haven’t investigated the library in detail yet, but it’s on my list.
In contradistinction with this are offering like CubeMx, Attollic, ESP’s free SDK, and so on. Typically, they’ll provide you with an IDE. That IDE might be based off Eclipse. Eclipse slows my system to a crawl. I also found CubeMx to be too “automagical” to my liking. It’s got its wizards, which makes it hard to determine what’s actually going on.
Or, if not for that, it’s the use of Python. ESP’s SDK seems to use “kproject” and CMakefile. What’s a kproject? There’s configuration files, and Makefiles that link to other Makefiles. It’s all an interweaved mish-mash of dependencies.
And the SDK wants to download and install other subsystems. But I already have a compiler. Why can’t you just use that?
I’m not singling out just ESP, you understand, they’re all like that. Mbed is similar. It seems to depend on incompatible Python modules, though. Fortunately mbed is available online via a web interface, so at least that’s something.
Then there are the free offerings, like PlatformIO. PlatformIO seems to rely on Atom (?). I don’t really know what PlatformIo and Atom are unrelated. As far as I can tell, Atom is a bloated editor. PlatformIO wraps more bacon around the pig, and wants to download the compiler for you particular MCU. At least that’s what I think is going on.
See what I mean? What does all this crap supposed to do? It reminds me of the time I was working at the then-Logica. This was the late-90’s, at the height of the tech boom. I had programmed in C on a Unix system for most of my time there. That meant Emacs and the GCC. I then worked on a small project on Windows using Microsoft Visual C++. My project manager – who thought that anything less than Lisp was doing things the hard way – commented on the vast number of files that Visual C++ automatically generated. “What are all these files ‘for’?” He had my sympathies on that.
Internet of Tripe
Back to more recent history. After playing with a Nano, I heard that ATTiny85’s were a good way to shrinkfy projects. I do like the 85’s, and built a few projects with them. I found that they were much easier to flash using a custom-made board for the Pi than using an Arduino as a programmer. My Arduino programmer always seemed a bit finnicky. The Pi programmer was reliable.
Although I admired the 85’s, their tedious flashing routine and lack of readily-availabe serial port meant they were a fiddle to work with.
The I discovered Espressif, with their ESP8266’s and ESP32’s. Wow, what fantastic MCUs they are. It’s like you went to hire a boat, but were handed the keys to a yacht. Plus they had built in Wifi, all for about 5 quid. Amazing!
When you have Wifi, it seems almost impossible that you can conceive of anything without Wifi. I had a cheap RTC clock, the infamous “Tiny RTC”. I got a pack of 5 of them for a couple of quid. Bargain! Except the Tiny RTC, based on a DS1307, has all the accuracy of an hour glass. The DS1307 is not especially accurate. I’m given to understand that the Tiny RTC is badly designed, meaning that the module is pretty useless. It was out by a minute a day. Pretty useless if you want to build a long-running clock.
I followed the advice of adding fudge-factors to the timing. After a bit of trial-and-error, I managed to come up with decent timings over a longish period.
It occurred to me that, with the ESP, I could sync the clock with a time-server over the interwebs. Thusly, I created a project which I imaginatively called “dev07”:
With the benefit of hindsight, I should have allowed for space around the ESP’s antenna. I couldn’t be arsed trying to write my own routine to convert UTC to local time, so I hit upon the idea of getting my Pi2 to act as a server of local time. The ESP then periodically syncs with Pi2.
I eventually replaced the project. I dragged it out today in order to take a piccy of it. The row of lights down the bottom is a “blinkt”, which I use as a bank of status lights. The status of the lights demonstates that the device is properly powered (I had been having problems with brownouts and Watchdog resets), it is talking to the DS1307 clock correctly, but that WiFi and NTP is not working. Well, the NTP not working is easily attributable to the WiFi not working. I suspect that I have long disabled the time server on my Pi in any case.
What did I learn?
Lesson 1: don’t buy crap. The need for WiFi and status lights for a simple project should really have been an obvious indicator that the Tiny RTC was unusable junk, and that I would have been better off with a much more usable module. So I went and bought a DS3231, which has vastly better precision. It cost more, but then again, at least it was fit for purpose.
Lesson 2: the internet is unreliable: really unreliable. Especially WiFi. All sorts of connection issues can occur, and caused all sorts of complications for me. The fact that I felt the need for status lights on such a simple projects should have been an additional “smell” that I should have ditched the DS1307 ages back.
Fortunately, I am only making these projects for hacking purposes for little money. People that have spend beaucoup dineros on fancy devices are hostages to the vagaries of internet availability and the vendor still maintaining its servers. Plenty of companies like Yahoo, Google, etc. get bored with their products and pull the plugs. Smaller companies – the ones you bought your IoT device from – are in an even more precarious position.
Just say “no” to the InternetOfShite. It’s all for vendor-lockin and information harvesting, you know.
With those lessons learned, I built a new device, “0clock”:
I still use it to this day. You see that it powered by our old friend, the Arduino Nano. It uses a vastly more accurate DS3231 clock, which should be accurate to within a couple of minutes a year. I suspect it is even more accurate than that, judging by how long I have kept it running. It also adjusts for daylight saving.
You may be asking if all this was worth it. If I’m being logical, then the answer is “no”. However, it was fun to make, I learned a lot. It also survives the frequent power outages we have around our neck of the woods, and doesn’t need pesky time resets when daylight savings starts or stops. And another thing…
Lesson 3: don’t throw away old projects. The board I used there was from a previous attempt at building a clock. There is some pins there where the original DS1307 was. The board was kept in a drawer for a long time, and I figured that I would salvage some of its components one day. In fact what happened was that I decided to resurrect the board. I snipped some wires to accommodate the DS3231 instead of the DS1307, and soldered in some wires for the switches on the segmental display. They don’t have any functionality at the moment, but I figured that whilst I was creating chaos with my soldering iron, I might as well wire up the switches properly.
The lesson of “don’t throw away old projects” has happened with other boards I built for different projects. You shelve them, but from time-to-time you think to yourself “you know, I’m actually going to use that project right now.
Lesson 4: is any project really finished? I find that no project is ever really “finished”. I build something, and then can see ways of improving it, or combining it with other functionality. Sometimes you have to draw a line and say that something is “good enough”.
My recent toys: STM32 and STM8. Baring all
Not so many months ago I discovered the STM32 “blue pill” ARM boards. They’re pretty neat, being a lot cheaper, and more powerful than the Arduinos. Initially I programmed them with the Arduino IDE. At the moment, I’m getting things done using ST’s online mbed programmer.
Being disillusioned with what is available, I am trying to go down the “bare metal” route on the STM32. It is a long slow journey, but I’m making progress. I’ve got blinking, delays, interrupts and USART working to my satisfaction. There’s still SPI, I2C and PWM to do yet, but once I’ve got those down, I figure I’ll have a very usable library.
In tandem, I bought a couple of STM8S’s. Online resources are a bit thin on the ground. But I’ve got USART, blinking, delays and interrupts working, in addition to SPI master and slave. So, some good progress. I’m finding the STM8’s to be easier to program than the STM32’s. The former is a much simpler chip. It’s a cheaper chip. Size-wise, it seems between an ATTiny85 and a Nano. I think there are a lot of possibilities with this chip, and it may end up being one of my favourite chips for projects that don’t need a lot of grunt.
When I have libraries working to my satisfaction, I fully intend to tell the community. The way I see it is they won’t be the best that you can get. But they will at least be functional and act as a springboard and learning exercise for those that want to experiment with the chips. Compilation is simple is speedy; no need for Python tools, submodules, or any of that. Just libraries that can be built in seconds and linked in simply, keeping abstractions to a minimum, with no complex infrastructure.
That’s all for now. I hope you found it interesting.