Project Logs

Collapse

• Advances in microelectronics --- a potted viewpoint

  Ken Yap • 11/14/2021 at 21:59 • 0 comments

  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...

  Read more »

• 8048 version published

  Ken Yap • 07/31/2019 at 12:28 • 0 comments

  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.

• Marking project as completed

  Ken Yap • 11/27/2018 at 06:03 • 0 comments

  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.

• Firmware and schematics have been released

  Ken Yap • 10/31/2018 at 22:37 • 0 comments

  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. 😃

• Got the time setting buttons working

  Ken Yap • 10/28/2018 at 10:00 • 0 comments

  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 get the display working

  Ken Yap • 10/27/2018 at 13:28 • 0 comments

  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.

• Waiting for serial inteface LEDs

  Ken Yap • 10/24/2018 at 05:31 • 0 comments

  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.

• Current consumption

  Ken Yap • 10/21/2018 at 14:31 • 0 comments

  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.

• More hardware and code modifications

  Ken Yap • 10/18/2018 at 04:05 • 0 comments

  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.

• I draw my circuit using Kicad

  Ken Yap • 10/18/2018 at 03:54 • 0 comments

  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.

View all 14 project logs