Revisiting an old digital clock

Here is the digital clock freak again. This time to update something old. What the image shows is one of the first digital watches produced around 8 years ago when I dabbled in micro PICs. I had a development board from MikroElettronica with which I experimented with several things by gaining experience with these systems.

When, today again, I design new digital watches I wonder what the difference could be compared to those already produced, to make them different. In fact if you have the patience to read my article "Allegria, the mad watchmaker is back !”You will find a rundown of working and other watch projects left on paper or deactivated / disassembled or only demonstrative.

At the time of the production of this watch (circa 8/9 Years ago) I didn't have much knowledge with RTC devices and with display management a 7 segments. So the realization of this involved the use of well 8 integrated circuits with a lot of study to connect them and make them functional. Four of these were used to manage the timer and the other four to drive the displays. The heart of this system was the micro PIC16F84: a small micro with a few ports available but sufficient for what I needed. Having no RTC, the clock was provided by the pic through the setting of its internal timers to generate an impulse per second. They weren't very precise but all in all it was fine.

What was then the difference from the others ?: the latter were not part of the display (it was a cannibalized device from an old solo decoder 4 figures) but they were viewed through a crown of 12 LEDs that lit individually one after the other 5 seconds. Here is the reason for the four integrated.

Why then redo or "revisit" what is still working ?

First: in this period of "forced enclosure”You need to do something that isn't always reading or watching TV (as well as preparing lunch and dinner or shopping !!) for which I thought: why not readjust this old watch with more modern tools ?.

Second: Occasionally this watch showed signs of fatigue: he stopped casually for no apparent reason.

Third: Missing an RTC (that holds values ​​thanks to the stack) the values ​​were obviously not preserved so after sudden Black_Out, it was necessary to reposition the watch using the four buttons used for this purpose.


Without prejudice to the recovery of some parts including: the box that contains it, i 4 display, i 12 LEDs already wired and the keypad with the four buttons, I started studying the circuit starting from how to generate and drive i 12 led each 5 seconds and with which device to switch them on. The scheme below is the first result.

Reading the seconds from the RTC discriminating when i 4 lower bits are = zero or five generate a clock pulse (transition H_L_H) that sent to the first entrance of the 7493 advances the count by one unit. This integrated is a "4 bit binary counter”And presents at the exits Q0 / Q3 all values ​​from00” a “FF according to binary logic. These four outputs are connected to the inputs "A0 / A3"Of the integrated 74154 very old decoder "4-16"Or at each binary configuration at the entrance, the exit "S0/S15"Equivalent goes logically"0"Keeping the other a"1"Logical. As you can see from the diagram, each output from "S0" to "S11" drives a led. But that's not enough: the meter "MUST reset to 12 pulse and return to zero otherwise the synchronism of the seconds is lost. It is enough to bring "Q2 e Q3”At the entrances MR1 / MR2 of the counter which will reset to zero when the two bits are at "1" logic. (twelfth impulse).

However, there is a problem: when voltage is given to the clock, this counter does not reset but presents a random binary configuration to the outputs. And this creates the non-synchronization of the seconds.

I posted this problem in the forum: how to reset the counter at power on and when it counts to 12. I have to thank Amilcare e PicMicro675 who have proposed me some schemes. But since I am stubborn and stubborn I have studied and re-studied how to remedy the problem. I think I have a good programming experience not only currently with Arduino but also in the past (I was a software designer for a multinational company) for which: what can be problematic via hardware can perhaps be solved via software.

I have found two solutions: the first via software / hardware keeping the original scheme. In the sketch I programmed the third button. After each power on of the system one of the 12 LED lights up based on the Q0 / Q3 value of the 7493. Then each time the button is pressed it is sent to the clock 7493 an impulse that goes forward each led. When the "0" LED lights up, the TIME / MINUTE / SECONDS synchronization is assumed = 0 and the clock is started with the fourth button updating the RTC.

The second solution is in the following scheme:

