Seemanta’s Blog

Welcome to the third and concluding part of ‘The Origins’ series of posts. In the last two posts I have described how I conceived my ‘gift’, and created a working prototype of the same for my friend. Also, I talked about how I met the challenges while going from the prototype stage to the final ‘product’ stage.

Here, in this concluding part, I would talk about some of the enhancements I did to the existing ‘gift’. Well, it happened after my friend’s Birthday. About 2 weeks later, she called up and told me that the clock has suddenly stopped working. I became worried. I was thinking that maybe the battery ran out. Of course, I was using the idle mode of the AT89S52 which saves power, but not as much as the power down mode.

The main difference between the idle mode and power down mode is that the oscillator keeps running in idle mode but not in power down mode. Without the oscillator, the current drawn from idle mode to power down mode drops from milliamperes to microamperes. Savings of three orders of magnitude !!

But there is a catch. Waking up the AT89S52 microcontroller from Idle mode is much simpler than the power down mode, as we shall soon see. Anyway, I at once went to my friend’s place and picked up the stopped clock. I brought it back home, after assuring my friend that I would return it within a week or so.

To my relief, I realized that the clock had not stopped because the batteries drained out. In fact, they did not drain out. Somehow they leaked and created a gooey mess inside the clock. Luckily it was not that much and I was able to clean it up within no time. And then when I put fresh batteries, the clock started to work again ! But it would utilize only the idle mode, resulting only in a meager power savings.

Now I had two options :

a) Play it safe and return the clock as it is, with a set of fresh and superior quality batteries. But this would still not improve the battery life of the clock.

b) Utilize the full power of power down mode and take the battery life of the clock to its maximum. But this would require me to perform a ’surgery’ of sorts by possibly interfacing another IC, an attempt which could screw up the entire gift, if not done carefully.

After a lot of thinking, I decided to go with plan b). My friend had repeatedly warned me not to damage her gift and she wanted it back as it was. But I decided to ignore her for the moment and go ahead with my plan. The worst part was that I had no backup plan in case I failed . But there are times in your life when you JUST need to take a certain amount of risk!

Now if you look at the DS12887 specs, the RTC chip can be configured to generate an interrupt each second. My AT89S52 micro would be tied up with this IRQ or interrupt request line and with each second ticking by, it would get an interrupt. The interrupt service routine or ISR of this interrupt would then do its job of updating the time on the LCD display. Fairly simple, eh ?

Here is a rough timing diagram of the RTC /IRQ characteristics:

As you can see, the RTC chip asserts the /IRQ line by pulling it low. This continues to be at low state as long as the register C of the RTC is not read. The moment it is read, the /IRQ line goes back to its default state of high. Notice the shape of the bold part of the above graph. For now, it would suffice to notice that is an ‘L-shaped’ curve.

Now, let us look at the timing characteristics of waking up the AT89S52 from power down mode.

As you can see here, the blue shaded region shows the region of power down. Notice how the AT89S52 does not wake up immediately when the interrupt line /INT0 asserted. But it has to be kept asserted for a minimum of 2 machine cycles. And then after that time, when the line is de-asserted does the AT89S52 microcontroller wake up and resumes operation in the normal mode. Notice the emboldened part of the above curve. Its can be described as a ‘U-shaped’ curve.

So you see in order to wake up from power down mode, the AT89S52 needs an ‘U-shaped’ curve. But the RTC is able to provide only an ‘L-shaped’ curve. But wait, you would argue, that from the first graph of the RTC /IRQ characteristics, when the register C of the RTC is read, the /IRQ line would get automatically de-asserted and hence the ‘U-shaped’ curve would be realized. Good point, but let me indicate that the register C of the RCT can be read by the AT89S52 only when it has woken up and is in the normal mode. So you see, this is a chicken-and-egg problem. Briefly, it can be stated as:

“To get a U-shaped curve you need to read RTC register C in normal mode and to be in normal mode, you again need a ‘U-shaped’ curve.”

Some vicious circle, eh? Unless of course there is a way to convert the ‘L-shaped’ curve into an ‘U-shaped’ curve. In such a case, I could connect such a device between the RTC and the AT89S52. Every time the RTC generates the ‘L-shaped’ curve, this ‘device’ would convert it into a ‘U-shaped’ curve. This would wake up the AT89S52 successfully from power down mode. But the question was, what is such a device that would perform the above requirement of converting a ‘L-shaped’ pulse to a ‘U-shaped’ one?

