ATtiny Adventure -- I2C on ATtiny 84/85

Originally posted on


UPDATE: Added info on making SPI programming jig (makes life a lot easier).

UPDATE: Added ATtiny 84 info (though, the post is meant for the ATtiny 85).

I’ve been non-traditional microcontroller curious for a bit. Then, I had to put a Digi-Key order together for some real cheap stupid stuff (some SOT-23 N-Channels for the LiPo charger circuit) and I thought, “What the hell, let’s order some ATTiny 85s.” Being cheap like I am, I ordered SMD:

I then ran over to OSHPark and made a little breakout for it:

This brought the price for one ATTiny 85 board to $1.53 each. This is great, since the ATTiny 85 has an internal oscillator up to 8mhz, allowing it run without any passives.

I was pretty excited the day they came in. I soldered them together, put some headers on them, and tossed them into a bread board. I switched over to Goggle and searched how to program these little guys. The first article I hit was the one I eventually used, I just warn you, dear reader, read careful not to miss the bit about ignoring the error. Personally, like the dumb-arse I am, programmed my first little ATtiny 85 a hundred times thinking it wasn’t working before I caught the caveat in the instructable:

“It should give the following error twice: avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny 85”

This error means you programmed it successfully.

But you all probably got that.

The easiest way to get going with I2C with the ATtiny 85 is using the TinyWireS and TinyWireM libraries for Arduino.

  • TinyWireS (this is Rambo’s library, he updated the original with onRequest, onReceive functions)
  • TinyWireM

To get the ATtiny 84 to work you’ll need to add support:

They were developed to be comparable to the Wire library for Arduino. To install them, just unzip them and place them in your Arduino libraries folder (e.g., C:\Program Files\Arduino\libraries).

(Here’s the pinoutfor the ATtiny 84)

The I2C connections are pretty straight forward:

  • Arduino SDA <— 4.7k Resistor Tied to 5v —-> ATtiny 85 – PB0
  • Arduino SCL <— 4.7k Resistor Tied to 5v —-> ATtiny 85 – PB3
  • ATtiny 85 – PB1 <— 330 Resistor —- LED —- > GND

Below is code meant to demonstrate the purpose of this projects. It sets the ATtiny 85 as an I2C slave. It receives data over the I2C line, parses it into an integer, then writes this value of the integer to pin 1 (PB1).

// the 7-bit address (remember to change this when adapting this example)
#define I2C_SLAVE_ADDRESS 0x4

// Get this from
#include <TinyWireS.h>

// The default buffer size, Can't recall the scope of defines right now
#define TWI_RX_BUFFER_SIZE ( 16 )

//Character variable used to echo data back.
char chrSendData;

//Variables used in getting and parsing data.
char rxChrData; //Receives the data.
char rxString[12];  //Varbiable for holding one string of data.
int rxIndex = 0; //Used to index rxString.

//Integer for holding the pwm value received from master.
int pwmValA;

