Well we are only half way through the month and I have been quite productive. It started with a battle to program the Atmega32 development board. The first programmer I brought was from the same company that supplied the board. However I failed to notice that the programmer was only supported in BASCOM and I certainly had no intention of writing my microcode using BASIC. This programmer is really a rip off costing 38 pounds and is not supported under Linux or winavr or AVR Studio. If you haven’t realised it yet, DO NOT BUY THIS PROGRAMMER!!!
I then happened to be in Farnells, buying some electrical components, when I noticed that they were chucking out a couple of Atmel AVRISPmkII programmers. These have the new 6 pin In Service Programming (ISP) connectors and my development board has the older style 10 pin ISP connector. Anyhow as it was a freebie and I’m not one to pass up on a free toy especially after spending a small fortune in Farnells over the past few weeks. So I took it home with a certain amount of pleasure at getting something useful for free.
After a quick look at the interface pin outs in the AVR Studio help pages I quickly knocked up a converter board to transform the 6 pin layout into a 10 pin one. The other four pins are basically linked to the ground from the 6 pin connector. I have written a newbies guide to programmers and you should read this if you want to make such a converter yourself. Having spent the best part of the morning researching and making the converter I was rather disappointed to find I could not program my development board with the programmer. I tried using AVR Studio (Atmel’s own integrated development tool) but it kept throwing an error when trying to connect to the ATmega32 chip. I had another attempt from winavr but it would not recognize the USB device. In frustration I tried from Linux using avrdude. This time it recognised the device, sort of, but kept throwing an error message. I was coming to the conclusion that there is no such thing as a free lunch and certainly not a free working programmer.
With tail between my legs I went back to the Active Robots site and purchased their parallel port programmer. The only computer I own with a parallel port is my trusty Linux machine. I thought I had better go with the parallel port programmer given my abject failure with the USB ones. This programmer also had the advantage of having a older style 10 pin programming cable to match the 10 pin programming port on the development board.When it arrive i plugged it in. Copied my hex file across to the Linux box and with some trepidation executed the avrdude programming command. Eurika!!! The bloody thing worked. I quickly hacked up a flashing LED program and compiled it on winavr before uploading the hex file into the development board and hey presto it worked. I can’t tell you the elation I felt when that LED first flashed. This was the culmination of hours of frustrating effort. Funnily enough though, my wife didn’t share the same level of jubilation as me to this marvelous leap of technological advance. At least there was some understanding from the #highaltitude IRC group.
With the sweet taste of success in my mouth I set out to find a USB programmer which would work with the rest of my computers all of whom lacked a parallel port. From Google I stumbled across the Olimex website. Now these guys make some nice programmers according to avr freaks so I quickly purchased an AVR ISP 500 which had a USB connection and both the 6 pin and 10 pin programming cables. This really had to work. The day came. I plugged it in and ahhh! The bloody thing wouldn’t work I tried everything and constantly faced the same error message again and again. Clutching at straws now and having read a review about the Atmel AVR Dragon working with avrdude. I bit the bullet and went and brought the Dragon from Farnells on the way home from work. I could have screamed when the bugger didn’t work. I now had to ask myself what the hell was I doing wrong.
I re-read all the programmer documentation and then the development board documentation… and there was the answer in black and white. The 10 pin header on the development board was wired completely the opposite way around to the Atmel standard. With in a few minutes I made up a crossover cable by attaching a 10 pin IDC connector the wrong way around on one end of the programming cable. I plug it all together and tested the Olimex programmer and of course it worked. The same with the Atmel AVRISPmkII and the Dragon. I now had four working programmers. A precautionary note, the Atmel USB drivers do not work with winavr. If you are going to use this as your development tool, and I would suggest that you do, then you have to use the USB drivers provided in the winavr install directory. Read the instructions or my programmers guide here to find out how to install them and where they are.
Having finally got my programmers to work it was time to decide on which development environment to use. Atmel offer a very good free C programming language IDE called AVR Studio this can be downloaded for free from the Atmel website. There is also a BASIC compiler called BASCOM which is probably better suited to programmers less competent in C. There is a fee for BASCOM which is enough to put you off, about fifty pounds if I remember correctly. Finnally the one closest to my heart, the open source AVR development platform winavr which uses the avr-gcc and a host of other small programs. After a quick play with the first and last development tools, skipping the BASCOM option, I settled for the winavr environment. This also allowed me to choose to develop under Linux as well as Windoze.
Having read and slightly digested the ATmega32 manual I discovered that the chip is quite capable of controlling the camera servo. After a quick bit of searching around the web I found a few examples of setting up PWM (pulse width modulation) on the ATmega32 and with a little coercion manage to implement it into the main Icarus control code. The whole camera control could now me managed from the AVR processor and out could go the Pololu servo controller saving a few grams of weight and far less programming and wiring.
Rebuilt the camera cradle using the previous experience to give a neater result.
Programming a one second real time clock. This might get a bit technical but I needed to do various things in second intervals. Now on a microprocessor a second is a very long time. In fact on the microprocessor I’m using for this project it has to count up to 16,000,000 for a second to parse. When you are writing programs its not very efficient to sit there counting CPU cycles. There is a timer which does this for you whilst you can be doing other things in your program. If you use the timer to count the cycles, you then need a way for your program to stop what it doing when the timer reaches the value you requested. This is called an interrupt. What ever your program is currently doing is stopped and
The Atmega32 is attached to an external 16MHz Oscillator.
This means the cpu clock tics 16,000,000 times per second. To put it another way the processor can execute 16 million instructions per second. The challenge comes when we want to measure second intervals.
The timers have a convenient feature which allows the number of oscillations to be divided by a pre scaler. These prescalers are 8,32,64,128,256,1024. Given that we are using an 8 bit timer we can only count up to 255 before the clock rolls over back to 0. As we want to count a relatively large number of cycles we use the highest prescaler of 1024. 16,000,000 / 1025 = 15625 timer counts per second.
The next task is to find values less than 255 ( the timer can’t count hight than this) which can be divided into 15625 to give a whole number. If we end up with a reminder we will not be measuring a second exactly. Once we have this divisor and the result it only a question of setting the timer to count to the divisor and counting the number of times this occurs until it reaches the result of the calculation. Phew !!! Lets look at the solution.
Dividing 15625 by 125 equals 125 a nice round number less than 255. It a shame the result is 125 as it causes confusion between the divider and result.
This means that we need to cycle around a counter up to 125, a 125 times, because 125 * 125 = 15625.
The counter counts by default from 0 to 255.
So we need to seed the counter to start at 125 cycles below 255.
255 – 125 = 130 = 0x82
The timer is seeded by setting the timer counter register to the start position each time the clock rolls over.
TCNT0 = 0x82
To test this I set up a second counter and counted the seconds over a 5 and a half hour period.
The results are as follows :-
Mon Aug 25 01:29:00 BST 2008 : Second counter = 1
Mon Aug 25 06:58:00 BST 2008 : Second counter = 19801
This shows a deviation of ~+1 second in 5 1/2 hours. Given that this was done by eye it may even be reasonable to assume the error is even less. However this will easily suffice for my needs. In future experiments I would consider attaching an external 32.768 kHz oscillator to timer2 to provide a more suitable real time clock.
Picture of current development
Moving into the last half of August …
I wrote a guide on how to modify a Canon Ixus 400 camera for remote control and put it on the UKHAS wiki a link to which is here.
In the process of writing a guide to selecting and using AVR programmers to prevent some one going through the nightmare experiences I went through.
Temperature sensors proved to be a little more interesting that I first thought. I search high and low for a sensor capable of recording temperatures close to minus 60 degrees. The first sensor I came across was the LM35 range of sensors from National Semiconductor. Being new to this electronics lark I found the cheapest one in the range and ordered up 10 of them given they were so cheap. It didn’t take long after their arrival to discover from the data sheet that the sensors only went down to 0 deg C. Lesson learnt, read the data sheet first.
The slightly more successful purchase of an LM35CAZ gave me the temperature range of -40 to 110 deg. C. The problem with this sensor was that it need to be supplied with +- voltage to allow it to report the negative temperatures. The sensor works by outputting a voltage of 10.0mV per degree Celsius. To measure the voltage the ADC converter on the ATmega32 chip would be used.
Then out of the blue (I can’t remember where) I came across the Dallas Semiconductor temperature sensors. These looked a whole lot more promising with temperature range from -55 .0 to 125.0 deg. C. I settled on the DS1821 sensor though the DS18S20 looked very interesting. In truth I brought both and was soon over whelmed by the extra programming required to manage the DS one wire protocol with multiple devices. I settled for three of the DS1821’s connected to 3 separate pins on the ATmega32.
Below is a some video of the temperature sensors in action.
<SORRY NEED TO PUT VIDEO IN HERE>
