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!
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.
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
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:
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:
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!
A few months ago, I got myself two DS5000T microcontrollers. DS5000T is a popular product from Maxim semiconductors. It is (yet) another microcontroller based on the 8051 core. However, it is much advanced than plain 8051s or even the very popular AT89S52 microcontroller.
A very special word of thanks to Maxim who made the free samples of DS5000T available to me free of cost. In the market they cost about 50 USD each. Without their support I would not have been able to make this project. So thank you, Maxim !
So here is how a DS5000T looks like:
The DS5000T is considered advanced because it has an in built serial bootloader within it as well as its entire RAM contents are backed up even when you do not connect power. This makes it one of the most expensive 8051 based microcontrollers out there today. Because of the serial bootloader, we do not need any specialized programming hardware to burn the microcontroller. All we need to do is connect the microcontroller to a PC serial port and then follow a particular protocol and then send the hex file we wish to burn in it using that particular protocol. The bootloader accepts the data stream through the serial port and performs in-application programming of the device, thereby programming our hex file in it. Oh and did I mention it has an inbuilt real time clock as well ?
When I got these DS5000Ts, I at once set out to create a sort of development board for it. I was lucky to come across this link which gave the complete schematic for just such a thing. So I went ahead and created my board. Here is a snap of it:
On the left hand side, you can see two connectors. The bigger grey one is the RS232 or the serial port connector. The other end of it goes directly to my laptop. Well, not exactly since I do not have a serial port on my laptop. It actually connects to the output of my USB-to-Serial converter.
The smaller white one is the USB which powers the development board. On the top there is a small slider switch which is used to switch the board from programming mode to run mode and vice versa. All these details would be explained in the forthcoming video.
The big black IC that you see at the center is the DS5000T. It is somewhat bigger because of the fact that the DS5000T is completely based on NV RAM which is maintained by a small in built battery. This battery maintains the program as well as data contents for as long as 10 years. So technically, this microcontroller does not have any flash ROM or EEPROM. It contains NV RAM only, all of it. The NV RAM can be partitioned and a part of it can be configured to act as program memory and the other as data memory (8051 has a Harvard architecture). There is a total of 32KB available on the DS5000T and so I can configure the entire 32KB as program without any data or a part of the 32 Kb as program and the remaining part as data. I can also potentially misconfigure it to have 0 Kb program and 32 Kb data. But then the microcontroller would not work at all !
Now comes the biggest problem: I had my development board but no software to burn it. Well, there was this utility from Maxim itself to load hex files into it using the serial bootloader but then it was windows based and did not run on Linux. Being a Linux fanatic, I set out to create a Linux port for that loading software.
Just then it dawned upon me that I could use my earlier ‘gnuProload’ and enhance it so that it could talk to a DS5000T microcontroller as well. In case you have not read my earlier story on ‘gnuProload’ I suggest you do so, primarily because it is a very interesting read and secondly, it would some give you some background about gnuProload itself.
So after a weekend hacking session I was ready with my new version of gnuProload, which I preferred to call version 2.1. I made considerable enhancements in this version. First there was this ‘preferences’ dialog where the user could choose various settings like serial port device, baud rate, microcontroller type etc.. Secondly, I fixed some other bugs and made the operation much more smoother than the previous version. Thirdly, gnuProload settings were now entirely driven from a user config file. Various settings could be changed by changing the config file which was parsed once when gnuProload started up.
I made a screencast to show a demo of gnuProload. It is followed by the actual LED blinking demo wherein you can see how a small assembly program that I have written blinks an LED. Do post in your comments if you like the video (Clink on the HD button in Youtube if you want a larger, better quality version of the video)
So, that was about me and my DS5000T. Here’s hoping I would create more exciting stuff with my DS5000Ts !
P.S. If you wondering how I created my screencast video then it is actually a combination of audacity, record-my-desktop, gnome-sound-recorder, ffmpeg and Windows Movie Maker. Phew!
P.P.S. Due to problems with the sound quality I was getting with record-mydesktop, I had to record the sound separately and then add it into the main screencast video. This is where audacity and ffmpeg came in handy. Maybe I shall write a small how to do this as well !
A very happy new year to you all and I wish that the new year brings you more joy, happiness and prosperity.
Well, I got to celebrate my new year in a bit more special way than usual. A day late, but my new Dell Studio 14 laptop arrived on 2nd Jan. Actually it had arrived on 1st Jan itself but since that was a holiday and also since I had given my work address for delivery I was able to pick it up only on 2nd. I specifically wanted a small sleek laptop rather than a bulky one. Also I wanted it to look a bit different than the scores of inspirons that we have out everywhere. So I went for the Studio range which is a trade-off between the lower end inspirons and the high end XPSs.
And here is my configuration, not too fancy but decent enough:
- Intel Core 2 Duo(T5800), 2.00 Ghz, 800 FSB , 2 MB cache
- 3 GB DDR2 RAM
- 320 GB SATA HDD from Western Digital, model no. WD3200BEVT
- Integrated 2.0 MP Webcam with lateral array microphone
- Windows Vista Home Premium pre-installed (I installed Ubuntu Intrepid later on, of course)
- 1280×800 pixels TrueLife(tm) 14.1” WXGA screen.
- In built 8-in-1 SD card reader
- Dual Headphone jacks.
- Slot Load 8X DVD R/W Drive with dual layer write capabilities
- In built wireless network catcher that can be used to detect wireless networks without powering up the laptop.
- Travel remote that slides into the express card slot.
- Dell Wireless 1397 802.11b/g Half Mini Card
- Dell(TM) Wireless 370 Bluetooth Module
- In built 10/100/1000 Gigabit ethernet
- Pair of Creative Noise Isolation ear buds (EP630) supposedly free and which costs about 1300 INR in India.
- All OS, drivers and utilities DVDs. This is very important and not offered by any other laptop manufacturer that I know of.
I had ordered it on 19th Dec. My hands had already started to itch starting from that day, ending only on 2nd Jan. I am really happy with my laptop and here are some snaps that I took of it:
Also here is a YouTube video with me reviewing the various aspects of the it. I have tried to cover as much points as possible but in case there is some aspect you feel I have missed out, you can drop me a comment and I would be happy to help you.
And one more thing, the video is split into two parts since YouTube restricts all videos to 10 minutes.
So here you go, enjoy and do write in your comments:
My sojourn of the AVR world is proving to be a worthwhile venture. I must admit architecture-wise, things are a bit more complicated on the AVR than on the stock 8051. However that initial learning curve is easily offset by the ease of using C as a programming language. And not to mention the euphoric sensation of using the gnu tool chain over Linux to create my stuff.
I thought the best way would be to learn each subsystem of the AVR ATMega32 in turn. So this week, I chose the Timer/Counter sub-system. And so here I am demonstrating Pulse Width Modulation (PWM) on the AVR which makes use of the underlying timer/counter system to generate a PWM output on one of its port pins.
I am not going to describe PWM here, as Wikipedia has a very good article on the same. Also, if you find the Wikipedia article mathematically daunting, you may read this alternative article here.
This demo is relatively simple and does not involve hours of soldering or anything. If there was anything that I had to devote time to, then it was the official ATMega32 datasheet. But it needs a lot of guts to even try to understand the terse(but correct) language of these datasheets. Something like legal-speak, every word has its own technical meaning and cannot be substituted by another word even if they are synonyms in the ‘normal’ english sense. So I spent about half a day getting familiar with the ins and outs of the AVR and finally sometime late in the night, I came up with this contraption for the demo.
Here is a small video of my demo. Do leave in your comments afterwards. And don’t forget to stay tuned for more upcoming AVR stuff !
ATMega16 microcontroller: 160 Rupees.
Other Circuit components: 60 Rupees.
Solder wire: 15 Rupees.
AVR-GCC/AVR-GDB: Zero (if you exclude the broadband cost of downloading)
The sense of satisfaction when I was finally able to debug AVR code on chip using my new homemade JTAG, over Linux: PRICELESS !!
Yes !! I was finally able to finish setting up my AVR development environment and let me tell you, the night I did it, I was not able to sleep due to excitement !
In my previous post, I had mentioned as to how I was able to come up with a minimal setup consisting of a programmer board and a general purpose development board for the Atmel AVR series of microcontrollers. Well, now that setup is complete, with the addition of a fully functional JTAG board. What this JTAG board allows me, is to examine my code execute at runtime on the actual hardware without incurring any execution overheads. It allows me to change variables at will, put breakpoints wherever I wish and inspect how my embedded program behaves. All these greatly increase my productivity as a programmer.
When I was working with the AT89S52 (an 8052 variant from Atmel) I did not have the luxury of on chip JTAG debugging and as a result I would spend hours trying to solve bugs which were very simple and would have got caught if I had some kind of on chip debugger. Solving bugs then was mainly by ‘thinking’ or by lighting up LEDs (in stead of ‘printf()’ statements that we use in our ‘normal’ programs for debugging).
The circuit schematics for this JTAG board are from the aquaticus ROV project site. And as usual I managed to take some photographs of this new JTAG board while I was constructing it.
Starting the construction of my JTAG board. Here you can see the IC bases of the MAX232 and the ATMega16 along with the crystal soldered on the PCB.
With some more components soldered. Notice the USB connector for supplying power to the board directly from my PC USB and the JTAG connector.
The completed board. Notice the serial port connector at the bottom left corner and the actual ICs snapped onto the board finally. Also notice the 10 pin JTAG connecting ribbon to the right.
The completed JTAG board in action. To its left, you can see my prototyping board. And further to the left I have a red LED connected to the pin 0 of port B. I am blinking this LED through a very small C program. The program execution can be stepped through using gdb in my host system.
And finally, my new JTAG board in action on my Linux host. The program source code is at the bottom left corner of the screen and behind in the terminal, you can see AVARICE running in the background accepting connections from GDB. GDB, running within DDD GUI, is the top most window where you can clearly see a breakpoint being hit.
And also, here is a short video of by JTAG board in action:
Hope you liked this post. Stay tuned for more posts as I embark on a new journey of exploring the AVR microcontroller !
I am deeply attached to the 8051 microcontroller. In the truest sense, it has been my first love. It was the very first microcontroller which I was introduced to and then it was love at first sight. Even my undergraduate project work was based on the 8051 microcontroller. (Although sometime back I did purchase an Arduino board, which in fact has an Atmega16 microcontroller in it. But you know the thing with Arduino, the processing IDE abstracts out everything for you and I never really was HW-aware that I was working with an Atmega in the strictest sense. So in effect this particular project represents my true close encounter with the AVR series of microcontrollers).
So even when I started this hobby of creating embedded stuff for fun at home, it was my natural choice. I had my own development platform - both software and hardware for the 8051 and I enjoyed creating stuff using it. For an interesting story on how I got my development platform together for the 8051, take a look at this post.
Of late however, I decided it was time to see beyond the horizon of the 8051 microcontroller. So I decided to take upon a new beast. Two most popular choices were the PIC microcontroller and the Atmel AVR. After doing some research, I zeroed down on the AVR, chiefly for three reasons:
a) Most of the basic AVR micros had JTAG debugging. Till now the 8051 variant (AT89S52) I was using did not have any debugging facilities.
b) AVR packs in more MIPS for the same clock frequency compared to a PIC.
c) Freely downloadable and FULL version of the IDE for the AVR from its makers, Atmel. On the other hand the full version of the PIC development IDE from Microchip costs real money.
Besides, the AVR is much more advanced than the plain old 8051 which I am using currently. It has :
a) An in built 8 channel ADC. The AT89S52 has none.
b) An in built hardware SPI(Serial Perepheral Interface) and TWI(Two-Wire Interface). The AT89S52 has none.
c) An in built EEPROM to store program settings and persistent data. The AT89S52 has none.
d) An in built analog comparator. The AT89S52 has none.
e) An in built PWM generator to control DC motors and the like. The AT89S52 has none.
f) In built JTAG debugging, the MOST important factor for me. The AT89S52 has none.
g) The AVR RISC architecture has been designed ground up to be keeping in mind the C language. So very compact and high density code can be generated with the widely available avr-gcc C compiler. AT89S52, on the other hand was never designed to work with C, although there are compilers(both closed source and open source) which claim to generate efficient code.
Of course, there are about a zillion 8051 variants(SILABs, Analog Devices etc.) out there in the market today which boast of all these add on capabilities like ADC/SPI/USB connectivity etc. But I compared with only the plain vanilla 8051 (AT89S52) here, because that is the one I have used so far and also to level the playing field.
After an extensive research, I gathered the following list in order to realize a complete HW+SW development platform for my future AVR projects.
a) A programmer to ‘burn’ the hex files into my microcontroller : PonyProg(SW) + SIProg(HW).
b) A small ‘development’ board wherein I can prototype my creations before ‘deployment’ : ATMega32 Dev Board.
c) A compiler/assembler suite (possibly with an IDE) to create the software to run on the ATMega32.(AVRStudio, WinAVR)
d) A JTAG board to allow real time and in-system debugging of the microcontroller : Aquaticus JTAG Board .
It took about 2 days to create a) and b). As for c), I was able to very easily download them from the web. Currently, I am engaged in making d), the JTAG debugging board and once that is done, the setup for me development environment would be complete.
Oh, here are some pictures that I took yesterday of my first setup consisting of the programmer board and the development board. Please don’t mind the crudeness of my stuff. I am still to learn to make actual PCBs at home and so till then please adjust with the ugly-looking pre-drilled PCBs. I wrote a simple C program to blink an LED on and off to see if my setup was working properly.
My own programmer board based upon the modified SI prog circuit. Notice the serial port connectors at top left corner. I admit, I could have made it much more compact. Also notice the crude power lines coiled up like a snake. For this board, I am drawing the needed 5 volts from the PC SMPS power supply.
The small development board with the ATMega32 in place along with the 8Mhz crystal and the power terminals.
My first AVR LED blinky program. The Program was written in the AVR Studio IDE, compiled using avr-gcc and programmed using my new SIProg programmer board.
So that’s about my first tryst with the AVR microcontroller. I hope you enjoyed reading it as much I enjoyed writing it.
I also do hope that my dear old 8051, does not get jealous and get me wrong. She is still my first love. AVR and I are just friends!
A few months ago, I had got myself some samples of serial EEPROMs. In case you are wondering what they are, the name says it all. They are Serial EEPROMs(Serial Electrically Erasable Programmable Read Only Memory). By serial I mean is that they don’t have a parallel data or address bus that we normally associate with EEPROMS. Instead, they have a serial interface and protocol to read/write data onto them.
Two of the most popular serial protocols associated with serial EEPROMs are the SPI (standing for Serial Peripheral Interface) and the I2C (Or Inter-Integrated Circuit). ( The latter is by Philips and the former is by Motorola, in case you are curious).
Anyway, the Serial EEPROM I had was as SPI one, a 25AA256 from Microchip, to be precise. Before I dived headlong into anything, I wanted to first test my EEPROM chip. So what better way than to quickly connect it with my Arduino and check.
So that is what I did. And let me tell you that I cannot take credit for any of the code this time. I found the code completely in the Arduino website. But anyway, below is a photo I took of the system.
Readind/Writing an SPI Serial EEPROM using an Arduino. Ignore the red LEDs on the breadboard. They are from a previous project and have nothing to do with this particular demonstration.
The code for the above can be found here. I had to change a few parameters in the code for make it to work with my EEPROM. The EEPROM used in the link above had a page boudnary of 128 bytes, while the EEPROM which I had, had a page boundary of 64. So, I did a minor change to my program by replacing ‘128′ by ‘64′.
That’s it ! It worked ! I was able to read and write into my EEPROM and it was great fun! Now with the assurance that my EEPROM was ok, I would be safely able to create my own software to read/write my EPROM.
But that’s the topic of another post. My next post would be a demonstration of my very own software to read/write into the EEPROM. Something, which I have dubbed ‘SEAShell - Serial EEPROM Access Shell’. Some slick naming, eh ? Stay tuned!
).
(Clink on the HD button in Youtube if you want a larger, better quality version of the video)
Recent Comments