ComputerVoltageSources

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