--- 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