ComputerVoltageSources

I've been thinking about my speakjet and whether I want to change the
interface. It is interfaced using P6 and P7 for serial output and
buffer half full. The issue with using serial output is that it is
implemented in software so interrupts have to be disabled. It's a
real pain to program and use with timer interrupts or MIDI.

I bought the TTS256 chip to put in front of it so I can send words,
not allophones. I got to thinking about the I2C bus and whether this
would make a better interface. I started looking at the Atmel AVR
capability and found some ap notes to implement the I2C bus in
software, and a combination software and hardware. The next processor
up is the ATMEGA8 which implements a full I2C interface in hardware.
I've used this chip before and it is available in a narrow 28 pin DIP.
With 1K bytes of RAM, I wouldn't even have to implement flagging.

I called BasicMicro to find out about their I2C implementation. The
Hitachi H8 has an I2C interface implemented in hardware.
Unfortunately BasicMicro implemented the command in software.
However, since it is synchronous, it will work fine with interrupts.

This may be a path in the future to design some I2C to 'whatever' in
the Atmel parts. Philips has over 150 I2C parts and one that looked
interesting to me was an I2C to 8 bit parallel port. Another
alternative might be to try and use the H8 hardware via basic but this
may be more complex than it is worth. By the time one does this, it
may be no more performance than the software implementation.

Anyone out there experienced in I2C interfacing?

Dave

>
> Anyone out there experienced in I2C interfacing?
>

Me. I2C is commonly used for temperature monitoring and other low level
controls in storage and server products.

John Loffink
The Microtonal Synthesis Web Site
http://www.microtonal-synthesis.com
The Wavemakers Synthesizer Web Site
http://www.wavemakers-synth.com

Can you use the software I2C command with the hardware I2C port pins?
Will they fight with each other?

> I called BasicMicro to find out about their I2C implementation. The
> Hitachi H8 has an I2C interface implemented in hardware.
> Unfortunately BasicMicro implemented the command in software.
> However, since it is synchronous, it will work fine with interrupts.
>
>

Software mode just bit bangs GPIOs, so there should be no contention with
the I2C HW since the 3664 pins won't be configured for it.

John Loffink
The Microtonal Synthesis Web Site
http://www.microtonal-synthesis.com
The Wavemakers Synthesizer Web Site
http://www.wavemakers-synth.com

> -----Original Message-----
> From: ComputerVoltageSources@yahoogroups.com
> [mailto:ComputerVoltageSources@yahoogroups.com] On Behalf Of Grant Richter
> Sent: Tuesday, March 28, 2006 12:21 AM
> To: ComputerVoltageSources@yahoogroups.com
> Subject: [ComputerVoltageSources] Re: I2C bus for expansion
>
> Can you use the software I2C command with the hardware I2C port pins?
> Will they fight with each other?
>
> > I called BasicMicro to find out about their I2C implementation. The
> > Hitachi H8 has an I2C interface implemented in hardware.
> > Unfortunately BasicMicro implemented the command in software.
> > However, since it is synchronous, it will work fine with interrupts.
> >
> >

Thanks to John's help I was able to decode the I2C from the AtomPro24.
The forum has several comments about people having lots of issues
with the I2COut command. One stated that you must use an address
byte. I monitored the I2C on my PSIM with my scope (one of the brand
new Tektronix DPO4000's with serial data/I2C analysis capability).
Since I don't have a receiver, I could only look at the first byte
(since there is no ACK). However, I saw the same issue with having to
specify an address. I will document this in my FAQ.

The command syntax is:
I2cout datapin,clockpin,{ErrLabel},Control,{Address},[data … data]

If an address is not specified, there will be 1 start bit and the
first data byte (shifted right 1 bit) will be used for the address
(Control byte not used). If an address is specified, there will be 2
start bits and the Control byte will be used for the address.

i2cout p6,p7,i2cerr,($23<<1),$14,["h"] ;8 bit adr=$23, two start bits

i2cout p6,p7,i2cerr,($23<<1),$14,["hello"] ;8 bit adr=$23, two start
bits

i2cout p6,p7,i2cerr,($23<<1),["h"] ;8 bit adr=$34 (1/2 of "h"), one
start bit

i2cout p6,p7,i2cerr,($23<<1),["hello"] ;8 bit adr=$34 (1/2 of "h"),
one start bit

We had a SAA1064 I2C to 4 digit LED driver in the stockroom so I
brought one home. I'll wire it up and see if I can communicate with
it. At least it will provide the ACKs for me.

Dave

Do we have to pay for your DPO4000 too? That will be one expensive piece of
code. :-)

John Loffink
The Microtonal Synthesis Web Site
http://www.microtonal-synthesis.com
The Wavemakers Synthesizer Web Site
http://www.wavemakers-synth.com

