Hi Dave
--- In
ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@...>
wrote:
> the cycles are stretched by the interrupt service routine. It all
> seems to work quite well (as long as you used a scope to figure out
> the peculiarities of the i2cout command).
>
(first off... like John i must confess my scope-envy.... dang.... some
poor guys only have money and good looks but your scope translates
DATA!....... giant-geek-WOW!)
anyway...
> The burst data transfer is 4545 bytes/second. Now that I have a known
> data stream, I will see if I can get an AVR to correctly receive it.
> I'm not going to do anything until my LCD arrives and I can verify
> functionality of my code. I don't want to tear the development system
> down yet. The LCD is scheduled to arrive Monday.
>
Thanx for the I2C example (previous post) ... quirky but usuable , it
seems. Your examples were great though... made it very clear right
away for me.
Now... i read the posts back a ways and maybe i'm missing something...
but ... does the latest interface plan for the LCD hang it off a I2C buss?
i'm just curious.
In one of my job incarnations, i used an I2C buss and some PICs to
implement a portable conveyer belt system and i had to combine slave
PICs and memory devices running at different speeds. It was one of
those projects that worked robustly in theory and in testing but hung
in production only when i was on vacation!
If we use the I2C buss for an eventual memory channel do you expect
that we'll have to cope with the switching gears on the data rate
(SCL) line?
best,
-doc