Total Phase Blog

I have multiple Aardvark^TM I2C/SPI Host Adapters and I plan to use them for a production flow; programming SPI EEPROMs (Microchip 93AA56AT-I/OT). It looks like this device is not supported by Flash Center Software. Also, to program this device, it looks like polarity needs to be set as "active high". Can you send me information about editing SS polarity for this device?

Thanks for your question! In a recent update of the Flash Center^TM Software, for greater flexibility to support more devices, programming parameters were added. One parameter, spiSSPolarity, can be used for programming the SS polarity: it is a Boolean parameter that sets the output polarity of the SS line. For details, please refer to section 4.3.6 of the Flash Center Software User Manual.

Flash Center Software can be customized to create you part files.

Figure 1: Flash Center Software

Currently, the Flash Center Software does not provide built-in support for the Microchip 93AA56AT SPI EEPROM device. However, the Flash Center Software does provide built-in support for a similar device, the Catalyst CAT93C56, 8-bit mode. With that information, we recommend programming the Microchip 93AA56A as described below.

Programming Microchip 93AA56A

Connect the Microchip 93AA56A ORG pin to ground. This will configure the device to function in the 8-bit mode.

In the most current Flash Center Software, choose the device CAT93C56.
Perform the read and program & verify operations on your Microchip 93AA56A with the Aardvark host adapter.

