total phase - university of minnesota...total phase aardvark i2c/spi embedded systems interface data...

Features� I2C – Two wire interface

� Standard mode (100 kbps) and fast mode (400 kbps)� Variable bitrate (1–663 kbps)� Byte throughput rates are near theoretical maximums� Master transmit and receive� Asynchronous slave transmit and receive� Repeated start, 10-bit addressing, and combined format

� SPI – 4 wire serial communication protocol� Up to 8 Mbps master signaling rate� Up to 4 Mbps slave signaling rate� Full duplex master transmit/receive� Asynchronous slave transmit/receive� Configurable slave select polarity for master mode

� GPIO – General Purpose Input/Output� General purpose signaling on I2C and/or SPI pins� Internal caching of GPIO configuration

� I2C Monitor� Unobtrusively record traffic on an I2C bus� Supports bus speeds up to 125 kHz

� USB host communication� Up to 3 Mbps transfer to host PC� Powered from USB, eliminating power adapters� Reports as a full-speed device (12 Mbps) to USB 2.0 hosts

� Software API� Linux and Windows compatible� Easy to integrate application interface

� Upgradeable Firmware� Field upgradeable over USB� Error checking prevents upgrade disasters

SummaryThe Aardvark I2C/SPI Embedded Systems Interface is a host adapterthrough USB. It allows a developer to interface a host PC to a downstreamembedded system environment and transfer serial messages using the I2Cand SPI protocols. I2C and SPI functionality can be used concurrently. Ad-ditionally, the I2C and/or SPI pins can be used for general purpose signalingwhen the respective subsystem is not in use. An I2C monitoring feature isalso available to unobtrusively record traffic on an I2C bus.

Aardvark I2C/SPI Embedded Systems Interface

Data Sheet v3.1December 6, 2004

www.totalphase.com © 2003 Total Phase, Inc.

TOTAL

PHASE

I2C/SPIAARDVARK

Total Phase Aardvark I2C/SPI Embedded Systems Interface

1. General Overview

1.1 I2C Background

HistoryWhen connecting multiple devices to a microcontroller, the address anddata lines of each devices were conventionally connected individually.This would take up precious pins on the microcontroller, result in a lot oftraces on the PCB, and require more components to connect everythingtogether. This made these systems expensive to produce and suscepti-ble to interference and noise.

To solve this problem, Philips developed Inter-IC bus, or I2C, in the1980s. I2C is a low-bandwidth, short distance protocol for on board com-munications. All devices are connected through two wires: serial data(SDA) and serial clock (SCL).

Because all commnication takes place on only two wires, all devices musthave a unique address to identify it on the bus. Slave devices have apredefined address, but the lower bits of the address can be assigned toallow for multiples of the same devices on the bus.

Theory of OperationI2C has a master/slave protocol. The master initiates the communication.The sequence of events are:

1. The master device issues a start condition. This condition informsall the slave devices to listen on the serial data line for their re-spective address.

2. The master device sends the address of the target slave deviceand a read/write flag.

3. The slave device with the matching address responds with an ac-knowledgment signal.

4. Communication proceeds between the master and the slave onthe data bus. Both the master and slave can receive or transmit

www.totalphase.com 2

Figure 1: Sample I2C Implementation

Regardless of how many slave units are attached to the I2C bus, there are onlytwo signals connected to all of them. Consequently, there is additionaloverhead because an addressing mechanism is required for the master deviceto communicate with a specific slave device.

Master

Slave Slave Slave

SDA

SCL


data depending on whether the communication is a read or write.The transmitter sends 8-bits of data to the receiver which replieswith a 1-bit acknowledgment.

5. When the communication is complete, the master issues a stopcondition indicating that everything is done.

The above figure shows a sample bitstream of the I2C protocol.

FeaturesI2C has many features other important features worth mentioning. It sup-ports multiple data speeds: standard (100 kbps), fast (400 kbps) and highspeed (3.4 Mbps) communications.

Other features include: � Built in collision detection, � 10-bit Addressing, � Multi-master support, � Data broadcast (general call).

For more information about other features, look at the references at theend of this section.

Benefits and DrawbacksSince only two wires are required, I2C is well suited for boards with manydevices connected on the bus. This helps reduce the cost and complexi-ty of the circuit as additional devices are added to the system.

Due to the presence of only two wires, there is additional complexity inhandling the overhead of addressing and acknowledgments. This can beinefficient in simple configurations and a direct-link interface such as SPImight be preferred.

References� I2C-bus – Philips Semiconductors Official I2C website

