Archive

Posts Tagged ‘AT89S52’

gnuProload - an official introduction

November 15th, 2009

It has been quite some time (more than year) since I created my gnuProload software to program AT89S52 microcontrollers over Linux after reverse engineering an existing software which ran only on windows. But a few months ago, I enhanced that software to enable it to program even Dallas DS5000T microcontrollers.

If you want to know how gnuProload itself came into being, please read this post first. It is quite interesting, in case you are passionate about software in general and open source in particular. It tells the story of how I refused to walk into the trap of closed source software and how I was forced to reverse engineer a piece of software which ran only on windows (prior to my reverse engineering) ;-). In case you are wondering, the name of that post is derived from the critically acclaimed movie by Stanley Kubrick, Dr. Strangelove ;-).

Ok, let’s not digress. What happened was that sometime around August, this year, I was contacted by a fellow from Brazil who visits various universities giving lectures on embedded development on Linux etc. So he wanted to present my software in one of his talks. I was flattered, naturally :-). So I went ahead and created a set of slides for him to present it in his talks. In this post, I am just providing those same slides for you to go through. I hope these bunch of slides will give you more information rather than my original post about gnuProload.

So here it is, download and enjoy! Oh and by the way, you would need OpenOffice.org to view these slides. And if you are too lazy to download it, here is a PDF copy of it ;-).

Enjoy! As usual, don’t hesitate to put in your comments. Have a nice day!

~Seemanta

admin Embedded Hobbyist, My Creations, Tech , , ,

Embedded development platforms I own

April 21st, 2009

I started creating small embedded projects for fun about a year and a half back. Since then I have been hooked into it and today it takes the entirety of my free time. I started out with the humble 8051 and along the way have had the fortune of laying my eyes on the sexy Arduino, the powerful AVR and even the austere MSP430. A list of my embedded projects can be accessed here.

Here is a brief overview of the platforms that I own, as of this writing. By platform, I mean a hardware and software setup that allows me to write code in C or assembly, compile/assemble that code, ‘burn’ that binary into the target microcontroller and then possibly debug that ‘burned’ code.

1. AT89S52 development platform: This is the very first platform I ever owned. I purchased this from a company in Gujarat (a western province in India) called Sunrom. I am very satisfied with their product although a bit disappointed with the company for the lack of Linux support for its flashing software. I chose this as my first platform since I was most familiar with the architecture of the ATMEL AT89S52. AT89S52 has a 8-bit CISC architecture.

AT89S52 Development Platform

My AT89S52 Development Platform

Type: Purchased
Approximate cost2250 INR (2006)
On Chip Debug support: No
Linux support: No. But I created a ‘reverse-engineered’  linux port for its flashing software. Look here.
Cons: Lack of Linux support from Sunrom and on chip debug.
Pros: Availability of some very good development tools like SDCC, ASEM51 etc.
My Comments: Best system to start embedded development at a minimum cost. Good value for money.
Overall Rating: 4.0/5

2. MSP430 EZ430-RF2500 USB development tool: I went to attend the MSP430 day conducted by Texas Instruments all over the globe and they gave this USB development tool as a free sample. This tool can be programmed via the IAR IDE that runs on windows through the PC USB. For the unitiatiated, MSP430 is a range of ultra low power microcontrollers from Texas Instruments. It has a 16-bit RISC architecture. Frankly speaking, I have never created any big project with the MSP430. Main reason being that for it to work, a separate 3.7 V power supply is needed for this ultra low power beast. Normal 5 volts that we use usually for other micros would fry it. But the circuit components would still need 3.7 volts. Thus, a kind of isolation would be needed to make sure that the 5V does not flow into the MSP430. This is one reason, I have never tried making anything with this platform. It just lies in my shelf, gathering dust till the moment of its beckoning comes.

A plus point however is that Texas Instruments have also created DIP version of this microcontroller which helps the hobbiyst who is occasional not well equipped to perform SMD soldering.

MSP430 Development Platform

My MSP430 Development Platform

