ComputerVoltageSources

The April 2006 issue of "Nuts and Volts" has an article on serial
buses called "Short-Range Networking", starting on page 12. I found
it very interesting as it covers I2C and the issues with pull-up
resistors and related items. I also find, based on the article, that
some programming languages have a very strange idea of 'optional' data
items in their commands. If you stop and think about it, I2C supports
127 different devices, so how could you have a command to send or
receive data that does NOT include the device id? So, of course, if
you don't supply an ID, the command is not going to assemble the
proper data stream for the bus. With normal data rates from 10kbps to
100kbps, and fast rates from 400kbps to 3.5Mbps, I suspect that there
is a lot we can do using the I2C bus if we make it available on the
CVS board. Please note that I do not see any use to this on the front
panel, as it really is designed around expansion types of devices, and
we want all of our front panel space for the end use connectors. It's
no big deal to run a cable between panels when you are installing them
(do it all the time with the power cables right?).

BTW the article also discusses the SPI bus. SPI is potentially
faster, but seems more limited as the 'addressing' is handled
externally to the data bus and requires individual device selects, and
the associated I/O pins to drive them. (I know, I know, you can use
binary select lines and de-multiplex them, but for 3 devices, you need
2 pins, 3 pins gets you up to 7 devices, and so on and so on. A lot
of extra lines above the 3 used for the actual communications.)

Larry T.

--- In ComputerVoltageSources@yahoogroups.com, "Larry T." <larry@...>
wrote:

> If you stop and think about it, I2C supports 127 different devices,
> so how could you have a command to send or receive data that does
> NOT include the device id? So, of course, if you don't supply an
> ID, the command is not going to assemble the proper data stream for
> the bus.

I think it's a matter of nomenclature. The I2COut command specifies
a control byte. There is no defined 'control' byte that I know of in
I2C protocol. The first byte is an address and r/w combination which
I believe is the AtomPro 'control' byte. The r/w bit need not be
specified since there is a separate in and out command. However,
there is a 10 bit addressing mode which requires a second byte. I
haven't put this on a protocal analyzer but I believe that the
specified 'optional' address byte is the 2nd address byte for 10 bit
addressing (note that the AtomPro calls this 16 bit addressing.)

> With normal data rates from 10kbps to 100kbps, and fast rates from
> 400kbps to 3.5Mbps, I suspect that there is a lot we can do using
> the I2C bus if we make it available on the CVS board.

The I2CIn and Out command supports only the 100kbps mode (as
described on a phone call with BasicMicro). After reading the
specifics in the H8 hardware manual, I'm not convinced that one can
do a lot better using the dedicated hardware. It's a pretty simple
implementation that requires a large amount of software support in
Basic. Implementing this in assembly would help but I have been
unsuccessful in achieveing this or finding anyone else who has.

> Please note that I do not see any use to this on the front
> panel, as it really is designed around expansion types of devices,
> and we want all of our front panel space for the end use
> connectors.

I'll probably go my own route on the connector because I'll want
debug capability for these two pins as well as the display
microcontroller. The display microcontroller programs in-circuit via
SPI. That requires a 5 pin interface. Adding to this these two pins
(which can be digital I/O) and I need 7 pins externally. I'm tired of
feeding wires through the Switchcraft jacks so I can connect to these
processors. As soon as I finish verifying the display functionality,
I plan on coding an I2C to serial to control the TTS256 and
SpeakJet. I have thought about additional LEDs, digital I/O and the
like. Perhaps even a second MIDI channel. Once I get I2C interfaced
to the Atmel AVRs, then lots of possibilities open up. So I agree
with the front panel comment, just not for development and debug.

I'd love to see a common front panel, possibly from Stooge
Industries, so we can keep the price down. The other benefit is a
common hardware configuration which will help with software
compatibility. One of the key issues we'll have to face is software
compatibility with all the possibilities of assembly permutations.
It would be very nice to be able to share programs without
modifications.

Dave