(http://www.semiconductors.philips.com/buses/i2c/)� I2C (Inter-Integrated Circuit) Bus Technical Overview and Frequently Asked

Questions – Embedded Systems Academy(http://www.esacademy.com/faq/i2c/)

� Introduction to I2C – Embedded.com (http://www.embedded.com/story/OEG20010718S0073)

� I2C – Open Directory Project Listing (http://dmoz.org/Computers/Hardware/Buses/I2C/)


Figure 2: I2C Protocol

Since there are only two wires, this protocol includes the extra overheadof the addressing and acknowledgement mechanisms.

START

Slave Address STOP

READ/

WRITE

Data Data

ACK ACK


1.2 SPI Background

HistorySPI is a serial communication bus developed by Motorola. It is a full-du-plex protocol which functions on a master-slave paradigm that is ideallysuited to data streaming applications.

Theory of OperationSPI requires four signals: clock (SCLK), master output/slave input(MOSI), master input/slave output (MISO), slave select (SS).

Three signals are shared by all devices on the SPI bus: SCLK, MOSI andMISO. SCLK is generated by the master device and is used for synchro-nization. MOSI and MISO are the data lines. The direction of transfer isindicated by their names. Data is always transferred in both directions inSPI, but an SPI device interested in only transmitting data can choose toignore the receive bytes. Likewise, a device only interested in the incom-ing bytes can transmit dummy bytes.

Each device has its own SS line. The master pulls low on a slave's SSline to select a device for communication.

The exchange itself has no pre-defined protocol. This makes it ideal fordata-streaming applications. Data can be transferred at high speed, of-ten into the range of the tens of megahertz. The flipside is that there isno acknowledgment, no flow control, and the master may not even beaware of the slave's presence.


Figure 3: Sample SPI Implementation

Each slave device requires a separate slave select signal (SS). Thismeans that as devices are added, the circuit increases in complexity.

Slave 1

SCLK

MOSI

MISO

SS

MasterSCLK

MOSI

MISO

SS1

SS2

SS3 Slave 2

SCLK

MOSI

MISO

SS

Slave 3

SCLK

MOSI

MISO

SS


ModesAlthough there is no protocol, the master and slave need to agree aboutthe data frame for the exchange. The data frame is described by two pa-rameters: clock polarity (CPOL) and clock phase (CPHA). Both parame-ters have two states which results in four possible combinations.

These combinations are shown in the above table.

Benefits and DrawbacksSPI is a very simple communication protocol. It does not have a specifichigh-level protocol which means that there is almost no overhead. Datacan be shifted at very high rates in full duplex. This makes it very simpleand efficient in a single master single slave scenario.

Because each slave needs its own SS, the number of traces required isn+3, where n is the number of SPI devices. This means increasedboard complexity when the number of slaves is increased.

References� Introduction to Serial Peripheral Interface – Embedded.com

(http://www.embedded.com/story/OEG20020124S0116)� SPI - Serial Peripheral Interface

(http://www.mct.net/faq/spi.html)


Figure 4: SPI Modes

The frame of the data exchange is described by two parameters, theclock polarity (CPOL) and the clock phase (CPHA). This diagram showsthe four possible states for these parameters and the correspondingmode in SPI.

MODE 0

Clock Phase (CPHA)

Clo

ck P

olari

ty (C

POL)

CPHA = 0

CPO

L = 0

CPO

L = 1

CPHA = 1

MODE 2

MODE 1

MODE 3

sample sample

sample sample


2. Hardware Specifications

2.1 Pinouts

2 – GND 4 – NC/+5V 6 – NC/+5V 8 – MOSI 10 - GND

1 – SCL 3 – SDA 5 – MISO 7 - SCLK 9 - SS

( Red )

The ribbon cable that ships with the Aardvark adapter has a standard IDCfemale connector with 0.100” socket spacing.

Ground

GND (Pin 2):

GND (Pin 10):

It is imperative that the Aardvark adapter be on a common ground withthe target system. If the grounds are not connected, the signaling is en-tirely unpredictable and communication will likely be corrupted. Two pinsare connected to provide a solid ground path.

I2C Pins

SCL (Pin 1):

Serial Clock line – the signal used to synchronize communication be-tween the master and the slave.

SDA (Pin 3):

Serial Data line – the signal used to transfer data between the transmitterand the receiver.

SPI Pins

SCLK (Pin 7):

Serial Clock – control line that is driven by the master and regulates theflow of the data bits.

MOSI (Pin 8):

Master Out Slave In – this data line supplies output data from the masterwhich is shifted into the slave.

MISO (Pin 5):

Master In Slave Out – this data line supplies the output data from theslave to the input of the master.

SS (Pin 9):

Slave Select – control line that allows slaves to be turned on and off viahardware control.

Powering Downstream DevicesIt is possible to power a downstream target, such as an I2C or SPI EEP-ROM with the Aardvark adapter's power (which is provided by the USB



port). It is ideal if the downstream device does not consume more than20-30 mA. The Aardvark adapter is compatible with USB hubs as well asUSB host controllers (see section below on USB compliance). USB hubsare technically only rated to provide 100 mA per USB device. If the Aard-vark adapter is directly plugged into a USB host controller, it can theoreti-cally draw up to 500 mA total, leaving approximately 400 mA for anydownstream target. However, the Aardvark adapter always reports itselfto the host as a low-power device (<= 100 mA). Therefore, drawing largeamounts of current from the host is not advisable.

NC/+5V (Pin 4): I2C Power

NC/+5V (Pin 6): SPI Power

By default, these pins are left unconnected at the time of shipping. Forhardware versions 2.00 and greater, these pins are switched through thesoftware API. A maximum of 50 mA may be drawn from each pin.

For hardware versions prior to 2.00, power cannot be supplied unless theappropriate jumpers are connected inside the Aardvark unit. To connectVDD to pins 4 and 6, connect jumpers J301 and J302.

Opening your Aardvark unit will void any hardware warranty. Anymodifications are at the user's own risk.

2.2 Signal Levels/Voltage Ratings

Logic High LevelsAll signal levels are nominally 3.3 volts (+/- 10%) logic high. This allowsthe Aardvark adapter to be used with both TTL and CMOS logic level de-vices. A logic high of 3.3 volts will be adequate for TTL-compliant de-vices since such devices are ordinarily specified to accept logic high in-puts above approximately 3 volts.

ESD protectionThe Aardvark adapter has built-in electrostatic discharge protection toprevent damage to the unit from high voltage static electricity.

Drive CurrentThe Aardvark adapter can drive all output signals with a maximum of 10mA current source or sink.

2.3 I2C Signaling Characteristics

SpeedThe Aardvark I2C master can operate at a maximum bitrate of 663 kbpsand supports many intermediate bitrates between 1 kHz and the maxi-mum. The power-on default bitrate is for the I2C master unit is 100 kbps.

For slave functionality, the Aardvark adapter can operate at any rate lessthan the maximum bitrate of 595 kbps.

It is not possible to send bytes at a throughput of exactly 1/8 times the bit-rate. The I2C protocol requires that 9 bits are sent for every 8 bits of data.



There is also a finite time required to setup a byte transmission. In thedevelopment of the Aardvark adapter, many optimizations have been em-ployed to decrease this setup time. This allows byte throughputs withineach transaction to be very close to the theoretical maximum bytethroughput of 1/9 the bitrate.

There can be extra overhead introduced by the operating system be-tween calls to the Aardvark API. These delays will further reduce theoverall throughput across multiple transactions. To achieve the fastestthroughput, it is advisable to send as many bytes as possible in a singletransaction (i.e., a single call to the Aardvark API).

Pull-up ResistorsThere is a 2.2K resistor on each I2C line (SCL, SDA). The lines are effec-tively pulled up to 3.3V, so that results in approximately 1.5 mA of pull-upcurrent. If the Aardvark adapter is connected to an I2C bus that also in-cludes pull-up resisters, the total pull-up current could be up to double ofthis, yielding a total of 3 mA. (The I2C specification allows for a maximumof 3 mA pull-up current on each I2C line.)

As long as downstream I2C devices can sink more than 5 mA of current,the protocol should operate properly. The Aardvark device is able to sinkover twice that value, so it is possible to have two Aardvark devices com-municate with each other as master and slave.

Hardware versions 2.00 and later have the ability to switch the pull-up re-sistors by through the software API. Refer to the API section for moredetails.

I2C Clock StretchingWhen the Aardvark adapter is configured as an I2C master, it supportsboth inter-bit and inter-byte slave clock-stretching. If a slave device pullsSCL low during a transaction, the adapter will wait until SCL has been re-leased before continuing with the transaction.

Known LimitationsSince firmware version 2.00, the Aardvark adapter supports the repeatedstart, 10-bit addressing, and combined format features of the I2C protocol.

Since firmware version 3.00, the Aardvark adapter can keep the slavefunctions enabled even while master operations are executed through thesame adapter. The Aardvark adapter can even respond to slave re-quests immediately after losing bus arbitration during the slave address-ing phase of a master transaction.

Multi-master is also supported with the following features:

1) If there is a bus collision during data transmission and the Aardvarkadapter loses the bus, the transaction will be be cut short and the hostAPI will report that fewer bytes were transmitted than the requestednumber. This condition can be distinguished from the case in whichthe downstream slave cuts short the transmission by sending a NACKby using the function aa_i 2c_r ead_ext .



2) Collisions are not detected in the following situations:� Between a REPEATED START condition and a data bit� Between a STOP condition and a data bit� Between a REPEATED START and a STOP condition

This constraint can be phrased in a different manner. Say that I2Cmaster device A has a packet length of X bytes. If there is a secondI2C master device, B, that sends packets of length greater than Xbytes, the first X bytes should never contain exactly the same data asthe data sent by device A. Otherwise the results of the arbitration willbe undefined.

This is a constraint found with most I2C master devices used in a multi-master environment.

2.4 SPI Signaling Characteristics

SPI WaveformsThe SPI signaling is characterized by the following waveforms.

SS

SCLK

MISO

MOSI

MISO

MOSI

t2t1

tp

Figure 5: SPI Waveform

Three different times are of note: t1, time from the assertion of SS# to the firstclock cycle; t2, time from the last clock cycle and the deassertion of SS#; tp,clock period.

SS

SCLK

MISO

MOSI

MISO

MOSI

MISO

MOSI

td

Figure 6: SPI Byte Timing

td, is the setup time between SPI bytes.



Symbol Parameter Min Max Units

t1 SS# assertion to first clock 10 20 µs

t2 Last clock to SS# deassertion 5 10 µs

tp Clock period 125 8000 ns

td Setup time 7 9 µs

SpeedsThe Aardvark SPI master can operate at bitrates of 125 kHz, 250 kHz,500 kHz, 1 MHz, 2 MHz, 4 MHz, and 8 MHz. The power-on default bi-trate is 1000 kHz. The quoted bitrates are only achievable within each in-dividual byte and does not extend across bytes. There is approximately9 sµ of setup time required in between each byte which results in a totaltransmission period of the byte transmission time plus 9 s.µ

The Aardvark SPI slave can operate at any bitrate up to 4 Mbps. Howev-er, there must be at least 10 sµ between the start of byte n and the startof byte n+1. Otherwise, bit corruption will result and transmission behav-ior will be unpredictable.

Similarly, when the Aardvark adapter is configured to act as an SPI slave,and the slave select is pulled high to indicate the end of a transaction,there is a data processing overhead of sending the transaction to the PChost. As such, if the SPI master sends a subsequent transaction in rapidsuccession to the Aardvark slave, the data received by the Aardvarkslave may be corrupted. There is no precise value for this minimum inter-transaction time, but a suggested spacing is approximately 100-200 us.

Pin DrivingWhen the SPI interface is activated as a master, the slave select line(SS) is actively driven low. The MOSI and SCK lines are driven as ap-propriate for the SPI mode. After each transmission is complete, theselines are returned to a high impedance state. This feature allows theAardvark adapter, following a transaction as a master SPI device, to bethen reconnected to another SPI environment as a slave. The Aardvarkadapter will not fight the master lines in the new environment.

Consequently, any SPI slave target to which the Aardvark adapter is in-terfaced must have a pull-up resistor on its slave select line, preventingfluttering of the voltage when the Aardvark adapter stops driving the sig-nal. It is also advisable that every slave also have passive pull-ups onthe MOSI and SCK lines. These pull-up resistors can be relatively weak– 100k should be adequate.

As a slave, the MOSI, SCK, and SS lines are configured as an input andthe MISO line is configured as an output. This configuration is held aslong as the slave mode is enabled (see the API documentation later inthe datasheet).

Known LimitationsThere is currently an issue with SPI mode 2 (clock idles high, and sam-



pling of MOSI is on the leading edge) that induces periodic bit corruptionsin the most significant bit of certain bytes. The bug has been noted forSPI slave devices and there may also be corruptions when using thismode for sending or receiving messages as an SPI master. Unfortunate-ly there is no fix for this problem and the best solution is to use anothermode. If you have any questions regarding this issue please contact To-tal Phase support.

It is only possible to reliably send and receive transactions of 4 KiB orless as an SPI master or slave. This is due to operating system issuesand the full-duplex nature of the SPI signaling.

Aardvark Device Power ConsumptionThe Aardvark adapter consumes less than 100 mA of current. This iswithin the USB 1.1 current specification for devices powered from a USBhost adapter (500 mA maximum per device) or a USB hub (100 mA maxi-mum per device).

2.5 USB 1.1 Compliance

The Aardvark adapter is USB 1.1 compliant and will also operate as a fullspeed (12 Mbps) device on a USB 2.0 hub or host controller

2.6 Temperature Specifications

The Aardvark device is designed to be operated at room temperature(10–35° C). The electronic components are rated for standard commer-cial specifications (0–70° C). However, the plastic housing, along withthe ribbon and USB cables, may not withstand the higher end of thisrange. Any use of the Aardvark device outside the room temperaturespecification will void the hardware warranty.



3. Software

3.1 Compatibility

LinuxThe Aardvark software is compatible with all standard distributions ofLinux with integrated USB support. Kernel 2.4.18 or greater is recom-mended.

WindowsThe Aardvark software is also compatible with Windows 2000 and Win-dows XP. The software's compatibility with Windows 98 and WindowsME has not been tested. Theoretically, the Aardvark software is compati-ble with these legacy operating systems, but there will be no support pro-vided by Total Phase for these environments.

3.2 Linux USB Driver

As of version 3.0, the Aardvark communications layer under Linux the nolonger requires a specific kernel driver to operate. It does however re-quire that / pr oc/ bus/ usb is mounted on the systemwhich is the caseon most standard distributions.

There are two different ways to access the Aardvark adapter, throughUSB hotplug or by mounting the entire USB filesystem as world writable.The hotplug method is the preferred method because only the Aardvarkadapter would be world writable and hence more secure.

USB HotplugUSB hotplug requires two configuration files which are available fordownload from the Total Phase web site. These files are: aar dvar k andaar dvar k. user map. Please follow the following steps to enable hot-plugging.

1. As superuser, unpack aar dvar k and aar dvar k. user map to/ et c / hot pl ug/ usb.

2. chmod 755 / et c / hot pl ug/ usb/ aar dvar k

3. chmod 644 / et c / hot pl ug/ usb/ aar dvar k. user map

4. Unplug and replug your Aardvark adapter(s) .

Driver Installation/UninstallationOften, the / pr oc/ bus/ usb directory is mounted with read-write permis-sions for root and read-only permissions for all other users. If an non-privileged user wishes to use the Aardvark adapter and software, onemust ensure that / pr oc/ bus/ usb is mounted with read-write permis-sions for all users. The following steps can help setup the correct permis-sions. Please note that these steps will make the entire USB filesystemworld writable.



1. Check the current permissions by executing the following command:“l s - al / pr oc/ bus/ usb/ 001”

2. If the contents of that directory are only writable by root, proceed withthe remaining steps outlined below.

3. Add the following line to the / et c / f s t ab file:none / pr oc/ bus/ usb usbf s def aul t s, devmode=0666 0 0

4. Unmount the / pr oc/ bus/ usb directory using “umount ”

5. Remount the / pr oc/ bus/ usb directory using “mount ”

6. Repeat step 1. Now the contents of that directory should be writableby all users.

3.3 Windows USB Driver

Driver InstallationAs of version 3.0, the Aardvark communications layer under Windows nolonger uses a virtual serial port driver. The switch to a more direct USBdriver should improve the installation and performance of PC and Aard-vark adapter communication. To install the appropriate USB communica-tion driver under Windows, step through the following instructions. This isonly necessary for the very first Aardvark adapter that is plugged into thePC. Subsequent plugs and unplugs are automatically handled by the op-erating system.

Windows 2000:

1. When you plug in the Aardvark adapter into your PC for the first time,Windows will present the “Found New Hardware Wizard.” Select“Next.”

2. On the next dialog window, select “”Search for a suitable driver for mydevice (recommended)” and click “Next.”

3. On the third screen, uncheck all settings and check “Specify a loca-tion” and click “Next.”

4. Click “Browse...”, navigate to either the CD-ROM (“\usb-drivers\win-dows” directory), or temporary directory where the driver files havebeen unpacked (for downloaded updates).

5. Select “ftdibus.inf” and click “Open”, then click “Ok”.

6. Click “Next” on the subsequent screen, followed by “Finish” to com-plete the installation. This completes the installation of the USB driv-er.

Windows XP:

1. When you plug in the Aardvark adapter into your PC for the first time,Windows will present the “Found New Hardware Wizard.”

2. Select “Install from a list or specific location (Advanced)” and click“Next.”



3. Select “Search for best driver in these locations:”, uncheck “Search re-movable media”, check “Include this location in the search”

4. Click “Browse...”, expand My Computer and navigate to either the CD-ROM (“\usb-drivers\windows” directory), or temporary directory wherethe driver files have been unpacked (for downloaded updates).

5. Click “OK”, then click “Next”

6. A dialog will inform the user that the USB driver has been installed.Click “Finish”

Both Windows 2000 and Windows XP:

7. Once the installation is complete, confirm that the installation wassuccessful by checking that the device appears in the “Device Manag-er.” To navigate to the “Device Manager” screen select “Control Panel| System Properties | Hardware | Device Manager.”

8. The Aardvark device should appear under the “Universal Serial BusControllers” section.

Driver RemovalHere are instructions to remove the USB communication driver from theoperating system. It is critical that all Aardvark adapters have beenremoved from your system before proceeding with this process.

1. Navigate to either the CD-ROM (“\usb-drivers\windows” directory), ortemporary directory where the driver files have been unpacked (fordownloaded updates).

2. Run FTD2XXUN. EXE and follow the instructions.

3.4 USB Port Assignment

LinuxThe Aardvark adapter is assigned a port on a sequential basis. The firstadapter is assigned to port 0, the second is assigned to port 1, and so on.If an Aardvark adapter is subsequently removed from the system, the re-maining adapters shift their port numbers accordingly. Hence with nAardvark adapters attached, the allocated ports will be numbered from 0to n- 1.

WindowsThe Aardvark adapter is assigned a port on a sequential basis. The firstadapter is assigned to port 0, the second is assigned to port 1, and so on.If there are other FTDI-based USB devices connected to the WindowsPC, these will also be assigned USB ports, thereby adjusting the port as-signments of the Aardvark adapters accordingly. If an Aardvark adapter(or other FTDI-based USB device) is subsequently removed from the sys-tem, the remaining adapters shift their port numbers accordingly.



Detecting PortsTo determine the ports to which the Aardvark adapters have been as-signed, use the aa_f i nd_devi ces routine as described in followingAPI documentation.



3.5 Aardvark Dynamically Linked Library

PhilosophyThe Aardvark DLL provides a robust approach to allow present-day Aard-vark-enabled applications to interoperate with future versions of the de-vice interface software without recompilation. For example, take the caseof a graphical application that is written to communicate I2C or SPIthrough an Aardvark device. At the time the program is built, the Aard-vark software is released as version 1.2. The Aardvark interface softwaremay be improved many months later resulting in increased performanceand/or reliability; it is now released as version 1.3. The original applica-tion need not be altered or recompiled. The user can simply replace theold Aardvark DLL with the newer one. How does this work? The applica-tion contains only a stub which in turn dynamically loads the DLL on thefirst invocation of any Aardvark API function. If the DLL is replaced, theapplication simply loads the new one, thereby utilizing all of the improve-ments present in the replaced DLL.

On Linux, the DLL is technically known as a shared object (SO).

DLL LocationTotal Phase provides language bindings that can be integrated into anycustom application. The default behavior of locating the Aardvark DLL isdependent on the operating system platform and specific programminglanguage environment. For example, for a C or C++ application, the fol-lowing rules apply:

On a Linux system this is as follows:

1. First, search for the shared object in the application binary path. Note, that searching the application binary path requires /proc filesys-tem support, which is standard in 2.4.x kernels. If the /proc filesystemis not present, the shared object will not be loaded from the executionpath unless that path happens to also match one of the followingsearch criteria.

2. Next, search in the application's current working directory.

3. Search the paths explicitly specified in LD_LI BRARY_PATH.

4. Finally, check any system library paths as specified in / et c / l d. so. -conf and cached in / et c / l d. so. cache.

On a Windows system, this is as follows:

1. the directory from which the application binary was loaded.

2. the application's current directory,

3. 32-bit system directory (ex: c:\winnt\System32) [Windows NT/2000/XPonly],

4. 16-bit system directory (ex: c:\winnt\System or c:\windows\system),

5. the windows directory (ex: c:\winnt or c:\windows),



6. the directories listed in the PATH environment variable.

If the DLL is still not found, an error will be returned by the binding func-tion, AA_UNABLE_TO_LOAD_LI BRARY.

VersioningThe Aardvark DLL checks to ensure that the firmware of a given Aardvarkdevice is compatible. Each DLL revision is tagged as being compatiblewith firmware revisions greater than or equal to a certain version number.Likewise, each firmware version is tagged as being compatible with DLLrevisions greater than or equal to a specific version number.

Here is an example.

DLL v1. 20: compat i bl e wi t h Fi r mwar e >= v1. 15

Fi r mwar e v1. 30: compat i bl e wi t h DLL >= v1. 20

Hence, the DLL is not compatible with any firmware less than version1.15 and the firmware is not compatible with any DLL less than version1.20. In this example, the version number constraints are satisfied andthe DLL can safely connect to the target firmware without error. If there isa version mismatch, the API calls to open the device will fail. See the APIdocumentation for further details.

3.6 Rosetta Language Bindings: API Integration into Custom Applications

OverviewThe Aardvark Rosetta language bindings make integration of the Aard-vark API into custom applications simple. Accessing Aardvark functional-ity simply requires function calls to the Aardvark API. This API is easy tounderstand, much like the ANSI C library functions, (e.g., there is no un-necessary entanglement with the Windows messaging subsystem likedevelopment kits for some other embedded tools).

First, choose the Rosetta bindings appropriate for the programming lan-guage. Different Rosetta bindings are included with the software distribu-tion on the distribution CD. They can also be found in the software down-load package available on the Total Phase website. Currently the follow-ing languages are supported: C/C++, Python, and Visual Basic. Next,follow the instructions for each language binding on how to integrate thebindings with your application build setup. As an example, the integrationfor the C language bindings is described below.

1. Include the aar dvar k. h file included with the API software packagein any C or C++ source module. The module may now use any Aard-vark API call listed in aar dvar k. h.

2. Compile and link aar dvar k. c with your application. Ensure that theinclude path for compilation also lists the directory in which aar d-var k. h is located if the two files are not placed in the same directory.

3. Place the Aardvark DLL, included with the API software package, inthe same directory as the application executable or in another directo-



ry such that it will be found by the previously described search rules.

VersioningSince a new Aardvark DLL can be made available to an already compiledapplication, it is essential to ensure the compatibility of the Rosetta bind-ing used by the application (e.g., aar dvar k. c ) against the DLL loadedby the system. A system similar to the one employed for the DLL-Firmware cross-validation is used for the binding and DLL compatibilitycheck.

Here is an example.

DLL v1. 20: compat i bl e wi t h Bi ndi ng >= v1. 10

Bi ndi ng v1. 15: compat i bl e wi t h DLL >= v1. 15

The above situation will pass the appropriate version checks. The com-patibility check is performed within the binding. If there is a version mis-match, the API function will return an error code,AA_I NCOMPATI BLE_LI BRARY.

CustomizationsWhile provided language bindings stubs are fully functional, it is possibleto modify the code found within this file according to specific require-ments imposed by the application designer.

For example, in the C bindings one can modify the DLL search and load-ing behavior to conform to a specific paradigm. See the comments inaar dvar k. c for more details.

3.7 Application Notes

Asynchronous MessagesThere is buffering within the Aardvark DLL, on a per-device basis, to helpcapture asynchronous messages. Take the case of the Aardvark adapterreceiving I2C messages asynchronously. If the application calls the func-tion to change the SPI bitrate while some unprocessed asynchronousmessages are pending, the Aardvark adapter will transact the bitratechange but also save any pending I2C messages internally. The mes-sages will be held until the appropriate API function is called.

The size of the I2C and SPI buffers are 16 KiB each and they can holdmany separate transactions. The buffers are only used when an Aard-vark API call is invoked. The buffer size is adequate since the overall lim-itation for asynchronous messages is fundamentally determined by theoperating system's internal buffer size. This concept is explained below.

Receive SaturationThe Aardvark adapter can be configured as an I2C or SPI slave. A slavecan receive messages asynchronously with respect to the host PC soft-ware. Between calls to the Aardvark API, these messages must bebuffered somewhere in memory. This is accomplished on the PC host,courtesy of the operating system. Naturally the buffer is limited in sizeand once this buffer is full, bytes will be dropped.



An overflow can occur when the Aardvark device receives asynchronousmessages faster than the rate that they are processed – the receive linkis “saturated.” This condition can affect other synchronous communica-tion with the Aardvark adapter. For example, if the SPI slave is receivingmany unserviced messages (messages left pending in the operating sys-tems buffer), a subsequent call to change the bitrate of I2C could fail inthe following manner.

1. The software sends a command to the Aardvark adapter tochange the bitrate.

2. The Aardvark adapter responds that the bitrate was set to agiven value.

3. The response is lost since the operating system's receivebuffer was full.

The requested bitrate has most likely been set by the Aardvark device,but the response was lost. A similar problem can happen when one at-tempts to disable the very slave that is saturating the incoming receivebuffer! The API function sends a command to disable the slave, but theacknowledgment from the Aardvark adapter is lost. The API call will treatthis as a communication error, but if the slave was actually disabled, asubsequent call to disable the slave should complete without errors.

The receive saturation problem can be improved in two ways. The obvi-ous solution is to reduce the amount of traffic that is sent by the masterbetween calls to the Aardvark API. This will require the ability to reconfig-ure the offending master device. The other option is to more regularlypoll the slave to obtain any pending asynchronous messages. Keep inmind that each call to capture pending asynchronous data can have atimeout of up to 500 ms. If there is other time critical code that must beexecuted simultaneously, it is best to use the asynchronous polling func-tion found in the API which allows for variable timeout values.

ThreadingThe Aardvark DLL is designed for single-threaded environments so as toallow for maximum cross-platform compatibility. If the application designrequires multi-threaded use of the Aardvark functionality, each AardvarkAPI call can be wrapped with a thread-safe locking mechanism beforeand after invocation. A call to any Aardvark API function that communi-cates with the host synchronously will also fetch any pending asyn-chronous messages, buffering them for subsequent calls to the asyn-chronous (slave) receive functions.

USB Scheduling DelaysEach API call that is used to send data to and from the Aardvark adaptercan incur up to 1 ms in delay on the PC host. This is caused by the in-herent design of the USB architecture. The operating system will queueany outgoing USB transfer request on the host until the next USB frameperiod. The frame period is 1 ms. Thus, if the application attempts to ex-ecute several transactions in rapid sequence there can be up to 1 ms de-lay between each transaction plus any additional process scheduling de-



lays introduced by the operating system. Again, the best throughput canbe achieved for single transactions that transfer a large number of bytesat a time.



4. Firmware

4.1 Field Upgrades

PhilosophyThe Aardvark adapter is designed so that its internal firmware can be up-graded by the user, thereby allowing the inclusion of any performance en-hancements or critical fixes available after the purchase of the device.The upgrade procedure is performed via USB and has several errorchecking facilities to ensure that the Aardvark adapter is not renderedpermanently unusable by a bad firmware update. In the worst case sce-nario, a corruption can cause the Aardvark adapter to be locked until asubsequent clean update is executed.

The upgrade utility is also compatible with older devices that use thelegacy virtual serial port communications drivers (pre-3.00 firmware revi-sions). The older serial port driver must be installed on your operatingsystem. When listing such devices, the upgrade utility will report thesedevices with port numbers starting at 128. The devices will also bemarked as “serial” as opposed to the “direct” identifier. Upgrading thelegacy firmware will cause the Aardvark unit to automatically switch to us-ing the new communications driver interface. If the host PC does nothave the appropriate driver installed, the operating system may promptthe user for the new driver upon completion of the firmware upgrade.Please refer to the section on USB driver installation above for more in-formation on how to install the new driver.

ProcedureHere is the simple procedure by which the Aardvark firmware is upgrad-ed.

1. Download the latest firmware from the Total Phase website.

2. Unzip the downloaded file. It should contain the aaf l ash utility. Thisutility contains the necessary information to perform the entirefirmware update.

3. Run aaf l ash (aaf l ash. exe on Windows or aaf l ash on Linux). Itwill first display the firmware version contained in the utility along withthe required hardware version to run this firmware version.

4. It will list all of the detected devices along with their current firmwareand hardware versions.

5. Select a device to upgrade. Note the firmware and hardware ver-sion of the device before proceeding. If the selected device's hard-ware is not suitable to accept the new firmware, an error will be printedand the utility will be reinvoked.

6. If the chosen device is acceptable, the aaf l ash utility will update thedevice with the new firmware. The process should take about 3 sec-onds, with a progress bar displayed during the procedure.



7. The upgraded Aardvark adapter should now be usable by any Aard-vark-enabled application.

8. In the event that there was a malfunction in the firmware update, theAardvark adapter may not be recognizable by an Aardvark-enabledapplication. Try the update again, since the Aardvark adapter hasmost likely become locked due to a corruption in the upgrade process.If the update still does not take effect, it is best to revert back to theprevious firmware. This can be done by running a previous version ofaaf l ash that contains an earlier firmware version. Check the TotalPhase website or the distribution CD that was included with your Aard-vark adapter for previous versions of the firmware.



5. API Documentation

5.1 Introduction

The API documentation that follows is oriented toward the Aardvark Rosetta C bindings. Theset of API functions and their functionality is identical regardless of which Rosetta languagebinding is utilized. The only differences will be found in the calling convention of the functions.For further information on such differences please refer to the documentation that accompanieseach language bindings in the Aardvark software distribution.

5.2 General Data Types

The following definitions are provided for convenience. All Aardvark data types are unsigned.

t ypedef unsi gned char aa_u08;

t ypedef unsi gned shor t aa_u16;

t ypedef unsi gned i nt aa_u32;

5.3 Notes on Status Codes

Most of the Aardvark API functions can return a status or error code back to the caller. Thecomplete list of status codes is provided at the end of this chapter. All of the error codes areassigned values less than 0, separating these responses from any numerical values returnedby certain API functions.

Each API function can return one of two error codes with regard to the loading of the underlyingAardvark DLL, AA_UNABLE_TO_LOAD_LI BRARY and AA_I NCOMPATI BLE_LI BRARY. If thesestatus codes are received, refer to the previous sections in this datasheet that discuss the DLLand API integration of the Aardvark software. Furthermore, all API calls can potentially returnthe error AA_UNABLE_TO_LOAD_FUNCTI ON. If this error is encountered, there is likely a seri-ous version incompatibility that was not caught by the automatic version checking system.Where appropriate, compare the language binding versions (e.g., AA_HEADER_VERSI ON foundin aar dvar k. h and AA_CFI LE_VERSI ON found in aar dvar k. c ) to verify that there are nomismatches. Next, ensure that the Rosetta language binding (e.g., aar dvar k. c and aar d-var k. h) are from the same release as the Aardvark DLL. If all of these versions are synchro-nized and there are still problems, please contact Total Phase support for assistance.

Any API function that accepts an Aar dvar k handle can return the error AA_I NVALI D_HANDLEif the handle does not correspond to a valid Aardvark device that has already been opened. Ifthis error is received, check the application code to ensure that the aa_open command re-turned a valid handle and that this handle is not corrupted before being passed to the offendingAPI function.

Finally, any I2C or SPI API call that communicates with an Aardvark device can return the errorAA_COMMUNI CATI ON_ERROR. This means that while the Aardvark handle is valid and the com-munication channel is open, there was an error receiving the acknowledgment response fromthe Aardvark adapter. This can occur in situations where the incoming data stream has beensaturated by asynchronously received messages – an outgoing message is sent to the Aard-vark adapter, but the incoming acknowledgment is dropped by the operating system as a resultof the incoming USB receive buffer being full. The error signifies that it was not possible toguarantee that the connected Aardvark device has processed the host PC request, though it islikely that the requested action has been communicated to the Aardvark adapter and the re-



sponse was simply lost. For example, if the slave functions are enabled and the incoming com-munication buffer is saturated, an API call to disable the slave may return AA_COMMUNI CA-TI ON_ERROR even though the slave has actually been disabled.

If either the I2C or SPI subsystems have been disabled by aa_conf i gur e, all other API func-tions that interact with I2C or SPI will return AA_I 2C_NOT_ENABLED or AA_SPI _NOT_EN-ABLED, respectively.

These common status responses are not reiterated for each function. Only the error codes thatare specific to each API function are described below.

All of the possible error codes, along with their values and status strings, are listed following theAPI documentation.



5.4 General API calls

Find Devices (aa_find_devices)i nt aa_f i nd_devi ces ( i nt nel em,

aa_u16 * dev i ces) ;

Get a list of ports to which Aardvark devices are attached.

Arguments

nel em: Maxi mum si ze of t he ar r ay

devi ces: ar r ay i nt o whi ch t he por t number s ar e r et ur ned

Return Value

This function returns the number of devices found, regardless of the array size.

Specific Error Codes

None.

Details

Each element of the array is written with the port number.

Devices that are in use are OR'ed with AA_PORT_NOT_FREE (0x8000). UnderLinux, such devices correspond to Aardvark adapters that are currently in use.Under Windows, such devices are currently in use, but it is not known if the de-vice is an Aardvark adapter.

Example:

Devices are attached to port 0, 1, 2ports 0 and 2 are available, and port 1 is in-use.ar r ay => 0x0000, 0x8001, 0x0002;

If the input array is NULL, it is not filled with any values.

If there are more devices than the array size (as specified by nel em), only thefirst nel em port numbers will be written into the array.

Find Devices (aa_find_devices_ext)i nt aa_f i nd_devi ces_ext ( i nt nel em,

aa_u16 * dev i ces, aa_u32 * uni que_i ds) ;

Get a list of ports and unique IDs to which Aardvark devices are attached.

Arguments

nel em: Maxi mum si ze of t he ar r ay

devi ces: ar r ay i nt o whi ch t he por t number s ar e r et ur ned

uni que_i ds: ar r ay i nt o whi ch t he uni que I Ds ar e r et ur ned

Return Value

This function returns the number of devices found, regardless of the array size.


None.



Details

This function is the same as aa_f i nd_devi ces( ) except that is also returnsthe unique IDs of each Aardvark device. The IDs are guaranteed to be non-zeroif valid.

The IDs are the unsigned integer representation of the 10-digit serial numbers.

Open an Aardvark device (aa_open)Aar dvar k aa_open ( i nt por t _number ) ;

Open the Aardvark port.

Arguments

The port number is the the same as the one obtained from the aa_f i nd_de-vi ces function. It is a zero-based number.

Return Value

This function returns an Aardvark handle, which is guaranteed to be greaterthan zero if valid.


AA_UNABLE_TO_OPEN: The specified port is not connected to an Aardvark de-vice or the port is already in use.

AA_I NCOMPATI BLE_DEVI CE: There is a version mismatch between the DLLand the firmware. The DLL is not of a sufficient version for interoperabilitywith the firmware version or vice versa. See aa_open_ext ( ) for more infor-mation.

Details

This function is recommended for use in simple applications where extended in-formation is not required. For more complex applications, the use ofaa_open_ext ( ) is recommended.

The open function also deactivates all slave functionality. An Aardvark devicecould have potentially been opened, enabled as a slave, and configured to sendasynchronous responses to a third-party master. If the controlling applicationquits without calling aa_cl ose( ) , the port is freed but the slave functions canstill be active. The open function deactivates slave functionality to ensure thatthe new application has access to an Aardvark device that is in a known-state.Also the I2C bus is freed, in the event that it was held indefinitely from a previousAA_I 2C_NO_STOP transaction.

Open an Aardvark device (aa_open_ext)Aar dvar k aa_open_ext ( i nt por t _number , Aar dvar kExt * aa_ext ) ;

Open the Aardvark port, returning extended information in the supplied structure.

Arguments

por t _number : same as aa_open

aa_ext : poi nt er t o pr e- al l ocat ed st r uct ur e f or ext endedver s i on i nf or mat i on avai l abl e on open



Return Value

This function returns an Aardvark handle, which is guaranteed to be greaterthan zero if valid.


AA_UNABLE_TO_OPEN: The specified port is not connected to an Aardvark de-vice or the port is already in use.

AA_I NCOMPATI BLE_DEVI CE: There is a version mismatch between the DLLand the firmware. The DLL is not of a sufficient version for interoperabilitywith the firmware version or vice versa. The version information will be avail-able in the memory pointed to by aa_ext .

Details

If 0 is passed as the pointer to the structure, this function will behave exactly likeaa_open( ) .

The Aar dvar kExt structure is described below:

st r uc t Aar dvar kExt { Aar dvar kVer si on ver s i on; / * Feat ur es of t hi s devi ce. * / i nt f eat ur es;}

The features field denotes the capabilities of the Aardvark device. See the APIfunction aa_f eat ur es for more information.

The Aar dvar kVer s i on structure describes the various version dependenciesof Aardvark components. It can be used to determine which component causedan incompatibility error.

st r uc t Aar dvar kVer si on { / * Sof t war e, f i r mwar e, and har dwar e ver si ons. * / aa_u16 sof t war e; aa_u16 f i r mwar e; aa_u16 har dwar e;

/ * FW r equi r es t hat SW must be >= t hi s ver si on. * / aa_u16 sw_r eq_by_f w;

/ * SW r equi r es t hat FW must be >= t hi s ver si on. * / aa_u16 f w_r eq_by_sw;

/ * API r equi r es t hat SW must be >= t hi s ver si on. * / aa_u16 api _r eq_by_sw;} ;

All version numbers are of the format:( maj or << 8) | mi norexample: v1. 20 would be encoded as 0x0114.

The structure is zeroed before the open is attempted. It is filled with whatever in-formation is available. For example, if the firmware version is not filled, then thedevice could not be queried for its version number.

This function is recommended for use in complex applications where extended



information is required. For simpler applications, the use of aa_open( ) is rec-ommended.

This open function also terminates all slave functionality as described for theaa_open( ) call.

Close an Aardvark (aa_close)i nt aa_cl ose ( Aar dvar k aar dvar k) ;

Close the Aardvark port.

Arguments

aar dvar k: handl e of an Aar dvar k adapt er t o be c l osed

Return Value

An Aardvark status code is returned with AA_OK on success.


None.

Details

An Aardvark adapter could have potentially been opened, enabled as a slave,and configured to send and receive asynchronous responses to and from a third-party master. A call to aa_cl ose( ) will deactivate all slave functionality. Alsothe I2C bus is freed, in the event that it was held indefinitely from a previousAA_I 2C_NO_STOP transaction.

Get Port (aa_port)i nt aa_por t ( Aar dvar k aar dvar k) ;

Return the port number for this Aardvark handle.

Arguments

aar dvar k: handl e of Aar dvar k adapt er

Return Value

The port number corresponding to the given handle is returned. It is a zero-based number.


None.

Details

None.

Get Features (aa_features)i nt aa_f eat ur es ( Aar dvar k aar dvar k) ;

Return the device features as a bit-mask of values, or an error code if the handle is notvalid.

Arguments

aar dvar k: handl e of an Aar dvar k adapt er



Return Value

The features of the Aardvark device are returned. These are a bit-mask of thefollowing values.

#def i ne AA_FEATURE_SPI ( 1<<0)#def i ne AA_FEATURE_I 2C ( 1<<1)#def i ne AA_FEATURE_GPI O ( 1<<3)#def i ne AA_FEATURE_I 2C_MONI TOR ( 1<<4)


None.

Details

None.

Get Unique ID (aa_unique_id)aa_u32 aa_uni que_i d ( Aar dvar k aar dvar k) ;

Return the unique ID of the given Aardvark device.

Arguments


Return Value

This function returns the unique ID for this Aardvark adapter. The IDs are guar-anteed to be non-zero if valid. The ID is the unsigned integer representation ofthe 10-digit serial number.


None.

Details

None.

Status String (aa_status_string)const char * aa_st at us_st r i ng ( i nt s t at us) ;

Return the status string for the given status code.

Arguments

st at us: s t at us code r et ur ned by an Aar dvar k API f unct i on

Return Value

This function returns a human readable string that corresponds to st at us . Ifthe code is not valid, it returns a NULL string.


None.

Details

None.

Logging (aa_log)i nt aa_l og ( Aar dvar k aar dvar k, i nt l evel , i nt handl e) ;



Enable logging to a file.

Arguments


l evel : t he l oggi ng det ai l l evel as descr i bed bel ow

handl e: a f i l e descr i pt or

Return Value



None.

Details

The handle must be standard file descriptor. In C, a file descriptor can be ob-tained by using the ANSI C function "open" or by using the function "fileno" on aFILE* stream. A FILE* stream obtained using f open or can correspond to thecommon st dout or st der r – available when including st dl i b. h.

The logging detail level can be one of the following options.

0 – none1 – error2 – warning3 – info4 – debug

Note that if the handle is invalid, the application can crash during a logging oper-ation.

Version (aa_version)i nt aa_ver si on ( Aar dvar k aar dvar k, Aar dvar kVer s i on * ver si on) ;

Return the version matrix for the device attached to the given handle.

Arguments


ver s i on: poi nt er t o pr e- al l ocat ed st r uct ur e

Return Value



None.

Details

If the handle is 0 or invalid, only the software version is set.

See the details of aa_open_ext for the definition of Aar dvar kVer s i on.

Configure (aa_configure)i nt aa_conf i gur e ( Aar dvar k aar dvar k, AA_CONFI G conf i g) ;

Activate/deactivate individual subsystems (I2C, SPI, GPIO).



Arguments


conf i g: enumer at ed t ype speci f yi ng conf i gur at i on

AA_CONFI G_GPI O_ONLY Configure all pins as GPIO.Disable both I2C and SPI.

AA_CONFI G_SPI _GPI O Configure I2C pins as GPIO.Enable SPI.

AA_CONFI G_GPI O_I 2C Configure SPI pins as GPIO.Enable I2C.

AA_CONFI G_SPI _I 2C Disable GPIO.Enable both I2C and SPI.

AA_CONFI G_QUERY Queries existing configuration(does not modify).

Return Value

The current configuration on the Aardvark adapter will be returned. The configu-ration will be described by the same values in AA_CONFI G.


AA_CONFI G_ERROR: The I2C or SPI subsystem is currently active and the newconfiguration requires the subsystem to be deactivated.

Details

If either the I2C or SPI subsystems have been disabled by this API call, all otherAPI functions that interact with I2C or SPI will return AA_CONFI G_ERROR.

If configurations are switched, the subsystem specific parameters will be pre-served. For example if the SPI bitrate is set to 500 kHz and the SPI system isdisabled and then enabled, the bitrate will remain at 500 kHz. This also holds forother parameters such as the SPI mode, SPI slave response, I2C bitrate, I2Cslave response, etc.

However, if a subsystem is shut off, it will be restarted in a quiescent mode. Thatis to say, the I2C slave function will not be reactivated after re-enabling the I2Csubsystem, even if the I2C slave function was active before first disabling the I2Csubsystem.

Note: Whenever the configure command is executed and GPIO lines are en-abled, the GPIO lines will be momentarily switched to high-Z before their direc-tion and pullup configurations are executed.

Target Power (aa_target_power)i nt aa_t ar get _power ( Aar dvar k aar dvar k, aa_u08 power _mask) ;

Activate/deactivate target power pins 4 and 6.

Arguments


power _mask: enumer at ed val ues speci f y i ng power pi n s t at e



AA_TARGET_POWER_NONE Disable target power pins

AA_TARGET_POWER_BOTH Enable target power pins

AA_TARGET_POWER_QUERY Queries the target power pin state

Return Value

The current state of the target power pins on the Aardvark adapter will be re-turned. The configuration will be described by the same values as in the tableabove.


AA_I NCOMPATI BLE_DEVI CE: The hardware version is not compatible with thisfeature. Only hardware versions 2.00 or greater support switchable targetpower pins.

Details

Both target power pins are controlled together. Independent control is not sup-ported. This function may be executed in any operation mode.

Asynchronous Polling (aa_async_poll)i nt aa_async_pol l ( Aar dvar k aar dvar k, i nt t i meout ) ;

Check if there is any asynchronous data pending from the Aardvark adapter.

Arguments


t i meout : t i meout i n mi l l i seconds

Return Value

A status code indicating which types of asynchronous messages are availablefor processing.

AA_ASYNC_NO_DATA No asynchronous data is available.

AA_ASYNC_I 2C_READ I2C slave read data is available.Use aa_i 2c_sl ave_r ead to get data.

AA_ASYNC_I 2C_WRI TE I2C slave write stats are available.Use aa_i 2c_sl ave_wr i t e_st at s to getdata.

AA_ASYNC_SPI SPI slave read data is available.Use aa_spi _sl ave_r ead to get data.

AA_ASYNC_I 2C_MONI TOR I2C monitor data is available.Use aa_i 2c_moni t or _r ead to get data.

These codes can be bitwise OR'ed together if there are multiple types of dataavailable.


None.



Details

Recall that, like all other Aardvark functions, this function is not thread-safe.

If the timeout value is negative, the function will block indefinitely until data ar-rives. If the timeout value is 0, the function will perform a non-blocking check forpending asynchronous data.

As described before, the Aardvark software contains asynchronous queues thatcan be filled during synchronous operations on the Aardvark adapter. If data isalready in one or more asynchronous queues, it will immediately return with all ofthe types of asynchronous data that are currently available. Further data may bepending in the operating system's incoming receive buffer, but the function willnot examine that data. Hence any pending data in the operating system's in-coming buffer will not be reported to the user until the Aardvark's softwarequeues have been fully serviced.

If there is no data already available, this function will check the operating sys-tem's receive buffer for the presence of asynchronous data. The function willblock for the specified timeout. It will then only report the type of the very firstdata that has been received. The function will not examine the remainder of theoperating system's receive buffer to see what other asynchronous messages arepending.

One can employ the following technique to guarantee that all pending asyn-chronous data have been captured during each service cycle:

1. Call the polling function with a specified timeout.

2. If the polling function indicates that there is data available, call the ap-propriate service function once for each type of data that is available.

3. Next, call the polling function with a 0 timeout.

4. Call the appropriate service function once for each type of data that isavailable.

5. Repeat steps 3 and 4 until the polling function reports that there is nodata available.



5.5 I2C Interface

Notes1. It is not necessary to set the bitrate for the Aardvark I2C slave.

2. An I2C master operation read or write operation can be transacted while leaving the I2C slavefunctionality enabled. In a multi-master situation it is possible for the Aardvark adapter tolose the bus during the slave addressing portion of the transaction. If the other master thatwins the bus subsequently addresses this Aardvark adapter's slave address, the Aardvarkadapter will respond appropriately to the request using its slave mode capabilities.

3. It is always advisable to set the slave response before first enabling the slave. This ensuresthat valid data is sent to any requesting master.

4. It is not possible to receive messages larger than approximately 4 KiB as a slave due to op-erating system limitations on the asynchronous incoming buffer. As such, one should notqueue up more than 4 KiB of total slave data between calls to the Aardvark API.

5. Since firmware revision 2.00 it is possible for the Aardvark I2C master to employ some of theadvanced features of I2C. This is accomplished by the AA_I 2C_FLAGS argument type thatis included in the aa_i 2c_r ead and aa_i 2c_wr i t e argument lists. The following optionsare available can be logically OR'ed together to combine them for one operation.

AA_I 2C_NO_FLAGS Request no options.

AA_I 2C_10_BI T_ADDR Request that the provided address is treated as a 10-bitaddress. The Aardvark I2C subsystem will follow thePhilips I2C specification when transmitting the address.

AA_I 2C_COMBI NED_FMT Request that the Philips combined format is followed dur-ing a I2C read operation. Please see the Philips specifica-tion for more details. This flag does not have any effectunless a master read operation is requested and theAA_I 2C_10_BI T_ADDR is also set.

AA_I 2C_NO_STOP Request that no stop condition is issued on the I2C bus af-ter the transaction completes. It is expected that the PCwill follow up with a subsequent transaction at which pointa repeated start will be issued on the bus. Eventually anI2C transaction must be issued without the “no stop” optionso that a stop condition is issued and the bus is freed.

6. Since firmware revision 3.00 it is possible for the Aardvark I2C master to return an extendedstatus code for master read and master write transactions. These codes are describedbelow and are returned by the aa_i 2c_r ead_ext and aa_i 2c_wr i t e_ext functions.

AA_I 2C_STATUS_BUS_ERROR A bus error has occurred. Transaction was aborted.

AA_I 2C_STATUS_SLA_ACK Bus arbitration was lost during master transaction; an-other master on the bus has successfully addressedthis Aardvark adapter's slave address. As a result,this Aardvark adapter has automatically switched toslave mode and is responding.



AA_I 2C_STATUS_SLA_NACK The Aardvark adapter failed to receive acknowledg-ment for the requested slave address during a masteroperation.

AA_I 2C_STATUS_DATA_NACK The last data byte in the transaction was not acknowl-edged by the slave.

AA_I 2C_STATUS_ARB_LOST Another master device on the bus was accessing thebus simultaneously with this Aardvark adapter. Thatdevice won arbitration of the bus as per the I2C speci-fication.

These codes can provide hints as to why an impartial transaction was executed by theAardvark adapter. In the event that a bus error occurs while the Aardvark adapter is idle andenabled as a slave (but not currently receiving a message), the adapter will return the buserror through the aa_i2c_slave_read function. The length of the message will be 0 bytes butthe status code will reflect the bus error.

GeneralI2C Pullup (aa_i2c_pullup)

i nt aa_i 2c_pul l up ( Aar dvar k aar dvar k, aa_u08 pul l up_mask) ;

Activate/deactivate I2C pull-up resistors on SCL and SDA.

Arguments


pul l up_mask: enumer at ed val ues speci f yi ng pul l up s t at e

AA_I 2C_PULLUP_NONE Disable SCL/SDA pull-up resistors

AA_I 2C_PULLUP_BOTH Enable SCL/SDA pull-up resistors

AA_I 2C_PULLUP_QUERY Queries the pull-up resistor state

Return Value

The current state of the I2C pull-up resistors on the Aardvark adapter will be re-turned. The configuration will be described by the same values as in the tableabove.


AA_I NCOMPATI BLE_DEVI CE: The hardware version is not compatible with thisfeature. Only hardware versions 2.00 or greater support switchable pull-upresistors pins.

Details

Both pull-up resistors are controlled together. Independent control is not sup-ported. This function may be performed in any operation mode.

Free bus (aa_i2c_free_bus)i nt aa_i 2c_f r ee_bus ( Aar dvar k aar dvar k) ;

Free the Aardvark I2C subsystem from a held bus condition (e.g., “no stop”).



Arguments


Return Value

An Aardvark status code is returned that is AA_OK on success.


AA_I 2C_ALREADY_FREE_BUS: The bus was already free and no action wastaken.

Details

If the Aardvark I2C subsystem had executed a master transaction and is holdingthe bus due to a previous AA_I 2C_NO_STOP flag, this function will issue the stopcommand and free the bus. If the bus is already free, it will return the status codeAA_I 2C_BUS_ALREADY_FREE.

Similarly, if the Aardvark I2C subsystem was placed into slave mode and in themiddle of a slave transaction, this command will disconnect the slave from thebus, flush the last transfer, and re-enable the slave. Such a feature is useful ifthe Aardvark adapter was receiving bytes but then was forced to wait indefinitelyon the bus because of the absence of the terminating stop command. After dis-abling the slave, any pending slave reception will be available to the host throughthe usual aa_i 2c_sl ave_wr i t e_st at s and aa_i 2c_sl ave_r ead API calls.

The bus is always freed (i.e., a stop command is executed if necessary) and theslave functions are disabled at software opening and closing of the device.

MasterSet Bitrate (aa_i2c_bitrate)

i nt aa_i 2c_bi t r at e ( Aar dvar k aar dvar k, i nt bi t r at e_khz) ;

Set the I2C bitrate in kilohertz.

Arguments


bi t r at e_khz: t he r equest ed bi t r at e i n khz.

Return Value

This function returns the actual bitrate set.


None.

Details

The power-on default bitrate is 100 kHz.

Only certain discrete bitrates are supported by the Aardvark I2C master interface.As such, this actual bitrate set will be less than or equal to the requested bitrate.

If bi t r at e_khz is 0, the function will return the bitrate presently set on theAardvark adapter and the bitrate will be left unmodified.



Master Read (aa_i2c_read)i nt aa_i 2c_r ead ( Aar dvar k aar dvar k, aa_u16 s l ave_addr , AA_I 2C_FLAGS f l ags, aa_u16 num_byt es, aa_u08 * dat a_i n) ;

Read a stream of bytes from the I2C slave device.

Arguments


sl ave_addr : t he s l ave f r om whi ch t o r ead

f l ags: speci al oper at i ons as descr i bed i n “ Not es” sect i on

num_byt es: t he number of byt es t o r ead ( maxi mum 65535)

dat a_i n: poi nt er t o dat a

Return Value

Number of bytes read.


AA_I 2C_READ_ERROR: There was an error reading from the Aardvark adapter.This is most likely a result of a communication error.

Details

For ordinary 7-bit addressing, the lower 7 bits of the addr should correspond tothe slave address. The topmost bits are ignored. The Aardvark I2C subsystemwill assemble the address along with the R/ Wbit after grabbing the bus. For 10-bit addressing, the lower 10 bits of addr should correspond to the slave address.The Aardvark adapter will then assemble the address into the proper format asdescribed in the Philips specification, namely by first issuing an write transactionon the bus to specify the 10-bit slave and then a read transaction to read the re-quested number of bytes. The initial write transaction can be skipped if the“Combined Format” feature is requested in conjunction with the 10-bit addressingfunctionality.

The dat a pointer should be allocated at least as large as num_byt es .

It is possible to read zero bytes from the slave. In this case, num_byt es is setto 0 and the dat a argument is ignored (i.e., it can be 0 or point to invalid memo-ry). However, due to the nature of the I2C protocol, it is not possible to addressthe slave and not request at least one byte. Therefore, one byte is actually re-ceived by the host, but is subsequently thrown away.

If the number of bytes read is zero, the following conditions are possible.� The requested slave was not found.� The requested slave is on the bus but refuses to acknowledge its ad-

dress.� The Aardvark adapter was unable to seize the bus due to the pres-

ence of another I2C master. Here, the arbitration was lost duringthe slave addressing phase – results can be unpredictable.



� Zero bytes were requested from a slave. The slave acknowledged itsaddress and returned 1 byte. That byte was dropped.

Ordinarily the number of bytes read, if not 0, will equal the requested number ofbytes. One special scenario in which this will not happen is if the Aardvarkadapter loses the bus during the data transmission due to the presence of anoth-er I2C master.

If the slave has fewer bytes to transmit than the number requested by the mas-ter, the slave will simply stop transmitting and the master will receive 0xf f foreach remaining byte in the transmission. This behavior is in accordance with theI2C protocol.

Master Read Extended (aa_i2c_read_ext)i nt aa_i 2c_r ead_ext ( Aar dvar k aar dvar k, aa_u16 sl ave_addr , AA_I 2C_FLAGS f l ags, aa_u16 num_byt es, aa_u08 * dat a_i n aa_u16 * num_r ead) ;

Read a stream of bytes from the I2C slave device with extended status information.

Arguments




num_byt es: t he number of byt es t o r ead ( maxi mum 65535)

dat a_i n: poi nt er t o dat a

num_r ead: t he act ual number of byt es r ead

Return Value

Status code (see “Notes” section).


None.

Details

This function operates exactly like aa_i 2c_r ead, except that the return valuenow specifies a status code. The number of bytes read is returned through anadditional pointer argument at the tail of the parameter list.

The status code allows the user to discover specific events on the I2C bus thatwould otherwise be transparent given only the number of bytes transacted. The“Notes” section describes the status codes.

For a master read operation, the AA_I 2C_STATUS_DATA_NACK flag is not usedsince the acknowledgment of data bytes is predetermined by the master and theI2C specification.

Master Write (aa_i2c_write)i nt aa_i 2c_wr i t e ( Aar dvar k aar dvar k, aa_u16 s l ave_addr ,



AA_I 2C_FLAGS f l ags, aa_u16 num_byt es, const aa_u08 * dat a_out ) ;

Write a stream of bytes to the I2C slave device.

Arguments




num_byt es: t he number of byt es t o wr i t e ( maxi mum 65535)

dat a_out : poi nt er t o dat a

Return Value

Number of bytes written.


AA_I 2C_WRI TE_ERROR: There was an error reading the acknowledgment fromthe Aardvark adapter. This is most likely a result of a communication error.

Details

For ordinary 7-bit addressing, the lower 7 bits of the addr should correspond tothe slave address. The topmost bits are ignored. The Aardvark I2C subsystemwill assemble the address along with the R/ Wbit after grabbing the bus. For 10-bit addressing, the lower 10 bits of addr should correspond to the slave address.The Aardvark adapter will then assemble the address into the proper format asdescribed in the Philips specification. There is a limitation that a maximum ofonly 65534 bytes can be written in a single transaction if the 10-bit addressingmode is used.

The sl ave_addr 0x00 has been reserved in the I2C protocol specification forgeneral call addressing. I2C slaves that are enabled to respond to a general callwill acknowledge this address. The general call is not treated specially in theAardvark I2C master. The user of this API can manually assemble the first databyte if the hardware address programming feature with general call is required.

It is actually possible to write 0 bytes to the slave. The slave will be addressedand then the stop condition will be immediately transmitted by the Aardvarkadapter. No bytes are sent to the slave, so the dat a argument is ignored (i.e., itcan be 0 or point to invalid memory).

If the number of bytes written is zero, the following conditions are possible.� The requested slave was not found.� The requested slave is on the bus but refuses to acknowledge its ad-

dress.� The Aardvark adapter was unable to seize the bus due to the pres-

ence of another I2C master. Here, the arbitration was lost duringthe slave addressing phase – results can be unpredictable.

� The slave was addressed and no bytes were written to it becausenum_byt es was set to 0.



The number of bytes written can be less than the requested number of bytes inthe transaction due to the following possibilities.

� The Aardvark adapter loses the bus during the data transmission dueto the presence of another I2C master.

� The slave refuses the reception of any more bytes.

Master Write Extended (aa_i2c_write_ext)i nt aa_i 2c_wr i t e_ext ( Aar dvar k aar dvar k, aa_u16 s l ave_addr , AA_I 2C_FLAGS f l ags, aa_u16 num_byt es, const aa_u08 * dat a_out aa_u16 * num_wr i t t en) ;

Write a stream of bytes to the I2C slave device with extended status information.

Arguments




num_byt es: t he number of byt es t o wr i t e ( maxi mum 65535)

dat a_out : poi nt er t o dat a

num_wr i t t en: t he act ual number of byt es wr i t t en

Return Value



None.

Details

This function operates exactly like aa_i 2c_wr i t e, except that the return valuenow specifies a status code. The number of bytes written is returned through anadditional pointer argument at the tail of the parameter list.

The status code allows the user to discover specific events on the I2C bus thatwould otherwise be transparent given only the number of bytes transacted. The“Notes” section describes the status codes.

For a master write operation, the AA_I 2C_STATUS_DATA_NACK flag can beuseful in the following situation:

� Normally the I2C master will write to the slave until the slave issues a NACK orthe requested number of bytes have been written.

� If the master has wishes to write 10 bytes, the I2C slave issues either an ACKor NACK on the tenth byte without affecting the total number of bytes trans-ferred. Hence, the aa_i 2c_wr i t e function cannot provide the caller with theinformation that the 10th byte was ACK'ed or NACK'ed.

� On the other hand, if the aa_i 2c_wr i t e_ext is used, the status code willdistinguish the two scenarios. This status information could be useful for fur-



ther communications with that particular slave device.

SlaveSlave Enable (aa_i2c_slave_enable)

i nt aa_i 2c_sl ave_enabl e ( Aar dvar k aar dvar k, aa_u08 addr , aa_u16 maxTxByt es, aa_u16 maxRxByt es) ;

Enable the Aardvark adapter as an I2C slave device.

Arguments


addr : addr ess of t hi s sl ave

maxTxByt es: max number of byt es t o t r ansmi t per t r ansact i on

maxRxByt es: max number of byt es t o r ecei ve per t r ansact i on

Return Value



None.

Details

The lower 7 bits of addr should correspond to the slave address of this Aardvarkadapter. If the topmost bit of addr is set, the slave will respond to a general calltransmission by an I2C master. After having been addressed by a general call,the Aardvark I2C slave treats the transaction no differently than a single slavecommunication. There is no support for the hardware address programming fea-ture of the general call that is described in the I2C protocol specification sincethat capability is not needed for Aardvark devices.

If maxTxByt es is 0, there is no limit on the number of bytes that this slave willtransmit per transaction. If it is non-zero, then the slave will stop transmittingbytes at the specified limit and subsequent bytes received by the master will be0xf f due to the bus pull-up resistors. The response that is transmitted by theslave is set through the aa_i 2c_sl ave_set _r esponse function described be-low. If the maximum is greater than the response (as set throughaa_i 2c_sl ave_set _r esponse) the Aardvark slave will wrap the responsestring as many times as necessary to send the requested number of bytes.

If maxRxByt es is 0, the slave can receive an unlimited number of bytes from themaster. However, if it is non-zero, the slave will send a not-acknowledge bit afterthe last byte that it accepts. The master should then release the bus. Even if themaster does not stop transmitting, the slave will return the received data back tothe host PC and then transition to a idle state, waiting to be addressed in a sub-sequent transaction.

It is never possible to restrict a transmit or receive to 0 bytes. Furthermore, oncethe slave is addressed by a master read operation it is always guaranteed totransmit at least 1 byte.



If a master transaction is executed after the slave features have been enabled,the slave features will remain enabled after the master transaction completes.

Slave Disable (aa_i2c_slave_disable)i nt aa_i 2c_sl ave_di sabl e ( Aar dvar k aar dvar k) ;

Disable the Aardvark adapter as an I2C slave device.

Arguments


Return Value



None.

Slave Set Response (aa_i2c_slave_set_response)i nt aa_i 2c_sl ave_set _r esponse ( Aar dvar k aar dvar k, aa_u08 num_byt es, const aa_u08 * dat a_out ) ;

Set the slave response in the event the Aardvark adapter is put into slave mode and con-tacted by a master.

Arguments


num_byt es: number of byt es f or t he sl ave r esponse

dat a_out : poi nt er t o t he sl ave r esponse

Return Value

The number of bytes accepted by the Aardvark slave for the response.


None.

Details

The value of num_byt es must be greater than zero. If it is zero, the responsestring is undefined until this function is called with the correct parameters.

Due to limited buffer space on the Aardvark slave, the device may only accept aportion of the intended response. If the value returned by this function is lessthan num_byt es the Aardvark slave has dropped the remainder of the bytes.

If more bytes are requested in a transaction, the response string will be wrappedas many times as necessary to complete the transaction.

The buffer space will nominally be 64 bytes but can change depending onfirmware revision.

Slave Write Statistics (aa_i2c_slave_write_stats)i nt aa_i 2c_sl ave_wr i t e_st at s ( Aar dvar k aar dvar k) ;

Return number of bytes written from a previous Aardvark I2C slave to I2C master transmis-sion.



Arguments


Return Value

The number of bytes written asynchronously.


AA_I 2C_SLAVE_TI MEOUT: There was no recent slave transmission.

Details

The transmission of bytes from the Aardvark slave, when it is configured as anI2C slave, is asynchronous with respect to the PC host software. Hence, therecould be multiple responses queued up from previous write transactions.

This function will wait 500 milliseconds before timing out. See theaa_async_pol l function if a variable timeout is required.

Slave Write Statistics Extended (aa_i2c_slave_write_stats_ext)i nt aa_i 2c_sl ave_wr i t e_st at s_ext ( Aar dvar k aar dvar k,

aa_u16 * num_wr i t t en) ;

Return number of bytes written from a previous Aardvark I2C slave to I2C master transmis-sion with extended status information.

Arguments


num_wr i t t en: t he number of byt es wr i t t en by t he s l ave

Return Value



None.

Details

This function operates exactly like aa_i 2c_sl ave_wr i t e_st at s , except thatthe return value now specifies a status code. The number of bytes written is re-turned through an additional pointer argument at the tail of the parameter list.

The only possible status code is AA_I2C_STATUS_BUS_ERROR which can oc-cur when an illegal START, STOP, or RESTART condition appears on the busduring a transaction. In this case the num_written may not exactly reflect thenumber of bytes written by the slave. It can be off by 1.

Slave Read (aa_i2c_slave_read)i nt aa_i 2c_sl ave_r ead ( Aar dvar k aar dvar k, aa_u08 * addr , aa_u16 num_byt es, aa_u08 * dat a_out ) ;

Read the bytes from an I2C slave reception.



Arguments


addr : t he addr ess t o whi ch t he r ecei ved message was sent

num_byt es: t he maxi mum s i ze of t he dat a buf f er

dat a_out : poi nt er t o dat a buf f er

Return Value

This function returns the number of bytes read asynchronously.


AA_I 2C_SLAVE_TI MEOUT: There was no recent slave transmission.

AA_I 2C_DROPPED_EXCESS_BYTES: The msg was larger than num_byt es .

Details

If the message was directed to this specific slave, * addr will be set to the valueof this slave's address. However, this slave may have received this messagethrough a general call addressing. In this case, * addr will be 0x80 instead of itsown address.

The num_byt es parameter specifies the size of the memory pointed to by dat a.It is possible, however, that the received slave message exceeds this length. Insuch a situation, AA_I 2C_DROPPED_EXCESS_BYTES is returned, meaning thatnum_byt es was placed into dat a but the remaining bytes were discarded.

There is no cause for alarm if the number of bytes read is less than num_byt es .This simply indicates that the incoming message was short.

The reception of bytes by the Aardvark slave, when it is configured as an I2Cslave, is asynchronous with respect to the PC host software. Hence, there couldbe multiple responses queued up from previous transactions.


Slave Read Extended (aa_i2c_slave_read_ext)i nt aa_i 2c_sl ave_r ead_ext ( Aar dvar k aar dvar k, aa_u08 * addr , aa_u16 num_byt es, aa_u08 * dat a_out aa_u16 * num_r ead) ;

Read the bytes from an I2C slave reception with extended status information.

Arguments


addr : t he addr ess t o whi ch t he r ecei ved message was sent


dat a_out : poi nt er t o dat a buf f er

num_r ead: t he act ual number of byt es r ead by t he s l ave



Return Value



None.

Details

This function operates exactly like aa_i 2c_sl ave_r ead, except that the returnvalue now specifies a status code. The number of bytes read is returned throughan additional pointer argument at the tail of the parameter list.

The only possible status code is AA_I2C_STATUS_BUS_ERROR which can oc-cur when an illegal START, STOP, or RESTART condition appears on the busduring a transaction.



5.6 SPI Interface

Notes1. The SPI master and slave must both be configured to use the same bit protocol (mode).

2. It is not necessary to set the bitrate for the Aardvark SPI slave.

3. An SPI master operation read or write operation can be transacted while leaving the SPIslave functionality enabled. During the master transaction, the slave will be temporarily de-activated. Once the master transaction is complete, the slave will be automatically reactivat-ed.

4. It is always advisable to set the slave response before first enabling the slave. This ensuresthat valid data is sent to any requesting master.

5. It is not possible to receive messages larger than approximately 4 KiB as a slave due to op-erating system limitations on the asynchronous incoming buffer. As such, one should notqueue up more than 4 KiB of total slave data between calls to the Aardvark API.

6. It is not possible to send messages larger than approximately 4 KiB as a master due to oper-ating system limitations on the asynchronous incoming buffer. The SPI is full-duplex sothere must be enough buffer space to accommodate the slave response when sending as amaster.

7. Sending zero bytes as an SPI master will simply toggle the slave select line for 5–10 s.µ

GeneralConfigure (aa_spi_configure)

i nt aa_spi _conf i gur e ( Aar dvar k aar dvar k, AA_SPI _POLARI TY pol ar i t y , AA_SPI _PHASE phase, AA_SPI _BI TORDER bi t or der ) ;

Configure the SPI master or slave interface.

Arguments


pol ar i t y: AA_SPI _POL_RI SI NG_FALLI NG or AA_SPI _POL_FALLI NG_RI SI NG

phase: AA_SPI _PHASE_SAMPLE_SETUP or AA_SPI _PHASE_SETUP_SAMPLE

bi t or der : AA_SPI _BI TORDER_MSB or AA_SPI _BI TORDER_LSB

Return Value



None.

Details

These configuration parameters specify how to clock the bits that are sent andreceived on the Aardvark SPI interface.

The polarity option specifies which transition constitutes the leading edge andwhich transition is the falling edge. For example, AA_SPI _POL_RI SI NG_FALLI NG



would configure the SPI to idle the SCLK clock line low. The clock would thentransition low-to-high on the leading edge and high-to-low on the trailing edge.

The phase option determines whether to sample or setup on the leading edge.For example, AA_SPI _PHASE_SAMPLE_SETUP would configure the SPI to sampleon the leading edge and setup on the trailing edge.

The bitorder option is used to indicate whether LSB or MSB is shifted first.

The pair (AA_SPI _POL_FALLI NG_RI SI NG, AA_SPI _PHASE_SETUP_SAMPLE) wouldcorrespond to mode 3 in the figure found in the “SPI Background” chapter.

MasterSet Bitrate (aa_spi_bitrate)

i nt aa_spi _bi t r at e ( Aar dvar k aar dvar k, i nt bi t r at e_khz) ;

Set the SPI bitrate in kilohertz.

Arguments


bi t r at e_khz: t he r equest ed bi t r at e i n khz.

Return Value

This function returns the actual bitrate set.


None.

Details

The power-on default bitrate is 1000 kHz.

Only certain discrete bitrates are supported by the Aardvark adapter. As such,this actual bitrate set will be less than or equal to the requested bitrate unless therequested value is less than 125 kHz, in which case the Aardvark adapter willdefault to 125 kHz.

If bi t r at e_khz is 0, the function will return the bitrate presently set on theAardvark adapter and the bitrate will be left unmodified.

Set Slave Select Polarity (aa_spi_master_ss_polarity)i nt aa_spi _mast er _ss_pol ar i t y ( Aar dvar k aar dvar k, AA_SPI _SS_POLARI TY pol ar i t y) ;

Change the output polarity on the SS line.

Arguments


pol ar i t y: AA_SPI _SS_ACTI VE_LOW or AA_SPI _SS_ACTI VE_HI GH

Return Value



None.



Details

This function only affects the SPI master functions on the Aardvark adapter.When configured as an SPI slave, the Aardvark adapter will always be setup withSS as active low.

Master Write/Read (aa_spi_write)i nt aa_spi _wr i t e ( Aar dvar k aar dvar k, aa_u16 num_byt es, const aa_u08 * dat a_out , aa_u08 * dat a_i n) ;

Write a stream of bytes to the downstream SPI slave device and read back the full-duplexresponse.

Arguments


num_byt es: number of byt es t o send

dat a_out : poi nt er t o t he byt es t o t r ansmi t out

dat a_i n: poi nt er t o memor y t hat wi l l hol d t he r ecei ved dat a

Return Value

This function returns the total number of bytes read from the slave which normal-ly will be the same as the number of bytes written to the slave.


AA_SPI _WRI TE_ERROR: There was an error writing to the Aardvark adapter.This is most likely a result of a communication error. Make sure thatnum_byt es is less than 4 KiB.

Details

The dat a_i n pointer should reference memory that is at least allocated to thesize specified by num_byt es . Otherwise there will be a memory access viola-tion in the program.

If num_byt es is 0, no bytes will be written to the slave. However, the slave se-lect line will be dropped for 5–10 s.µ This can be useful in sending a signal to adownstream SPI slave without actually sending any bytes. For example, if anSPI slave has tied the slave select to an interrupt line and it sees the line is tog-gled without any bytes sent, it can interpret the action as a command to prepareits firmware for an subsequent reception of bytes. If num_byt es is 0, dat a_outand dat a_i n are completely ignored by this function and can be set to 0.

If the return value of this function is less than num_byt es , there was an error.SPI is a bit-blasting scheme where the master does not even know if there is aslave on the other end of the transmission. Therefore, it is always expected thatthe master will send the entire length of the transaction.

An error will likely occur if the number of bytes sent is significantly greater than 4KiB. This function cannot reliably execute larger transfers due to the buffering is-sues explained in the “Software | Application Notes” section. Only a partial num-ber of bytes will be sent to the slave and only a partial number will be receivedfrom the slave; it is quite possible that these numbers will not be equal. The size



of the partial response is returned by this function and the data will be in thememory pointed to by dat a_i n. Note that the last few bytes of the responsemay be corrupted as well.

SlaveSlave Enable (aa_spi_slave_enable)

i nt aa_spi _s l ave_enabl e ( Aar dvar k aar dvar k) ;

Enable the Aardvark as an SPI slave device.

Arguments


Return Value



None.

Slave Disable (aa_spi_slave_disable)i nt aa_spi _s l ave_di sabl e ( Aar dvar k aar dvar k) ;

Disable the Aardvark as an SPI slave device.

Arguments


Return Value



None.

Slave Set Response (aa_spi_slave_set_response)i nt aa_spi _s l ave_set _r esponse ( Aar dvar k aar dvar k, aa_u08 num_byt es, const aa_u08 * dat a_out ) ;

Set the slave response in the event the Aardvark adapter is put into slave mode and con-tacted by a master.

Arguments


num_byt es: number of byt es f or t he sl ave r esponse

dat a_out : poi nt er t o t he sl ave r esponse

Return Value

The number of bytes accepted by the Aardvark for the response.


None.



Details

The value of num_byt es must be greater than zero. If it is zero, the responsestring is undefined until this function is called with the correct parameters.

Due to limited buffer space on the Aardvark slave, the device may only accept aportion of the intended response. If the value returned by this function is lessthan num_byt es the Aardvark slave has dropped the remainder of the bytes.

If more bytes are requested in a transaction, the response string will be wrappedas many times as necessary to complete the transaction.

The buffer space will nominally be 64 bytes but may change depending onfirmware revision.

Slave Read (aa_spi_slave_read)i nt aa_spi _s l ave_r ead ( Aar dvar k aar dvar k, aa_u16 num_byt es, aa_u08 * dat a_i n) ;

Read the bytes from an SPI slave reception.

Arguments



dat a_i n: poi nt er t o dat a buf f er

Return Value

This function returns the number of bytes read asynchronously.


AA_SPI _SLAVE_TI MEOUT: There was no recent slave transmission.

AA_SPI _DROPPED_EXCESS_BYTES: The msg was larger than num_byt es .

Details

The num_byt es parameter specifies the size of the memory pointed to by dat a.It is possible, however, that the received slave message exceeds this length. Insuch a situation, AA_SPI _DROPPED_EXCESS_BYTES is returned, meaning thatnum_byt es was placed into dat a but the remaining bytes were discarded.

There is no cause for alarm if the number of bytes read is less than num_byt es .This simply indicates that the incoming message was short.

The reception of bytes by the Aardvark adapter, when it is configured as an SPIslave, is asynchronous with respect to the PC host software. Hence, there couldbe multiple responses queued up from previous write transactions.


The SPI API does not include a function that is analogous to the I2C functionaa_i 2c_sl ave_wr i t e_st at s . Since SPI is a full-duplex standard, the slavewrites to the master whenever it receives bytes from the master. Hence, a re-ceived message from aa_i 2c_sl ave_r ead implies that an equal number ofbytes were sent to the master.



5.7 GPIO Interface

Notes1. The following enumerated type maps the named lines on the Aardvark I2C/SPI output cable

to bit positions in the GPIO API. All GPIO API functions will index these lines through a sin-gle 8-bit masked value. Thus, each bit position in the mask can be referred back its corre-sponding line through the mapping described below.

AA_GPI O_BI TS: enumer at ed t ype of l i ne l ocat i ons i n bi t mask

AA_GPI O_SCL Pin 1 0x01 I2C SCL line

AA_GPI O_SDA Pin 3 0x02 I2C SDA line

AA_GPI O_MI SO Pin 5 0x04 SPI MISO line

AA_GPI O_SCK Pin 7 0x08 SPI SCK line

AA_GPI O_MOSI Pin 8 0x10 SPI MOSI line

AA_GPI O_SS Pin 9 0x20 SPI SS line

2. There is no check in the GPIO API calls to see if a particular GPIO line is enabled in the cur-rent configuration. If a line is not enabled for GPIO, the get function will simply return 0 forthose bits. Another example is if one changes the GPIO directions for I2C lines while the I2Csubsystem is still active. These new direction values will be cached and will automatically beactivate if a later call to aa_conf i gur e disables the I2C subsystem and enables GPIO forthe I2C lines. The same type of behavior holds for aa_gpi o_pul l up and aa_gpi o_set .

3. Additionally, for lines that are not configured as inputs, a change in the pullup configurationusing aa_gpi o_pul l up will be cached and will take effect the next time the line is activeand configured as an input. The same behavior holds for aa_gpi o_set when a line is con-figured as an input instead of an output.

4. On Aardvark adapter power-up, directions default to all input, pullups default to disabled andoutputs default to logic low. Also the GPIO subsystem is off by default. It must be activatedby using aa_conf i gur e.

5. Note: For hardware version 1.02, it is not possible to have high-Z inputs on the I2C linessince that hardware has 2.2K pullups on the I2C bus.

InterfaceDirection (aa_gpio_direction)

i nt aa_gpi o_di r ect i on ( Aar dvar k aar dvar k, aa_u08 di r ect i on_mask) ;

Change the direction of the GPIO lines between input and output directions.

Arguments


di r ect i on_mask: each bi t cor r esponds t o t he physi cal l i neas gi ven by AA_GPI O_BI TS. I f a l i ne' s bi t i s 0, t he l i nei s conf i gur ed as an i nput . Ot her wi se i t wi l l be an out -put .

Return Value





None.

Details

None.

Pullup (aa_gpio_pullup)i nt aa_gpi o_pul l up ( Aar dvar k aar dvar k, aa_u08 pul l up_mask) ;

Change the pullup configuration of the GPIO lines.

Arguments


pul l up_mask: each bi t cor r esponds t o t he physi cal l i ne asgi ven by AA_GPI O_BI TS. I f a l i ne' s bi t i s 1, t he l i ne' spul l up i s act i ve whenever t he l i ne i s conf i gur ed as ani nput . Ot her wi se t he pul l up wi l l be deact i vat ed.

Return Value



None.

Details

None.

Get (aa_gpio_get)i nt aa_gpi o_get ( Aar dvar k aar dvar k) ;

Get the value of current GPIO inputs.

Arguments


Return Value

An integer value, organized as a bitmask in the fashion described byAA_GPI O_BI TS. Any line that is logic high will have a its corresponding bit ac-tive. If the line is logic low the bit will not be active in the bit mask.


None.

Details

A line's bit position in the mask will be 0 if it is configured as an output or if it cor-responds to a subsystem that is still active.

Set (aa_gpio_set)i nt aa_gpi o_set ( Aar dvar k aar dvar k, aa_u08 val ue) ;

Set the value of current GPIO outputs.



Arguments


val ue: a bi t mask speci f y i ng whi ch out put s shoul d be set t ol ogi c hi gh and whi ch shoul d be set t o l ogi c l ow.

Return Value



None.

Details

If a line is configured as an input or not activated for GPIO, the output value willbe cached. The next time the line is an output and activated for GPIO, the out-put value previously set will automatically take effect.



5.8 I2C Bus Monitor

Notes1. The Aardvark adapter can continuously monitor I2C traffic up to 125 khz. It may be possible

to monitor higher bitrates for small transactions, but the reliability is not guaranteed.

2. Activating the bus monitor will disable all other functions on the Aardvark adapter and flushall pending asynchronous messages. The Aardvark adapter will be placed into the AA_CON-FI G_GPI O_ONLY mode by default. Once the bus monitor is disabled, the user must useaa_conf i gur e to re-enable either I2C or SPI functions if these operations are required.

3. Once the bus monitor is enabled, the execution of any other communication function on theAardvark adapter will disable the bus monitor.

4. The I2C pullup resistors can be enabled or disabled during I2C monitor use. Simply use theaa_i 2c_pul l up function before enabling the bus monitor.

5. Once enabled, the I2C monitor automatically monitors the attached I2C bus and returns databack to the host asynchronously. Due to operating system limitations on the asynchronousincoming buffer, one must ensure that the asynchronous data is serviced regularly. As such,one should not queue up more than 4 KiB of total monitor data between calls to the AardvarkAPI. For example, problems can arise when there is a high flow of traffic on the bus that isbeing monitored.

FunctionsMonitor Enable (aa_i2c_monitor_enable)

i nt aa_i 2c_moni t or _enabl e ( Aar dvar k aar dvar k) ;

Enable the Aardvark adapter as an I2C monitoring device.

Arguments


Return Value



None.

Details

This function has a 100 ms delay to flush all communications buffers.

Monitor Disable (aa_i2c_monitor_disable)i nt aa_moni t or _sl ave_di sabl e ( Aar dvar k aar dvar k) ;

Disable the Aardvark adapter as an I2C monitoring device.

Arguments


Return Value





None.

Details

This function has a 100 ms delay to flush all communications buffers.

Monitor Read (aa_i2c_monitor_read)i nt aa_i 2c_moni t or _r ead ( Aar dvar k aar dvar k, aa_u16 num_byt es, aa_u16 * dat a) ;

Read the bytes from an I2C monitor operation.

Arguments



dat a: poi nt er t o dat a buf f er

Return Value

This function returns the number of monitor bytes read.


AA_I 2C_MONI TOR_NOT_ENABLED: The monitor functionality was not enabled.

Details

Once enabled, the I2C monitor automatically monitors the attached I2C bus andreturns data back to the host asynchronously. This function allows the PC to re-trieve the asynchronous data into a buffer for analysis.

The monitored data is returned in a semi-raw format. The returned data buffercontains all information about bit-level signaling on the bus. Parsing this informa-tion is simple and the user is referred to the examples that are included with theAardvark software distribution. Furthermore, the Control Center applicationdemonstrates a GUI that uses this monitoring function.

The information in each element of the returned buffer is marked as follows:

1. Element is equal to the constant AA_I 2C_MONI TOR_CMD_START(0xf f 00) if a start bit has been encountered.

2. Element is equal to the constant AA_I 2C_MONI TOR_CMD_STOP(0xf f 01) if a start bit has been encountered.

3. If the element is neither a start or stop bit, the bottom 8-bits are equalto the 8 data bits of the I2C transaction.

4. The element can have the 9th bit equal to 1 if the data byte was not ac-knowledged by the I2C receiving device. One can test for this condi-tion by bitwise AND'ing the element with AA_I 2C_MONI TOR_NACK(0x100).

The monitor function returns one I2C transaction at a time. It expects that everytransaction starts with an I2C START bus signal. The function returns when en-countering a STOP command. The application can then process the transaction



and call the monitor function again to process a subsequent transaction.

In the event of a repeated start on the bus, the incoming buffer will contain aSTART code without a prior STOP code. All traffic between the initial STARTcommand and the final STOP command will be returned in one call to this func-tion.

As per the I2C protocol, the slave address is the first byte transmitted after theSTART command. The user can analyze this byte to determine the slave ad-dress for the bus transaction as well as the direction of the transaction (i.e., mas-ter read versus master write). The top 7 bits of the byte correspond to the slaveaddress and the least significant bit denotes the transfer direction. See thePhilips I2C protocol definition for more details.

There can be bit alignment issues if the monitor is plugged into a bus that is al-ready in the middle of an I2C transaction. The data will most likely be corrupted.Likewise, there can be corruption if there is an overflow of the operating system'sreceive buffer.




5.9 Error Codes

Literal Name Value aa_status_string() return value

AA_OK 0 ok

AA_UNABLE_TO_LOAD_LI BRARY -1 unable to load library

AA_UNABLE_TO_LOAD_DRI VER -2 unable to load USB driver

AA_UNABLE_TO_LOAD_FUNCTI ON -3 unable to load binding function

AA_I NCOMPATI BLE_LI BRARY -4 incompatible library version

AA_I NCOMPATI BLE_DEVI CE -5 incompatible device version

AA_COMMUNI CATI ON_ERROR -6 communication error

AA_UNABLE_TO_OPEN -7 unable to open device

AA_UNABLE_TO_CLOSE -8 unable to close device

AA_I NVALI D_HANDLE -9 invalid device handle

AA_CONFI G_ERROR -10 configuration error

AA_I 2C_NOT_AVAI LABLE -100 i2c feature not available

AA_I 2C_NOT_ENABLED -101 i2c not enabled

AA_I 2C_READ_ERROR -102 i2c read error

AA_I 2C_WRI TE_ERROR -103 i2c write error

AA_I 2C_SLAVE_BAD_CONFI G -104 i2c slave enable bad config

AA_I 2C_SLAVE_READ_ERROR -105 i2c slave read error

AA_I 2C_SLAVE_TI MEOUT -106 i2c slave timeout

AA_I 2C_DROPPED_EXCESS_BYTES -107 i2c slave dropped excess bytes

AA_I 2C_BUS_ALREADY_FREE -108 i2c bus already free

AA_SPI _NOT_AVAI LBLE -200 spi feature not available

AA_SPI _NOT_ENABLED -201 spi not enabled

AA_SPI _WRI TE_ERROR -202 spi write error

AA_SPI _SLAVE_READ_ERROR -203 spi slave read error

AA_SPI _SLAVE_TI MEOUT -204 spi slave timeout

AA_SPI _DROPPED_EXCESS_BYTES -205 spi slave dropped excess bytes

AA_GPI O_NOT_AVAI LABLE -400 gpio feature not available

AA_I 2C_MONI TOR_NOT_AVAI LABLE -500 I2c bus monitor feature not available

AA_I 2C_MONI TOR_NOT_ENABLED -501 I2c bus monitor not enabledTable 1: Aardvark API Error Codes



6. Legal / Contact

6.1 Disclaimer

All of the software and documentation provided in this datasheet, is copy-right Total Phase, Inc. ("Total Phase"). License is granted to the user tofreely use and distribute the software and documentation in complete andunaltered form, provided that the purpose is to use or evaluate TotalPhase products. Distribution rights do not include public posting or mir-roring on Internet websites. Only a link to the Total Phase download areacan be provided on such public websites.

Total Phase shall in no event be liable to any party for direct, indirect,special, general, incidental, or consequential damages arising from theuse of its site, the software or documentation downloaded from its site, orany derivative works thereof, even if Total Phase or distributors havebeen advised of the possibility of such damage. The software, its docu-mentation, and any derivative works is provided on an "as-is" basis, andthus comes with absolutely no warranty, either express or implied. Thisdisclaimer includes, but is not limited to, implied warranties of mer-chantability, fitness for any particular purpose, and non-infringement. To-tal Phase and distributors have no obligation to provide maintenance,support, or updates.

Information in this document is subject to change without notice andshould not be construed as a commitment by Total Phase. While the in-formation contained herein is believed to be accurate, Total Phase as-sumes no responsibility for any errors and/or omissions that may appearin this document.

6.2 Life Support Equipment Policy

Total Phase products are not authorized for use in life support devices orsystems. Life support devices or systems include, but are not limited to,surgical implants, medical systems, and other safety-critical systems inwhich failure of a Total Phase product could cause personal injury or lossof life. Should a Total Phase product be used in such an unauthorizedmanner, Buyer agrees to indemnify and hold harmless Total Phase, itsofficers, employees, affiliates, and distributors from any and all claimsarising from such use, even if such claim alleges that Total Phase wasnegligent in the design or manufacture of its product.

6.3 Contact Information

Total Phase can be found on the Internet at http://www.totalphase.com/.If you have Aardvark support-related questions, please email the productengineers at [email protected]. For questions about TotalPhase's corporate services, please send inquiries to [email protected].


© 2002-2004 Total Phase, Inc.All rights reserved.


Table of Contents

Features...................................................................................................................................1

Summary.................................................................................................................................1

1. General Overview................................................................................................................2

1.1 I2C Background............................................................................................................................2 History.......................................................................................................................................................2 Theory of Operation...................................................................................................................................2 Features....................................................................................................................................................3 Benefits and Drawbacks............................................................................................................................3 References................................................................................................................................................3

1.2 SPI Background............................................................................................................................4 History.......................................................................................................................................................4 Theory of Operation...................................................................................................................................4 Modes........................................................................................................................................................5 Benefits and Drawbacks............................................................................................................................5 References................................................................................................................................................5

2. Hardware Specifications.....................................................................................................6

2.1 Pinouts..........................................................................................................................................6 Ground.......................................................................................................................................................6 I2C Pins.....................................................................................................................................................6 SPI Pins.....................................................................................................................................................6 Powering Downstream Devices.................................................................................................................6

2.2 Signal Levels/Voltage Ratings......................................................................................................7 Logic High Levels......................................................................................................................................7 ESD protection..........................................................................................................................................7 Drive Current.............................................................................................................................................7

2.3 I2C Signaling Characteristics.......................................................................................................7 Speed........................................................................................................................................................7 Pull-up Resistors.......................................................................................................................................8 I2C Clock Stretching..................................................................................................................................8 Known Limitations.....................................................................................................................................8

2.4 SPI Signaling Characteristics.......................................................................................................9 SPI Waveforms..........................................................................................................................................9 Speeds....................................................................................................................................................10 Pin Driving...............................................................................................................................................10 Known Limitations...................................................................................................................................10 Aardvark Device Power Consumption.....................................................................................................11

2.5 USB 1.1 Compliance..................................................................................................................11

2.6 Temperature Specifications........................................................................................................11

3. Software..............................................................................................................................12

3.1 Compatibility...............................................................................................................................12



Linux........................................................................................................................................................12 Windows..................................................................................................................................................12

3.2 Linux USB Driver........................................................................................................................12 USB Hotplug............................................................................................................................................12 Driver Installation/Uninstallation..............................................................................................................12

3.3 Windows USB Driver..................................................................................................................13 Driver Installation.....................................................................................................................................13 Driver Removal........................................................................................................................................14

3.4 USB Port Assignment.................................................................................................................14 Linux........................................................................................................................................................14 Windows..................................................................................................................................................14 Detecting Ports........................................................................................................................................15

3.5 Aardvark Dynamically Linked Library.........................................................................................16 Philosophy...............................................................................................................................................16 DLL Location...........................................................................................................................................16 Versioning................................................................................................................................................17

3.6 Rosetta Language Bindings: API Integration into Custom Applications....................................17 Overview..................................................................................................................................................17 Versioning................................................................................................................................................18 Customizations........................................................................................................................................18

3.7 Application Notes........................................................................................................................18 Asynchronous Messages........................................................................................................................18 Receive Saturation..................................................................................................................................18 Threading................................................................................................................................................19 USB Scheduling Delays..........................................................................................................................19

4. Firmware.............................................................................................................................21

4.1 Field Upgrades...........................................................................................................................21 Philosophy...............................................................................................................................................21 Procedure................................................................................................................................................21

5. API Documentation...........................................................................................................23

5.1 Introduction.................................................................................................................................23

5.2 General Data Types...................................................................................................................23

5.3 Notes on Status Codes...............................................................................................................23

5.4 General API calls........................................................................................................................25 Find Devices (aa_find_devices)..............................................................................................................25 Find Devices (aa_find_devices_ext)........................................................................................................25 Open an Aardvark device (aa_open).......................................................................................................26 Open an Aardvark device (aa_open_ext)................................................................................................26 Close an Aardvark (aa_close).................................................................................................................28 Get Port (aa_port)....................................................................................................................................28 Get Features (aa_features).....................................................................................................................28 Get Unique ID (aa_unique_id).................................................................................................................29 Status String (aa_status_string)..............................................................................................................29 Logging (aa_log)......................................................................................................................................29



Version (aa_version)...............................................................................................................................30 Configure (aa_configure).........................................................................................................................30 Target Power (aa_target_power).............................................................................................................31 Asynchronous Polling (aa_async_poll)....................................................................................................32

5.5 I2C Interface...............................................................................................................................34

Notes.........................................................................................................................................34

General......................................................................................................................................35 I2C Pullup (aa_i2c_pullup)......................................................................................................................35 Free bus (aa_i2c_free_bus)....................................................................................................................35

Master........................................................................................................................................36 Set Bitrate (aa_i2c_bitrate)......................................................................................................................36 Master Read (aa_i2c_read).....................................................................................................................37 Master Read Extended (aa_i2c_read_ext)..............................................................................................38 Master Write (aa_i2c_write).....................................................................................................................38 Master Write Extended (aa_i2c_write_ext)..............................................................................................40

Slave..........................................................................................................................................41 Slave Enable (aa_i2c_slave_enable)......................................................................................................41 Slave Disable (aa_i2c_slave_disable).....................................................................................................42 Slave Set Response (aa_i2c_slave_set_response)................................................................................42 Slave Write Statistics (aa_i2c_slave_write_stats)...................................................................................42 Slave Write Statistics Extended (aa_i2c_slave_write_stats_ext)............................................................43 Slave Read (aa_i2c_slave_read)............................................................................................................43 Slave Read Extended (aa_i2c_slave_read_ext).....................................................................................44

5.6 SPI Interface...............................................................................................................................46

Notes.........................................................................................................................................46

General......................................................................................................................................46 Configure (aa_spi_configure)..................................................................................................................46

Master........................................................................................................................................47 Set Bitrate (aa_spi_bitrate)......................................................................................................................47 Set Slave Select Polarity (aa_spi_master_ss_polarity)...........................................................................47 Master Write/Read (aa_spi_write)...........................................................................................................48

Slave..........................................................................................................................................49 Slave Enable (aa_spi_slave_enable)......................................................................................................49 Slave Disable (aa_spi_slave_disable).....................................................................................................49 Slave Set Response (aa_spi_slave_set_response)................................................................................49 Slave Read (aa_spi_slave_read)............................................................................................................50

5.7 GPIO Interface............................................................................................................................51

Notes.........................................................................................................................................51

Interface.....................................................................................................................................51 Direction (aa_gpio_direction)...................................................................................................................51 Pullup (aa_gpio_pullup)...........................................................................................................................52 Get (aa_gpio_get)....................................................................................................................................52 Set (aa_gpio_set)....................................................................................................................................52

5.8 I2C Bus Monitor..........................................................................................................................54

Notes.........................................................................................................................................54

Functions...................................................................................................................................54



Monitor Enable (aa_i2c_monitor_enable)................................................................................................54 Monitor Disable (aa_i2c_monitor_disable)..............................................................................................54 Monitor Read (aa_i2c_monitor_read)......................................................................................................55

5.9 Error Codes................................................................................................................................57

6. Legal / Contact...................................................................................................................58

6.1 Disclaimer...................................................................................................................................58

6.2 Life Support Equipment Policy...................................................................................................58

6.3 Contact Information....................................................................................................................58


total phase - university of minnesota...total phase aardvark i2c/spi embedded systems interface data...

Documents