Advances in microcontrollers

This is my point of view and summarises the improvements since I began hacking hardware. After reviewing the history you may appreciate how much easier MCUs are to work with now compared to in the past.

Semiconductor logic technology

The original 8042 used NMOS logic. This was already an improvement over PMOS logic which required higher voltages so interfacing with TTL had become easier. However NMOS logic has now been supplanted by CMOS logic which contributes to some of the advantages below.

Power consumption

MCUs of that era drew tens of milliamps. This obviously limited battery operation. Nowadays MCUs can draw microamps in quiescent mode. So battery and solar cell operation become possible. Cue the rise of IoT devices. This partly offsets concerns about the power consumption of lots of these devices in consumer hands.

Power handing

The MCUs of the past could only drive a small number of TTL unit loads, so interface chips were needed if you wanted to drive loads. Now MCUs are capable of driving higher currents of the order of tens of milliamps per pin and can be connected directly to displays, saving chips.

Clock rate

Clock rates of that era were around 1-10 MHz. Now MCUs can easily be clocked 5-10 times faster.

Clock drive

Clock drive inputs were already getting simpler. The 8080 microprocessor required a complicated set of clock signals, usually provided by an auxiliary chip, the 8224. The 8085 simplified that by taking that clock circuit on chip.

Later on, for non-timing critical applications, the quartz crystal could be replaced by a lower cost ceramic resonator, or even an RC circuit. Today there are chips that have the RC components on chip which saves another pin or two and the designer doesn't even have to think about the clock.

Program storage

In that era, programs were stored in mask ROM or EPROM. Mask ROM was only for mass production, so testing and small runs had to be done with EPROM. So either one had to connect an external EPROM (see Pin count below) or the MCU had to have a quartz window for UV erasure, increasing chip price. If you were quite sure the program worked, you could use an OTP version that was programmed in the same way, but only once.

The first advance was moving to EEPROM. This meant that the program memory could be reprogrammed electrically, eliminating the quartz window. Then the next step, combining the EEPROM with the MCU contributed to advantages below.

Greater integration

One advantage MCUs had over microprocessors was that peripherals were integrated on the same chip. However this ran up against the number of package pins. It was not unusual to multiplex the buses to the external memory and peripherals to conserve pins. Or use expansion chips like the 8243. With EEPROM and peripherals on chip, the buses no longer needed to be exposed to the outside world. This means that more pins can be dedicated to peripherals. Or you could put MCUs in packages with fewer pins, even as low as 8. At the other end of the spectrum, smaller pin footprints of SMD ICs allow more pins to the outside world if desired.

CPU program and data bit width

Now that the EEPROM is on chip, there no longer needs to be a relationship between the width of the program memory and the data memory. For instance the PIC program words are 12 bits and other weird sizes. This assumes a Harvard computer architecture where the program and data stores are separate.

Glue technologies

These days instead of using discrete logic ICs to interface MCUs to other devices, one can use CPLDs or an even older technology, GALs. These are reprogrammable, sometimes even in situ, allowing you to correct logic errors without circuit board rework.

However, CPLDs cater more to professional products which are transitioning to 3.3V or lower so there are less options for connecting with 5V logic and also the packaging won't be DIP, but PLCC or SMD.

Some hobbyists have cunningly used MCUs like AVRs as glue logic. One recent Z80 SBC used an AVR to provide program memory and interfaces. Yes, it does feel strange to use a more powerful micro as a slave to an old one.

Rise of serial protocols

Another way to conserve pins and interconnections is to transfer data serially. Nowadays many peripherals are interfaced with serial protocols reducing lines compared to parallel protocols. Protocols like I2C, SPI, and custom ones are used. This is assisted by the increased clock rate of MCUs so transfer time isn't an issue. Sometimes the chip hardware or instruction set has assists for these protocols.

Rise of modules

With standard protocols, manufacturers could make modules to simplify design. Instead of, for example, designing drive circuitry for an array of seven-segment LEDs, one can get a module which incorporates the LEDs, multiplexing, current limiting, brightness control, and even keyboard input. One example is the TM1637 chip found on many cheap 4 digit LED displays. There are only 4 pins to connect, 2 power, clock and data.

You see usage of this in this clock where I have reduced the hassle of interfacing seven-segment LEDs with all the attendant drive transistors and resistors by using a cheap off-the-shelf serial driven display board. But this requires writing bit-banging code and ensuring that the MCU has enough processor cycles.

The whole concept of modules and specific implementations like Arduino shields makes life easy for the experimenter. Less soldering is required.

Toolchains

As MCU architectures became more sophisticated, they became better targets for higher level languages like C. The architectural conventions of C mean that you could not support C on an 8048 or 8042. On the 8051 family, you can. The increase in sizes of program memory and clock speed mean that it's no longer as crucial to program in assembler and one can afford to "waste" memory and CPU power in return for being able to write clearer code and larger programs. The Arduino ecosystem allows experimenters to connect their computer to the board, then edit a sketch, compile and test in a tight loop.

Improvements in software tools means that it has become easier to write compilers; it's no longer an arcane art. The open source movement makes more candidates to choose from and community participation makes the software better.

Construction techniques

While this is not directly related to MCUs, construction choices are different now. The breadboard is still useful, but for production, you design PCBs with CAD tools and send the plot files over the Internet for fabrication. No need for the old-school resist pens, or photoresist and exposure masks, and noxious chemicals to prepare, etch, and clean the board. Other steps like silk screen printing, solder masks, and drilling are thrown in. The factory can even presolder standard SMD components, or custom components you provide, for a price of course. And there is recovery of copper if the board is milled.