Type: Free Sample given by Texas Instruments for MSP430 day attendees.
Approximate cost: 40 USD, if I remember correctly.
On Chip Debug support: Yes
Linux support: GCC port of MSP430 seems to work in Linux, but have heard horror stories from people trying to make the USB tool which I have work in Linux. Problem is compounded by Texas Instruments not releasing the sources for the DLL needed to talk with the USB stick tool.
Cons: Lack of proper Linux support. IAR compiler does not work beyond 4k code size.
Pros: DIP version is hobbyist friendly and availability of MSP-GCC is a boon for those who cannot afford the IAR C compiler.
My Comments: Not recommended for newcomers.
Overall Rating: 2.5/5

3. Arduino: This tiny physical computing platform has taken the embedded hobby world by storm. There are thousands of websites all over the web with thousands of cool arduino projects. Arduino is easy to learn and easy to program. But while many people would recommend it for newcomers, I would really not do so. Arduino lets users program at a somewhat abstract level using its IDE which is based on processing. I firmly believe that someone should start with embedded development with the guts-first approach, i.e. learn the architecture from inside out and start programming in assembly language before graduating to high level languages like C or processing/wiring.

Arduino Development Platform

My Arduino Development Platform

Type: Purchased
Approximate cost: 35 USD, back in 2008.
On Chip Debug support: No
Linux support: Yes. Arduino works out of the box with my laptop which has Ubuntu Intrepid Ibex.
Cons: Lack of on chip debug really makes creating complex stuff a pain in the butt.
Pros: Lots of sites on the web to start development.
My Comments: Not recommended for newcomers. But would readily recommend for experienced developers.
Overall Rating: 4.0/5

4. AVR ATmega: This is my latest acquisition in the world of embedded platforms. I hand made this myself after hours of backbreaking soldering sessions. But every minute of those sessions was wortwhile when I was able to use plain old GDB to perform hardware debugging of my target board. And did I mention, it works in windows too ? You just need to install win-avr and avr studio :-) .

For the uninitiated, AVR is a RISC architecture from ATMEL and is wildly popular among hobbyists. The best thing about AVR is the availability of the completely free GNU tool chain for this arcthitecture which is why is it so much popular among students and hobbyists.

AVR ATMega Development Platform

My AVR ATMega Development Platform

Type: Hand made
Approximate cost: 300 INR or 7.5 USD (Believe me !!)
On Chip Debug support: Yes.
Linux support: Yes. AVR ATmega is fully supported on Linux through AVaRice and the AVR port of the GNU toolchain.
Cons: Might be a bit daunting for the absolute noob to make this with bare hands, but then it can be also purchased from ATMEL but be ready to shell out in the range of 100 USD.
Pros: Very hacker friendly, and GNU/Linux friendly too. Works on windows along with win-avr and avr studio.
My Comments: Excellent  for newcomers. Also a great way to learn basics of soldering and embedded development.
Overall Rating: 4.5/5

So this completes my review. And no prizes for guessing who the winner is!. It is no doubt the AVR platform that steals the show. And why not? With its powerful on chip debug, 100% free GNU tool chain, GDB compatible software, Windows plus Linux compatibility, AVR really does steal the show.

That is all the time I have this time. Happy embedding!!
With this thought, I now take your leave and would see you all in my next post!

regards,
Seemanta

admin Embedded Hobbyist , , , , , , ,

USB powered LCD table clock using a DS12887 RTC and AT89S52

October 31st, 2008

In pursuit of my embedded endeavors, I ended up making many ‘gifts’ for my friends. One day I decided it was high time I made something for myself for a change.

So I had this DS12887 RTC chip and a DS1820 temperature sensor lying around. Heck, I even had the code for my first major project, the AT89S52 powered digital clock/thermometer which I could re-use for this.

So at once I went to work and after a few hours’ soldering session, I was able to come up with the hardware for my clock. One difference from my original clock is that, I have used a 1-line LCD in this clock. So what that means is that the date and the time won’t appear together. So I had to give an extra button which when pressed, would show the date. Hmm! This meant some more code changes. The temperature sensor would of course, remain as it was. And yes, I did not take pains to implement the alarm functionality here as I did with my first clock.

