so this week was a tough one. I started out trying to finish up the camera project from last week. Problem is the camera is a complicated piece of machinery. I give kudos to any one who can get one running. so i will give Moritz kudos for getting it running. one of the tricky things with the camera is that you have to talk to it and tell it what you want it to do. The camera won't even start until you tell it to. So the first thing we had to do was talk to it. The camera uses i2c protocol for communication, also know as twi (two wire interface).
twi is a master-slave communication technique. The master controls a clock and sends data based on that clock cycle. the slave devices can get the clock rate and then determine the frequency of data. with this configuration you can have as many slave devices as you want. each slave has a address, so that they can be addressed individually by the master. pretty cool huh? I thought it was too until i tried to implement it. There are a lot of specifics that, if not handled exactly right, will keep it from working.
so what does all of this have to do with output?
I needed a way to make sure that i was communi-cating with the camera properly. so i looked around and remember that i had done a project last year using blinkM led's. blinkm's are made by thingm . They are RGB LED's that have a attiny45 that controls the color and pattern of the led. and, you guessed it, they use i2c to communicate.
we were able to use the blinkm's to debug our twi code and make it work with the camera. and in the process i thought it would be really cool to make my own blinkm's, or as i like to call them joshm's. which makes a lot of sense if you plan to use quite a few of them because they are pretty pricey ( buy them here ).
there were a few steps in the process:
create a master controller back to top
i used a atmega168 to create a master controller for my experiment. I chose it because i could program it to communicate serial to the computer and twi to the slave devices. by doing this, i could program the master and disconnect the programmer and use serial to tell the master what to tell the slave devices. I created a board that had all pin outs for the atmeag168 so that i could get as much use out of the board as possible. having a multi-purpose atmega168, i know, will come in handy.
create a test slave back to top
similar to the master controller, i wanted a flexible slave controller. i used an attiny45 for this. it is almost perfect for the job with one small exception. the red of the rgb is tied to the reset pin for programming. the means that it gets a little fussy when trying to make sure everything works. also i wish i had included a seperated set of pin-outs from the twi communication so that i won't have had to unplug and replug all the wires between test. despite a few hold ups i was able to get it working. now all that is left is to write a really robust program that gives the chip a lot of functality.
debug back to top
i wanted to talk a little bit about the issues i had with getting the communication to work. twi is one of those things that is probably very simple to those who have been in this field a while and once you get a library that does twi communication you never have to worry about it again. which puts novices in a really wierd predicament where it is hard to find an example of twi that can be adapted to work for your purposes. also the master and slave are 2 totally different things. the master is the one setting a clock and initiating communication, where the slave is listening for a clock and communication. in the end i was able to find several examples and stitch them together into a working prototype.
create joshm back to top
after getting a working test version i decided to create a few prototypes to try communicating with multiple slaves at once. i am still working on finalizing these tests, but there are so pictures of my board designs.