I've published a 8048 version of the board, with schematics and fabrication files, verified working. Link to the GitHub repository is in the links section. The board fabrication by Elecrow was related here. Note that the hardware configuration differs a bit from the 8042.

I built a version of the clock on perfboard, this time using a real 2764 EPROM, see the photo in the details or gallery.

I have nothing good to say about perfboard. It is not a serious circuit board technology except for small circuits. The main difficulty is getting good solder joints with flying wires. Stripboard is only slightly better and has its own drawbacks. The only reason I used perfboard is because I had a last one lying around from decades ago and I decided to use it up. Certainly I won't be getting any more.

I got the clock to boot and show the time but not advance. Also there were unreliable joints which caused the clock to stop working if I wiggled the board.

I consider the point of the project proven and won't be doing anyting more with this design so I'll mark this project as completed. Time to release the breadboard space and move on to other MCUs.

The time setting buttons and brightness control (both buttons pressed) are now working on the breadboard.

I have released the firmware and schematics at Github, see the project links.

There won't be any more planned design changes but I will keep the project ongoing until I successfully build a production board and perhaps make a one-chip version by programming a 8742, after which I'll mark it completed.

Presentation is important! Project boxes don't hack it. Plastic looks so nerdy. I may have to take up woodworking to build housings for my projects so that they are acceptable gifts. I may have to move to the seaside to collect driftwood. 😃

I compared the routine to the one for the plasma clock project and it's essentially the same. Then I thought to measure the voltage on the T0 and T1 pins. It was floating, and looks like there is no internal pullup resistor inside the chip as I had assumed. I added a couple of pullup resistors to the circuit and the buttons now work as designed. There pullup resistors must have been already present in the plasma clock.

Next to test that pressing both buttons together will cycle the brightness.

I got my TM1637 display today. 😃

I wired it up to my Arduino Uno, checking with a continuity meter that the connections were correct. I have learnt not to trust looking at the pin positions because it's easy to see off-by-one. I then ran the test sketch in the blog article which implements a 4-digit counter. It works great. This provided a baseline so I knew the display worked and the serial protocol was the one published.

I wired it up to my breadboard, again checking the connections with a continuity meter. A mistake like swapping the power lines, would blow the display and set me back a few weeks, the time required to receive another display from eBay. And I would be kicking myself.

Turned it on and got scrambled segments. ☹️ So I went back to the bit-banging code and compared my assembler code to the C original. I tried simplifying the code by commenting out sections. One thing I tried was to set all 7 segments on. However the result was 6 lit up and this was different for each digit. Aha, I must be missing one data bit in the serial transmission. Looked at the code, and sure enough, I had missed one final clock transition in my code, all of two lines of assembler. This is always a hazard when translating code from one language to another.

I took the usual celebratory photo which you can see in the Details section, showing 12:35, not long after switch on, as the initial time is 12:34:56 (seconds not displayed). 😃

The time setting switches don't work yet. I have made some large changes here from the plasma clock project so that's not surprising. I'll have to go back to the simulator to debug this. But enough for the day, better stop while I'm ahead.

They should arrive this week. Buying from eBay means you need to have several irons in the fire so that you don't get bored while waiting for parts to arrive, so I've been working on other projects too. I'm going to make this project public later today anyway. Since I have the blink LED going at 1 Hz I'm pretty sure that part of the code is being executed. The only part I'm not sure of is whether the bit-banging code to transmit to the serial interface LED array works but I'm sure I can fix it if it doesn't.

I measured the current consumption of the 8042 MCU by inserting a milliamp meter in the +5V supply to the chip. It confirms reports of other experimenters that it's scandalously high compared to modern MCUs. I measured around 80 mA. I only sampled a few chips—no time to test every one—but there was little variation across the NMOS chips by age or manufacturer, or whether it was a ROM or EPROM part. However a couple of chips labelled 80C42 made by NEC only drew about 8 mA, far better. Whether NMOS or CMOS has a greater impact on the current draw.

You won't feel the difference by touch; 80 mA means 400 mW dissipation, barely noticeable.

So, generally not a MCU you want to use when power is limited. But you should look at the whole application. If you are driving heavy power devices then the amount taken by the MCU may be insignificant.

I decided to put in a brightness button connected to a port 2 bit, to cycle the brightness levels. When I powered up the breadboard the LED blinked at the correct rate but didn't turn off completely; looked like some extra bit changes were happening.  Were the port bit AND and OR instructions in the set doing the right thing? Seems so, bit banging is exactly their purpose and other people used them with no problems. So I added a conditional section to my code, which is a standalone Blink program, made another EEPROM and tested it. Turned off the LED cleanly. I looked at my code again, and saw that I was reading  port 2 at one point to get the state of the brightness button. Long story short, the read didn't return high for the other bits as I thought. I removed the read and the LED blinked cleanly. But how will I get a brightness button now?

So I decided I would overload the hour and minute buttons so that pressing both simultaneously would cycle the brightness level. Simultaneous means both buttons down within the debounce periond (100 ms) of each other so it won't affect single button functions. Tested this in the simulator and got it to work after some iterations. So now there is no need to read port 2 and I've saved a button.

Added a discharge diode for the reset capacitor so that it will be ready for the next power on quickly.

Now to wait for the serial line LED displays to arrive.

Never let an opportunity to learn go to waste, I say. I installed Kicad 5.0 on my system and started using it to draw the circuit. The learning curve is steep, I have to consult the Internet for puzzling problems, but I get the hang of it. Being a stickler for a neat diagram, I modify it a lot to make it neater. Bus lines in Kicad are great.

I will be using a 2816 EEPROM for testing. This has 24 pins instead of the 28 of the 2764, so on a paper copy of the diagram I write the correct pin numbers in pencil. Even so I make some mistakes that I correct after some testing with a continuity meter.