> -----Original Message-----
> From: ComputerVoltageSources@yahoogroups.com
> [mailto:ComputerVoltageSources@yahoogroups.com] On Behalf Of djbrow54
>
> byte. I monitored the I2C on my PSIM with my scope (one of the brand
> new Tektronix DPO4000's with serial data/I2C analysis capability).

....

> Funny you should mention this. No one has ever asked me if I plan to
> donate my source code. I'm just sitting quietly waiting for my spec
> to be designed in. Then I can share my proprietary pricing. Let's
> see, I have to pay for my computer, STK500, 1000 lines of code at the
> going price; it's going to make that FrontPanelExpress 5U panel seem
> cheap! :-J

--- In ComputerVoltageSources@yahoogroups.com, "John Loffink"
<jloffink@...> wrote:

>
> Do we have to pay for your DPO4000 too? That will be one expensive
> piece of code. :-)

You know, this scope is quite affordable. But no, I've just borrowed
it for now.

I did manage to interface the AtomPro24 I2C to a SAA1064 I2C to 7
segment LED driver. I am sending 6 data bytes in a single message (7
bytes total since it includes the device address byte) in 1.32 mS.
The receiver is correctly ack'ing the packets and I am not getting any
AtomPro24 errors.

With interrupts enabled at 1 mS timer, I can see the packets jitter as
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).

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.

Dave

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

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

--- In ComputerVoltageSources@yahoogroups.com, "drmabuce" <drmabuce@.

> (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!)

For those with scope envy, I put a screen shot of the DPO4000 decoding
the I2C bus in my photo album. This was my experiment to send a
single byte of data. As I thought, you can't easily. You have to add
the address as an extra byte of data (e.g. sending two bytes of data).
The first address is ignored and the first byte of data is sent as the
address.

Ignore the 'glitches' on the data lines. I'm running about 3 feet of
parallel cable out of my PSIM and over to my bench. My system
grounding is also a mess. Short signals look fine.

The top traces are the captured waveform. The yellow line is my Aux
out which I use to measure the total time the i2cout command takes.
The bottom waveforms are the zoomed image with the I2C protocol
analysis displayed.

I also added a photo for a workspace concept using the I2C to greatly
expand the I/O and display to a retro mega-system.

Dave

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

--- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@...>
wrote:

> I also added a photo for a workspace concept using the I2C to greatly
> expand the I/O and display to a retro mega-system.

LOL!
hey man! you stole my panel idea.... if i was Don Buchla there'd
ALREADY be a letter from my lawyer in your mailbox!
;^>

maybe we should follow a microsoft design model and if the I2C buss
senses NON-CVS components on the buss it de-installs them and sets off
Harry's pager!

8]

(leering smartass grin)
-doc

Hi Dave
--- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@...>
wrote:

> The top traces are the captured waveform. The yellow line is my Aux
> out which I use to measure the total time the i2cout command takes.
> The bottom waveforms are the zoomed image with the I2C protocol
> analysis displayed.

all i can say is ....
oooooooooooooo ahhhhhhhhhhhhhhhh

80
=)

-doc

A few questions, if I may.

1. Are you using the hardware I2C pins on the PSIM?

2. The PSIM I2C port has the pullup resistors going to ground instead of +5v, did you fix
this?

3. If you did not fix the resistors, then the I2C port is not open collector (drain) but is
using the "hard" pullups on the GPIO section of the pin driver. That means only 1 device
can be on the I2C bus?

--- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@...> wrote:
>
> --- In ComputerVoltageSources@yahoogroups.com, "John Loffink"
> <jloffink@> wrote:
> >
> > Do we have to pay for your DPO4000 too? That will be one expensive
> > piece of code. :-)
>
> You know, this scope is quite affordable. But no, I've just borrowed
> it for now.
>
> I did manage to interface the AtomPro24 I2C to a SAA1064 I2C to 7
> segment LED driver. I am sending 6 data bytes in a single message (7
> bytes total since it includes the device address byte) in 1.32 mS.
> The receiver is correctly ack'ing the packets and I am not getting any
> AtomPro24 errors.
>
> With interrupts enabled at 1 mS timer, I can see the packets jitter as
> 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).
>
> 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.
>
> Dave
>

--- In ComputerVoltageSources@yahoogroups.com, "Grant Richter"
<grichter@...> wrote:

> 1. Are you using the hardware I2C pins on the PSIM?

I am using the I2C pins on the PSIM. However, the I2COut command for
the AtomPro24 does not use the H8 hardware. BasicMicro did a software
implementation of I2C protocol (I called and talked with them). It
will use any two pins specified in the command. I looked at the H8
documentation to interface directly to the I2C hardware but decided it
could be slower than using the I2Cout command. I am able to transmit
a byte in ~220 uS using I2COut. That's not much time to control the
hardware registers using Basic. I figured it would be a performance
wash at best and more complex coding.