void requestEvent(){  

//Handles receiving i2c data.
void receiveEvent(uint8_t howMany)
    if (TinyWireS.available()){  
      if (howMany < 1)
      {   // Sanity-check
      if (howMany > TWI_RX_BUFFER_SIZE)
      {   // Also insane number

      if (!howMany)
      {   // This write was only to set the buffer for next read
      {   //Gets i2c data.
          rxChrData = TinyWireS.receive();
          //Places the characters in an array one at a time.
          rxString[rxIndex] = char(rxChrData);
          //Increment the data array.
          //If a stop character is read, parse the char array and convert it to a single integer.  
          if (rxChrData == ':'){
              //This is a low memory form of parsing the char array into an intger
              pwmValA = int(100*rxString[2]+10*rxString[3]+rxString[4]);
              //Prints the parsed value.
              //Writes the parsed value to pin 1 (PB1).
              analogWrite(1, pwmValA);
              //Resets the char array index.
              rxIndex = 0;  

void setup()
    pinMode(1, OUTPUT); // OC1A, also The only HW-PWM -pin supported by the tiny core analogWrite
    //Sets up the onReceive function (what we do if we get stuff).
    //Sets up the onRequest function (what we do if asked to send something).

void loop()
//Detects a stop sending command.

//Puts the data we got into a variable to send back for error checking.
chrSendData = char(rxChrData);


I’ve also included the code I used on my Arduino Mega, which was setup as the master.

Your setup should not look like this :P

I’ve got several ideas I’d like to attempt with this setup. But, it is somewhat silly. The I2C reduces the ATtiny 85 to four pins. But one of those is the reset pin (PB5), so really, only 3 usable pins.

Before I started working with the Tiny I was lurking in the shoutbox and oversaw Protowrx chatting about making an ATtiny into a serially controlled motor driver. So, I set to it. I had chosen I2C because I wanted to make a setup like the DRV8830 (Spark fun has a breakout). Of course, like the numbskull I am I didn’t do the simple math before sinking hours into interfacing with a chip.

Most H-Bridge ICs require three pins a motor. Two digital pins for direction and one for PWM. Even cheaping out and using one PWM pin for both motors, that’s still five. _And…_the ATtiny 85 has 8 pins. 1 x Power, 1 x Ground, 2 x I2C line, which leaves us with….4 pins. Oh wait! One of those is the reset pin and cannot be used without losing the ability to program it without an AVR programmer (which I have, but what a pain in the ass). So! In short, there are 3 usable pins after interfacing with the ATtiny. I’d have done myself a favor if I had remembered an 80s classic.

Still, I’ve I got it in my head to attempt doing something like this: 2 Pin HBridge control. Only, tying the PWM line together. Not having much luck right now (only spent about 20 minutes, wanted to get this typed up before I forgot crap).

Another idea is to use a Software Serial to send one way communication through the serial line. But it doesn’t make much sense, since 4 pins aren’t much better than 3, given my intentions.

Ok. In conclusion, I’m not sure why I did this. It really doesn’t make much sense, other than the adventure. I’m sure it’s one of those things I work out now and I won’t find a use until much later. The real killer is thinking about how you can buy a full Arduino Pro Mini on the eBay for $3.45. A little more than double the cost of an ATtiny 85 but triple the pins and utility. Eh!

Making a ATtiny Jig:

I hate breadboarding. Let me admit that. Mainly, it is having wires everywhere, my little dyslexic brain can’t keep up. And when I first started working with the ATtiny uCs I found it to be a pain to have to move my little ATtiny’s between my full circuit and the SPI programming circuit. So, I thought, “Why not make a SMD programming pad and jig interface?”

Well, here is the crude son-of-a-bitch:

It’s nothing fancy, but it is a time saver.

I put both the interface pads and the jig in my Eagle library.



Ladvien’s Eagle Library

Here is my ATtiny 84 with the pads and the Jig PCB:

Jig ($.60

ATtiny 84 PCB ($1.85)

These are the pogo pins I used:

P100-B1 – 1.36mm diameter

It was not too hard to put together, I set it up something like this. Then, it is all about added flux to where the pins meet the PCB and soldering like you would usual header pins.

And here it is in action. It surprised the hell out of me, worked exactly like I wanted it.

I’m sure I’ll eventually add some stabilizer bars between the two-PCBs and maybe a guide pin to prevent me from pressing the pins in the wrong holes :(

Still, it is MUCH easier than pulling it from the breadboard and moving it to a new circuit. Makes me happy.

A Friendly Overlord

Originally posted on

I’ve been working on this one in silence for a bit.

Awhile back it hit me, before I started growing my Overlord project in complexity I wanted to refine it for ease-of-use. Therefore, I began translating my Overlord project into a Python module I could build off.

A Friendly Overlord

I figure, this would make it easier for anyone to use. This includes myself, I’ve not forgotten my identity as a hack, nor will anyone who pops the hood on this module :)

But, at its core, there are few essential inputs:

  1. Color to track.
  2. Compass reading.

So, I spent some time translating the code into a callable module. This experiment was mainly for my own use, yet I knew it’d grow healthier if I had LMR’s feedback, elder or noob.

When I started I actually planned (gasp) out what would make this code more user friendly. I didn’t think long; the two things that have taken the most time tweaking to get this code useful are:

  1. Adjusting the compass heading.
  2. Selecting the color to track.

To address the first issue, I developed a “auto-compass calibration function.”

def mapper(x, in_min, in_max, out_min, out_max):
    #This will map numbers onto others.
    return ((x-in_min)*(out_max -out_min)/(in_max - in_min) + out_min)

def compass(headingDegrees):
    global compassInitFlag
    global initialRawHeading
    global intRx

    #This sets the first compass reading to our 0*.
    if compassInitFlag == False:
       initialRawHeading = headingDegrees
       compassInitFlag = True
       print initialRawHeading

    #This is the function that actually maps offsets the compass reading.
    global intialRawHeading
    if headingDegrees >= initialRawHeading:
        adjHeading = mapper(headingDegrees, initialRawHeading, 360, 0, (360-initialRawHeading))
    elif headingDegrees <= initialRawHeading:
        adjHeading = mapper(headingDegrees, 0, (initialRawHeading-1),(360-initialRawHeading), 360)

    #Here, our compass reading is loaded into intRx
    intRx = adjHeading

Basically, this function takes the very first compass reading and adjusts all other readings. So, all you have to do is put your robot in the direction you want it to consider “North,” start your code, and this function will convert all other readings.

The second issue took me a little longer to deal with: easy color selection. In short, I rewrote most of the color detection parts of the code to take advantage of the OpenCV’s CamShift algorithm. This function is more resilient to lighting changes or other near color objects, but it is also more CPU intensive. At some point, I’ll probably go back and write a variant that sticks with the old largest-target-color-mass method.

Ok, what this means for the user? When the code starts you select the color you’d like by left-click and dragging a selection box over an area. The mean color of the selected area will be tracked and this will also start the rest of the code.

What does Friendly Overlord give you?

Well, a lot. And when I finish writing the damn thing, more than alot.

Here’s a list, and only one bit is untrue.

  1. It tracks your robot, providing its x and y relative to your webcam.
  2. It will provide a target coordinates, which I’ll later make addressable in case someone wants to do something cool, rather than have their robot drive around and catch virtual dots. Lame.
  3. It will take the compass reading you provide, translate it to a heading relative to the camera, then, it will send commands to your robot telling it to turn until it is in alignment, then move towards the target.
  4. Make you a cuppa (CP, DanM, did I use that right?)
  5. It will allow you to tweak pretty much any element of the code (e.g., overlord.targetProximity = 5)

What does it not do?

  1. Take care of your serial data. You’re own your on, bud.
  2. Write your robot uC code for you.
  3. Provide you with your robot’s heading (though, when I delve into two-color detection this could be done with two-dots on your bot. But really, it’d be easier and near cheaper to get an HMC5883L).

Alright, so let’s talk code. How little code does it take to use it?

import serial
from time import sleep
import threading
import overlord

#Initialize Overlord variables.

#Open COM port to tether the bot.
ser = serial.Serial('COM34', 9600)

def OpenCV():
    #Execute the Overlord.

def rx():
        # Read the newest output from the Arduino
        if ser.readline() != "":
            rx = ser.readline()
            rx = rx[:3]
            rx = rx.strip()
            rx = rx.replace(".", "")
            #Here, you pass Overlord your raw compass data.  

def motorTimer():
        #This is for threading out the motor timer.  Allowing for control
        #over the motor burst duration.  There has to be both, something to write and
        #the motors can't be busy.
        if overlord.tranx_ready == True and overlord.motorBusy == False:
            ser.flushOutput() #Clear the buffer?
            overlord.motorBusy = True
            overlord.tranx_ready = False
        if overlord.motorBusy == True:
            sleep(.2) #Sets the motor burst duration.
            sleep(.3) #Sets time inbetween motor bursts.
            overlord.motorBusy = False

#Threads OpenCV stuff.
OpenCV = threading.Thread(target=OpenCV)

#Threads the serial functions.
rx = threading.Thread(target=rx)

#Threads the motor functions.
motorTimer = threading.Thread(target=motorTimer)

This is fully functional code. You’ll notice that really, only about 10 lines get Friendly Overlord going, the rest handle Serial functions and motor firing. Be warned, the motor firing code will change, since it is written how I like it right now, eventually will be designed to be as flexible as possible.


  1. overlord.dVariables() #Sets the Friendly Overlord variables.
  2. overlord.otracker() # The module’s heart. Handles color tracking, angle calculation, etc.
  3. overlord.compass(x) # You pass it an compass heading as an integer in degrees (0-360) and it does the rest.
  4. overlord.tranx_ready # Simple flag to indicate last bit of serial data has be sent.
  5. overlord.tranx # Variable that contains the serial command to be sent to the robot.
  6. overlord.motorBusy # Flag to indicate if the robot is still in the middle of a movement.

That’s about it. In the module? 399 lines of code, or so. Still relatively small for a program but not something I want to wade through without a damned good reason.

Ok. So, where am I going with this?

Hell if I know. I want to make it as versatile as possible. Eventually, I’d like to be tracking nth number of robots. I envision a swarm of Yahmez’ Baby bots flying all over the place, Friendly Overlord tracking them, and communicating with them via IR.

But in the more immediate future, I’d like to make every variable tweakable. Especially, variables useful to others. For instance, the overlord.tX and overlord.tY are currently controlled by the module. They are simply randomized numbers. But, I’ll make a flag in the next two days to take control of them from your own code. You can decide where you’d like your robot to go. Whether it be to your mouse pointer (overlord.targetY = overlord.mouseY) or a complex set of way-points to lead him through a maze. Really, I’ll probably code around the feedback I get.

Now, some obligatory stuff.

Here are some of the current variables addressable from your program:

#How close to does the robot need to be? Greater is less accurate.
#Defaults to 5.
overlord.targetProximity = 5

#Defaults to 0, 0
overlord.guiX = 440
overlord.guiY = 320

#Random target constraint; so target doesn't get placed too far from center.
#Defaults to 1, 640, 1, 480
overlord.targetLeftLimit = 20
overlord.targetRightLimit = 400
overlord.targetBottomLimit = 320
overlord.targetTopLimit = 20

But I’d like to make every variable needed by the user available.

Ok. So, here’s what I need: Someone to use it and provide feedback. I’m getting too close to it and bleary of thought.

I’ve thought of doing a few things to get some feedback:

  1. Setup a challenge (I’ve got some surplus).
  2. Offer to mail one person a month a setup (two Bluetooth PCBs and a cheap webcam).

Any suggestions?

I think I’ll make a walkthrough video pretty soon (kinda miss making stupid videos) but I’m a little worn out right now.