“Think, Seemanta, think!”, I said to myself, and viola! the answer came to me. I needed, what is called a ‘Monostable Multivibrator’ in this case. This multivibrator would have two states, one stable state at logic 1 and one quasi-stable state at logic 0. When triggered, it would go to the low state momentarily and then come back to the high state. Here is a diagram showing the functionality of a Monostable Multivibrator:

So, can you notice the ‘L-shaped’ input changing into a ‘U-shaped’ output above? That is the key and that is the reason, I have put parts of the curves of the RTC and the AT89S52 as bold, for better understanding. And so, I got myself a 74HC123(which is a Monostable Multivibrator) and interfaced it with between my RTC and my AT89S52. Here is a schematic diagram of the connection. I guess if you understood the above discussion, the below would not need any explanation:

Luckily, there was some space on my clock main board and I was able to squeeze in a 74HC123 in that space and after a ’surgical’ soldering session, I was able to complete the interfacing. Yippee! I was finally able to get power down mode in my clock and save power.

This time, with brand new batteries, the clock ran for more than 2 months. Once again, after about 2 and half months, my friend tells me that the clock has stopped working. Not only that, but it seems while setting the contrast, the top part of the contrast control potentiometer also came off. So I got back the clock for a second time in order to repair the faulty potentiometer. But I also had another idea of my own. I decided to get rid of the battery problem once and for all. I mean even with power down mode, I was able to extend the life to only about 2.5 months. This was the maximum I could achieve. But I thought, what if, I gave the clock another power source and make it a dual power operated gift? I rejected the idea of putting a step down transformer because of lack of space.

Then I got this idea of using the computer USB to power it. If you recall, the computer USB is capable of providing a steady 5 volts DC power, and can source about 100 milliamperes. So, I got my self a USB connector socket, and a DPDT switch, or Double-pole Double-Throw switch. Here is a schematic of how I used it:

A DPDT switch can be used to switch between two sets of positive and negative terminals. One set would come from the USB and the other set would come from the battery terminals. The above diagram would make it clear.

So, there I was after successfully enhancing the power consumption of the clock, I was able to give it two power sources - USB and battery. I told my friend to connect the clock to the USB in case batteries are drained out at least till a fresh set of batteries are purchased. So that was it. I felt a huge relief after two major successful ’surgeries’ of the clock. Unfortunately, I do not have any pictures to show of the final thing. But I will see if I can ask my friend to take some pictures and send them across.

So this was the concluding part of the ‘The Origins’ series. I hope you enjoyed reading it as much as I enjoyed writing it. I apologize for the sheer length of the posts, but with a project of such magnitude, this came as something unavoidable to me.

Stay tuned for my next post, where I will post more of my technical creations.

P.S. All images used in this post were created using OpenOffice.org diag software and are copyrighted.

admin Embedded Hobbyist, My Creations, Tech 8051, 8052, AT89S52, Digital Alarm Clock/Thermometer, Embedded Hobbyist

In my last post (which was the first one in this series), you read why and how I undertook my first major embedded hobby project. You also read about how I struggled to make various components of my digital clock/thermometer and come up with a prototype.

In this part, of this on going series, I would tell you how I finally managed to get ready the final ‘gift’, and on time too !

So, to begin with, I had this prototype with me, which had every functionality it was supposed to have. It was able to show the time, it was able to show the temperature. That’s not all, it was able to allow the user to set the time, alarm. And everything was configurable too. The user could control whether to show the time only, temperature only, both or even neither. The user could turn ON or OFF even the daily and hourly alarms independently. I was very proud to have completed my prototype.

But a major task still lay ahead. My prototype was still a prototype, far from being a presentable gift. So in my quest to complete everything before the deadline, I started to plan the ‘fabrication’ of my gift. The first thing I did was to buy a plastic case to house the clock. I got myself a transparent plastic box, about 2.5 x 4.5 x 2 inches. The ‘box’ was transparent plastic and the lid was of a bluish tint.

My plan was to use the lid to contain all the controls like LCD contrast control, LCD backlight , time/alarm setting tactile switches etc as a ‘front panel’ of sorts. The power switch would be behind the clock and the box would also contain the batteries to power the clock. I carefully chose a pre-drilled PCB to act as the ‘motherboard’ for my clock circuitry, so that it was able to fit within the box. Imagine later on after soldering all the circuit components, if I realized that the pcb would not fit inside the box. So selecting the proper size for the pcb was very important.

