I first used microcontrollers in the early 1990s, with I think the PIC16C54, a homemade parallel port programmer and one of the versions of this book constantly on my desk.
Looking at the features of that now it rather surprisingly minimal.
- It has one 8 bit timer.
- 512 bytes of code and 25 bytes of RAM.
- That's it.
No 16 bit timers, no UART, SPI, I2C, Analogue functions, SRAM, touch sensors, USB, LCD drivers etc.
The technology of those microcontrollers goes back to the 1980s. There was a earlier version of that chip in the ZX Spectrum+ external keypad (back before Microchip split from GI).
Those were meant to be developed with ceramic EPROM versions with glass windows to UV erase the contents. The production chips were one time program.
It feels like the stories you hear of people writing programs on punched cards and then getting one shot to run them on the actual mainframe, and it may or may not have worked.
I had one shot. I bought the chip, wrote the code, programmed it and hoped it would work.
If it didn't, I had to raid my pocket money and buy another chip. I think I finally got some LEDs flashing on the second or third attempt, but I was very proud at the time.
PIC16C84
A few years later the PIC16C84 came along with double the program memory, and it was now EEPROM program memory which was electrically erasable, and so could be programmed time and time again.
My first PIC16C84 programmer was built from design by Derren Crome in Everyday Practical Electronics magazine (February 1996, pp 102).
I am sure the original veroboard programmer with four rectangular red LEDs on it is still around somewhere, but I can't find it at the moment. I later replaced that with a kit version based on the same design, which I still have.
The introduction of the electrically erasable versions brought this to hobbyists like the teenage me to be able to develop code and try it in real time.
This version did now had all the following features:
- 1K EEPROM program memory
- 36 registers
- A single 8 bit timer
- An external interrupt
I built lots of projects with those, including my final year degree project. That was a demonstration system for a way of controlling car lights with a single power bus and an optical cable. My test setup was a 4x3 sheet of plywood with two mini Metro taillights from the scrapyard and a few coils of fibre. I wish I had a camera in those days, no records of any of it unfortunately.
I still have a few bits of old project boards. I wonder where I salvaged the chips on this one from? 74LS04 from 1977, a ceramic 54LS138 from 1985. Only the PIC would have been new, the later PIC16F84.
I think this was a clock control board - I built a lot of clocks in those days. These ones used the larger PIC16F874 I think.
But we did an awful lot with those minimal features. It was a similar discipline to writing on an 8 bit computer. Every byte and every cycle counted. Every bit of lazy coding wasted time and space, both of which were precious.
When you think about it, the PICs were RISC processors, Reduced Instruction Set Computer, with 35 instructions. That's not too different to the standard 6502 with 56 instructions, and fewer registers and not even the single 8 bit timer.
I am sure writing under those constrains breeds better programmers. The old approach to "my code is running slow" was "rewrite it to be faster and more efficient". The modern approach is "specify more RAM and a faster processor".
Arduino
Roll on to the next generation, something like the ATmega328P found in Arduinos and the like.
That seemed to bring on a whole new wave of possibilities with it's neatly packages microcontroller and USB programmer all in one.
The ATmega328 and chips of that generation had a while load of more peripherals.
- Two 8 bit times
- A 16 bit timer
- 6 channel ADC
- USART
- SPI
- I2C (or rather TWI which is compatible as I2C is a licenced protocol)
- Analog Comparator
- 32K program memory
- 2K SRAM
Such a world of possibilities.
Although, again, I built clocks.
One thing to note here is that each of those features had their own dedicated pins. There was one pin that could be RS232 TX. Most could be an IO pin, some could also be analogue inputs or external interrupt sources.
When designing things, you had to be aware that if you wanted to use SPI, then you had to use pins 16, 17, 18 and 19. That was sometimes a problem, specially when I often need an 8 bit wide port and usually find they are broken up with pins I need for serial or SPI etc.
AVR series
Things have moved on again. Microchip bought Atmel and brought a lot of PIC style things to the latest round of AVR microcontrollers, which now carry a Microchip logo.
They also have their own combined programmer and dev board, the Curiosity Nano series.
These have been quite useful, since I have never got on with their programmers like the MPLAB (should be) Snap (ped in half).
They are also small and cheap enough (~ £15) that you can just wire them into a project during development.
These have an embarrassment of peripherals compared to the lowly PIC16C84 and even the ATmega328P.
- 128K program
- 16K RAM
- 512 bytes EEPROM
- 4 x 16 bit timers
- 12 bit timer
- Real time clock
- 3x USART
- 2x SPI
- I2C (TWI)
- 10 Analogue inputs
- 3 Analogue comparators
- 1 Zero crossing detector
- 18 channel touch controller
However, there is an important difference, these features are no longer tied to particular pins.
If you want to use an RS232 port, there are now three, so you can have your RS232 TX on pins 2, 10, 12, 16, 22 or 26.
The datasheets now have massive tables showing the various multiplexing options.
This is a bit of a double edged sword, all this flexibility means there is a lot more to configure to map the signals to the right pins.
There are also two new internal systems which can be incredibly powerful.
The Event System and the CCL (Configurable Custom Logic) system allow you to wire up some of those peripherals and pins in different ways.
Configurable Custom Logic
In it's simplest form, the CCL is a few gates of configurable logic, sort of like a mini GAL chip. You have multiple three input, one output blocks. You can do things like take three input pins and set an output high when one is low and the other two are high, or whatever, according to a pre-programmed truth table.
You can also add sequential logic like flip flops to these signals.
That can be useful, and can save a logic chip or two. I used this to remove the need for one of the flip flops in the Minstrel 4th (although I then used it for something else).
Where it becomes more interesting is there are some other inputs you can add to the logic, such as the output of timers etc.
Events
The event system is another way of wiring thing together, again, all behind the scenes requiring only setup code and stealing no cycles after that.
You can do things like get a timer to trigger the ADC to start an analogue conversion, you can get an external pin to trigger a timer, or count a pulse.
When I was first investigating the Mini VIC, I had one of these setup with timers generating the video sync, all does with this linked logic and no code other than the original setup. The horizontal sync counter would output the pulse at the start and clock the vertical sync counter, which would output it's own sync pulse at the appropriate point.
You can use also wire the event and CCL system together to do quite complex tasks, for example, you could have three pins that were ANDed together in the CCL and then sent to a timer via the event system to increment a counter.
You can also change things on the fly from code, so in the Minstrel 4D, I had the signal sent to the EAR pin configured as a CCL output. This could either be wired to the analogue comparator output, or it could be controlled by the output of a shift register clocking through data from SD card or loaded over serial.
But ....
With something like the ATmega328, it was fairly easy to set things like that up, as there were limited options, so once you enabled the RS232 USART, you know it was going to use pins 2 and 3 (although as is the law in this situation, there is no point in checking which is which as 50% of the time you it will be wrong anyway, RX-RX or RX-TX etc.)
Because of all the options in the AVR chips, various tools are provided to configure things for you.
I don't want to put you off here, but they don't always work. There seems to be an update every time you start up, and there is a whole new system every couple of years, and unfortunately none of them are perfect.
Having tried many of these at different times, and haven't found one that suits me yet (which I am sure is partly my fault).
The main issues I have found are:
- Life cycle - as they move to new systems, the old ones stop being updated to add support for new devices
- Bugs - with so many devices, and so many combinations of options, there are bound to be mistakes
- Bloat - in order to support all these things, the code generated tends to be quite large and inefficient
Those may not be a problem for you (or indeed me), depending on the application. Often I want to be able to flip IO pins in a single cycle. However if the timing is not that important, the framework will generate nice commands like
- LED_set_level(true);
Depending on the compile options, that might be optimised, but otherwise there is a lot of overhead with C function calls, saving lots of registers and them restoring them at the end.
I have found the best way for me is to use the tools to generate some code, and then try to pick through the dozens and dozens of files generated to find which bits I need to add to my simple C or assembler projects.
I think a good way to demonstrate this would to run through a real world example, with increasing complexity, to get to the functionality that I needed, and then condensing that to the few lines of assembler are actually important.
This post is already getting a bit long, so I will do that as a part 2.
Adverts
Lots of things built using microcontrollers are available from my Tindie Store.
I can still ship worldwide.
Currently it looks like Royal Mail to the US is working without having to pay tariffs (computer parts are excluded from the 10% so there is just a handling fee, which I pre-pay). There still may be delays or charges. We're all pawns in a petulant child's political games, but we've got to just keep going and try to make this stuff work.
Patreon
You can support me via Patreon, and get access to advance previews of development logs on new projects like the Mini PET II and Mini VIC and other behind the scenes updates. The part two to this post should be appearing there shortly. This also includes access to my Patreon only Discord server for even more regular updates.
