ComputerVoltageSources

--- In ComputerVoltageSources@yahoogroups.com, "drmabuce" <drmabuce@.
..> wrote:
> 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 bus?
> i'm just curious.

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.

One possibility is to interface the SpeakJet to these pins.  I did 
this in my PSIM with a serial out and buffer half full status in.  
However, this interface is poor for three reasons.  The serial out is 
a software implementation so interrupts have to be off.  The rate is 
<< MIDI so you will loose messages.  Also the buffer half full flag 
doesn't allow you to control pauses very well.  They all have to be 
programmed in the data stream. The SpeakJet requires a lot of bytes to 
communicate with.

I bought a TTS256 which should allow me to communicate with the 
SpeakJet via 'text'.  The other issues still remain.

Not knowing anything about I2C, I looked at the Philips page.  While 
they have a lot of devices, I didn't find anything particularly 
interesting except some 8 bit in/out chips.  They do have LCD 
controllers but they are for direct control of the actual panels.

The ATMEGA8 AVR which I used for my keyboard project has I2C in 
hardware.  It should be a fairly easy job to interface this to the 
hardware serial and make an I2C to RS232 to TTS256 to SpeakJet 
interface.  I may just do this to upgrade my PSIM.

I started thinking about whether the display should be interfaced via 
I2C.  It certainly is a possibility.  However, I don't trust any of 
BasicMicro's documentation and the forums indicate a lot of issues 
with I2C so I decided to experiment a bit with it.

So ... now to the CVS.

We could keep the display interface the same via MIDI.

We could develop an I2C interface for the display.  It's hard to think 
of any advantages for this.  The MIDI interface and protocol is 
proven.  I2C is not, and there are lots of horror stories about I2C 
hanging.  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.  This is a lot to remember and will complicate the code. 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.

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.

> In one of my job incarnations, i used an I2C bus 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!

Yet another horror story.
 
> 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 might be able to play with one.  I'm not exactly sure how 
well polled input works.  I'm still thinking that once we get these 
units in our hands, we'll find some neat expansion opportunities.

Dave