> 2. The PSIM I2C port has the pullup resistors going to ground
> instead of +5v, did you fix this?

The resistors are not installed on my PSIM board. My schematic shows
them connected to +5 but it doesn't matter since they're not
installed.

> 3. If you did not fix the resistors, then the I2C port is not open
> collector (drain) but is using the "hard" pullups on the GPIO
> section of the pin driver. That means only 1 device can be on the
> I2C bus?

The I2COut command appears to set the pins selected to open drain. I
know this because everything was hung until I added external pullup
resistors. It is operating in an open drain configuration. Once I
added 3' of cable to reach my bench, I can 'really' tell that it's
operating with passive pullups.

Dave

> > 2. The PSIM I2C port has the pullup resistors going to ground
> > instead of +5v, did you fix this?
>
> The resistors are not installed on my PSIM board. My schematic shows
> them connected to +5 but it doesn't matter since they're not
> installed.
>

I have a schematic labeled Rev. 2b showing them going to ground.

If you have a chance, could you check the corrected Rev. number?

Thank you.

--- In ComputerVoltageSources@yahoogroups.com, "Grant Richter"
<grichter@...> wrote:

> > > 2. The PSIM I2C port has the pullup resistors going to ground
> > > instead of +5v, did you fix this?
> >
> > The resistors are not installed on my PSIM board. My schematic
> > shows them connected to +5 but it doesn't matter since they're not
> > installed.
> >
> I have a schematic labeled Rev. 2b showing them going to ground.
> If you have a chance, could you check the corrected Rev. number?

Rev 1.0C 2/29/2004

Thank you.

--- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@...> wrote:
>
> --- In ComputerVoltageSources@yahoogroups.com, "Grant Richter"
> <grichter@> wrote:
> > > > 2. The PSIM I2C port has the pullup resistors going to ground
> > > > instead of +5v, did you fix this?
> > >
> > > The resistors are not installed on my PSIM board. My schematic
> > > shows them connected to +5 but it doesn't matter since they're not
> > > installed.
> > >
> > I have a schematic labeled Rev. 2b showing them going to ground.
> > If you have a chance, could you check the corrected Rev. number?
>
> Rev 1.0C 2/29/2004
>

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

I'd just leave it on the CVS PCB. Add the I2C connections behind the panels
for adding functions and leave front panels for MIDI, serial port and analog
modular signals.

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

Port I/O expansion is the most useful application of I2C in this context.
It will add more digital I/Os (gates).

Philips has some programmable LED flashers that could operate as self
running clocks, set them and forget them from the Basic Micro standpoint.

For memory and analog/digital conversion, SPI is the more common interface
and has a much larger selection of cost effective solutions.

> We could keep the display interface the same via MIDI.

Agreed.

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

I'd think of an I2C expansion as an addon to the CVS. There's no need to
spin the LCD Support PCB, just make a new PCB that attaches to the CVS.

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

I could tell you many. Don't even think about multimastering, long stubs on
the bus, or more than a handful of slaves.

John Loffink
The Microtonal Synthesis Web Site
http://www.microtonal-synthesis.com
The Wavemakers Synthesizer Web Site
http://www.wavemakers-synth.com

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

Uh, not really. SMBus is an enhancement to I2C developed by Intel that
fixes several deficiencies with I2C bus, such as adding a watchdog timeout
to any device driving the bus. I've been involved with I2C periodically
over the last nine years. Let's just say that there are many misbehaving
devices out there.

If we keep it simple, then there shouldn't be problems.

John Loffink
The Microtonal Synthesis Web Site
http://www.microtonal-synthesis.com
The Wavemakers Synthesizer Web Site
http://www.wavemakers-synth.com

Hi John

--- In ComputerVoltageSources@yahoogroups.com, "John Loffink"
<jloffink@...> wrote:
ise given those conditions

> >
> > I2C might be very well-behaved if I2C-friendly components are
> > designed-in.
> >
>
> Uh, not really. SMBus is an enhancement to I2C developed by Intel that
> fixes several deficiencies with I2C bus, such as adding a watchdog

timeout

> to any device driving the bus. I've been involved with I2C periodically
> over the last nine years. Let's just say that there are many

misbehaving

> devices out there.
>
> If we keep it simple, then there shouldn't be problems.
>

well then, i'm glad i hedged my semantic position with the the word
"might"...
;')

if you've had MULTIPLE bad experiences , it sure trumps my one dinky
project.... sounds to me like we need to leave this skunk under the
house and not try to coax him out and try to make a pet of him!

with 8 analog I/O's why get greedy now!
;'>

avanti!
-doc