The Flash Center application is written using standard APIs, which you can use as is or you can customize to create a program for your specifications, such as your own part file. The Aardvark Software API supports multiple operating systems (Windows, Linux, and Mac) and programming languages (C, Python, Visual Basic, and C#). Program examples are included. For information about adding part files and about API, please refer to section 4 and section 5 of the Aardvark Host Adapter User Manual, respectively.

For additional information, please refer to the following documents:

We hope this answers your question. If you have other questions about our host adapters or other Total Phase products, feel free to email us at sales@totalphase.com or submit a request for technical support.

I am working on a new design that will be installed in a system. To do so, I need to save board space. My target USB bus is inside of an embedded system. To analyze and verify the results, I'll need to tap off the lines to monitor the USB bus. To use the Beagle USB 480 Protocol Analyzer, I think I'll only need to wire in GND and the D+/D- signal pair - is that correct?

Thanks for your question! Section 3.1 of the Beagle Protocol Analyzer User Manual describes the four main architectures for connecting devices to the Beagle analyzer.

Figure 1: Beagle USB Protocol Analyzer Connections

As the system that you will be analyzing is embedded, the architecture to use is probably (d), as shown above in Figure 1. You are correct that GND and the D+/D- signals are needed. The D+/D- signal path of a USB does not have to be broken to be monitored by a Beagle USB protocol analyzer. The VBUS, GND, D+, and D- lines can be connected to either the Type A or Type B connector on the Beagle analyzer using "T" connections.

The method of connecting the analyzer to the embedded bus will vary depending on the accessibility of the signals on the target system. You may need to cut open a USB cable to attach the wires to the target system.

If the signal lines are easily accessible through a header or test pads, then connecting to it should be straightforward. If the signals are not easily accessible, the wires may need to be soldered directly to IC pins or to traces on the printed circuit board. Extreme caution of this is required; note that Total Phase cannot be held responsible if equipment is damaged from such activities.

Following are some of the factors to consider when monitoring an embedded USB:

How to connect to the signal lines
Ensuring signal integrity between the target device and the Beagle USB analyzer
Ensuring 5V is present on the VBUS so that the Beagle USB analyzer recognizes the presence of the host

For details about connecting the Beagle USB analyzer, please refer to the knowledge base article Monitoring an embedded USB with a Beagle USB Protocol Analyzer.

For more information, please refer to the following documents:

I am using the Aardvark I2C/SPI Host Adapter in the SPI Slave mode. How can I specify multiple responses for the Aardvark to return, such that each packet returns a different response?

To provide some background, the delay between bytes in my application is short enough that the Aardvark adapter can only echo what is reads from MOSI after the first byte. MOSI is not connected to the SPI master, so I have tied the MOSI and MISO signals together with a 1K resistor. I have no control over the timing of SCLK or the timing between packets. The timing is too fast for a typical computer to change the response in real-time.

Thanks for the question! The Aardvark adapter, along with the Control Center Software can store one response to any packet, as a slave. The response cannot be changed on the fly, so to change the data that the Aardvark adapter slave sends, the Aardvark adapter's set response must be set to a different value each time. For example, for the Aardvark adapter to send AA in the first read, BB in the second read, and CC in the third read:

Set the first slave response with AA and then execute the first master read.
Set the second slave response with BB and then execute the second master read.
Set the third slave response with CC and then execute the third master read.

The following is an example of how that can be done. Please note this example uses an Aardvark I2C/SPI Host Adapter, the Control Center Software and the Total Phase SPI Flash Demo Board. If necessary, the SPI Flash Demo Board can be substituted with an off-the-shelf SPI slave device.

Control Center Software can be used to control the response of an Aardvark I2C/SPI Host Adapter in SPI Slave mode

Figure 1: Control Center Software - SPI Slave Mode

Ensure the most current USB drivers and version of the Control Center Software are installed.
Verify the setup by writing and reading to the SPI flash device (M25P32) that is on the SPI Flash Demo Board. For these instructions, please refer to the knowledge base article Writing and Reading from SPI Flash Using Aardvark Adapter and Control Center.
In the following example, commands are sent to the slave device to set its response. For details about using the Control Center Software, please refer to the Control Center Software User Manual.
1. Send A B C D from the SPI master device.
2. Set the Aardvark SPI slave Response to 1 2 3 4.
3. Receive from the SPI master device. Verify the SPI slave device sends 1 2 3 4 to the SPI master device.
4. Send E F G H from the SPI master device; the SPI master device then sends E F G H to SPI slave device.
5. Set the Aardvark SPI slave Response to 5 6 7 8.
6. Receive from the SPI master device. Verify the SPI slave device sends 5 6 7 8 to the SPI master device.

For additional information, please refer to the following documents:

I am using a Komodo CAN Duo Interface with the LabVIEW software and Komodo LabView Drivers (VI). I write a packet, and when I read the bus, the packet I am looking for has already been sent by the other node - I miss reading it. The loop works fine for two iterations before this fault occurs.

This behavior suggests a buffer is overloaded and needs to be cleared. How do I clear the buffer?

Thanks for the question! There is buffering within the Komodo DLL, on a per-device basis, which helps capture asynchronous messages. For example, in the case of the Komodo interface receiving CAN messages asynchronously:

If the application calls the function to change the state of a GPIO while unprocessed asynchronous messages are pending, the Komodo interface will modify the GPIO pin but will also save any pending CAN messages internally.
The messages are then held until the appropriate API function is called.

For more information please refer to section 3.8.1 of the Komodo Interface User Manual.

GUI Interface for Komodo LabVIEW Drivers

Figure 1: Komodo LabVIEW Drivers

Here is an overview about buffering:
The Komodo CAN Duo Interface can be configured as an active CAN node or as a passive monitor. A CAN channel can receive messages asynchronously with respect to the host computer software. Between the calls to the Komodo API, these messages must be buffered in memory. This is accomplished by the operating system of the computer host. The size of this buffer is limited; when this buffer is full, bytes of data are dropped.

An overflow can occur when the Komodo device receives asynchronous messages faster than the rate that they are processed - the receive link is "saturated". This condition can affect other synchronous communication with the Komodo interface.

Solutions to clear a saturated receiving buffer:
There are two methods to address a saturated buffer.

One option is to reduce the amount of traffic that is sent by all CAN nodes between calls to the Komodo API. This requires the ability to reconfigure the offending CAN device(s).
The other option is to poll the CAN channel to collect pending messages more frequently. For more information, please refer to section 3.8.2 of the Komodo Interface User Manual.

Detect a filled Komodo buffer:
The Komodo has a limited buffer for buffering CAN packets and CAN events. If this buffer is filled, the Komodo interface will not report new packets or events and it will stop transmitted packets on the CAN bus. This can be detected by seeing a KM_READ_END_OF_CAPTURE in the status field of the km_can_info_t struct from the km_can_read function. Also, in this scenario the CAN write functions will return with an error code of KM_CAN_SEND_FAIL.

To decrease the possibility of buffer saturation, the following steps can be taken:

Ensure the CAN bus is properly terminated; otherwise the Komodo is saturated with CAN errors.
Use only one port on the Komodo device.
Use only one CAN channel on the Komodo device.
Use a lower CAN bitrate.

For more information about CAN API functions, please refer to section 5.6.1 of the Komodo Interface User Manual.

For additional information, please refer to the following:

Komodo Interface User Manual
Total Phase Products
Product Selector Guide

I need to capture USB 2.0 bus data between a scanner and computer. The information is scanned from a coupon, and then OCR (optical character recognition) is applied to identify the information on that coupon - the amount to deduct from the purchase price. Currently, the process is slow and the result of the scan is not always accurate - the coupon often needs to be rescanned before the sale can be completed. In addition, the scanned information needs to be saved so that it can be printed on the purchase receipt. The file will be rewritten - that information does not need to be permanently saved after it is printed on the receipt and the sales transaction is completed.

Can you recommend which USB protocol analyzer to apply for this project? This is a large project - we will be updating 100 systems in our stores.

Also, which software applications do you recommend? I understand an “expression” can be set to start the reading., and then take the 50 next characters and save the data in a file. To make the sales transactions more efficient, I need the data in real-time.

Thanks for your questions! For your application, we recommend the Beagle USB 480 Protocol Analyzer, which is a robust non-intrusive device. It can monitor high-speed, full-speed, and low-Speed USB 2.0 (480 Mbps / 12 Mbps / 1.5 Mbps). The Beagle 480 has Real-Time USB class-level decoding with the Data Center Software, two capture modes (real-time and delayed-download), high-speed USB chirp detection, robust automatic speed detection, hardware-based packet suppression, and digital inputs and outputs for synchronizing with external logic. The Beagle 480 analyzer can also detect suspend/resume events and unexpected signals.

Using the USB 480 Protocol Analyzer to capture USB 2.0 bus data

Figure 1: Beagle USB 480 Protocol Analyzer

You can capture USB 2.0 data with the Beagle 480 analyzer using the Data Center Software and the Beagle Software API.

The Data Center Software is a bus monitoring software application that displays captured USB bus data in true real-time through the Beagle analyzer. This eliminates the need to write custom software to control the analyzer. You can export the captured USB 2.0 Bus data to a CSV format file or to save it to a tdc file.
The Beagle Software API is used to control the analyzer, and to write a custom program for your defined specifications. API comes with support for multiple OS (Windows, Linux, and Mac) and multiple languages (C, Python, Visual Basic, and C#), and includes examples. We recommend using the Python bindings as it is a simple language, and a good option for scripting. For details about API functions, please refer to section 6 of the Beagle Protocol Analyzer User Manual.

For additional information, please refer to the following documents:

We hope this answers your questions. If you have other questions about our USB protocol analyzers or other Total Phase products, feel free to email us at sales@totalphase.com or submit a request for technical support.

I have two different SPI devices and I need to transmit two different command settings. Because of the separate SS (slave select) signal pins, it looks like the Cheetah host adapter should work with this:

Using the Cheetah SPI Host Adapter for the SPI Interface. The two SPI devices that I intend to control with the Cheetah adapter have different command lengths, which will be transmitted simultaneously:
- SS1 requires a 72-bit command
- SS2 requires a 24-bit command
Using the Aardvark I2C/SPI Host Adapter to control the I2C interface
Operate all devices from the same computer

Is the selection of adapters correct? Also, can you recommend how to configure this setup for the SPI commands?

Thanks for your questions! Both the Cheetah SPI and Aardvark I2C/SPI Host Adapters can be run from the same computer. They will require separate software connections, but there will be no issues using the same computer. Based on the setup that you described, the Cheetah and Aardvark adapters are appropriate for your application.

Regarding SPI transfer rates, you can transfer SPI data with the Cheetah adapter using the Cheetah GUI Software, the Flash Center Software or the Cheetah Software API. Following is a summary of what each software application provides:

Use Cheetah SPI Host Adapter and Software to Control SPI Devices with Different Bitrates and Command Lengths

Figure 1: Cheetah SPI Host Adapter

The Cheetah GUI Software provides full access to all Cheetah adapter functionality, and eliminates the need to write custom software to control the adapter.
The Flash Center Software provides mechanism to quickly erase, program, and verify SPI based EEPROM and flash memory Chips. It has extensible XML parts library with built-in support for EEPROMs and serial flash chips from major manufacturers.
The Cheetah Software API is used to control the adapter, and to write a custom program to achieve the user goals. The API comes with support for multiple OS (Windows, Linux, and Mac) and multiple languages (C, Python, Net, and C#), and includes examples. We recommend using the Python bindings as it is a simple language, and a good option for scripting.

For your SPI data requirements, we recommend using two separate Cheetah SPI Host adapters with two Cheetah GUI Software instances, one for each Cheetah Adapter, which can be on the same computer. One Cheetah adapter with Cheetah GUI (or Cheetah API) can send one SPI slave a packet of one specified length and bitrate. In the same time, the second Cheetah adapter can send the second SPI slave a packet with the other specified packet length and bitrate. A summary follows:

Connect each Cheetah adapter to one Cheetah GUI instance.
Configure Cheetah GUI-1 to the appropriate SS signal, packet size, and bitrate (SS1, 72 bit packet size).
Configure Cheetah GUI-2 to the appropriate SS signal, packet size, and bitrate (SS2, 24 bit packet).

For additional information about using the Cheetah adapter with the Cheetah GUI Software, please refer to the knowledge base article Writing and Reading from SPI Flash Using Cheetah Adapter and Cheetah GUI.

For additional information, please refer to the following documents:

We hope this answers your questions. If you have other questions about our Host Adapters or other Total Phase products, feel free to email us at sales@totalphase.com or submit a request for technical support.

I am trying to communicate to the Komodo CAN Duo Interface device using the Keysight VEE software - a graphical IDE that is similar to National Instrument's LabVIEW. VEE cannot import in "enum" types. There is a Komodo LabVIEW Driver for the Komodo devices and VEE is similar to LabVIEW . My question - can Komodo software be modified to work with the VEE software? How can I do that?

Thanks for your question! We do not officially support Agilent VEE because we do not have this environment in our lab. However, Keysight VEE can interface with any standard C DLL. Because of that, you can use our komodo.dll and bind to the functions within it. The guidelines are as follows:

You can use komodo.dll and bind to the functions within it.
You will need to use komodo.dll, but you will not need to use komodo.c and komodo.h.
You will not need to change the following files: komodo.dll, komodo.h, komodo.c.

Komodo CAN Interface can be used with many applications

Figure 1: Komodo CAN Duo Interface

There is one caveat. When you follow the Keysight VEE instructions on how to interface to C DLLs and you want to call to a Komodo Software API function, you need to add the prefix “c_” to the Komodo API. For example, to call to the Komodo function km_open, you first add the prefix "c_" and then call to c_km_open. For additional information about Komodo Software API functions, please refer to section 5 of the Komodo Interface User Manual. Also, please refer to the documentation from Agilent VEE for information about how to interface to C DLLs.

For additional information, please refer to the following documents:

We hope this answers your question. If you have other questions about our protocol analyzers and other Total Phase products, feel free to email us at sales@totalphase.com or submit a request for technical support.

I plan to use the Cheetah SPI Host Adapter for a half-duplex 3-wire SPI slave device. Can the Cheetah adapter be configured to interface with a 3-wire SPI? Is there anything special I would need to do?

Thanks for your question! The Cheetah SPI Host Adapter can be used with 3-wire SPI slave devices. Although it refers to the Aardvark I2C/SPI Host Adapter, you can follow the instructions in the knowledge base article Interfacing with 3-wire SPI. Following is the information that applies to your question.

A normal SPI interface consists of four signals: clock (SCLK), slave select (!SS or !CS), master input/slave output (MISO), and master output/slave input (MOSI). As SPI is a full-duplex device, it will have separate pins for input data and output data. A half-duplex is similar to the true SPI, but one pin is used for I/O (input and output). To configured the host adapter, insert a 10k resistor between the MOSI signal and the MISO signal, and then connect the MISO line to the data line of the SPI slave device. The example below shows connecting the Aardvark adapter to a National LM74 device - this configuration can also be used for the Cheetah host adapter and other half-duplex SPI devices.

Connecting a Full-Duplex Host SPI Adapter to a Half-Duplex SPI Device

Figure 1: Connect a Full-Duplex Host SPI Adapter to a Half-Duplex Device

When the slave is driving MISO, the SPI host adapter's readings will not be disturbed by the state of the MOSI line. If the system uses 5.0V as a logical high, then a maximum current of 0.5mA will flow through the resistor.

When the slave's data line is configured as an input, the voltage levels for MOSI and MISO will be essentially the same - there will be a small voltage drop across the resistor because the high-impedance slave sinks a small amount of current.

As the Cheetah SPI Host Adapter is designed to be used with a full-duplex SPI device, you will need to set up the bytes to be transmitted correctly. An example program is available that interfaces the Aardvark host adapter to the National LM74 - read and write data to the device. You can modify the program for the specifications of your setup and the SPI device that you will be using.

For information about software API commands used in the example program, please refer to section 5 of the Aardvark Adapter User Manual. For information about the software commands to use with the Cheetah adapter, please refer to section 5 of the Cheetah Adapter User Manual.

For additional information, please refer to following documents:

We hope this answers your question. If you have other questions about our Host Adapters or other Total Phase products, feel free to email us at sales@totalphase.com or submit a request for technical support.

I have two different SPI devices and I need to transmit two different command settings. Because of the separate SS (slave select) signal pins, it looks like a Cheetah host adapter should work with this.
The two SPI devices that I intend to control with the Cheetah adapter have different command lengths:

SS1 requires a 72-bit command
SS2 requires a 24-bit command

The commands will be transmitted one after another, not in parallel. How can I configure this?

Thanks for your question! Having three separate SS signals, the Cheetah SPI Host Adapter can control up to three separate SPI devices Regarding SPI transfer rates, you can transfer SPI data with the Cheetah adapter using the Cheetah GUI Software, the Flash Center Software or the Cheetah Software API.

Figure 1: Cheetah SPI Host Adapter

Following is a summary of the advantages of each software application:

The Cheetah GUI Software provides full access to all Cheetah adapter functionality, and eliminates the need to write custom software to control the adapter.
The Flash Center Software provides mechanism to quickly erase, program, and verify SPI based EEPROM and flash memory Chips. It has extensible XML parts library with built-in support for EEPROMs and serial flash chips from major manufacturers.
The Cheetah Software API is used to control the adapter, and to write a custom program to achieve the user goals. The API comes with support for multiple OS (Windows, Linux, and Mac) and multiple languages (C, Python, Net, and C#), and includes examples. We recommend using the Python bindings as it is a simple language, and a good option for scripting.

Using one Cheetah GUI, you use (one Cheetah GUI or Cheetah API) instance to connect to the one Cheetah SPI Host Adapter and to the two SPI slave devices.

For the first transmission, the Cheetah adapter (with Cheetah GUI or Cheetah API) can send the first SPI slave a command using a specified packet length with bitrate.
For the second transmission, the Cheetah adapter can send the second SPI slave a command using a different specified packet length and bitrate.

The guidelines are as follows:

Connect the Cheetah adapter to one Cheetah GUI instance.
Configure Cheetah GUI for the appropriate SS signal for the devices: packet size and bitrate
- SS1, 72 bit packet size
- SS2, 24 bit packet

For additional information, please refer to the following documents:

I am developing an interface for a planter that is connected to a tractor with a display monitor via CAN bus. For the agricultural industry, I found an open source program (ISOAgLib) that could work with for this, but that program was created for a different device. We already have and use the Komodo interfaces - can I use the Komodo API to have this program connect with the Komodo CAN Duo Interface?

Thanks for your question! We provide USB drivers, Komodo Software API and a shared library, which can used to interface third party software to communicate with the Komodo interface. The Komodo Software API and the shared library for C, C#, Python, .NET, VB.NET, VB6. Drivers and the Komodo Software API can be downloaded for free.

Komodo API Software can be used to run third party software with the Komodo protocol analyzer

Figure 1: Komodo CAN Duo Interface

Using our API, you should be able to have the Komodo interface communicate with your 3rd party software.

The Komodo Software API is used to control the Komodo interface and to write a custom program that supports your specification. The API comes with support for multiple OS (Windows, Linux, and Mac) and multiple languages (C, Python, Visual Basic, and C#), and includes example programs. We recommend using the Python bindings as it is a simple language and is a good option for scripting. For additional information about the API, please refer to section 5 of the Komodo Interface User Manual.

Other software applications are available:

The Komodo GUI Software provides full access to all Komodo interface functionality, and eliminates the need to write custom software to control the Komodo interface. It has 3 operation modes: General CAN, Activity board, and Batch.
The Data Center Software is a bus monitoring software application that displays captured I2C, SPI, USB, and CAN bus data in true real-time through the Komodo CAN interface as well as the Beagle protocol analyzer.

For more information, please refer to the following documents:

We hope this answers your question. If you have other questions about our protocol analyzers or other Total Phase products, feel free to email us at sales@totalphase.com or submit a request for technical support.

You can batch program devices using the Aardvark I2C/SPI Host Adapter and any of the following applications: the Control Center Software, the Flash Center Software or the Aardvark Software API. Following is a summary of the example provided in our latest knowledge base article, Programming I2C EEPROM using Aardvark Adapter and Control Center Batch Mode. With some modification, this example be used for programming other devices.

This setup of this example:

The Aardvark adapter as the I2C master
The AT24C02 I2C EEPROM as the slave device. In this setup, the EEPROM is part of the I2C/SPI Activity Board.
The Control Center Software installed on a computer
Writing data to the slave device will be followed by reading the data

Initial Configuration
The Aardvark provides the I2C pull-ups and target power to the memory device on the Activity board. The batch command for this configuration will be as follows:

I2C mode: i2c="1" spi="1" gpio="0"
Enable target power: tpower="1"
Enable I2C pullups: pullups="1"

Writing and Reading to the Device
For the AT24C02 memory device, the write operation will be Page Write and the read operation will be Sequential read.

Write
The default I2C target address is 0x50. For Page Write, AT24C02 requires a 7-bit device address, one byte memory address, and two or more bytes of memory data. For information about programming a 7-bit device, please refer to the knowledge base article 7-bit, 8-bit, and 10-bit I2C Slave Addressing.

In this example, the commands for writing 256 bites will be as shown below. Note - this example represents the first and last i2c_write commands used for writing 256 bytes of data.

<i2c_write addr="0x50" count="2" radix="16">00 00</i2c_write>
<i2c_write addr="0x50" count="2" radix="16">FF FF</i2c_write>

Read
The AT240C Sequential Read operation uses two commands: i2c_write following by i2c_read. In this example, the read commands will be as follows:

<i2c_write addr="0x50" count="1" radix="16" nostop="1">00</i2c_write>
<i2c_read addr="0x50" count="256"/>

About the write command parameters:

Device address: addr="0x50"
Number of data bytes: count="1"
Data format: radix="16"
Memory address: 0x00
No stop: nostop="1"

About the read command parameters:

Device address: addr="0x50"
Number of data bytes: count="256"

Writing to the Device Using Batch Mode:

Connect the Aardvark adapter to the computers via the USB connector.
Connect the Aardvark adapter to the I2C/SPI activity board via the I2C/SPI connector.
Launch the Control Center and connect to the Aardvark adapter:
1. Click Configure Aardvark Adapter.
2. Select the Aardvark Adapter.
3. Click OK to connect to the adapter.
Click Aardvark and then choose Batch Mode.
Write to the memory
1. Click Load and then choose i2c-eeprom-write.
2. Click Open and then Execute.

Figure 2: Aardvark Adapter Reads 256 Bytes From AT24C02

Reading from the Device Using Batch Mode:

Click Load and then select i2c-eeprom-read.
Click Open, and then Execute.

Figure 2: Aardvark Adapter Reads 256 Bytes From AT24C02

For more information, please refer to the following documents:

If you have questions about our host adapters or other Total Phase products, feel free to email us at sales@totalphase.com or submit a request for technical support.

I plan to run a design verification tests (DVT) for long periods. For part of the DVT, I'll need to continue running the test and capture data as errors occur. For another part of the DVT, I'll need to capture data and stop running the test when an error occurs. Which USB protocol analyzer do you recommend, and how can I run and capture the data as described?

Thanks for your question! Both the Beagle USB 5000 Protocol Analyzer and the Beagle USB 480 Power Protocol Analyzer have the ability to trigger on errors during a long-term capture. They can be set up to capture data and run continuously or to start a capture when a certain trigger event occurs, such an error. Using the Data Center Software with these protocol analyzers, you can analyze and capture all data, set up a trigger for your event of interest only, run firmware validation, bring up new USB devices, as well as other features for capturing and analyzing data.

There are two methods for trapping an error over an extended capture period:

Capture all data and search for the error(s) in the log - this method will require a large amount of storage.
Use the Complex Match feature to set up a trigger and only log the traffic around the trigger.

To use Complex Match, first set up a trigger condition and then start the capture. The Beagle USB Protocol Analyzer will then run in a “pre-trigger” mode until the trigger condition is met. During the pre-trigger mode, the protocol analyzer captures traffic in a circular buffer and retains only the most recent records. The amount of data that can be saved is determined by the on-board memory buffer you set aside for that purpose.

Once the trigger condition is met, the Data Center Software will download the data in the pre-trigger buffer. You can configure the device to continue to continue running or to stop almost immediately. There are two ways to continue running the capture:

Continue capturing data - it will stop when all the storage space is filled.
Program the analyzer to loop while filtering out most of the packets, which simulates a stop. The advantage of this approach is that you can capture indefinitely while looking for the error. Note - this method is limited to configuring one trigger condition for a capture - you can define a very detailed trigger condition. An example of using Complex Match to configure a trigger is shown below in Figure 1.

Using Data Center Software option of Complex Match to set up a trigger

Figure 1: Data Center Software showing Complex Match

The Data Center Software can display cumulative errors, which is accessed by using the Statistics Tab of the Navigator pane. In this case, the display shows both the gross and the breakdown of errors are displayed, as well as other information.
You can narrow the scope of the statistics by selecting the various levels in the bus tree in the Navigator screen. The statistics are live while a capture is running, as shown below in Figure 2.

Figure 2: Data Center Software Panes

The LiveFilter feature can be used to display only the errors in the Transaction Window, as shown below in Figure 3.

Figure 3: Data Center Software Errors Only Transaction Window

For information about errors that could be viewed it the Transaction log error column, please refer to section 6.6, Table 7 of the Data Center Software User Manual.

For information about errors what could be viewed when using the Complex Match feature, please refer to section 6.3.10, Figure 57 of the Data Center Software User Manual.

For additional information, please refer to the following documents:

If you have other questions about our analyzers or other Total Phase products, feel free to email us at sales@totalphase.com or submit a request for technical support.

We are using the Beagle USB 480 Protocol Analyzer for bus diagnostics. It seems that the Data Center Software used with the Beagle analyzer has limited memory space, which is determined by the available RAM and the configuration of the computer we are using: 4GB/2GB. We need to monitor the USB bus for a week or more. How can we increase the available memory for the Data Center Software to record the data capture from the Beagle analyzer?

Thanks for your question! The available memory for storage for the Beagle USB 480 Protocol Analyzer and the Data Center Software is limited by the memory that is available on the computer. This feature cannot be changed in the current version of Data Center software.

To increase the memory buffer, you can activate the capture mode, Circular Buffer, in the Data Center Software.
For greater results, you can use the Beagle API Software to spool the data to another storage device, such as the hard drive of the computer.

Figure 1: Data Center Software Circular Buffer

The software circular buffer option allows the Data Center Software application to discard past records during a capture, which keeps the capture size below the capture data limit.

Removing the data records begins at the start of the first index of the transaction table, regardless of whether or not that record is visible.
When the buffer is full, the Data Center Software pushes the oldest record and overwrites it with the newest record.

For additional information about the Circular Buffer feature, please refer to section 4.14.3 of the Data Center Software Manual.

For greater memory storage, we recommend using the Beagle API Software, which can be downloaded for free. Many sample programs are provided, which you can modify as needed for your specifications. One of the API examples, capture_usb480 outputs the data to stdout in a comma-separated format (CSV), and also includes some basic collapsing of the data. This output data can be redirected to a file. This example code can also be modified to change the format of the data. Following is a section of the example code:

2506,4663763366,USB,( OK CHIRP_J; )
2507,4663813616,USB,( OK CHIRP_K; )
2508,4663863866,USB,( OK CHIRP_J; )
2509,4663914133,USB,( OK RESET; )
2510,4664158366,USB,( OK HIGH_SPEED; )
2511,4664158366,USB,( ),COLLAPSED [735 SOF]
2512,4755939250,USB,( OK ),SETUP,2d 00 10
2513,4755939583,USB,( OK ),DATA0,c3 00 05 01 00 00 00 00 00 eb 25
2514,4755940116,USB,( OK ),ACK,d2
2515,4755951683,USB,( OK ),IN,69 00 10
2516,4755952083,USB,( OK ),DATA1,4b 00 00
2517,4755952616,USB,( OK ),ACK,d2
2518,4756041600,USB,( ),COLLAPSED [347 SOF]
2519,4799295900,USB,( OK ),SETUP,2d 01 e8
2520,4799296233,USB,( OK ),DATA0,c3 80 06 00 01 00 00 12 00 e0 f4
2521,4799296750,USB,( OK ),ACK,d2
2522,4799313116,USB,( OK ),IN,69 01 e8

The Beagle API Software is supported on 32-bi and 64-bit operating systems Windows, Mac OS X, and Linux. The languages supported include C, C#, Python, .NET, VB.NET, and VB6. For additional information about the API software, please refer to section 6 of the Beagle Protocol Analyzer User Manual.

For more information, please refer to the following documents:

I am using an Aardvark I2C/SPI Host Adapter as an I2C slave and another device as a master. I am using 7-bit addressing. After every write command to the Aardvark I2C slave device, the master device tries to read what it has written. The Aardvark is sending a NACK after the master executes a Read command immediately after the Write command. I have some questions about this:

Why is the I2C slave device, the Aardvark adapter, giving a NACK for a Read command after each Write?
Do I have to delay the read operation after each write?
Must NACK always occur after each Write operation from the master?

Thanks for your questions! The Aardvark I2C/SPI Host Adapter's behavior, as a master and a slave, follow theI2C standard specifications. These specifications are described in detail in section 2.3 of the Aardvark Adapter User Aardvark manual.

What you have observed in your setup is the normal behavior of the Aardvark I2C/SPI Host Adapter as an I2C slave device. Following are examples of setting Max Rx bytes and how the Aardvark I2C slave responds.

To answer your questions, the Aardvark adapter, as a slave, gives a NACK for a read command because it is unable to accept data. It will not occur after every write operation, only when it is unable to accept data. The reason the Aardvark adapater is unable to accept data is due to “Max Rx Bytes” setting in the Control Center Software as shown below.

Setting Max Rx Bytes for the Aardvark Adapter in I2C Slave Mode

Figure 1: Setting Max Rx Bytes for the Aardvark I2C/SPI Host Adapter in I2C Slave Mode

If the Max Rx bytes is set to 9 and the master sends the Aardvark 9 bytes of data, then the Aardvark sends the NACK after it receives the 9th byte. The Aardvark I2C slave informs the master device to not send (write) more bytes of data.
If the Max Rx bytes is set to 4 and the master sends the Aardvark 9 bytes, then the Aardvark sends NACK after it receives the 4th byte. The Aardvark I2C slave informs the master device to not send more bytes of data.
However, if the Max Rx bytes is set for 20 and the master sends the Aardvark 9 bytes, then the Aardvark receives 9 bytes without delivering NACK. In this case, the Aardvark I2C slave does not receive a 20th byte - therefore, a NACK is not sent. In this case, you would not have to delay the read operation after each write. The master device can read the data from the Aardvark slave by using a Read ACK.

For additional information, please refer to the following documents:

To test and evaluate SPI devices, I have been using the Aardvark I2C/SPI Host Adapter and the Control Center Software. For my next project, I need to use LabVIEW and I'll need a special application. What can you tell me about the API software? Can I use the Aardvark API Software to create a LabVIEW application?

Thanks for your questions! You can use the Aardvark API Software to control the Aardvark adapter and to write a custom program for your specifications. The API comes with support for multiple operating systems (Windows, Linux, and Mac) and multiple languages (C, Python, Visual Basic, and C#), and includes software examples. For more information about the Aardvark API Software, please refer to section 5 of the Aardvark I2C/SPI Host Adapter User Manual.

However, we do offer LabVIEW drivers for the Aardvark adapter, which is based on the Aardvark API Software. Like the Aardvark API Software, the Aardvark LabVIEW driver is also provides examples, which can also be customized to create a custom program for your specification. For an example of using Aardvark LabVIEW for SPI devices, please refer to the knowledge base article Sending SPI Messages Between Two Aardvark adapters Using Aardvark LabVIEW. The following is a summary of that article.

This example uses two Aardvark I2C/SPI Host Adapters (one SPI master and one SPI slave) and two of the LabVIEW examples, connect and spi:

connect: Indicates if the I2C/SPI/GPIO functions are available, and displays the following information about the connected Aardvark adapters: port number, Aardvark handle, serial number, hardware version, and firmware version.
spi: Reads and writes SPI data between two Aardvark adapters.

Instructions:

Download and install the latest version of Aardvark LabVIEW Driver.
Connect the two Aardvark adapters to the computer via the USB connectors.
Connect the two Aardvark adapters to each other via the I2C/SPI connector.
Install LabVIEW for Windows from the LabVIEW website.
Launch the Aardvark LabVIEW Driver.
Run the original connect Aardvark LabVIEW Driver example that is provided in the Aardvark LabVIEW Driver package.
Figure 1: Aardvark LabVIEW Connect Driver
Send the SPI data between two Aardvark adapters, using the Aardvark LabVIEW Driver SPI example.

Aardvark LabVIEW Example Driver: Aardvark LabVIEW SPI Driver

Figure 2: Aardvark LabVIEW SPI Driver

We are trying to do consecutive SPI accesses as quickly as possible and minimize the time between SS going from inactive to active again. We’re looking at the specifications of both the Aardvark I2C/SPI Host Adapter and the Cheetah SPI Host Adapter, but we could use more details and would appreciate your help on our questions below:

Are the host adapters programmable – can we set them up to send multiple sequential SPI accesses from a single call?
What is the minimum time between SPI accesses?

Thanks for your questions! For your application, if you are using the SPI host adapter as an SPI master, we recommend using the Cheetah adapter.

Although both host adapters are programmable, the Cheetah adapter can operate at much higher speeds as an SPI master and can communicate with up to three SPI slaves. The minimum time between access is 250us compared to 2ms for the Aardvark adapter. The Aardvark adapter is more of a general-purpose host adapter that can operate as either an SPI Master or an SPI Slave (in addition to supporting I2C as well). Software APIs are available for both adapters, which allow you to create custom programs to meet your specifications. The following summaries describe the key features of the adapters.

Figure 1: Cheetah SPI Host Adapter

Cheetah SPI Host Adapter:

When using the adapter as an SPI master and higher speed is needed, we recommend using the Cheetah SPI master adapter. The key features of the Cheetah adapter are listed below.

The Cheetah adapter operates up to 50 MHz, can provide gapless shifting, and provides control over the timing of the data that is shifted out.
The Cheetah adapter can send multiple transactions of 8-bit data without delay.
This adapter use a high-speed USB link between the adapter and the computer - the USB latency is about 250us.
An asynchronous interface is provided, which can increase the operational speed for your application.
Cheetah API Software is available, which includes examples that can be customized for your system specification.

For additional information about Cheetah SPI signaling characteristics, please refer to section 2.5 of the Cheetah SPI Host Adapter User Manual. For information about the Cheetah API software, please refer to section 5 of the user manual.

The Aardvark Host Adapter GPIO Feature Can Be Used to Send Interrupt Signals

Figure 1: Aardvark I2C/SPI Host Adapter

Aardvark I2C/SPI Host Adapter:

The key features of the Aardvark adapter are listed below.

The Aardvark adapter can operate at bitrates up to 8 MHz as an SPI master and 4 MHz as an SPI slave.
The Aardvark adapter can transfer up to 8-bit data without td delay. There are timing limitations, which is why we recommend the Cheetah adapter specifically for your application:
- When the Aardvark adapter transfers 16-bit data, there is a delay. The maximum bitrates occur within each individual byte – the bitrates do not extend across bytes.
- There are various overheads and delays that decrease the overall speed of data transfer, such as SS# assertion to the first clock, setup time for each byte, the last clock to SS# deassertion and the time between the start of the bytes.
- The GUI and the OS may add additional delay due to internal overhead. In addition, the Aardvark adapter also has a 2ms round-trip latency, which is caused by the full-speed USB link between the computer and the Aardvark adapter. These delays further reduce the throughput across multiple transactions.
To achieve the fastest throughput, you can use the Aardvark API Software to send many bytes as possible in a single transaction.

For additional information about the Aardvark SPI signaling characteristics, please refer to section 2.4 of the Aardvark I2C/SPI Host Adapter User Manual. For information about the Aardvark API Software, please refer to section 5 of the user manual.

For more information, please refer to the following sources:

We hope this answers your questions. If you have other questions about our host adapters or other Total Phase products, feel free to email us at sales@totalphase.com or submit a request for technical support.

Question from Customer

I am working on a project and we are looking into using the Cheetah SPI Host Adapter to program SPI flash devices. Our setup will have two separate flash chips, which will be selected through their chip select (CS) signals. I understand that the Cheetah adapter can be used to program these chips. My question - is this also supported by the Flash Center Software and could we one binary image to program both flash devices? One flash chip will have the “lower” address space and the other flash chip will have the “higher” address space.

Alternatively, could we open a binary file and select part of that file to be written to address the first flash device, and then select the other part of that file to be written to the address of the second flash device?

Response from Support

Thanks for your questions! There are two solutions for programming two flash devices: one solution uses the Flash Center Software and two Cheetah adapters; the other solution uses Cheetah Software API and one Cheetah adapter to program both flash devices.

Solution 1: Cheetah Adapter with Flash Center Software:

With two Cheetah adapters connected to the host PC and with their 10-pin headers connected to the flash chips, open Flash Center and connect both Cheetah adapters to the software. Load your binary file and simply use the hex editor to cut and paste the data you want written to your flash chips. Remember to check the checkboxes as appropriate in the Adapters section to make sure that you programming the right chip.

Figure 1: Programming with the Flash Center Software

For more information about programming and SPI flash with the Cheetah adapter and the Flash Center Software, please refer to the knowledge base articles:

Solution 2: Cheetah Adapter with Cheetah API:

You can use the Cheetah Software API to control the adapter, and to write a custom program for your test setup and test. You can create a program to use the SS1 and SS2 signals from one Cheetah adapter, as well as program the flash devices with separate binary files.

The Cheetah Software API supports multiple operating systems (Windows, Linux, and Mac) and multiple languages (C, Python, Net, and C#), and includes examples. For more information about the Cheetah Software API, please refer to section 5 of the Cheetah Host Adapter User Manual.

For more information, please refer to the following documents:

We hope this answers your question. If you have other questions about our Cheetah SPI Host Adapter or other Total Phase products, feel free to email us at sales@totalphase.com or submit a request for technical support.

As the number of embedded applications grow and as their requirements increase in speed and complexity, the need for a more powerful and flexible embedded systems tool has become significantly more important. The new Promira Serial Platform improves the production, test, design, as well as the development, emulation and debugging of complex embedded I2C and SPI applications.

The current Promira platform includes these features:

Integrated level shifting - work with signal voltages ranging from 0.9 - 5.0V without additional accessory boards or external cabling.
Remote control - run automated tasks over the Ethernet. Expand the range of production and prototype units beyond interfacing multiple units to a computer via USB.
More customization - configure and use up to six GPIOs.
More target power - provide up to 200 mA to target devices, which in many cases, eliminates the need for an external power source.
Higher speeds for interfacing with I2C and SPI devices - compared to the Aardvark I2C/SPI Host Adapter, the Level 1 application is twice as fast for I2C programming and eight times as fast for SPI programming. Higher speeds are available with the Level 2 and Level 3 applications.
Download new applications for the Promira Serial Platform - instantly obtain and use more features now and as they become available; new applications will be developed and released, including- dual/quad-IO SPI, eSPI, I2C/SPI protocol analysis, and more.
Software support - the Promira Serial Platform can be used with many software applications. The Promira Software API is provided with working examples. The Promira Aardvark Wrapper Software API enables developers to use applications that were created with the Aardvark Software AP. The Control Center Serial Software supports the full use of I2C, SPI and GPIO functionalities.

Promira Serial Platform offers more features at higher speeds

Figure 1: Promira Serial Platform

Following are answers to some of the frequently asked questions about our new product:

Q. What can Promira do for Production and Automated Testing?

In the production and test environments, the Promira Serial Platform can:

Program firmware and other data in the production environment.
Exercise DUTs and run regression tests.
Interface to the production line over the Ethernet.

Q. What can Promira do for developers more quickly than before?

In the research and development environments, the Promira Serial Platform can:

Burn firmware to EEPROM.
Program in-system any I2C- or SPI-based memory chip.
Emulate master or slave devices:
- Use as a master to interface with sensors, memory chips and other peripherals; emulate an MCU and actively poll sensors, read/write BIOS memory and control the bus.
- Use as a slave to test commands sent from MCUs; simulate sensors and validate the commands sent by the master device.

We are all very excited - this new product joins the ranks of our industry-leading debugging tools, which could possibly become the best and last solution that you will need for I2C and SPI development.

For more information about our new Promira Serial Platform, please refer to the following documents:

If you have other questions about the Promira Serial Platform or other Total Phase products, feel free to email us at sales@totalphase.com or submit a request for technical support.

Question from the Customer:

We are testing an I2C device. To record the points in time when values change, we are looking for a way to continuously read back a register, which we have not accomplished with a logic analyzer. Here’s what we want to do:

Continuously read-back I2C for the time period that we specify.
Retrieve those read-back values as a CSV file.

What are your recommendations?

Response from Support:

Thanks for your questions! There are two possibilities. If you only need to monitor the device over the I2C bus, we recommend the Beagle I2C/SPI Protocol Analyzer. If you need to write to and read from the I2C device, we recommend the Aardvark I2C/SPI Host Adapter. For both devices, Total Phase provides a Software API that you can use to write your own applications customized for your test requirements. The API comes with support for multiple OS (Windows, Linux, and Mac) and multiple languages (C, Python, Visual Basic, and C#).

The Beagle I2C/SPI Protocol Analyzer can be used for read-back and saving data in CSV format.

Figure 1: Beagle I2C/SPI Protocol Analyzer

Monitoring the I2C Device with the Beagle I2C/SPI Protocol Analyzer:

The Beagle I2C/SPI Protocol Analyzer is a non-intrusive device that monitors the I2C bus up to the rate of 4MHz, and can be used with the Data Center Software or Beagle Software API. These software applications are free and can be downloaded.

Regarding your test setup, you can use the Beagle analyzer with the Data Center Software to capture the I2C data to the memory, and display it in the Data Center transaction log. After the stopping the capture, you can save the transaction log data to the default tdc file or export the data to a CSV file.
The Data Center Software transaction log displays the time that each transaction occurs in the timestamp column. Examples are provided in the Data Center Software.
You can use the Beagle API Software to capture I2C data, and then manipulate and save the data based on your system requirements and test specifications. The Beagle API Software is provided with software examples that you can use and customize for your test setup.

Aardvark Host Adapter read-back data can be saved in CSV format.

Figure 1: Aardvark I2C/SPI Host Adapter

Actively Communicating with the I2C Device with the Aardvark IC2/SPI Host Adapter:

The Aardvark I2C/SPI Host Adapter actively communicates on the I2C bus, as well as performs I2C write and read operations. The Aardvark adapter supports I2C up to 800 KHz, and supports: Flash Center Software, Control Center Software, and Aardvark Software API.

Regarding your test setup, when the Aardvark adapter is configured as an I2C master and used with the Control Center Software, manual read and write operations can be performed. Additional information about these operations, please refer to steps 1-12 of the knowledge base article Programing I2C EEPROM Using Aardvark Adapter, Level Shifter Board and Control Center.
With the Control Center Software, you can store the I2C transaction log to a CSV file. For additional information about the Control Center Software and CSV files, please refer to section 3.2.4 of the Control Center Software User Manual.
With the Aardvark API Software, you can create programs for your system requirements and test specifications. The Aardvark API Software is provided with software examples that you can use and customize for your test setup.
The Flash Center Software package allows you to quickly erase, program, and verify I2C- and SPI-based EEPROM and Flash memory chips. The Flash Center Software application is written with standard Aardvark APIs that can be downloaded.

For additional information, please refer to the following documents:

I'm using the Aardvark I2C/SPI Host Adapter as an I2C master with the Aardvark Software API. Using C and LabVIEW drivers, I have seen the 1ms delay between separate executions as stated in section 3.8.4 in the Aardvark Host Adapter User Manual. For the next series of tests, I'll need to run the devices and the I2C data at a higher speed. Do you have any suggestions to speed up the sequential I2C execution and reduce the USB delays?

Response from Technical Support:

Thanks for the questions! The Aardvark adapter can operate at 1K Hz - 800KHz bitrate as an I2C master or an I2C slave. Many optimizations have been employed to decrease the setup time for the Aardvark adapter. The byte throughputs within each transaction are very close to the theoretical maximum byte throughput of 1/9 of the bitrate.

Regarding USB delays, the Aardvark adapter has a 2ms round-trip latency, which is caused by the full-speed USB link between your computer and the Aardvark adapter. The GUI and the operating system may add additional delay due to internal overhead. With the current version of the Aardvark adapter and the Aardvark API, there are no options to affect these delays. For additional information about the Aardvark I2C Signaling Characteristics, please refer to section 2.3 of the Aardvark I2C/SPI Host Adapter User Manual.

For much higher I2C data speeds and reduced USB latency, we recommend our new Promira^™ Serial Platform.

Figure 1: Promira Serial Platform

The Promira Serial Platform supports the I2C master mode at 1 kHz to 1.02 MHz, and the I2C slave mode at 1 kHz to 500 kHz; offering programming speeds up to 2x faster than that of the Aardvark adapter. When using USB 2.0 connectivity, the Promira platform uses a high-speed USB link between the Promira platform and the computer, which reduces the USB latency from 2ms to about 250us. The Promira platform also has an asynchronous interface that may provide additional speed-up for your setup. Other advanced features include functioning as an I2C master up to 1 MHz, Integrated level shifting from 0.9V to 5.0V, and USB 2.0 / Ethernet connectivity for faster downloads, remote control, and factory floor automation.

Regarding delays, every Promira platform I2C master read transaction will have a delay before the last byte, and there may be additional delays between bytes during the I2C master read and write. Although there is no inter-byte delay for the most part of the I2C transaction, the Promira Serial Platform occasionally requires additional time to process the received bytes and set up the next bytes. In this case, delay is inserted on the I2C bus. There can also be additional overhead caused by the operating system between the Promira API calls. For more information about the Promira I2C signaling characteristics, please refer to section 2.2 of the Promira Serial platform User Manual. For more information about Promira Software API, please refer to section 5 of the Promira Serial Platform User Manual.

There are delays that are inherent to the I2C bus protocol. The I2C requires that 9 bits are sent for every 8 bits of data; the throughput will not be exactly 1/8 times the bitrate. The maximum bitrates are only achievable within each individual byte; the bitrates do not extend across bytes. There is also a finite time required to set up a byte transmission.

For additional information, please refer to the following documents:

Support Question of the Week: Using the Aardvark I2C/SPI Host Adapter, How Can I Configure the Flash Center Software Parameters to Program SPI EEPROM Devices?

Support Question of the Week: To Save Board Space and Not Include a Connector on the PCB, How Should I Connect the Beagle USB Protocol Analyzer?

Support Question of the Week: How do I Control the SPI Slave Responses from an Aardvark I2C/SPI Host Adapter that is in SPI Slave Mode?

Support Question of the Week: How Do I Clear the Saturated Buffer When Using the Komodo CAN Duo Interface?

Support Question of the Week: With a USB Protocol Analyzer, What is the Fastest and Most Accurate Way to Capture USB 2.0 Bus Data for a Sales Transaction?

Support Question of the Week: How Can I Use the Cheetah SPI Host Adapters to Control SPI Devices with Different Bitrates and Command Lengths?

Support Question of the Week: How Do I Communicate to the Komodo CAN Duo Interface with a Graphical IDE other than LabVIEW?

Support Question of the Week: How do I Configure the Cheetah SPI Host Adapter For a Half-Duplex 3-wire SPI Slave Device?

Support Question of the Week: How Can I Use a Single SPI Host Adapter to Control SPI Devices with Different Bitrates and Command Lengths?

Support Question of the Week: How Can I Make Third Party Open Source Software Work with the Komodo CAN Duo Interface?

Support Question of the Week: Did You Know You Can Batch Program I2C Memory Devices With the Aardvark I2C/SPI Host Adapter and Total Phase Software?

Support Question of the Week: How Do I Configure Conditions for a USB Protocol Analyzer to Capture Data and Stop when Errors Occur?

Support Question of the Week: For Long-Term Data Captures with the Beagle Protocol Analyzer, How Can I Expand the Available Memory for Storage?

Support Question of the Week: Why Does My Aardvark I2C/SPI Host Adapter Send a NACK When I’m Trying to Read From It?

Support Question of the Week: How Can I Create a Custom LabVIEW Application to Test SPI Devices with the Aardvark I2C/SPI Host Adapter?

Support Question of the Week: Is the Aardvark I2C/SPI Host Adapter or the Cheetah SPI Host Adapter Better for High Speed Sequential SPI Accesses?

Using the Cheetah SPI Host Adapter, How Can I Program two Separate SPI Flash Devices with Different Parts of a Binary File?

Want to take your I2C/SPI development, emulation and debugging to the next level?

How Can I use a Host Adapter or a Protocol Analyzer to Continuously Read-Back I2C Data and Save as a CSV File?

What are the Options to Send I2C Data at 1 MHz?