After a hacking session, even the code was ready. But it took some time to adapt the existing code for my clock. Also due to the fact the DS1820 now was connected to a different set of IO pins of the AT89S52. So the code for the clock did not work out-of-the-box. However, the modifications were minor and I was soon done with it.

To power it, I decided to use USB (yeah! USB again!). This would be a good idea since, I planned to keep the clock on my office desk and my office desk computer is never turned off ;-) (And even if it is, the DS12887 RTC  would continue to maintain the time).

So here are some pictures of it:

The completed table clock. With my hand to give an idea of its size.

The completed table clock. With my hand to give an idea of its size.

Side view. Notice the card board I put at its back to support it.

Side view. Notice the card board I put at its back to support it.

Another snap of the clock.

Another snap of the clock.

Close up of the display.

Close up of the display.

Alas! I do not have a YouTube video of it this time ;-) But do post in your comments nonetheless. This clock now adorns my office desk!

admin Embedded Hobbyist, My Creations, Tech , , , , , ,

LED based 3-channel graphic equalizer for xmms

October 30th, 2008

Some time back, I had made a prototype for an LED based graphic equalizer for xmms. But that was just a prototype and was able to only handle the data from one channel.

This time around, I made a real (not a prototype)3 channel graphic equalizer. This is also a gift to one of my friends.

The Idea was the same : create an xmms plugin that sends the equalizer data via the PC serial port and program the AT89S52 to read the data from the PC serial port and dump it out through the 8-bit ports of the microcontroller to light up the LEDs to the music. The only difference was that in the prototype I had only a single column of LEDs but in this case I have 3 corresponding to each channel. That’s where the 3 IO ports of the AT89S52 came in handy. Oh, and yes, unlike the prototype, here I had to actually interface the MAX232 level shifters with my microcontroller. On the prototype, the MAX232 was already built into my AT89S52 development board.

Here is a picture I took of it:

The LED based 3-channel graphic equalizer for xmms.

The LED based 3-channel graphic equalizer for xmms.

Notice below, within the plastic connector case, is the RS232 connector connecting the board with my PC serial port. On top, the small and long white connector is the USB connector. As usual, this board is powered by the computer USB port, which is very convenient.

A video would be better in order to demonstrate this equalizer, I guess. So, here it is, a video which I uploaded into YouTube.

Comments/suggestions are invited.

admin Embedded Hobbyist, My Creations, Tech , , , , ,

LED based binary room temperature indicator

October 30th, 2008

The birthday of another of my friends was coming up and I decided to give him a ‘geeky’ gift. I saw that I had this DS1820 temperature sensor with me(I have been using a lot of DS1820 sensors lately ;-) ) and decided to create a ambient room temperature sensor for my friend.

Now, I did not want to get into the trouble of interfacing a complete LCD for this. So, I decided I would use 8 LEDs to show the temperature in binary format. with 8 LEDS, one would be green, to indicate the ‘binary’ point. And the remaining 7 would be used to indicate the temperature. The arrangement would be something like: 6 + 1 + 1. Or the first 6 red LEDs would show the integral part of the temperature, then comes the green ‘binary’ point(which would always remain green and lighted to distinguish it from the rest) and then finally 1 more red LED for showing the fractional part of the temperature, which can be either 0.0 or 0.5.

I decided to re-use the circuit board from my previous project, the POV toy for this. So after a few minutes of soldering to add the temperature sensor, it was ready. The code was also simple enough. Unfortunately, I do not have any photo of this. However, I did manage to take a video of it before I gifted it to my friend.

Here is the video, from YouTube:

As you can see, I have used USB to power the gadget. Cool, eh ? My friend sure liked it and needless to say, this gift has a tremendously high geek value ;-)

admin Embedded Hobbyist, My Creations, Tech , , , , ,

LED based POV toy for fun.

October 30th, 2008

