Archive

Posts Tagged ‘8051’

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

SEAShell - my new software for accessing Serial EEPROMs

May 3rd, 2009

Some time last year, I got myself  a few serial EEPROMs. As the name suggests, they are accessed serially using some serial protocol(usually SPI or I2C). Hence these serial  EEPROMs don’t have a parallel data/address bus that we normally associate with EEPROMs in general. Here is a photo of my SPI based EEPROM, a 25AA256 from Microchip.

Microchip_25AA256_SPI_EEPROM

Memory is written to and read from the EEPROM using a serial protocol, which may be SPI or I2C. I already wrote a post back then when I interfaced a SPI based serial EEPROM with my arduino board. This time, I have interfaced that same SPI based serial EEPROM(the microchip 25AA256 to be precise) with my Dallas DS-5000T microcontroller development board which has a DS5000T in it and that is basically a variant of the classic 8051 core. But alas! the DS-5000T does not support hardware SPI!! Hardware SPI means that you don’t have to implement the SPI protocol in software and by just setting up a few registers you can simply copy the byte in the output register and the microcontroller takes care of encoding each bit within that byte and sending it across the SPI bus. So that means that I had more work to do. I had to in fact implement the SPI bus protocol in software, which is also known by the term bit-banging. But before we discuss further let us look at how an SPI bus looks like:

SPI bus schematic

SPI bus schematic

As you can see, SPI works on a master-slave paradigm. The master is the one which initiates all data transfers. There can be several slaves on the same bus and the master has to select the slave it wants to communicate with by asserting the chip select line(also called slave select or SS line) of that slave. Here, SCLK stands for slave clock. The master has to supply the slave with clock pulses for it to work. MOSI means master out-slave in and MISO means master in-slave out. The former is used to transmit data from the master to the slave and the latter is used to receive data from the slave into the master. SS means slave select as indicated earlier. The slave would be active only when SS is asserted by the master by pulling it low.(It is asserted by pulling it low since SS is active low, indicated by the bar on top).

For more details about SPI, you can take a look at this Wikipedia link. The way my system is designed is that my DS5000T board acts my master which issues the EEPROM read/write commands. And the EEPROM itself acts as a slave. In order to communicate with the DS5000T, I use the PC serial port. The software that runs on my DS5000T, I call SEAShell -  or Serial EEPROM Access Shell. It is a shell in the sense that it allows you to read/write a particular byte within the EEPROM. Although I have not created a file system of sorts within my EEPROM, but that is an eventual goal. It would be really cool to have my own seemFS or Serial EEPROM Embedded Micro File-System. (I must add, I continue to impress myself with my cool names ;-) ).

So here is how my SEAShell setup looks like:

SEAshell_Schematic_Diagram

Schematic setup for SEAShell.

The circuit schematic of the connections between the DS5000T and the serial EEPROM is also very simple for this setup. It is so simple that I am not going to bother creating another drawing for it. The connections between the DS5000T and the 8 pin 25AA256 Serial EEPROM can be done as follows:

a) Pin 2.0 of  DS5000T –> Pin 1 of 25AA256 (/CS)

b) Pin 2.1 of DS5000T –> Pin 2 of 25AA256 (SO)

c) Pin 2.2 of DS5000T –> Pin 3 of 25AA256(/WP)

d) Pin 2.3 of DS5000T –> Pin 7 of 25AA256(/HOLD)

e) Pin 2.4 of DS5000T –> Pin 6 of 25AA256(SCK)

f) Pin 2.5 of DS5000T –> Pin 5 of 25AA256(SI)

g) Pin 4 of 25AA256 should be grounded.

h) Pin 8 of 25AA256 should be raised to VCC, +5 volts DC.

For more details about the 25AA256, you may refer to its official datasheet here.

The connection between the PC and the DS5000T board, of course uses the MAX232A level shifter(since RS232 voltage levels are not TTL compatible) and a few 10 uf capacitors. That is a standard connection and a bit of google can tell you how to interface a MAX232 IC with a serial port.

On the software side, I have written two programs for this:

a) SEAShell.asm  : An assembly language program for the 8051 that is burned into my DS5000T development board (using my very own gnuProload software, of course!). The job of this program is to provide an interface to the human user through the PC serial port to allow the human user to interactively (or in an automated way), read/write data into the Serial EEPROM. The source code for SEAShell.asm can be found here.

b) SEAShellUtil.c : A C language program that utilizes the automated mode of SEAShell.asm and can be used to read/write big files into the serial EEPROM. This is needed because we cannot expect a human user to type in several thousand bytes in case he/she wants to write them into the EEPROM. The source code for SEAShellUtil.c can be found here.

So my complete SEAShell setup comprises of the following  components:

a) The DS5000T development board. Note that any 8051 compatible microcontroller can be used because my SEAShell.asm uses only standard 8051 assembly language, no fancy 8051 variant specific things are used. Here I used my DS5000T because it was convenient for me. I could also have used my Atmel AT89S52 here.

b) The software consisting of SEAShell.asm and SEAShellUtil.c

c) The Serial EEPROM itself, which is a 25AA256. You can use any serial EEPROM which is based upon SPI. But you would have to modify the page size within the SEAShell.asm and SEAShellUtil.c code. Also find out whether the EEPROM accepts data MSB first or LSB first and then modify SEAShell.asm accordingly.

d) A simple serial port communication software like minicom (on Linux) or HyperTerminal(on Windows). Note that, SEAShellUtil.c would run only on Linux. However, you may try out the interactive mode of SEAShell.asm on any OS that has a serial port communication software(like minicom or HyperTerminal).

Here is a photo showing my hardware setup for SEAShell:

SEAShell_hardware_setup

Photo showing hardware setup for SEAShell.

The EEPROM can be seen on the right hand side fitted in a small ZIF socket. My DS5000T board can be seen on the left. Still further to the left you can see the serial port DB9 connector which connects to the PC on the other end. Also above the serial port connector is the small USB connector that supplies power to the DS5000T development board directly from my PC.

And to clarify matters more, here is a screencast which shows SEAShell in action:

I hope you like this post about SEAShell. As usual, do write in your comments and suggestions. Your comments go a long way in inspiring me to create more such stuff ;-) !

Until next time, this is Seemanta saying good-bye to you all and take care!

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

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