Here we intervene exclusively via software: The clock is provided with RTC every 5 seconds to pin "WHAT”. When the system is turned on, a reset pulse is sent to pins MR1 ​​/ MR2 of the 7493. During the normal cycle of counting and displaying hours / minutes, also count how many clock pulses have been supplied to 7493 and on the twelfth a reset pulse is sent. So operating the synchronization of the seconds is perfect.

This below is the scheme of how I had managed the management of 12 led con ben 4 integrated. Maybe the logic is a little complicated !.


I divide the scheme into functional blocks:

First block: Counter and decoder. The scheme is that relating to the first scheme (see above).

Second block: keypad to update Hours / Minutes / Seconds and start

Third bloccO: Display and decoder connection. This circuit is only an example as it can vary according to the type of display. (Anode o Cathode Common).

Fourth block is related to the RTC module.

Each of these blocks is connected to a pin of the ATMEGA_328 micro.


The connections of the timer, of the decoder and keypad should be clear. As for RTC, it is an old form PCF8583 with many features (alarms etc.) and a ram of 240 bytes like the more modern DS1307 and others. It connects with the I2C protocol (SCL/SDA) and it is very precise.

The display used is a recovery from an old decoder. Is formed from 4 encrypt a 7 segments. Being integrated, the pins are only four for the addressing of each digit and eight for the individual segments including the decimal point. It is however managed in ANODE_COMMON. That is, i 4 addressing pins go to +5 while the segments go to ground for ignition.

This display is managed by the chip MAX7219. At the time I did a fairly thorough study on this device and I have used it in many of my applications even without the use of displays but using standard LEDs or RGB LEDs. Alone it manages to handle up to 8 display a 7 segments or a matrix display 8×8. If then it is connected in cascade with others 7219 the number of displays can double.

There is however a small problem: by its nature this chip only manages displays Cathode_Common contrary to the used display that as mentioned is Anode_Common.

There are then two systems to manage both types of displays: intervene via hardware or via software or a mixture of both. Let's see how to intervene for the ANODE_COMMON displays.

Via Hardware: It is the most complex because it is necessary to invert all the signals: both those that drive the segments and those that direct the displays themselves. So for each signal a typical reverser is needed 74Ls04. In the case under consideration: 4 for directives e 8 for the signals are needed 12 i.e. inversors 2 x 74ls04 (6 inverters for each). The library that manages the chip can be downloaded from the web and used normally.

Via Software: It is only possible halfway in the sense that the addressing pins must still be inverted while the segment pins can be inverted via software from the management library functions. So the library must have a specific function to handle this inversion correctly.

About this library: after having studied in depth the one downloaded from the Web, I have developed a new one with other specific functions both for the displays a 7 segments and for matrix modules 8×8 7×5. It is not really a library according to the relative canons, but this so-called "library" is actually composed of two files with the extension ".ino”: the first contains all the specific functions and others of my production, the second contains the tables for decoding the characters to be sent to the 7-segment displays or to the matrices. And it manages both the anode_common and cathode_common displays simply by clearing the relative mode during the "init" phase. However, it is always necessary to invert the signals relating to the addressing of the displays.


PCB MAIN: houses the micro ATMEGA328 and circuitry to generate the system clock and the max7219. The various connectors for the keypad, for the display signals and for the timer module and for the RS323 module to load the sketch when needed.

PCB TIMER: houses the 7493 and the 74154 to generate i 12 led.

The connections are numerous also to recover what already exists.

Unfortunately, I don't have the right tools: having them, a single PCB could have been produced by housing all the components: micro Arduino, max721, display, led and keypad thus avoiding all connection wires.

The third "micro PCB" served me to reverse i 4 signals relating to the piloting of the display. I had to insert it outside the pcb_main as I did not remember the type of display for which I resorted to one “patch” external.