POV stands for Persistence of Vision. What this basically means is that the human retina retains or ‘persists’ the image that forms on it for a certain time period. And if another image follows the first image within this time period, the eye ‘perceives’ this as a continuos change rather than two separate images. This critical time period is 1/16th of a second. This same priciple is employed in movie theaters across the world. Movie frames are shown at the rate of 24 frames per second, giving 1/24th of a second time for each frame, enough for the human eye to ’see’ things in ‘motion’.

The same principle is employed in this toy I have created. Basically it consist of rapidly flashing LEDs in a certain order so that when the toy is moved fast enough through the air, the flashing LEDs create the illusion of letters hovering in mid air.

For this project, I have used an ATMEL AT89S52 microcontroller which is based upon the 8052 core. I have used a column of 8 LEDs for creating the POV effect. The code for this is quite simple and so I have not bothered to post it here. You can post a comment if you want it.

Initially it was not working properly because the delay I had used between lighting up each column was about 40 milliseconds. Then after some searching on the net for similar POV toys led me to believe 10 milliseconds might be a good delay.

And sure enough, 10 milliseconds made it work. I guess that it is the optimum speed taking into consideration the speed of my moving arm. Below are some time progression snaps that I took when I was making it, followed by a YouTube video showing it in action.

Just when I started building this thing. Finished off soldering the main IC base and the oscillator crystal.

After soldering the LEDs.

A view of the back side. I was too lazy to print a PCB and so used a pre-drilled board to make it.

My battery pack of 4 AAA cells, giving about 6 Volts to power the toy.

A cellophane sheet that I have used to pack the underside of the board which has many protruding pins due to the through hole components on the top.

Here I have finished soldering the battery pack. All I need now is a rubber band to hold everything in place.

Oh, did I forget to mention the power button at the back side of the board. I have to keep this pressed when I wave the toy in the air.

This is how the final thing looks like ! :-)

And as mentioned above, here is the YouTube video of this POV toy:

admin Embedded Hobbyist, My Creations, Tech , , , ,

The Origins - III

October 29th, 2008

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:

DS12887 RTC /IRQ rough timing 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:

Monostable Multivibrator characteristics.

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:

Schematic diagram of using the 74HC123 to wake up the AT89S52.

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

The Origins - II

October 10th, 2008

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:

With just the ZIF socket plus the crystal  soldered over the pre-drilled PCB.

With just the ZIF socket plus the crystal soldered over the pre-drilled PCB.

Underside of the pcb after soldering the ZIF socket and the crystal.

Underside of the pcb after soldering the ZIF socket and the crystal.

ZIF socket and the DS12887 RTC. Notice the purple bus lines interfacing the micro with the RTC.

ZIF socket and the DS12887 RTC. Notice the purple bus lines interfacing the micro with the RTC.

With some more wiring. Control lines of the RTC can now be seen.

With some more wiring. Control lines of the RTC can now be seen.

With still more wiring. The pcb now has many more connections. Also you can see the micro being inserted into the ZIF socket.With some more wiring. Control lines of the RTC can now be seen.

With still more wiring. The pcb now has many more connections. Also you can see the micro being inserted into the ZIF socket.With some more wiring.

Connectors for the LCD(in my left hand) connected to the micro.

Connectors for the LCD(in my left hand) connected to the micro.

Construction of the front panel. The LCD is inserted into the rectangular slot carved out with a paper cutter.

Construction of the front panel. The LCD is inserted into the rectangular slot carved out with a paper cutter over the 'lid'.

Connecting power to see the final thing work for the first time.

Connecting a temporary power switch and the LCD contrast control before powering it up.

The completed clock along with the rectangular box. The temperature sensor is still not connected.

The completed clock along with the rectangular box. The temperature sensor is still not connected. Just about to power it on for the first time.

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’:

Front elevation of the clock.

Front elevation of the clock, complete with the buzzer, the temperature sensor, the tactile switches and the DIP interface. Pardon the time used for testing, which seems to be from Jan 2000.

Side view pf the clock.

Side view of the clock.

The other side view of the clock.

The 'other' side view of the clock. Notice the power switch at the back.

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