Calibre UK UCA93 - Manual (Page 22)

CALIBRE
Issue 1.0 Page 19
01/07/03
Appendix B Migration Notes for Existing Calibre I2C Customers
These notes are intended for customers who have code working on one or more of Calibre UK’s
existing AT or PCI based adapters and wish to convert it to work with the new UCA93 Adapter. The
fundamental differences are a much reduced reliance on polling the status register, a new way of calling
slave functions and the introduction of new block transfer functions.
USB Bus Characteristics
The USB V1.1 bus is fast – data transfer rates can approach a 1 million 8-bit bytes per second. A brief
period of USB bus housekeeping is performed at 1mS intervals then the rest of that 1mS time slice is
available for data transfer to a particular peripheral in a particular direction. All transfers are initiated by
the host PC – it is very much in charge of the system. Direction changes cost bandwidth because even
a single byte transfer in a particular direction will occupy a time slice of 1mS. Single byte transfers in
alternate directions will effectively reduce the bus bandwidth to 1kHz! – similar to RS232. Software
functions for the UCA93 are fundamentally designed to reduce data direction changes and that is why
some of the traditional Calibre software method have had to be re-thought.
Polling the Status Register (and how to avoid it)
Traditional Calibre software requests a function (say SendAddress) then polls the status register until
the status indicates that the function has completed. On the UCA93 this is replaced by a function of the
type
I2CStatus = SendAddress(SlaveAddress);
which instructs the adapter to generate the start transmit the address then waits for a single status byte
to be returned from the adapter indicating how the transfer went. See Appendix A for details. One
status byte will always be returned even if the function fails and times out (about 500uS). Multiple polls
are not needed nor desirable and should be removed from code.
Previous Calibre I2C products used the PIN bit to synchronise data transfers between the I2C bus and
the host PC but this now is all handled by the PIC16F874 microcontroller on the Adapter.
Communication between the Adapter and host is now synchronised differently so to all intents and
purposes this bit is now redundant.
Block Functions
Block functions are I2C master functions designed to take advantage of the high bandwidth of the USB
bus whilst minimising data direction changes which slow the bus down. Instead of piecing together I2C
functions the user can for example load data into an array, then call a BlockWrite function.
Block Write Function
On receiving the BlockWrite function the adapter will generate the start and address, then optionally a
single or double pointer followed by a block of data up to 2048 bytes which is preset by the
SetBlockData function. If the slave device does not acknowledge, the adapter will send a stop after the
address, then repeat the sequence again up to Tries times to rouse the slave. If the slave still does not
acknowledge, the function will terminate cleanly. The user should keep track of the BlockWrite function
by immediately calling the BlockWriteStatus function which will return the status byte indicating how the
BlockWrite function got on and how it terminated.
Block Read Function
On receiving the BlockRead function the adapter will generate the start and address, then optionally a
single or double pointer. If the slave device does not acknowledge, the adapter will send a stop after the
address, then repeat the sequence again up to Tries times to rouse the slave. If the slave still does not
acknowledge, the function will terminate cleanly. The user should keep track of the BlockRead function
by immediately calling the BlockReadStatus function which will return the status byte indicating how the
BlockRead function got on and how it terminated. The data returned from the slave to the host via the
adapter can be accessed by calling the BlockRead function which accesses a global variable.
Slave Functions