I have to make a consideration: I compared the sketch produced using the pic16F84 with the new one that uses the micro ATMEGA_328. And the comparison is pitiful: the old sketch, comment lines included, was of 200 lines approx, while the new one, always including comments, slightly more than double. This is mainly due to the completely different management both as regards the timer, the RTC update, his reading and max7219; and if we also consider that in the old there was no such management, we get to almost 1000 lines of code. There is also another aspect: with the Mikro Elettronica development board it was possible to interactively debug instruction by instruction by checking the contents of the pic and variable registers. Hot changes could therefore be made. In the Arduino system all this is not possible (to me it is not yet). It is necessary to use the classic "Serial.print" phrases on the serial monitor, inserted in the various points of the sketch to verify "what happens at a certain level". This is the so-called "debug" which is activated in the sketch only if consent is received from the serial port. And this implies further writing of instructions.

The sketch structure is constructed with the following functions:

Reading the 5 RTC registers relating to Hours / Minutes / Seconds and audit log.

Function that stops or starts the counting of the RTC.

Function that converts register values ​​from BCD to individual values (Tens and united hours, tens and united minutes). This is necessary because the RTC updates the values ​​in BCD or the hours 12 is the actual value (in binary it would be "0b"). Splitting is necessary to drive the displays correctly.

The Display_Ore and Display_Minuti functions that send values ​​to the display.

The recompacting function of the values ​​to update the RTC.

The Read_Keyboard function to read the keypad when the hour or minutes and the synchronization of the seconds need to be updated.

The classic “setup” function where the parameters for the max7219 are set, the setting of the arduino pins, the first reading of the RTC and the display of the values, then the keypad management. The setup process ends when the start button is pressed: the RTC is then updated and the counting started. Any "debugging" is activated only if any character is sent from the serial port within three seconds of the message.

The "loop" function at this point is limited to reading the RTC, unpacking the values ​​and sending them to the displays, then the management of the seconds for the lighting of the LEDs. In total 24 lines including comments.

Finally, a couple of photos of the realization.

Main board with l’ RTC (still without battery), the micro ATMEGA and the MAX7219.

A view of the whole project with the connection cables to the display, to the keyboard and the LEDs. As I said, a single PCB could have been made with all the components…. but I don't have the equipment and also the experience to produce it.

Ok, I'm done with getting bored, I continue with the “closure” and let's see what I can come up with and invent.

Thank you for your attention and see you soon !!.

gvsoft April 2020



3 replies
  1. Picmicro675
    Picmicro675 says:

    I have some painful notes. Allow criticism to be constructive.
    The fact that you already had a MAX7912 in the circuit could allow you to expand the display on 12 LEDs via the same, therefore some component less.
    The project is beautiful, I don't want to complain. It is assumed that hardware-related problems can be avoided with fewer components. The rest must then be resolved with the software. So much so that the MAX7912 allows you to direct the single LED of how you want to turn it on.

    Then there are the choices of what you have in the drawers, obviously that the 16F84 I would not recommend to put in place. Also from the fact that it is of an absurd cost as if it were antiques, in fact it is. Then you could also think of taking a recently produced one like the 16F182x, pin-compatible.

    Production NOTE, better if the photos are bigger. Obviously you should then choose the scaling in the drafting of the article, but at least that you can have the visualization of the schemes with the writings quite legible.

    • gvsoft
      gvsoft says:

      Dear PicMicro675
      I have always appreciated constructive criticism….
      But I must point out that this project is not a remake of the old, but one “revisiting” or updating of existing with new devices. The use of the max7219 also for i 12 led would have led to a complete remake of the existing circuitry including wiring and different software level treatment logic. As for the PIC I had a good experience with the PIC16f887 with which I produced and published about 30 projects on another electronics site: the 16f84 was more than enough as an engine for the old project: the clock was provided by its internal timers, the displays were managed in multiplex and i 12 led by the seconds. All with well 8 integrated. I have not thought of including the old scheme in the article: and the difference would have been clearer. As for the photos I will try to do better with what I have available, the schemes are copy / paste from cad applications on pc.

  2. Amilcare
    Amilcare says:

    Great job as usual, I didn't think you were so quick in the general draft but, then I realized that in this period of time available we have too much.
    A scheme was not very visible and I made sure that by clicking on it we can expand to the real measurements.


Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply