I2C is a neat "little" protocol. The inverted commas are an indication of the magnitude of the technical documents that define this protocol. They are large and for the most part actually quite readable and comprehensible. I'll let the interested reader refer to the wikipedia page on this topic which is highly recommended as a jumping-off point for further research.
Anyway, my recent delvings into the interesting field of I2C (pronounced "eye squared see") were necessary because of my latest hacking project "pushprop".
Elsewhere on my blog I've posted a more detailed description of what pushprop is, but suffice it to say for this posting that pushprop is basically the software half of a much more significant project - a project that has no name as of yet.
The hardware half of this project is to be a "shield" PCB for the increasingly ubiquitous Raspberry Pi computer system.
Without wanting to reveal details which might end up changing at a later date, I'll only say that the shield PCB will feature at least 1 P8X32A microcontroller, but I'm aiming for "several" of them. I'm also hoping to have a configurable distributed system clock. Which is to say, all of the Propeller chips on the board will (optionally) share a variable frequency main clock source. Have a look at the datasheet for Maxim DS1077 and you'll have something to drool over :).
Incidentally, this DS1077 chip is controlled by the I2C protocol but that's not why I'm talking about I2C. I'm talking about I2C because I have had some fun and games with implementing the I2C protocol myself in PASM code on the Propeller chip.
I2C, for the uninitiated is a standardised way for two or more chips to communicate over a pair of wires. The wires are labelled SCL (Serial CLock) and SDA (Serial DAta). The simplest way to use I2C is to let your microcontroller be the Master device and the chip you're talking to be the Slave. That's what I was doing, my Slave device was the Propeller's own EEPROM on pins P28 and P29.
I wanted to make my Propeller read the contents of it's own EEPROM and sending all 32Kb of data to the PC over a 57600 baud serial port. Since the Propeller has no hardware (eg. in-silicon) implementation of I2C, I was forced to bitbang the protocol myself in PASM. A task that I had a lot of fun with.
The details of this little sub-project aren't terribly interesting apart from one thing... How your handle the SDA line. Since there can be many (over a hundred) devices on the bus at once, there must be a way to prevent multiple devices trying to pull the line down or pull it up simultaneously (which would cause a direct short circuit and releasing the smoke).
I2C solves this by never letting any device deliberately push SDA high! Instead, Pull-up resistors are used to allow the SDA line to drift "casually" towards VCC as soon as EVERY device on the bus has ceased to pull the line down to VSS. Any device can drag the SDA line low to GND, as part of the comms process.
I2C is absolutely fascinating and I urge you all to have a quick look at the protocol, or even have a go at implementing the Master device yourself. I2C isn't complicated to implement once you understand it's workings. I managed to get my Propeller to read my EEPROM without any glitches over I2C and the code required to do so is rather small in it's memory footprint.
Why am I reading the EEPROM? Because I want the pushprop software (C code running on the RasPi) to be able to non-invasively read the contents of the EEPROM remotely. Between the PC and the EEPROM is the Propeller chip so I have to write a bit of PASM that I can program into the Prop chip (without affecting the EEPROM) that allows the data from the EEPROM to be relayed back to the PC over the same serial port channel!
Later features of pushprop will make this rather esoteric feature obsolete (as I plan to directly drive the Propeller's I2C bus from the RasPi IO pins so I'll be able to talk directly betwen the PC and each EEPROM on the bus). But it's nice to have other options too :)
Anyway, my recent delvings into the interesting field of I2C (pronounced "eye squared see") were necessary because of my latest hacking project "pushprop".
Elsewhere on my blog I've posted a more detailed description of what pushprop is, but suffice it to say for this posting that pushprop is basically the software half of a much more significant project - a project that has no name as of yet.
The hardware half of this project is to be a "shield" PCB for the increasingly ubiquitous Raspberry Pi computer system.
Without wanting to reveal details which might end up changing at a later date, I'll only say that the shield PCB will feature at least 1 P8X32A microcontroller, but I'm aiming for "several" of them. I'm also hoping to have a configurable distributed system clock. Which is to say, all of the Propeller chips on the board will (optionally) share a variable frequency main clock source. Have a look at the datasheet for Maxim DS1077 and you'll have something to drool over :).
Incidentally, this DS1077 chip is controlled by the I2C protocol but that's not why I'm talking about I2C. I'm talking about I2C because I have had some fun and games with implementing the I2C protocol myself in PASM code on the Propeller chip.
I2C, for the uninitiated is a standardised way for two or more chips to communicate over a pair of wires. The wires are labelled SCL (Serial CLock) and SDA (Serial DAta). The simplest way to use I2C is to let your microcontroller be the Master device and the chip you're talking to be the Slave. That's what I was doing, my Slave device was the Propeller's own EEPROM on pins P28 and P29.
I wanted to make my Propeller read the contents of it's own EEPROM and sending all 32Kb of data to the PC over a 57600 baud serial port. Since the Propeller has no hardware (eg. in-silicon) implementation of I2C, I was forced to bitbang the protocol myself in PASM. A task that I had a lot of fun with.
The details of this little sub-project aren't terribly interesting apart from one thing... How your handle the SDA line. Since there can be many (over a hundred) devices on the bus at once, there must be a way to prevent multiple devices trying to pull the line down or pull it up simultaneously (which would cause a direct short circuit and releasing the smoke).
I2C solves this by never letting any device deliberately push SDA high! Instead, Pull-up resistors are used to allow the SDA line to drift "casually" towards VCC as soon as EVERY device on the bus has ceased to pull the line down to VSS. Any device can drag the SDA line low to GND, as part of the comms process.
I2C is absolutely fascinating and I urge you all to have a quick look at the protocol, or even have a go at implementing the Master device yourself. I2C isn't complicated to implement once you understand it's workings. I managed to get my Propeller to read my EEPROM without any glitches over I2C and the code required to do so is rather small in it's memory footprint.
Why am I reading the EEPROM? Because I want the pushprop software (C code running on the RasPi) to be able to non-invasively read the contents of the EEPROM remotely. Between the PC and the EEPROM is the Propeller chip so I have to write a bit of PASM that I can program into the Prop chip (without affecting the EEPROM) that allows the data from the EEPROM to be relayed back to the PC over the same serial port channel!
Later features of pushprop will make this rather esoteric feature obsolete (as I plan to directly drive the Propeller's I2C bus from the RasPi IO pins so I'll be able to talk directly betwen the PC and each EEPROM on the bus). But it's nice to have other options too :)