AVR-Chat

Has anyone done an I2C interface to a complex device, like a graphic
display, or buffered serial I/O interface?  I am about to start designing
one and wanted any words of wisdom/architectural approaches other have to
offer before I start.

Because my doodad is both stand alone and a peripheral, I would like to make
all the primitives (graphic stuff mostly) available as I2C commands.  Is
this a reasonable thing to do?


Cheers!
-----------
Larry Barello
www.barello.net

Hi Larry,

On 2/15/06, Larry Barello <yahoo@barello.net> wrote:
> Has anyone done an I2C interface to a complex device, like a graphic
> display, or buffered serial I/O interface?  I am about to start designing
> one and wanted any words of wisdom/architectural approaches other have to
> offer before I start.

I just did a bootloader. Not quite as complicated as what you're
looking at. It allows reading and writing of RAM, EEPROM and flash.

One thing to consider is to decide whether you want your commands to
be self contained (stateless) or stateful. Some OS's (like linux) will
issue an i2c command multiple times if it detects a failure. As these
things go, it's possible for one side to think an error exists while
the other side thinks that things are fine.

Using stateless commands means that you don't really care if the
command is issued multiple times, it will do the exact same thing each
time.

For example:

stateful: Use a register (in i2c parlance) to set an address. Read
from another location and have the address auto-increment. This puts a
bit less traffic on the i2c bus, but if one of your reads is reissued
then the auto-increment will give the wrong data.

stateless: Pass the address that you want to read with the read
request. Now if your command happens to get issued multiple times, you
get the same data back each time.

> Because my doodad is both stand alone and a peripheral, I would like to make
> all the primitives (graphic stuff mostly) available as I2C commands.  Is
> this a reasonable thing to do?

I don't see why not.

I'd recommend taking a look at the SMBus spec as well. it defines some
"standard" protocols for transferring data back and forth. I use the
Block Process Call alot.

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

Yes, I saw that the Gumstix has an i2c boot-loader and was planning on
incorporating that into my doodad at some point.  I would consider a
boot-loader a relatively complex device.

Stateless is kind of hard to do when reading or writing a buffer.  The rest
of the commands can be stateless.  I suppose one can "write the buffer" then
issue the command to execute it.  That command could be a NOP if the buffer
had not been written, or, has been operated on and flushed...  Then each
transaction would be stateless.

I was looking at the SMBUS a bit, and will heed your advice to look at it
more carefully.  Thanks for the pointer.


-----------
Larry Barello
www.barello.net


| -----Original Message-----
| From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
| Of Dave Hylands
| Sent: Wednesday, February 15, 2006 9:30 PM
| To: AVR-Chat@yahoogroups.com
| Subject: Re: [AVR-Chat] I2C
| 
| Hi Larry,
| 
| On 2/15/06, Larry Barello <yahoo@barello.net> wrote:
| > Has anyone done an I2C interface to a complex device, like a graphic
| > display, or buffered serial I/O interface?  I am about to start
| designing
| > one and wanted any words of wisdom/architectural approaches other have
| to
| > offer before I start.
| 
| I just did a bootloader. Not quite as complicated as what you're
| looking at. It allows reading and writing of RAM, EEPROM and flash.
| 
| One thing to consider is to decide whether you want your commands to
| be self contained (stateless) or stateful. Some OS's (like linux) will
| issue an i2c command multiple times if it detects a failure. As these
| things go, it's possible for one side to think an error exists while
| the other side thinks that things are fine.
| 
| Using stateless commands means that you don't really care if the
| command is issued multiple times, it will do the exact same thing each
| time.
| 
| For example:
| 
| stateful: Use a register (in i2c parlance) to set an address. Read
| from another location and have the address auto-increment. This puts a
| bit less traffic on the i2c bus, but if one of your reads is reissued
| then the auto-increment will give the wrong data.
| 
| stateless: Pass the address that you want to read with the read
| request. Now if your command happens to get issued multiple times, you
| get the same data back each time.
| 
| > Because my doodad is both stand alone and a peripheral, I would like to
| make
| > all the primitives (graphic stuff mostly) available as I2C commands.  Is
| > this a reasonable thing to do?
| 
| I don't see why not.
| 
| I'd recommend taking a look at the SMBus spec as well. it defines some
| "standard" protocols for transferring data back and forth. I use the
| Block Process Call alot.
| 
| --
| Dave Hylands
| Vancouver, BC, Canada
| http://www.DaveHylands.com/
| 
| 
| 
| Yahoo! Groups Links
| 
| 
| 
| 
|