In December 2001 I soldered 25 red LEDs and 5 resistors onto a square of veroboard:
then connected a locally produced PIC16F84 microcontroller development board via ribbon cable soldered to the veroboard, and a home-made power supply to it, wrote C code to create frames of patterns that changed over time, and used it as a Christmas decoration. It has been up each Christmas and New Year for the past 24 years at Christmas and New Year. The video below shows some of the patterns it has displayed.
Each time the code (or even just patterns) changed, the PIC microcontroller had to be removed from the development board, inserted into a programming board, and the binary (.hex format) including code and static data (e.g. pattern frames) uploaded to the device via a serial connection to the programmer board, then placed back into the development board .
I’ve used quite a few programmers over the years, starting with a parallel port programmer I built from a kit in conjunction with free software to write, read and verify bits written to the microcontroller. After parallel ports went the way of the dinosaur, and before USB ports were common, serial port pins were used to “bit bang” data to the microcontroller via a PIC pin, one bit at a time. Over time, serial ports became extinct too, and a USB to serial cable did not work as a replacement because the wires over which to bit bang data were absent. So, I kept an old Windows 95 laptop around for this purpose, since it still had serial port.
Compiled files (.hex files) had to be transferred to the laptop via a USB memory stick from one of a number of computers I used to write and compile the code on (Windows, Mac). Over time the C compiler had to change as well, from Hi-Tech to MPLAB.
I figured that one day the Windows 95 laptop was going to stop working or I would lose the only USB stick that worked with it.
So, in December last year (2024) I finally decided to change the microcontroller from a PIC 16F64 to an AVR based Arduino which has a cross-platform development environment and allows code to be read/written via a USB cable. That’s been the case for a decade or more now for many microcontroller and similar devices.
Although the General Purpose Input/Output (GPIO) pins changed, just 3 lines of the original C code had to be changed to get it to work with the Arduino! That’s is a testament to C. Had it been written in PIC assembly code (and I’ve written my share of machine-level code) or some now extinct special purpose language, or a compiler that’s no longer available or supported (or only on one operating system), a total rewrite would have been necessary.
To me, microcontrollers are like what microcomputers were 40 to 50 years ago, but with no operating system, except perhaps a bit of code that loads other code into a device. Early microcomputers (e.g. Apple I or II, TRS-80, Commodore Vic-20/64) didn’t have much of an operating system either. They just booted up into a read-eval-print loop (REPL) and called other code to load programs from tape or disk, display characters on the screen, play sounds and so on, often supported by specialised hardware.
The Arduino platform provides common pinouts irrespective of processor (e.g. AVR, ARM), a platform independent Integrated Development Environment (IDE), C++ as the development language, a common Application Programming Interface (API), a library of common code for many peripheral devices (e.g. keypads, LCDs), and a USB to serial programming and I/O route.
Before the Arduino, it was the wild west, like it was before the PC and Mac came to dominate. That diversity was interesting however, and 20 years ago I tried my hand at writing generic library code that was likely to work with multiple microcontrollers, and experimented with writing compilers (and interpreters) for various languages to run on microcontrollers. Starting from scratch is not necessary now.
The PIC16F84 had less than 100 bytes of RAM and less than 2K of non-volatile program (FLASH storage) and could run at between 4 and 10 MHz. I later replaced the PIC16F84 with the PIC16F628 which had more than 200 bytes of RAM, 3.5K of FLASH and had a clock speed of 20 MHz.
Optimising the code and patterns that were stored mattered a lot on these small devices!
Compare this with the AVR ATMega 328P used on the Arduino I switched to. It has 32K of program FLASH and 2K of RAM, although the clock speed is only 16 to 20 MHz. Still small by the standards of many microcontrollers now and orders of magnitude smaller when compared to the resources available on even the most modest laptop or smartphone today.
The AVR was made by ATMEL, which was eventually acquired by Microchip, maker of PIC microcontrollers, ironic because of the fierce rivalry between the two companies at one point, amusingly exemplified by this sticker:
The processor, clock speed, memory and on board peripherals in microcontrollers have improved significantly over time, and devices like the RPi PICO have more powerful processors (typically ARM based) and can be programmed either as an Arduino device or can run MicroPython, making it much easier to create more complex gadgets. But that’s for another post.
There’s a lot that can be explored in the world of microcontrollers, which are distinct from other small devices such as Raspberry Pi, NVIDIA Jetson, Beagle in at least one important way. The latter are full fledged computers that run an operating system, typically a variant of Linux.
Unless a microcontroller is running an interpreter, the code you write takes over the device completely. There may be a small boot-loader that loads the program to be run, but nothing like an operating system. Ultimately, when you program a microcontroller, the only code running is yours, compiled or assembled from a human-readable language into machine code. You control the vertical and the horizontal. If the device does nothing or if it does the wrong thing, it’s because there’s an error in your code or you wired something up incorrectly. Either way, it’s on you.
When I started writing for the PIC, it really was entirely my code, nothing I had not written myself vs use of Arduino library code. In the case of this simple LED grid, it still is all my code. Either way, this complete control over a device is appealing in an age of bloated operating systems, an enormous emphasis upon cybersecurity, and wasted power.
Microcontrollers are also an example of so-called green computing. There is an emphasis on low power consumption and small footprint.
That’s a topic worth exploring more in an age of Blockchain and more recently, Large Language Models. For example, some machine learning models can be trained on a more powerful computer, then run on a less power hungry microcontroller.
Another topic worth exploring is zero-instruction set computing.
So many things to write about.
Leave a Reply