Also, I knew from the start that I would have to use a ZIF socket into my final product also. There were two reasons for this: first was that, I knew that I might have to do some reprogramming and debugging in case the integration is not smooth. There was a high chance that the prototype code would need some modifications to successfully deploy it in the ‘field’. Secondly, I wanted to keep the option of giving software upgrades to my friend open. Not that with a normal IC socket these things would become impossible, but ZIF sockets have a zero risk of damaging the IC, while with normal sockets, the risk of damaging an IC while extracting is quite high, even with a IC extractor tool.

So with that, started the many hour long, back breaking soldering sessions. I did manage to take photographs in between such soldering sessions to show a time progression of the ‘motherboard’ acquiring its final form.

Here are a few such photos:

The way I envisioned the whole thing was to divide the clock into 3 layers:

Layer 0 (bottom) : Batteries and power switch
Layer 1 (middle) : The main board with all the circuitry and interconnections between individual components namely the micro, RTC and the LCD.
Layer 3 (top) : The user interface with all the controls like contrast control, back light, DIP interface and the LCD etc.

Each layer had to be connected to the next layer only at predefined points and these had to be snap-on contact points. So that if desired, each layer could be disassembled separately and taken out of the box. This also facilitated replacing batteries and repairing the clock in case of any problems.

This feat took a lot of patience and clever soldering to achieve. Basically, I brought out every external connection to layers above and below to the edges of the main board. And used snap on connectors there. That needed numerous drawings and re-drawings, not to mention extra care so that I do not mess up the connections. That’s where color coding my connecting wires came in handy.

So there I was, just a few more days were left for my friend’s birthday and I was happy to see her gift take shape. With trembling hands, I connected the batteries and switched it on! And voila! Nothing happened! The time came up on the LCD, alright, but thereafter it did not change with every passing second. This was really weird. When I removed the micro from the ZIF socket and put it into my prototype, it worked like magic !

I tried burning the code again with my programmer but to no avail. It simply would not run on the final product. Initially, I suspected the wiring in the motherboard, but I checked that too. But even that was fine. This problem was very mysterious. I tried all possible tricks over the next 2 days, but none worked. Now it was just about 4 days to my friends birthday, and I started to get scared.

Then it was a moment of pure epiphany when I realized that I had not connected my temperature sensor to my final product. The reason for that was that I just wanted to see the time come up properly before proceeding with connecting the temperature sensor. Kind of incremental approach. I realized that the proprietary 1-Wire protocol used certain primitives like sending a reset pulse of a fixed duration and then ‘wait’ for a response from the DS1820 IC. That’s how the entire protocol was defined. It consisted of passing data and waiting for some response. So the problem was clear now. Due to the absence of the DS1820 temperature sensor, my micro waited infinitely for the response, thereby freezing it. (I had not used the watchdog timer, to keep matters simple, although my micro was equipped with one).

I heaved a sigh of relief and then got myself together to integrate the temperature sensor onto the motherboard. Once that was done, I was able to see the time AND temperature both on the LCD. Now I needed to test the alarm, with the real buzzer. Note that, till now in my prototype, I had only used a small LED to substitute(read The Origins - I) and I had mentioned that it almost led to undoing of the alarm system of the clock. Here is how. The current was enough to light up the LED. But not enough to drive the buzzer to an audible beep. So all I could make out was a extremely feeble ‘beep’ when the alarm sounded off. This was 3 days before my friend’s birthday.

The next day, I immediately went to our local electronics market(about 18 km from my residence ) and purchased a general purpose NPN transistor. The idea was to use the feeble current to make use of the transistor as a switch to direct the 5 volts power supply(meant for powering the entire clock circuitry) into the buzzer. And it worked! I got a loud and audible alarm beep! There it was ! I was finally able to make everything work.

But even now, the front panel was only completed and still I had to assemble everything. This I did the night before my friend’s birthday and thankfully, I was able to finish it, right on the day of her Birthday.

Here are some pictures of the final ‘gift’:

In my next part of this ongoing series, I would explain certain technical aspects of this clock. especially how I improved its battery life by adding a 74HC121 IC. I also made the clock run on dual power, i.e. on batteries as well as on USB power drawn from any computer.So stay tuned for the next and concluding part of ‘The Origins’. Here is a YouTube video of the clock, which I shot after completing it:

admin Embedded Hobbyist, My Creations, Tech 8051, 8052, AT89S52, Digital Alarm Clock/Thermometer, Embedded Hobbyist