Hi Dave
thanks for your thorough reply. This forum has been very instructive
for me... a real bonus!
--- In
ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@...>
wrote:
>
> Here's the meandering flow of my thoughts ...
>
> I was designing the front panel and thought that I should bring the
> I2C out to the front panel in an extension connector. That way I
> could add some external I/O in the future.....
ah so!
that helps...
i see how this was an exploratory process... thx
> We could develop an I2C interface for the display. It's hard to think
> of any advantages for this.
i agree. This was behind my raising the questions in the first place
> The MIDI interface and protocol is
> proven. I2C is not, and there are lots of horror stories about I2C
> hanging.
"Proven" always gets a A+ in my class!
Sound's like you wouldn't need much urging to stick with a little
hijacked MIDI for an interface. So i'll keep my mouhy shut!
I don't have an iron in the LCD fire... but my opinion, as an
iterested spectator, is go with MIDI to talk to the LCD
> In fact, I haven't proven yet that I can send a single byte
> via I2C. The command seems to require an address so it can use the
> control as address, then it sends the address as data, so the data
> must be sent as the second byte. Or, you could specify a dummy
> control byte, it will send the address as the address, and data as the
> data.
that is what i remember from my little ride on the I2C buss...
> This is a lot to remember and will complicate the code.
-and how! ... plus .... if you have more than one type of device on
the buss with different clock speeds, the added headache of getting
that clock line synced is a pain and, in my case, it yielded some of
the messiest indecipherable error conditions i ever saw, (and i saw
370 assembler!!) Debugging was a nightmare
> Another
> advantage of interfacing the display via MIDI is that it is lightning
> quick. Sending a stream of characters to the display takes about 100
> uS of processing time. The I2C takes milliseconds.
>
!!!!!!!!!!!
(to quote Bill The Cat)
"thbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbt!!!!!!"
game over...
not worth it
> I would suggest we go with the proven MIDI design, get these modules
> built, and then begin to experiment with the I2C interface, either as
> two more I/O pins, or as an I2C bus. It might be interesting to pick
> up some of the Philips parts and see how well they work. If people
> decide later they'd like an I2C interface and it works reliably, then
> they can upgrade the LCD SUPPORT pcb. It's just a microcontroller,
> pins, and a regulator anyway.
>
sounds like a plan to me
i don't claim to have anything beyond a quick one-night stand with the
I2C buss but my experience was constrained by a tight schedule and
ungainly specs and parts forced on us by the contractor ... and it
went badly .... no surprise given those conditions
I2C might be very well-behaved if I2C-friendly components are
designed-in. But i strongly agree that it's a FUTURE expansion area
> > If we use the I2C bus for an eventual memory channel do you expect
> > that we'll have to cope with the switching gears on the data rate
> > (SCL) line?
>
> I'm not sure. That might be a better use for I2C. Any memory chips
> in mind?
I used EEPROMS PCF8582, they were already on the developers kit board.
They worked OK and didn't SEEM to be the cause of most of our failures
but the app had TINY data requirements. I'm sure we never moved more
than 1K (!!!)
> I might be able to play with one.
here is the development board we started with
http://www.triangledigital.com/man9092/ch2i2cspi.htm > I'm still thinking that once we get these
> units in our hands, we'll find some neat expansion opportunities.
>
perhaps we'll find out down the road a piece...
THANKS for all your interest and help
-doc