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