Extreme geekness: Atmel AVR

If you think that the previous posts certified my geekness. you ain’t seen shit.
This time it involves some electrical wiring, soldering, low-level C/C++ programming and lots of smoking: my first Atmel AVR project. Yeah baby, that’s what I’m talkin’ about.

I’ve ran into this technology a couple of years ago when I coded a desktop application to communicate with such a device. So I wasn’t really involved in designing the parts external to that.
A couple of weeks ago I decided to try the real deal and implement something inside the AVR controller. Since I wanted to do something that is actually useful, I decided to make a digital thermometer.

At first I searched for some temperature sensors and it seems that there are many options in that area. So I had to do lots of digging to find out what would best fit for such solutions. In the end, I found out that there are both sensors and AVR controllers supporting the I²C two wire interface. No, I didn’t have a clue about what that was before starting this. In fact I admit learning lots of the electronics basics with this project.
Based on I²C is how I got to my winning candidates: ATmega168 and the DS1621 sensor.

Obviously, the other part of the problem was getting the information displayed. I was aware of the (most obvious) options in that area from the beginning: LED display or LCD display. I knew that using an LED display will either use up my controller pins or force me to use some shift register to expand the number of outputs. Since I wanted to keep it simple I opted for an LCD device. I bought one that is a lot larger than necessary, but only because I also plan to use it for some other purposes.

This is how the whole thing looked like in it’s final phase.

No, of course the board is not something I built. It’s the STK200 AVR starter kit from Kanda which is also an AVR programmer.
I know how the whole thing looks messy, but I didn’t spent time in making it compact since that was not the actual purpose.

The TWI and the LCD interfaces didn’t seem impossible to code since it’s pretty standard and well documented stuff. But since I am a complete rookie on this, I didn’t want to spend too many nights re-inventing the wheel when there are lots of libraries taking care of the low-level communication. So I used Peter Fleury’s LCD and I²C master libraries to handle the low-level protocols.

What I did have to clarify in detail though (even if it was fairly light) was the DS1621 specs where each of the commands and expected results are described. This however was the part that I found the most attractive and I believe that in general these are the parts that are worth the trouble: at a certain level of specs, you get the detailed description of what bits you have to wire and what you get back. No questions asked – (almost) always works as specified.

Once I’ve put all the pieces together and managed to display the actual temperature value, I had to somehow validate the output. Not that there is much to do about it. The thing is that if you managed to read some value from the sensor it usually means that you did your part of the deal and an error in the actual numerical value is (probably) not something you caused. This was however not the case since I have a multimeter that also does temperature measuring among other things.

Yeah, I know, my place is pretty warm. In the winter I sometimes overreact with the heating. Anyways, the DS1621 also has an 0.5 degree error (at least that’s the spec value), as for the multimeter’s sensor I have no idea. Bottom line is that is good enough so I’m a happy panda.

I didn’t spend the time to draw the schematics of this, but if you are really interested drop me a note and I can send you some summary of what exactly is to be done.

It took me a while to learn everything since this doesn’t quite work like “learning a new framework for the platform you know for years”. But it’s definitely interesting and it’s definitely a new level of geekness for me. Fuck yeah.