One thing I've come to realise throughout this project is that describing the build is reasonably uneventful - it's really just a repetition of place components and do a load of soldering. It makes for much less of an interesting read.
Certainly on a personal level I have found the troubleshooting process to be much more interesting - discovering an issue and trying to figure out how to fix it in as few changes or additional components as possible. Some of my boards are quite dense with little room for more logic, especially if a fix needed a large block of logic to implement. And as you've seen the "rats nest" of wiring on the rear of the boards actually poses quite an accessibility problem getting to solder joints, even with the reasonably fine 1.5mm soldering iron tip that I have used.
Luckily, however, problems requiring fixes have been reasonably uncommon, with maybe a transistor or two added here and there. And I've been quite thankful for that.
So having said all of that, I'll skip most of the details of the build of this board, and fast forward to the troubleshooting stages.
Like in previous builds involving ripple counters, I built each stage one by one so that I could test that they all worked before burying them under a lot of wires. And like all of the counter stages that came before, I didn't encounter any significant issues. In fact, if I encountered anything that could be considered significant, it was generally that a floating reset input would generally cause that stage to not function until I pulled it low (otherwise it was in constant reset). One of the disadvantages of using MOSFETs over other types of transistors is that their gates are capacitive, which means that when they are floating their state is somewhat non-deterministic - that is to say they could be high, low, or somewhere "kind of in between" - so pulling up or down is essential.
This is often very easy to fix. Using a pair of tweezers I can create a short between the gate pin and the negative power supply rail, and that was usually enough to sort out that gate long enough that I was able to test the functionality of the n-bit counter that had been built up. Some gates were a little more stubborn than others and needed a tiny piece of wire soldered in to hold the pin low. The primary reason that was an issue at all was due to the way I built up the counter logic. I would typically start with the counter stages and then move to the surrounding reset logic, so to begin with the reset inputs of each counter stage were not connected.
By far the most significant issue that I came across with this build was to do with the preset input which was supposed to ensure that when the month counter resets (i.e. when the calendar moves between months) the day of month counter would reset to 1 instead of 0 (since there is no day 0 in any calendar I know of). As you'd see from the design log for the calendar module, I did breadboard the circuitry to determine whether or not using a small capacitor at the appropriate point in the circuit would hold the preset input low for a short period of time which would enable a corresponding reset input to assert itself high prior to the preset input going high. This sequence is required in order for the preset to work, and certainly it worked on my breadboard. Hence I designed in what was to be the original design of the circuit. But it turned out that this still didn't work quite right once the circuit had been fully built up, and it only became apparent when I showed off my clock to some friends and this little gremlin surfaced. So it was back to the drawing board to find a solution.
I started by scoping out the various reset signals to find out what was happening, and unfortunately I forgot to capture an image of the signals on my scope, but the basic problem that I discovered was that the reset signal that is generated by the large block of reset circuitry below the units counter would be so brief that combined with the capacitor loading the preset input I think it just never actually had a chance to go high. I believe I did notice the tiniest of bumps in the trace for the preset input where that signal had started to rise, but by that stage the counters had reset, and the resulting reset signal was no longer asserted, so the preset signal was dragged back down to ground.
My solution involved adding in some more gates to form another SR latch, one input would come from the original inverter that was connected to the preset input, with the capacitor removed. The other input would come from the AC_CLK/ signal to reset the SR latch once the preset input was no longer going to be needed. The capacitor was then moved down to the appropriate output of the SR latch and then fed in to the preset input. I did also breadboard this solution to ensure I wasn't going to be wasting more time, and that also proved to work, only this time in-circuit.
I really do wish I captured a screenshot from my scope so I could visualise all of what I just said above, but you'll just have to believe me (and I hope it all made sense). And yes, you're seeing the finished clock there, before I've gotten around to writing any blog material for the calendar decoder module. Oops? :-)
So while the day of month counter was now resetting correctly upon the month rolling over, the next problem I found was when pressing the reset button at the back of the clock, the day of month would reset to 0 instead of 1. I had a solution to this pretty much already worked out, and it used a typical combination of logic that I have used elsewhere to "suppress" a certain signal when another signal is asserted. This involves inverting the AC_CLK/ signal and feeding it in to a dual input NOR gate, with the other input of that NOR gate connected to MCLR. When ever MCLR happens to be asserted, the AC_CLK/ signal will not propagate to the SR latch to reset it, and thus the preset signal will be able to have some effect.
The result looks a bit more complicated than the original, and I guess it is, but hopefully is easy enough to follow:
I was fairly confident this would now work properly, so I went straight ahead and built it up - a total of 7 transistors making 4 new gates (146-149). And afterwards when testing it out, it all worked perfectly. Day of month was now resetting correctly upon month rollover and when the reset button was pressed.
Calendar module done! Here are the results:
Since there were some modifications to the circuitry which occurred after the design log was published, I've uploaded revised schematics along with this blog. They are in the same location as before.
Certainly on a personal level I have found the troubleshooting process to be much more interesting - discovering an issue and trying to figure out how to fix it in as few changes or additional components as possible. Some of my boards are quite dense with little room for more logic, especially if a fix needed a large block of logic to implement. And as you've seen the "rats nest" of wiring on the rear of the boards actually poses quite an accessibility problem getting to solder joints, even with the reasonably fine 1.5mm soldering iron tip that I have used.
Luckily, however, problems requiring fixes have been reasonably uncommon, with maybe a transistor or two added here and there. And I've been quite thankful for that.
So having said all of that, I'll skip most of the details of the build of this board, and fast forward to the troubleshooting stages.
Like in previous builds involving ripple counters, I built each stage one by one so that I could test that they all worked before burying them under a lot of wires. And like all of the counter stages that came before, I didn't encounter any significant issues. In fact, if I encountered anything that could be considered significant, it was generally that a floating reset input would generally cause that stage to not function until I pulled it low (otherwise it was in constant reset). One of the disadvantages of using MOSFETs over other types of transistors is that their gates are capacitive, which means that when they are floating their state is somewhat non-deterministic - that is to say they could be high, low, or somewhere "kind of in between" - so pulling up or down is essential.
This is often very easy to fix. Using a pair of tweezers I can create a short between the gate pin and the negative power supply rail, and that was usually enough to sort out that gate long enough that I was able to test the functionality of the n-bit counter that had been built up. Some gates were a little more stubborn than others and needed a tiny piece of wire soldered in to hold the pin low. The primary reason that was an issue at all was due to the way I built up the counter logic. I would typically start with the counter stages and then move to the surrounding reset logic, so to begin with the reset inputs of each counter stage were not connected.
By far the most significant issue that I came across with this build was to do with the preset input which was supposed to ensure that when the month counter resets (i.e. when the calendar moves between months) the day of month counter would reset to 1 instead of 0 (since there is no day 0 in any calendar I know of). As you'd see from the design log for the calendar module, I did breadboard the circuitry to determine whether or not using a small capacitor at the appropriate point in the circuit would hold the preset input low for a short period of time which would enable a corresponding reset input to assert itself high prior to the preset input going high. This sequence is required in order for the preset to work, and certainly it worked on my breadboard. Hence I designed in what was to be the original design of the circuit. But it turned out that this still didn't work quite right once the circuit had been fully built up, and it only became apparent when I showed off my clock to some friends and this little gremlin surfaced. So it was back to the drawing board to find a solution.
I started by scoping out the various reset signals to find out what was happening, and unfortunately I forgot to capture an image of the signals on my scope, but the basic problem that I discovered was that the reset signal that is generated by the large block of reset circuitry below the units counter would be so brief that combined with the capacitor loading the preset input I think it just never actually had a chance to go high. I believe I did notice the tiniest of bumps in the trace for the preset input where that signal had started to rise, but by that stage the counters had reset, and the resulting reset signal was no longer asserted, so the preset signal was dragged back down to ground.
My solution involved adding in some more gates to form another SR latch, one input would come from the original inverter that was connected to the preset input, with the capacitor removed. The other input would come from the AC_CLK/ signal to reset the SR latch once the preset input was no longer going to be needed. The capacitor was then moved down to the appropriate output of the SR latch and then fed in to the preset input. I did also breadboard this solution to ensure I wasn't going to be wasting more time, and that also proved to work, only this time in-circuit.
I really do wish I captured a screenshot from my scope so I could visualise all of what I just said above, but you'll just have to believe me (and I hope it all made sense). And yes, you're seeing the finished clock there, before I've gotten around to writing any blog material for the calendar decoder module. Oops? :-)
So while the day of month counter was now resetting correctly upon the month rolling over, the next problem I found was when pressing the reset button at the back of the clock, the day of month would reset to 0 instead of 1. I had a solution to this pretty much already worked out, and it used a typical combination of logic that I have used elsewhere to "suppress" a certain signal when another signal is asserted. This involves inverting the AC_CLK/ signal and feeding it in to a dual input NOR gate, with the other input of that NOR gate connected to MCLR. When ever MCLR happens to be asserted, the AC_CLK/ signal will not propagate to the SR latch to reset it, and thus the preset signal will be able to have some effect.
The result looks a bit more complicated than the original, and I guess it is, but hopefully is easy enough to follow:
|
|
I was fairly confident this would now work properly, so I went straight ahead and built it up - a total of 7 transistors making 4 new gates (146-149). And afterwards when testing it out, it all worked perfectly. Day of month was now resetting correctly upon month rollover and when the reset button was pressed.
Calendar module done! Here are the results:
Since there were some modifications to the circuitry which occurred after the design log was published, I've uploaded revised schematics along with this blog. They are in the same location as before.
- GitHub repo
- calendar-module.sch EAGLE schematic file
- calendar-module.pdf
