Embedded systems design combines the highly technical disciplines of hardware design and firmware and application software development. Embedded systems engineers face significant challenges throughout the design process, especially when it comes to the integration and debugging of hardware and software systems. 

As an embedded systems project matures and grows in complexity, it becomes increasingly hard to track down and isolate bugs in the code. One study conducted in 2013 by researchers at the University of Cambridge identified that software developers spend up to 50% of their time and budget on each project debugging code. This amounts to billions of dollars each year in developer salaries and overhead, funds that could easily be allocated elsewhere if there was a more efficient way to debug your product.

To help bring relief to developers in debug purgatory, we're offering up some of our preferred debugging techniques that actually work. We'll review some of the traditional run-time debugging techniques, describe the benefits of integration testing, and explain how developers can implement real-time trace debugging to discover and rectify software bugs, bringing products to market faster and with fewer errors.

Traditional Debugging Techniques

Our exploration of debugging techniques for embedded systems begins with traditional debugging techniques. These techniques can all be used to identify and isolate coding errors for removal from your firmware or software application, but the efficacy of each method depends on the unique circumstances of your project. Some of these methods include automation while several others are heavily manual processes. More complex embedded systems projects will typically benefit from more sophisticated debugging methodologies.

Debugging Method #1: "Print Method"

Print debugging is probably the simplest and most basic way of debugging an embedded system. The method is carried out by watching live print statements that are written on the screen as the code is executed. To achieve this, the developer must intersperse print statements throughout the code that will be printed on the screen when specific portions of code are executed. In this way, it is possible to visualize when specific parts of the code are executed.

While the print method can provide transparency into how the code is behaving, it is not typically ideal for more complex projects. Printed statements may confirm that a specific piece of code has executed, but they fail to provide a complete view of the system state that would be useful (and sometimes required) for tracking down more elusive errors. While the print method is useful for simple applications and for developers who lack access to a complete debugging environment, a more technical solution is required to meet the needs of more complex embedded systems projects. 

Debugging Method #2: "Run-time Methods"

The print debugging method is really just the simplest version of a run-time debugging technique. Run-time debugging methods share a common characteristic: they monitor the live execution of a process or a piece of code while the developer uses either manual techniques or debugging software to debug the process. In addition to the print method, run-time debugging methods include remote debugging and communication-based debugging.

Remote debugging describes a debugging technique where the process or code that is being debugged is executed in an environment that is separate from the debugger itself. Remote debugging is useful for embedded systems that do not have a full operating system implemented on them, making it easier for the developer to implement a small debug platform in the software that facilitates debugging from a remote location. In remote debugging, the debugger communicates with the debugged process over a network instead of directly initiating actions or waiting for events.

Communication-based debugging is a technique where the debugger is hooked into the communication between various processes on the embedded system. This allows for effective monitoring of data and messages that are passed between the processes, giving the debugger insight into the function of the application. A developer can set up a proxy process where all messages are sent through, then monitor the messages under various conditions to ensure that all processes are behaving as expected.

Without the right tools, debugging can prove an expensive and time-consuming process. Techniques like integration testing and real-time trace can help embedded systems engineers troubleshoot code errors more quickly than traditional, manual debugging methods.

Integration Testing Technique

Integration testing, sometimes referred to as System Integration Testing (SIT), describes a fundamentally different approach to testing and debugging embedded systems throughout the development process. This method borrows wisdom from new working methods of software development such as Agile and DevOps that promote periodic testing throughout the development process instead of a single, lengthy debugging process in the late stages of product development.

The wisdom behind integration testing can be summarized as follows:

In traditional software development, engineers develop working specifications, program individual modules and combine the modules to complete the program before testing begins. This process may produce a large number of errors. The detection and isolation of errors is complicated by the fact that the code has already been integrated. It may be difficult to identify and isolate bugs once all code modules have already been integrated.

To improve on this method, integration testing begins with unit testing. Before code modules are integrated, they must be subjected to unit tests in isolation to ensure they operate bug-free on their own. Unit testing ensures that each software component functions as expected on its own before being integrated with the whole.

Once a module has passed unit testing, it can be integrated with other modules to begin developing a system. Developers can start by combining low-level modules that implement a common functionality and establishing test cases and procedures to verify their correct functioning. Developers must write a battery of test cases that will be used to verify the build is working correctly. When two or more modules are integrated successfully and pass all relevant tests, developers can go on to incorporate more modules, write new test cases and repeat testing until the final bits of code are added to the system. 

Successful integration means that the software worked correctly on the target hardware and that the software performed as expected according to the requirements specified during the design phase of the project plan.

There are several ways that developers may choose to organize integration testing, but the most important points are:

1. Conduct unit testing before integrating the new code to ensure it works properly.
2. Write test cases for each new integration and ensure that a newly integrated module is functional before creating additional complexity.
3. Test early and often to avoid a lengthy and complicated debugging process towards the end of the development process.

Debugging with Real-Time Trace

The final debugging technique that we want to mention here, and the most powerful, is known as a real-time trace debugging.  With real-time trace, developers implement a hardware device such as a protocol analyzer that records information about the execution of processes in the code. This information can include sequences of program counter values, register reads and writes, and changes in device memory and associated data values.

When a developer notices that a process is behaving unexpectedly, real-time trace debugging provides complete and total insight into the functioning of the process within the code. The developer can produce a log that indicates exactly how the system changed while the process was executed, making it significantly easier to isolate, identify, and correct software bugs.

Real-time trace debugging can be implemented at any stage of development, as a complement to integration testing or when the software and hardware for the embedded system has been fully integrated. Trace information can also be captured non-intrusively, meaning that the system's timing and performance will not be affected by the trace. Real-time trace also enables developers to more easily capture, record and collect test results for future analysis of bugs.

Summary

While debugging can consume a large number of development resources, embedded systems engineers can choose to take advantage of debugging techniques and products that expedite the process and make it significantly easier to detect and diagnose coding errors in embedded systems.

At Total Phase, we offer industry-leading diagnostic tools like our Beagle USB 480 Protocol Analyzer, a non-intrusive bus monitoring solution that makes it easy to monitor activity and communications on the USB bus and isolate unexpected events. Building a product using SPI or I2C protocols? Our Beagle I2C/SPI Protocol Analyzer is perfect for engineers working in the lab or the field on SPI or I2C-based projects.

For further assistance, to determine which product is right for you, or for more information on how to buy, get in touch!

Request a Demo

Question from the Customer:

I am using the A2B Bus Monitor – Level 1 Application to record audio channel data. The Python script is installed and works properly, except that after capturing 40 MB the A2B Bus Monitor buffer is full. How can I capture and record more data?

Response from Technical Support:

Thanks for your question! The capture buffer in the A2B Bus Monitor is limited to about 15 seconds. If more audio data is needed, you can use the WebSocket interface of the A2B Bus Monitor to stream audio data directly to a disk.

Python Scripts for Streaming Audio Data to Disk

To help you get started, we provide a sample Python script that you can download, use, and modify as needed. This package includes the script audio_capture.py and information about using this script. This script requires Python 3, which can be downloaded from the Python website.

How the Script Works

The audio_capture.py script captures one or more audio streams to disk as 32-bit signed, mono, little-endian PCM files, one file per channel. When the script is invoked with no arguments, the following information is displayed:

Invoking the Script

Here is an example of invoking the script, and the expected output. Please note - [PROMIRA_IP] should be replaced with the actual IP address of your Promira Serial Platform.  The default address is 192.168.11.1. If you need to modify the IP address of the Promira Serial Platform, please see

The downstream audio channels are numbered 0 through 13, and upstream audio channels are numbered 32 through 45.

In this example, the script is streaming the first upstream audio channel (32) to disk.

Please note - the file raw-audio-ch32.pcm will be stored in the directory where the script is run.

We hope this answers your questions. Additional resources that you may find helpful include the following:

• A2B Bus Monitor User Manual
• A2B Bus Monitor Quick Start Guide
• A2B Bus Monitor Application Data Sheet
• Promira Serial Platform Data Sheet

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo

USB Type-C – One Cable to Rule Them All

USB Type-C was created to bring faster speeds and compatibility across all varieties of electronic devices. The idea was to create one cable and one specification that manufacturers would adopt for all new devices (you may have noticed every new phone being introduced to the market has a USB-C port on it). A uniform cable would allow for charging headphones, computers, and phones with a single adapter.  Additionally, devices like a hard drive or monitor would be plugged in with the same cable. Just a few years ago, all of this would likely require four separate cables and power bricks. This all can now be accomplished with a single USB Type-C cable as one of the many benefits of the USB-C standard.

As more and more USB-C accessories become available, the need for USB Type-C compatibility becomes an increasingly important issue. Today, external hard drives, power adapters, cables, and even headphones are widely available with a USB-C port.

Tangled cables; Image by: HighT3ch

A Shortage of USB Type-C Ports

Recently, tech giants, such as Apple and Google, have released devices that come with a single USB-C port, notably the new iPad Pro and MacBook Air. If the goal is to enable charging, device connectivity, and display with the same capabilities as older devices, problems begin to arise with the presence of only one port.

MacBook with single USB-C/Thunderbolt port; Image by: Cnet

It is common when using a computer, especially in an office environment, to have multiple external peripherals connected. The computer may have a backup USB hard drive, a keyboard and mouse, external displays, plus a power cable all plugged in. Most older laptops and computers are suited to this set up with most having at least one USB Standard-A port, an HDMI port, headphone jack, a power plug, and maybe even a Thunderbolt or mini DisplayPort port.  With newer laptop models offering only one USB Type-C port, questions begin to arise about how we connect all of our standard devices at a time.

Laptop with all IO ports being used; Image by: The Verge

As early adopters embrace USB-C connected computers and peripherals, they are being met with an interesting challenge: there are not enough USB-C ports on the computer to connect all of their peripherals at once.  In traditional laptops, when USB ports ran short, users simply reached for a hub to add more ports. However, a USB-C port expander hub does not yet exist.

Although USB-C stays consistent with the theme of cutting down clutter and simplifying the equipment needed to keep all your devices connected, the majority of USB-C enabled computers simply do not have enough USB-C ports to meet the needs of daily use.

USB-C port expander; Image by: BestBuy

[Note: There are a plethora of USB-C hubs on the market that provide HDMI, USB-A, Micro SD card readers, DisplayPort, etc. For devices using these legacy ports, it is possible to find a hub to expand a USB-C enabled computer. The issue arises when trying to connect multiple USB-C devices to a USB-C computer as a USB-C port expander that provides more USB-C ports does not exist.]

The Solution is USB4

The current USB specification has not defined how to develop USB Type-C hubs. Without clear direction on the technology future for Type-C hubs, developers have not moved forward in designing a solution to this issue facing consumers.  Fortunately, the USB-IF and USB developers have recognized this challenge.  With the upcoming release of the USB4 specification, developers will begin to have guidance on how to move forward with this enabling technology.

The USB4 specification was announced in 2019. The latest revision of the USB specification features increased data transfer rates, increased video resource allocation, and better Thunderbolt compatibility.

Total Phase Supports USB Type-C

USB Type-C and Thunderbolt are no doubt the future of device connectivity. The ability to use a uniform standard across all devices is not a far-fetched vision of the future. However, a single standard for all connections, as the industry is finding out, is a rather complicated task to tackle. USB Type-C and Thunderbolt have gotten us closer to this vision of the future and with the introduction and implementation of USB4 we may even be able to accomplish this noble goal.

To learn more about how Total Phase has contributed to accelerating progress in reaching this goal check out these blog posts about our Advanced Cable Tester v2 and USB Power Delivery Analyzer:

• The Relationship Between USB4 and the USB Type-C Connector
• Advanced Cable Tester V2 Demo Video
• USB Power Delivery Analyzer Demo Video

Want to learn what leaders in the cable market have to say about USB-C? Check out what Cable Matters has to say in the blog posts below:

• What devices use USB-C?
• What is USB4?
• What is USB-C?

Question from the Customer:

I need to program a serial SPI EEPROM with a hex file. Can I use your Aardvark I2C/SPI Host Adapter?  Which software application should I use with the Aardvark adapter?

Response from Technical Support:

Thanks for your questions! You can easily use the Aardvark adapter to program SPI EEPROMs. The contents of a hex file, as well as a binary or Motorola S-Record file, can be loaded for programming using the Flash Center Software.  It is also possible to use the Control Center Serial Software.

How the Applications Work

Here’s a summary of what the applications can do for you.

The Flash Center Software can quickly erase, program, and verify I2C and SPI based EEPROM and Flash memory devices. An XML parts library is provided with built-in support for EEPROMs and serial Flash chips from major manufacturers. However, if you need to program a device that is not yet supported, you can take an existing XML file and edit it per the data sheet of the device. For more information, please refer to this article about customizing XML files.

The Control Center Serial Software provides full access to all Aardvark adapter functionality and eliminates the need to write custom software to control the Aardvark adapter. It has also a batch scripting capability with the Aardvark XML Batch Script Language. For more information, please refer to this knowledge base article about programming in batch mode.

Programming Examples

We have two videos that show you how to program devices with the applications we recommended.

Programming an EEPROM with Flash Center Software

This video shows programming an SPI EEPROM using the Flash Center Software with a Cheetah SPI Host Adapter. You can use this information with your Aardvark I2C/SPI Host Adapter.

When loading a hex of or S-Record file for programming a device, you’ll need to do following:

• Define at least one byte of padding in the Pad text field before loading a file.
• Afterwards, click the Load File button and select the desired file.

When loading a hex or S-Record file, any undefined regions in the file will be filled with the byte sequence specified in the Pad text field. The data pattern will be repeated through all undefined regions of memory in the data image, aligned to the data pattern size.

Programming with the Control Center Serial Software

This video shows how to program an I2C EEPROM using the Control Center Serial Software with an Aardvark adapter. The information is very similar to programming an SPI device.

We hope this answers your questions. Additional resources that you may find helpful include the following:

• Aardvark I2C/SPI Host Adapter User Manual
• Flash Center Software User Manual
• Control Center Serial Software User Manual

If you want more information about our host adapters or other products, feel free to contact us with your questions, or request a demo that applies to your application.

One of the first and most important decisions an embedded systems engineer must answer when designing electronic systems is how the master and slave devices will communicate, that is, which communication protocol will be used to transfer data. There are several types of communication protocols that are typically used in embedded systems, including I2C, SPI, eSPI, USB, CAN, and many more. To determine which option is most suitable, engineers must understand the differing characteristics and advantages offered by each.

A common misconception that we've noticed relates to the relationship between the Inter-Integrated Circuit (I2C) and System Management Bus (SMBus) communication protocols. On the surface, these two communication protocols are quite similar, but there are some subtle differences that make them different and each one uniquely suitable for specific types of serial communication. Engineers must be aware of the distinctions between these two communication protocols in order to make the best decision about which one to leverage for a given project.

In this week's blog post, we're taking a deep dive into the I2C and SMBus communication protocols. We'll start with some background information, defining each of these protocols and giving a brief history of its development. Next, we'll work to flesh out the core differences and identify any similarities and opportunities for compatibility between SMBus and I2C.

What are SMBus and I2C? 

I2C Communication Protocol

The I2C communication protocol was first created in 1982 by Philips Semiconductor, a company known today as NXP Semiconductors. Since its inception, the protocol has been revised seven times. The 1992 revision saw the addition of a 400 kbit/s fast mode in addition to the standard 100 kbit speed, as well as an optional 10-bit addressing mode that increased the node capacity to 1008 nodes - well beyond what was possible with the 7-bit addressing used in the 1982 version.

I2C protocol uses two wires to transmit data between master and slave devices. The first line, known as the SDA line, is a bidirectional line used to transmit data between a master device and a slave device. The second line, known as the SCL line, is a unidirectional line controlled by the master device that carries a clock signal that ensures synchronicity between the master and slave device.

One of the great benefits of I2C protocol is that it supports a large number of devices on the same circuit. I2C protocol allows an unlimited number of master devices to communicate with a maximum of 1008 slave devices on the bus. All configurations here are possible: one master with one slave, multiple masters with a single slave, a single master with multiple slaves, or a multi master configuration with multiple slaves.

SMBus Communication Protocol

The SMBus communication protocol was first created in 1994 as a collaborative project between Intel and Duracell. SMBus is a two-wire communication protocol that was developed to support lightweight communication between low-bandwidth devices in embedded systems and specifically on computer motherboards. 

In an SMBus system, each device is assigned a unique device address using the familiar addressing system of I2C. Unlike I2C though, any device may be addressed by any other device on the network and any devices may assume the role of master or slave for a particular data transfer. Like the I2C protocol, SMBus also uses a dedicated line (often annotated SMBDAT) for data transfer and a clock line (often annotated SMBCLK). However, both of these lines are bidirectional in an SMBus system, which enables any device to act as the master and transmit the clock signal to the slave device for a specific data transfer.

The SMBus communication protocol was developed by Intel for communication with low-bandwidth devices on computer motherboards, such as fan or voltage sensors and battery systems.

Image courtesy of Unsplash

What are the Core Differences Between SMBus and I2C?

SMBus can be considered a subset of I2C. The standard borrowed many core design features from the existing I2C protocol, but introduced changes that promote efficient, low-bandwidth communication between devices. Below, we summarize the most important differences between the two protocols. 

Timeout and Clock Speed

Timeout and clock speed are the two most important differences between the I2C and SMBus communication protocols.  A timeout happens when the clock line is pulled low for longer than the timeout value. In the original I2C protocol specification, there is no established timeout value. Because the system never times out, there is a need for an error recovery process. In an I2C bus, error recovery is impossible in cases where the slave device holds Clock or Data low. In contrast, SMBus systems will timeout whenever the clock is held low for more than 35 milliseconds. 

Because the clock in an SMBUs system can time out, the system must prescribe a minimum clock speed to prevent timeouts. Therefore, SMBus systems have a minimum clock speed of 10 kHz and a maximum of 100 kHz. I2C systems have no minimum clock speed. They operate either in standard mode at 100 kHz, fast mode at 400 kHz, fast mode plus at 1 MHz,  or in high-speed mode at 3.4 MHz.

Electrical Characteristics

In addition to the changes in timeout and clock speed, there are differences in electrical characteristics between I2C and SMBus systems. Voltage levels in an I2C system typically range in value between 1.5V and 3.3V and are fixed. In contrast, the voltage levels in an SMBus system often range between 0.8V and 2.1V. In addition, SMBus specifies a minimum sink current of 100 micro amperes and a maximum of 350 micro amperes, while the I2C standard permits a maximum sink current of 3mA.

Addressing and Address Compatibility

In an I2C system, slaves are typically assigned an address during the development of the printed circuit board. It is worth noting that while the I2C protocol is free to implement, I2C slave addresses are typically allocated by NXP for a small fee. In addition to supporting fixed slave addresses, SMBus systems can also dynamically assign slave addresses at run time. Here, the SMBus master device uses a process called SMBus Address Resolutions Protocol (ARP) to reliably identify slaves and prevent two slaves from using the same address.

How are SMBus and I2C Compatible? 

Despite these minor differences, I2C and SMBus systems are generally mutually compatible. Both systems make use of two-wire communication and both can be operated at 100 kHz, which is essential for interoperability. To ensure compatibility between I2C and SMBUs systems, the most important factors are the clock speed and voltage characteristics. Compatibility is typically ensured when either:

• The minimum Vih of the target I2C device is 2.1V or less, OR
• The minimum Vih of the target SMBUS system is 3V or higher.

Conclusion 

When it comes to choosing a communication protocol for your next embedded systems project, you may find it useful to investigate other successful applications of your candidate protocols. While I2C protocol has been used successfully in many products and by many manufacturers, applications of SMBus are relatively more narrow. The primary application for SMBus systems has been monitoring of supply voltage, temperature, and cooling functions in computer motherboards.

Are you building a product that will use the I2C communication protocol?  Total Phase builds industry-leading diagnostic tools for I2C product development, like our Beagle I2C/SPI protocol analyzer that offers non-intrusive monitoring of I2C and SPI communications along with real-time data display. 

Learn how our diagnostic tools for embedded systems can help you perfect your product and get to market faster than you thought was possible.

Request a Demo

Question from the Customer:

I have been using the Beagle I2C/SPI Protocol Analyzer as an MDIO analyzer.  Today, I need to exercise a CFP2 MDIO port, reading at 2.5 MHz, or 4 MHz MDC rates at 2.5V. I have  the Aardvark I2C/SPI Host Adapter and the Cheetah SPI Host Adapter – could either do the job?

Response from Technical Support:

Thanks for your question! The Aardvark and Cheetah adapters do not support MDIO.  However, we do have a recommendation. For emulating signals over the SPI lines, we suggest using the Promira Serial Platform with and the appropriate Active Level Software, such as SPI Active - Level 1 Application.

Why Use the Promira Serial Platform

The Promira platform has many built-in features, including level shifting. Here is a summary:

• Level Shifting: 0.9 – 5.0V. For your setup, this feature saves you from integrating another component, the Level Shifter Board, in your setup.
• High-speed USB connectivity
• Ethernet connectivity

Additional features are available per Active Level application. The table below summarizes shows the features per application.

Emulating MDIO Signals

The Promira API allows you to develop the script to control two GPIO lines, making it possible to use the Promira platform as a MDIO master.

• One line operates as the MDIO clock (management data clock, similar to SPI clock)
• One line operates as the bidirectional MDIO data

The Promira API supports several operating systems and programming languages.  In addition, functional examples are provided that can be used as-is or modified for your setup requirements. For more information, please refer to the API Documentation section of the  Promira I2C/SPI Active User Manual

Please note, as the clock is software-driven, the duration of the clock periods cannot be controlled, only the clock edges.

We hope this answers your questions. Additional resources that you may find helpful include the following:

• Promiral Serial Platform Data Sheet
• Promira Serial Platform User Manual
• Promira I2C/SPI Active User Manual
• Promira Serial Platform Quick Start Guide
• MDIO Background

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo

The Total Phase Control Center Serial Software allows engineers working with the Aardvark I2C/SPI Host Adapter, Cheetah SPI Host Adapter, and Promira Serial Platform to develop and test their embedded systems.

When using these host adapters with the Control Center Serial Software, users can perform a variety of tasks; particularly, the Batch Mode feature allows for XML batch scripting to automate tasks.

In this blog, we’ll discuss the Batch Mode functionality, how to use it, and some use cases that can applied using this feature.

What is XML Batch Scripting and Batch Mode?

A batch script is file that contains a series of commands that are executed in sequence.  This is helpful in automating tasks that are generally repetitive.

In the Control Center Serial Software, the Batch Mode feature allows users specify an arbitrary set of instructions for the adapter to execute serially. This scripting language is based on XML.

Use Cases for Batch Mode

Reading and Writing to a Target Device

The Control Center Serial Software allows users to read and write to I2C or SPI target devices, but also allows users to automate such tasks using the Batch Mode feature. For instance, if users are looking to efficiently write a series of commands or perform multiple reads at once, this can be easily achieved.

Below is an example of batch instruction commands that read and write 2 bytes at 100 kHz to and from the I2C slave address 0x50:

<aardvark>
<configure i2c="1" spi="1" gpio="0" tpower="1" pullups="1"/>
<i2c_bitrate khz="100"/>
<i2c_write addr="0x50" count="2" radix="16">00 11</i2c_write>
<i2c_read addr="0x50" count="2"/>
</aardvark>

Below are the parameters for this example:

Configuration:

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

Bitrate:

• Requested bitrate in kHz: khz="100”

Write:

• Device address: addr="0x50"
• Number of data bytes: count="2"
• Data format: radix="16" (hexadecimal)

Read:

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

Reading Registers on an I2C Device

Users may also want to perform read and write commands to the registers of the target device to transfer I2C data to multiple sub-addresses. Using the Master Register Read function in I2C/SPI Mode in Control Center Serial Software allows users to perform this, but there is no direct command for this in Batch Mode. To perform this function, users can implement a register read in Batch Mode by using a “nostop” command following this configuration:

• First operation: I2C write with no stop
• Second operation: I2C read with stop

The example below reads 4 bytes at 100 kHz from I2C slave address 0x50 at register address 08:

<aardvark>
<configure i2c="1" spi="1" gpio="0" tpower="1" pullups="1"/>
<i2c_bitrate khz="100"/>
<i2c_write addr="0x50" count="1" radix="16" nostop="1">08</i2c_write>
<i2c_read addr="0x50" count="4"/>
</aardvark>

Where nostop="1" enables this parameter in the batch instruction commands and nostop="0" disables it.

Click here for more information on how to set up and perform a "Master Register Read" in Batch Mode.

Verifying a System Setup

Users can also use Batch Mode to more efficiently verify that a system set up is working as expected. When using a Total Phase host adapter with the Control Center Software and a Total Phase I2C/SPI Activity Board, users can program a test SPI or I2C device by executing an XML batch script.

This will allow users to execute a more detailed testing procedure and easily confirm their batch instruction commands are operating correctly before committing to a widespread operation.

For instructions on how to verify a test set up, please click here.

How to Use Batch Mode within the Control Center Serial Software

Using the Batch Mode feature is a quick and simple process.

To manually enter the commands and run the file in the Batch Mode console:

1. Launch the Control Center Serial Software.
2. Click on Adapter | Connect and connect to the Aardvark adapter
3. Connect the Aardvark adapter to the Activity board.
4. Click on Adapter | Batch Mode
5. Manually enter commands in the Batch Mode console
6. Click Execute.
7. Monitor transactions in the transaction log window.

To load an existing XML file and run in the Batch Mode console:

1. Launch the Control Center Serial Software.
2. Click on Adapter | Connect and connect to the Aardvark adapter
3. Connect the Aardvark adapter to the Activity board.
4. Click on Adapter | Batch Mode
5. Click on Load and select the XML file
6. Click Execute.
7. Monitor transactions in the transaction log window.

To see a video demonstration on how to use Batch Mode, please watch Programming an EEPROM with a Total Phase I2C Host Adapter.

Help Commands for Generating XML Batch Scripts

To use Batch Mode, a set of batch instruction commands needs to be generated in XML script format. For maximum flexibility, Batch Mode supports I2C, SPI, and GPIO functions.

For users looking for extra assistance with setting up batch instruction commands, the Control Center Serial Software includes Help Instructions that provide written instructions and guidance on how to configure the commands.

For complete instructions on how to set up an XML batch script, please see the user manual section 4.5 on Batch Mode.

Using an API to Create Custom Programs

While Batch Mode is a useful feature for a variety of use cases, developers may want to program custom solutions based on their own project requirements. Total Phase offers a free API for each of our tools including the Aardvark I2C/SPI Host Adapter, Cheetah SPI Host Adapter, and Promira Serial Platform. These tools can be used with our Control Center Serial Software to easily send data to I2C and SPI devices, but the same concepts can be applied to API functions. For instance, by using the respective adapter API, users can perform complex actions including:

• looping for repeatedly sending commands
• integrating with a custom GUI to execute batch commands in a separate terminal

Our APIs offer cross-platform support including Windows, Linux, and Mac, and support multiple languages like C, C#, Python 2/3, .NET, VB.NET, and VB6. Examples are also included that show how the API works, which can be modified and applied to your specific applications.

Click here to find the Software API for our host adapter tools:

• Aardvark Software API
• Promira Software API I2C/SPI Active
• Cheetah Software API

If you have any questions on how Batch Mode can help complete your own programming applications, please email us at sales@totalphase.com.

Question from the Customer:

How can I accurately determine the latency when sending data from one CAN port to another?

I am working with the Komodo CAN Duo Interface. Using strace with the Python loopback code, I see that the time between send and read is about 100 microseconds. The Komodo Software API command settings I am using are km_latency = 0 and timeout_ms = infinite. However, with a bitrate of 250 kHz, I expect it would take longer: at least 512 microseconds to send 8 bytes of data (8 bytes over CAN with ext ID = 128 bits).

Response from Technical Support:

Thanks for your question! There are considerations to factor in for latency, which are described in the following sections.

Setting Latency

Latency can be set to 0. When the latency is set to 0, the function sends the appropriate value to the firmware such that the firmware terminates the USB Request Block (URB) for each CAN packet sent back to the OS. This ensures the smallest latency possible.  You can also set the latency for a specific time value.  In this case, measure the time is takes for the CAN packet read in km_can_read() to execute, and then set the latency with an appropriate value.

Here are examples of setting the latency with the timeout_ms command:

• If timeout_ms is set to KM_TIMEOUT_IMMEDIATE, then km_can_read() becomes non-blocking and returns immediately.
• If timeout_ms is set to KM_TIMEOUT_INFINITE, then km_can_read blocks indefinitely until data is received.

For more information, please see the API Documentation section of the Komodo CAN Interface User Manual.

USB Traffic and Inherent Latency

There is an inherent latency when managing USB traffic as asynchronous USB Request Blocks (URBs) on the host PC. This occurs because the OS only sees data when an URB is either entirely filled, or the USB packet is short (terminated before the URB size is reached).

For this example, we will assume the size of the URBs is 100 bytes and each CAN packet only consumes 20 bytes of USB data. In this case, to fill the URB with 100 bytes, the URB would need to see 5 packets to get any USB data back to the OS. However, seeing 5 packets may take some undefined amount of time.

In order to determine the latency, a short packet will be issued by the Komodo interface once the latency timeout has elapsed.  This allows the data to be visible to the OS and API.

We hope this answers your question. Additional resources that you may find helpful include the following:

• Komodo CAN Interface User Manual
• Komodo Software API

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo

The Internet of Things (IoT) consists of everyday devices that connect to each other via the internet or other wireless networks. IoT devices are used in industrial applications and manufacturing, as well as in all types of vehicles and in the home. Despite the widespread deployment of IoT devices, however, little attention has been paid so far to the need to secure these devices from unwanted access or manipulation. As a result, there may already be billions of deployed IoT devices with inadequate security measures.

To help you protect your IoT devices from hackers, we're offering a selection of tips and advice on IoT security in this week's blog post. We'll elaborate on the importance of IoT security, then offer some basic and actionable advice that can help you secure your device against unwanted physical or cyber attacks.

Importance of IoT Security

While global quantities of IoT devices can now be counted in the tens of billions, security remains one of the most important concerns that will impact market success for product developers. As IoT devices see increased adoption in industrial, commercial and residential applications, issues with IoT security can lead to all sorts of negative consequences.

An example that's garnered much attention recently is CAN bus hacking in vehicles. Modern vehicles are heavily computerized, with each vehicle containing several different embedded systems across multiple networks. There is typically one network for engine and powertrain messages and a separate network for other types of data transmissions like radio and door locks. Each device on the vehicle network represents a potential attack vector for malicious actors. 

A hacker that gains access to the vehicle can connect a laptop to the vehicle's CAN bus controller to gain control of its computer systems.There have also been reports of hackers intercepting radio signals from key-less entry systems and cloning the signals to gain remote access to the CAN bus. Without the adequate security protocols in place, a hacker could remotely control a vehicle and steal it, joyride it, or use it in a crime.

Other types of IoT devices may be vulnerable to security threats as well. A home security system connected to the IoT could be penetrated by hackers and used to spy on home-owners or deliver false alarms. Some companies are using IoT devices to manage warehouse operations - here, a hack that causes unexpected system downtime could cost a company millions of dollars. The bottom line is that with billions of devices now connected to the IoT, there is a massive need to develop technology and common standards to ensure that these devices are not vulnerable to security breaches or tampering.

Vehicles today are more computerized than ever before, with a variety of embedded computers running on several networks. That means new safety features that help prevent collisions, but it could also mean that vehicles are more vulnerable to cyber attacks.

Image courtesy of Unsplash

Protecting Your IoT Devices Against Physical Tampering

Physical security, which can also be thought of as hardware security, consists of securing the physical IoT devices from interference by a malicious actor. While hackers may still be able to attack IoT devices through software or communication networks, adequate physical security will prevent hackers from directly tampering with devices. Here are a few steps you should take to start protecting your IoT devices against physical attacks.

Understand Invasive vs Non-Invasive Attacks

When it comes to physical attacks against connected devices, it can be useful to distinguish between invasive and non-invasive attacks. An invasive attack requires the attacker to gain access to the chip surface - they will need to completely open the device. A non-invasive attack simply requires that the attacker is close enough to the device to sense and manipulate its electrical characteristics. Both types of attacks should be accounted for in your physical security plan.

Restrict Device Proximity When Possible

Unlike network or software attacks, physical attacks typically only take place when the attacker can gain reasonably proximal access to the target device. Organizations with facilities that depend on IoT devices must take every precaution to secure the facility against all unwanted visitors and uninvited guests. Preventing unauthorized access to IoT devices is an excellent step towards mitigating the risk of a tampering attack.

Seven Types of Physical Security Attacks

Take a few moments to recognize seven different types of physical attacks against IoT device security. Which ones might apply to your devices? How would you prevent that?

1. Side Channel Analysis - the use of external hardware to analyze the power signature of an IoT device, hoping to steal secret information
2. Optical, EMFI, BBI - using lasers and other tools to trigger faults in the system that may expose security gaps
3. Tamper Attacks - using micro probes to directly steal information present in the wires of an IoT device
4. Power Glitching - an attempt to introduce glitches into the power supply to compromise the security of a device
5. Clock/Reset Glitching - an attempt to cause a glitch in the clock or reset network of a device that might expose a security flaw or some secret information
6. Frequency/Voltage Tampering - another attempt to introduce faulty behavior, this time by changing operating conditions of the chip. This can mean modifying the clock frequency or voltage to change how the device functions.
7. Temperature Attacks - increasing the environmental temperature can overheat an IoT device, causing unpredictable behavior that may be exploitable.

Protecting Your IoT Devices From Cybersecurity Attacks

Cyber attacks against IoT devices are becoming increasingly common. With so many new products coming out, consumers are excited to benefit from the latest conveniences that the IoT can offer. At the same time, consumers should be waking up to the very real security risks that can come with IoT devices and the need to secure those devices against possible cyber threats. We offer three tips to begin securing any IoT devices you currently own. 

Always Change Default Passwords

Home or business routers are a frequent target of IoT device hacking because many people neglect to change the default password. On any laptop, you can establish a connection with any network within range and access the router interface by typing its IP address into the address bar of any browser. For most routers, the default IP address is 192.168.2.1 and the default password is something like "admin". Leaving passwords on the default setting makes it painfully easy for hackers to gain access to your browsing history, online banking, etc. Always change default passwords!

If you're using the default password for your router, you could be taking big risks with your personal and financial information as well as your home network.

Use a VPN for IoT Devices in the Home

A virtual private network is a great way to protect in-home IoT devices against cyber attacks. When you connect to the internet from a home network, you broadcast your IP address across the internet for all to see. A malicious actor that finds your IP address may be able to use it to identify unsecured IoT devices that share the same address and try to attack or control them.

 A VPN acts as a remote server that hides your IP address from the world when you browse the internet, shielding your IP address, location and identity from anyone who might be watching.

Perform Regular Software Updates

A third step you can take to prevent cyber attacks is to perform frequent software updates for your IoT-connected devices. The companies that produce these devices release security patches that guard against known security issues. By updating on a regular basis, you'll gain access to the latest protections against the best known threats that the product manufacturer has identified. While this won't protect you against zero-day attacks, you should be less vulnerable to well-known attacks that may have affected others with the same device.

Conclusion 

The IoT marketplace is growing rapidly, but the development of IoT security is lagging behind and there's still plenty of work to be done for engineers who wish to secure their devices in the future. In addition to adequate protection from physical and cyber attacks, IoT devices should be thoroughly assessed to determine whether there are any security vulnerabilities in the code. 

At Total Phase, we create powerful diagnostic tools that help embedded systems engineers test and debug their products more efficiently and bring products to market faster and with lower costs. Want to see how we can help you deliver a more secure IoT product?

Request a Demo

Question from the Customer:

I am looking for a programmable SPI interface adapter for communicating with two SPI devices: one Master and one Slave. Here are the Master and Slave waveforms I plan to use for SPI communication. The delay gaps are defined for some of the transactions.

SPI Master Waveform

SPI Slave Waveform

The clock speed is 10 MHz.

It looks like the Promira Serial Platform with SPI Active Level 1 could work for this system. Can you please confirm my evaluation? Also, which software applications would you recommend for developing this system?

Response from Technical Support:

Thank you for your questions! Based on your required clock rate, using the Promira Serial Platform with SPI Active Level 1 Application should fulfill your system requirements.  To support your SPI waveform specifications, we recommend using Promira Software API I2C/SPI Active.

API Support for SPI Communication

The API commands support both 32-bit and 64-bit platforms, and multiple operating systems and program languages. Functional examples are also provided, which can be used as-is or modified as needed.

Using the API, you can send a variable number of bits from the Promira platform. The word size that you can set ranges from a minimum of 2 bits up to a maximum of 32 bits. With API commands, the word size that you can set ranges from a minimum of 2 bits up to a maximum of 32 bits.

API Commands for Writing and Delays

Here are API commands that could apply for your test plan.

Writing to Slave Device

Queue SPI Master Write (ps_queue_spi_write)

• Use this to queue a command that writes a stream of words to the downstream SPI slave device.

Queue SPI Master Write Word (ps_queue_spi_write_word)

• Use this to queue a command that writes a stream of the same word to the downstream SPI slave device

Inserting Timed Delays

Configure Delays (ps_spi_configure_delays)

• Use this command to configure delay between words.

Queue a Delay in Cycles (ps_queue_spi_delay_cycles)

• Use this command to queue a delay on the bus in clock cycles.

Queue a Delay in Nanoseconds (ps_queue_spi_delay_ns)

• Use this command to queue a delay on the bus in nanoseconds

For more information about Promira API commands, please refer to the API Document section of the Promira Serial Platform I2C/SPI Active User Manual.

Promira Serial Platform Features

Here is a summary of the basic features that the Promira platform supports.

• provides up to 200 mA of power to your embedded project
• operates with voltage levels from 0.9 V - 3.3 V, 5 V fault tolerant; output signal levels are configurable
• connects via High-speed USB or Ethernet

Additional features are available based on Active Level application licensed, which are described in the following sections.

SPI Active Application Features

Each application is a separate license. For SPI Active Levels 2 and 3, all previous SPI Active Level(s) must also be installed. Each application supports the following:

• program EEPROM, Flash, or other SPI memory
• slave response size up to 256 bytes
• configurable Slave Select (SS) polarity in master mode

Additional Features by Active Level Application

SPI Active - Level 1 Application supports the following:

• clock speeds up to 12.5 MHz in Master mode and 8 MHz in Slave mode
• up to 1 Slave Select: configurable, shared with GPIO
• use up to 6 GPIOs (2 GPIOs with SPI)

SPI Active - Level 2 Application  supports the following:

• clock speeds up to 40 MHz in Master mode and 20 MHz for Slave mode
• supports Single and Dual I/O SPI
• up to 3 Slave Selects: configurable, shared with GPIO
• use up to 12 GPIOs

 SPI Active - Level 3 Application  supports the following:

• clock speeds up to 80 MHz in Master mode and 20 MHz for Slave mode
• supports Single, Dual, and Quad I/O SPI
• up to 8 Slave selects: configurable, shared with GPIO
• use up to 16 GPIOs

We hope this answers your questions. Additional resources that you may find helpful include the following:

• Promira Serial Platform Data Sheet
• Promira Serial Platform System User Manual
• Promira Serial Platform Quick Start Guide

If you need more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo

The Control Center Serial Software is one of the free GUI applications offered by Total Phase.  It is designed specifically to work with our host adapter products allowing users to emulate a master or slave by quickly issuing Read and Write commands over an I2C or SPI bus.  This easy-to-use software tool can perform a variety of functions suited to a range of customer applications.  The Control Center Software can be used with the popular Aardvark I2C/SPI Host Adapter, our flagship Promira Serial Platform, or the speedy Cheetah SPI Host Adapter.

What does the Control Center Serial Software do?

The Control Center Serial Software was created to help users interface with their I2C and SPI devices. With the software, users are able to quickly connect to their target I2C or SPI system and issue read and write commands.  Programming, prototyping, and stress testing are among the various applications enabled by the software.  With direct access to I2C and SPI buses, you are able to begin testing and debugging within minutes of setup.

OS Support

One of the biggest pain points our customers face in the engineering world is the lack of support for operating systems across their tools. Some tools work on Linux, some on Windows and others on Mac OS. However, it is very rare to find a tool that works on all three of the major operating systems simultaneously. At Total Phase, our software programs work on all of the major operating systems: Windows, Linux, and Mac OS.

Software support for all major Operating Systems

Prototyping

Using the Control Center Serial Software with one of our host adapters, it is possible to easily prototype early designs. The Promira Serial Platform and Aardvark I2C/SPI adapter make this possible with the ability to act as a master or slave.  This provides the capability to simulate components before actually implementing them into the design.

Simply launch the Control Center Software, connect the Aardvark I2C/SPI adapter or Promira platform, and then access the I2C and SPI Master and Slave controls in the software. Enter the Master or Slave address and then enter data in the message box below.  Click Master Write and watch as the Control Center Software and Total Phase host adapter work together to simulate a component in your early stage product designs.

Programming

Programming is also made easy using the Control Center Serial Software and Total Phase tools. If you have the need to program a SPI or I2C chip for prototypes or production, the Control Center Serial Software makes the process easy.  Start by launching the Control Center Serial Software and connecting to the Aardvark or Cheetah adapter or the Promira platform.  Enter the slave address of the target device and simply enter the data into the message box and click Master Write. The host adapter will now program the target device with the data provided.  Using the Master Read function, it is possible to verify and read back the contents of the newly programmed device.

Programming Using Batch Scripting

The Control Center Serial Software also offers Batch Mode for executing a series of programming commands.  The Batch Mode supports XML scripting with a built-in editor and the ability to load and save files.  Using this mode, users can run repetitive commands or a series of tasks with a single click of the Execute button.   The script will be run and the progress will be shown in the transaction log below.

For more information on batch mode or automating tasks with Control Center, check out this blog post that goes into more detail on how to do both.

Stress Testing

The Control Center Serial Software is also useful for stress testing an I2C or SPI system. Stress testing is best performed using the batch mode to run an automated script designed to flood the system with information/data.  By sending large amounts of data or issuing a high volume of commands, developers can determine how a system preforms under extreme conditions. Stress testing helps to determine the device limits before delivery into the hands of customers. Using the Control Center Serial Software, stress testing is as simple as writing a script and then hitting the Execute button. Then sit back and watch as Total Phase tools put the system to work.  Check out this blog post to see how one of our customers stress tested their system using our Promira Serial Platform and the Control Center Serial Software.

Conclusion

The Control Center Serial Software is a must have when it comes to interacting with I2C or SPI embedded systems. This single piece of software enables a variety of applications including programming, prototyping, and stress testing.  The easy-to-use and feature-rich platform gives engineers exactly what they need when it comes to development tools. Combined with the Total Phase I2C and SPI host adapters and serial platforms, complete testing is possible at an affordable price. To learn more about our solutions for I2C and SPI testing give us a call at (408)-850-6501 or email us at sales@totalphase.com.

Question from the Customer:

I am using the Beagle USB 12 Protocol Analyzer to monitor a High-speed USB bus. It detects no USB traffic or enumeration - what am I missing?

Response from Technical Support:

Thanks for your question! The Beagle USB 12 Protocol Analyzer is a Low Speed and Full Speed USB sniffer that will only capture Low and Full Speed USB device traffic. Unless you are monitoring a HID (human interface device) such as mouse, mostly likely the USB speed exceeds the parameters of the Beagle USB 12 Protocol Analyzer. It is a great tool for a variety of HID products such as mice and keyboards, but not for USB devices that operate in High-speed mode.

Checking USB Device Speed

To see if speed is an issue, the USB Device Tree Viewer is the easiest way to see the device speed. When you run the USB Device Tree Viewer, you will see a list of USB Host Controllers. You can cycle through each port of the USB Root Hubs attached to these controllers to see what is connected to that port. Each USB device that is connected to your computer (mouse, Wi-Fi or Bluetooth adapter, webcam, etc.) will be shown on one of those ports. The Tree Viewer will also show the Device Bus Speed of the highlighted device. Here is an example of what could be displayed:

The displayed speed will be one of the following:

• 0x01 (Full-Speed, 12 Mbps)
• 0x02 (High-Speed, 480 Mbps)
• 0x03 (SuperSpeed, 5 Gbps/625 MBps)

Here is an example of what you could see on your computer:

High Speed Work Around

For an immediate work-around to monitor the data, you could place a Full speed USB Hub between the target High-speed USB device and the Beagle USB 12 Protocol Analyzer. The hub will force the device traffic down to 12 Mbps, which the Beagle USB 12 analyzer is capable of capturing.  However, you would not be able to class decode the USB transactions. For greater support, we recommend one of our High-speed USB protocol analyzers.

High-Speed USB Protocol Analyzers

To capture, view, and analyze High-speed USB data, we recommend one of these protocol analyzers:

• Beagle USB 480 Protocol Analyzer
• Beagle USB 480 Power Protocol Analyzer – Standard Edition

Each analyzer has its specifications and merits. To select which is best for your project, we recommend taking a look at our USB Analyzer Product Guide.  For higher speeds and power concerns, the Beagle USB 480 Power Analyzer is a widely used tool. It offers class-decoding, triggers, and filtering, as well as the deepest USB 2.0 High-speed hardware buffer of our tools.

We hope this answers your questions. Additional resources that you may find helpful include the following:

• Beagle Protocol Analyzer User Manual
• Data Center Software User Manual

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo

It has been over two decades since the iMac G3 became the first mass-market personal computer to incorporate Universal Serial Bus (USB) ports into its design. For those old enough to remember, USB replaced a whole range of serial and parallel ports that were used to connect computer peripherals such as monitors, keyboards, and other I/O devices. Different types of devices were manufactured with many different types of ports and compatibility between computers and peripherals was a constant issue. The USB standard changed all of this by establishing a "universal" port that could be used for all kinds of peripherals. 

Having gone through several iterations, the latest version of the USB standard known as the "Universal Serial Bus 4 (USB4™) Specification" was published in August 2019 by the USB-IF Promoter Group, an industry group with representation from Apple, Hewlett-Packard, Intel, Microsoft, STMicroelectronics, and Texas Instruments. Once again, the world's leading electronics firms have collaborated to bring us a new standard for USB that promises greater compatibility and even faster speeds.

With the first USB4 connector cables slated for release in 2021, we're using this week's blog post to take a closer look at what we've already learned and what we can expect from the USB 4.0 specification release. We'll cover the history of USB, new features that have been announced for USB4 and any additional details or rumors of what to expect from the upcoming release.

The History of USB

For younger readers, it might be difficult to appreciate just how different computing was before the introduction of USB. Prior to the 1995 publication of the USB standard, electronics manufacturers who built peripherals for computers faced major device compatibility challenges. Without a standard port design for peripherals, it was impossible to build a mouse or keyboard that would work on every machine. For consumers, it was a constant struggle to purchase compatible peripherals and a new computer purchase might require the user to swap their mouse, keyboard, and monitor with newly compatible replacements.

1995-1999: USB 1.0

The USB 1.0 standard was first published in 1995, offering data transfer speeds of up to 12 megabits per second. The familiar USB connector design was also released during this period, with its recognizable male and female connectors. It was 1998 when the iMac G3 become the first PC to include USB ports. Standardized porting meant that peripherals manufacturers could finally build products that would work for all consumers, regardless of what type of computer they used. Computer manufacturers rapidly adopted the USB port design for inclusion in their products.

2000-2007: USB 2.0

USB 2.0 had a profound effect on the world of computing. This was the first USB standard that included power options (users would soon use USB connector cables to charge their cell phones). The emergence of USB flash drives rendered floppy discs, compact discs, and DVDs obsolete as storage media, thanks to their minuscule size and high storage capacity. 

USB flash drives like this one largely replaced floppy discs and compact discs in the early 2000s as the most popular portable data storage media. The USB Type-A connector shown here has now been replaced by the reversible USB Type-C connector.

2008-2017: USB 3.0 & 3.1

In 2008 the USB 3.0 specification was published and later followed by the USB 3.1 standard.  These standards were necessary to ensure that consumers would benefit from advancements in technology that enabled greater data transfer speeds and other capabilities. USB 3.0 offered data rates of up to 5 Gbps, while the USB 3.1 upgrade offered a maximum speed of 10 Gbps. The USB Type-C connector cable was also introduced during this time period (in 2014, to be precise). USB Type-C offers a user-friendly reversible connector, but it may be adopted more slowly because of the ubiquity of USB Type-A and Type-B ports.

2017: USB 3.2

Released in 2017, the USB 3.2 standard is the first iteration that uses the USB Type-C connector. Transfer speeds of up to 20 Gbps make USB 3.2 the most powerful specification so far in terms of data transfer speed. The new SuperSpeed+ transfer mode was made possible by allowing multi-lane operation over existing wires that were meant to support the reversible design feature of the Type-C connector. The release of USB 3.2 also resulted in naming and branding changes for previous USB versions.

2021: USB 4.0

This brings us to the USB 4.0 standard. Released in August 2019, USB4 is based on the Thunderbolt 3 protocol specification developed by Intel. USB4 will support 40 Gbps throughput and new features that will enable high-speed data transfer with multiple end devices.

USB4 and Thunderbolt Compatibility

Since the release of USB 3.0, each new iteration of the USB standard has had increased bandwidth as its most important feature. In establishing USB4, the USB Implementer’s Forum sought to increase bandwidth even further and drive the adoption of the USB Type-C connector while minimizing user confusion. These aims resulted in the establishment of four design objectives outlined in the standard:

1. Offer display, data, and load/store functionality over a single USB Type-C connector.
2. Retain compatibility with existing ecosystem of USB and Thunderbolt products.
3. Define port capabilities for predictable and consistent user experience.
4. Provide increased host flexibility to configure bandwidth, power management, and other performance-related parameters for system needs.

Intel donated the specs for Thunderbolt 3 to the USB 4.0 project because its massive 40 Gbps throughput speeds were desirable for a range of applications, including storage, displays, and low-latency connections to peripherals. Despite this, not all USB4 devices will take advantage of Thunderbolt compatibility. It will be left to manufacturers to decide whether to build in compatibility with Thunderbolt or not. The caveat is that manufacturers who wish to advertise their products as Thunderbolt 3.0-compatible may require costly hardware validation from Intel before use of the trademark is permitted.

USB4 High-Speed Capabilities 

One of the design objectives for the USB 4.0 standard was to allow for flexible bandwidth configuration. This means that devices using USB4 may not take advantage of the maximum 40 Gbps signalling rate available - they may be built for 20 Gbps or even 10 Gbps signalling and users may require more sophisticated dual-lane cables to support greater transfer speeds. Users will have to shop carefully to ensure that specs for any USB4 devices match their specifications.

The best news about USB4 might be that it mandates support for the USB power delivery protocol across all devices. The protocol involves smartly negotiated power transfer rates to USB-powered devices, which should result in longer battery life, faster charges, and extended lifetime for frequently charged batteries. 

Summary

 The USB standard represents a significant effort on the part of electronics manufacturers to provide an integrated and consumer-friendly ecosystem for connecting computers with data storage, I/O, and other peripherals. USB4 introduces a range of upgrades that support this, including mandatory support for the USB power delivery protocol, Thunderbolt compatibility, and a robust 40 Gbps maximum bandwidth.

At Total Phase, we build products that support embedded engineers throughout product development, testing and debugging, and through to market release. Our Beagle USB 5000 v2 SuperSpeed Protocol Analyzer is a non-intrusive monitoring solution for product developers that offers complete transparency into the functioning of your device and helps streamline the debugging and software testing process.   We also offer the USB Power Delivery Analyzer for debugging communication on CC1 and CC2 during power contract negotiation.

Are you designing an embedded system or connected device that leverages the USB protocol? Learn how our diagnostic tools can help you save money in product testing and get to market even faster.

Request a Demo

Question from the Customer:

I am using the Aardvark I2C/SPI Host Adapter with an I2C device. I need to read and write to specific registers, such as:

• Write to register 0x2H
• Read from register 0x3H

How can I best approach this task?

Response from Technical Support:

Thanks for your question! For writing and reading to a register, we recommend using our free application, Control Center Serial Software, in batch mode.

Using Control Center Serial Software

When using the GUI dialog, the register read operation in the Control Center Serial Software is streamlined. The I2C write and I2C read transactions are combined, which makes this operation easier for the user. However, that method does not supporting writing to and then reading from different registers.  In batch mode, you can easily write more detailed scripts, such as writing to one register address and reading from another register address.

Read/Write Registers in Batch Mode

For example, to read 4 bytes from register address 0x11 on I2C slave 0x55, you can do the following.

f<i2c_read addr=" count="4"/>

Shown below is an example of a full I2C transaction that is sent on the I2C bus for master register write/read.

Master Register Write:

Master Register Read:

The Control Center Serial Software will display the transaction log. To understand the transaction log, we recommend referring to the I2C specification of your target device and compare that information with the sequence shown in the transaction log.

For an example of implementing writing to an I2C device and then reading from a specific register, please refer to the article Which Software Tool Should I Use with the Aardvark I2C/SPI Host Adapter to Read the Status Register Information?

You can also watch an example of using the Control Center Serial Software in batch mode. This video includes writing and implementing an XML script, and watching the transaction log.

We hope this answers your questions. Additional resources that you may find helpful include the following:

• Control Center Serial Software User Manual
• Aardvark I2C/SPI Host Adapter User Manual
  

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo

The Control Center Serial Software and Flash Center Software are free software platforms offered by Total Phase that allow users to interface with Total Phase programming tools such as our I2C and SPI host adapters.

While these software platforms offer unique ways to access the features on the Promira Serial Platform, Aardvark I2C/SPI Host Adapter, and Cheetah SPI Host Adapter, both programs allow the user to read and write to memory devices. So which one is best for programming requirements? In this article, we’ll provide a briefing of each of these software platforms and provide insight into which one is most fitting for certain applications.

About the Control Center Serial Software

The Control Center Serial Software can be used to interface tools including the Promira Serial Platform, Aardvark I2C/SPI Host Adapter, and Cheetah SPI Host Adapter and eliminates the need to write custom software to control these adapters. It allows users to perform a variety of different functions, including reading and writing to memory devices and executing XML batch scripting to perform more repetitive commands.

Just like the Control Center Serial Software name suggests, this software is great for easily controlling devices, allowing users to prototype and test certain systems during the development stages.

Features within the Control Center Serial Software include:

• I2C Module to emulate I2C Master or I2C Slave devices
• SPI Module to emulate SPI Master or SPI Slave devices
• GPIO Module to allow users to substitute I2C/SPI pins to send and receive signals.
• Configurations such as: I2C+SPI, I2C+GPIO, SPI+GPIO, and GPIO only
• Reading/writing/verifying I2C-, SPI-based EEPROM and Flash memory chips
• XML batch scripting
• Transaction log of all data transactions that come in and out of the host adapter.

I2C and SPI modules in Control Center Serial Software

About the Flash Center Software

The Flash Center Software can also be used to interface with the Promira Serial Platform, Aardvark I2C/SPI Host Adapter, and Cheetah SPI Host Adapter and allows users to quickly erase, program, and verify I2C- and SPI-based EEPROM and Flash memory chips.

The Flash Center Software is focused on providing users a streamlined way to interact with their Flash memory devices, whether it be quickly verifying a memory device’s contents or gang-programming multiple target devices in parallel using multiple host adapters.

Using the Flash Center Software, users can perform the following:

• Program + Verify- Writes data to one or more attached memory devices and then reads back the data to verify it for correctness. If the device is an SPI Flash, an erase cycle will be performed first. The erase will cover only those sectors, which will be written. (Note that it is possible to erase more data than is written if a write ends in the middle of a sector. A warning will be logged if this is the case.) Also, if the data to be written is large enough to require the entire device to be erase, and the memory device has an “erase all” instruction, the software will use the “erase all” instruction.
• Program- Writes data to the device, but does not perform the verification step. If the device is an SPI Flash, an erase cycle will be performed first, with the same caveats as Program + Verify.
• Program (No Erase)- A special mode for SPI Flash devices. It writes data to the device, but does not perform an erase cycle. This is useful if multiple memory images are to be programmed to the device. Use FF as the pad value when loading each memory image to avoid corrupting previously written data. Because the device may have been programmed prior to this operation, it does not perform the verification step.
• Read Device- Reads the contents of the selected device and replaces it in the current contents in the data buffer.
• Verify- Verifies the contents of the selected devices against the contents of the data buffer.
• Erase- Allows the user to erase the entire memory device or allows the erasure of portion of it. For partial erasure, users can specify the start addresses and length in the erase parameters dialog as either a decimal value or as a hexadecimal value.

Writing to an SPI Flash memory device in Flash Center Software

Which Software is Best for your Programming Requirements?

Both the Control Center Serial Software and Flash Center Software support programming I2C- and SPI-based EEPROM and Flash memory, but do so in different way depending on the user’s objective.

Programing Using Control Center Serial Software

When programming EEPROM devices using the Control Center Serial Software, users are essentially programming their devices with certain instructions to allow the I2C or SPI master or slave device to carry out or respond to certain commands. Programming an EEPROM device using a host adapter can allow users to emulate a master or slave device. Some examples as to how to control I2C and SPI devices include:

• Using the host adapter 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.
• Using the host adapter as a slave to test commands sent from MCUs; simulate sensors and validate the commands sent by the master device.

Users can write instructions using the command line in Control Center or by importing XML batch instructions in Batch Mode.

While the Control Center Serial Software can communicate with Flash devices, it is not as well-suited for performing commands that are used to read and write to Flash memory – however, users can still configure the software to do so if needed. For users looking to strictly program their Flash memory devices, using the Flash Center Software would be the right choice.

Programing Using the Flash Center Software

Using the Flash Center Software is appropriate when users require an interface to quickly and easily erase, program, and verify their I2C- and SPI-based EEPROM and Flash memory devices.

Instead of having the ability to control I2C or SPI master/slave devices like in the Control Center Software, this GUI is especially useful for quickly reading/writing to devices for the sole purpose of loading them with information. This software was specifically created to know the right commands to efficiently read and write to Flash memory and includes a large number of part files to define how to control the parts.

One of the more common applications for using the Flash Center Software is mass programming. Many customers use Total Phase host adapters in conjunction with this software to mass program their devices on a production line. With the gang programming capability, users can work with multiple chips and multiple adapters in parallel making it very effective for production environments.

To create a seamless programming experience for developers, the Flash Center Software includes built-in support for a large number of memory devices. Plus, the software allows users to easily add support for any I2C or SPI EEPROM or flash device by loading new XML-based part descriptor files.

For more information on how to program your EEPROM or Flash memory device using the Flash Center Software, visit our page: Fast and Easy Flash and EEPROM Programming.

If you still have any questions on which software is best for your programming requirements, please contact us at sales@totalphase.com.

Question from the Customer:

I need to emulate a SPI slave device that operates at 4 MHz. I am looking at the Promira Serial Platform and the applications. Would the SPI Active - Level 1 Application fulfill these requirements?

• The data packet is 40 bits in length.
• There is no inter-byte delay during 1 CS active event: 5 bytes continuously clocked out.

Response from Technical Support:

Thanks for your question! In summary, the Promira platform supports bitrates from 31 kHz to 80 MHz, and data can be delivered without inter-byte delay. With the SPI Active - Level 1 Application, the maximum bitrate in slave mode is 8 MHz so your bus speed of 4 MHz is supported. Detailed capabilities are provided in the following sections.

Transmitting Data Packets

The data transmission to the Promira platform occurs through a buffer. The implementation uses buffer sizes of 2 MB less 1 byte (2 MB – 1 B) for sending and receiving transactions as an SPI master or an SPI slave.

• The maximum data size of single command is 1 MB.
• The maximum amount of data in a queue is 64 MB – 1 B.

Packets in Slave Mode

Continuous Data. The word size can be set from 2 bytes to 32 bytes without inter-byte delay. For continuous data, assert Slave Select (SS) for the entire transaction.

. The maximum amount of slave data to collect is 2 MB -1 B. To avoid losing data, we recommend collecting the SPI slave data as soon as possible.

Speed and Latency

Here is additional information, which can be important for the system interface of your setup.

For many reasons, latency occurs. For example, the Promira Software API and the computer operating system (OS) may add delay due to internal overhead. The Promira platform also has latency caused by the Ethernet/USB link to the computer. Although rare, there can be also delays across the Ethernet/USB bus within a transaction. There are methods to reduce latency:

• The USB round-trip latency is reduced to 250us when using the High-speed USB over Ethernet connectivity.
• The duration of the USB round-trip latency is further reduced when using Ethernet connectivity.
• The Promira platform also supports API queuing, which may provide additional speed-up.
• Although rare, delays may occur with the Ethernet/USB bus within a transaction. For more information, please refer to SPI Signaling Characteristics section of the Promira Serial Platform I2C/SPI Active User Manual.

We hope this answers your questions. Additional resources that you may find helpful include the following:

• Promira Serial Platform I2C/SPI Active User Manual
• SPI Background

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo

Product testing and software debugging are two of the biggest challenges that embedded systems engineers face when creating a new product. To help streamline the process, embedded systems developers must invest in various types of electronics testing equipment that provide clear and concise feedback and insight into product performance. Logic analyzers and protocol analyzers are two of the most popular debugging tools for embedded systems, but there's another versatile tool that can be deployed in a variety of electronics testing applications: a signal generator.

A signal generator is a diagnostic testing device for electronic systems that functions by producing an electrical signal according to user specifications. There are many kinds of signal generators - five in total - with each type offering unique advantages and applications based on its capabilities to generate signals of varying characteristics. In this blog piece, we'll take a look at what exactly signals generators are and how they're used to measure the performance of electronic products.

What is a Signal Generator? 

A signal generator is an electronic device that generates either analog or digital electronic signals. The signal produced by a signal generator can be calibrated according to user specifications and adjusted on the basis of its frequency, impedance, waveform, modulation, and output voltage. Signal generators are used to test electronic devices and instruments in a variety of applications, and as a result, there are several different types of signal generators:

Oscillators

An electronic oscillator is classified as a signal generator. It produces a periodic, oscillating low-frequency electronic signal that may be analog or digital (sine wave signal or square wave signal). Oscillators are a typical component in processor chips or microcontrollers where they provide clocking for digital devices.

Standard Signal Generators

Standard signal generators are often used to measure the functional properties and performance of electronic devices such as radio receivers. They generate analog electrical signals across a wide range of power output levels and waveform variations (modulations).

Frequency Synthesizers

Frequency synthesizers take a single input frequency and generate electric signals across a wide range of frequencies according to programmed logic. They are used in many types of electronic devices, including telephones, televisions, and global positioning systems (GPS).

Pulse Generators

A pulse generator is a piece of electronic test equipment that generates rectangular pulses. Pulse generators are similar to function generators, but are used in projects that involve digital circuits while function generators are used with analog circuits.

Random Noise Generators

Random noise generators can do some very interesting things. The purpose of a random noise generator is to generate random electrical signals. Instead of generating an electrical signal according to user specifications, a random noise generator produces a random signals within parameters that are set by the user. A random noise generator can be used to measure noise figure and frequency response for an electronic device, or even to generate random numbers.

How Does a Signal Generator Work?

The five types of signal generators mentioned above have one core aspect in common: they are all used to produce electric signals. However, each type is unique in the types of signals that it is capable of producing, and therefore, in its testing applications. An electric signal can be described as a voltage whose value changes over time according to a function specified by the user. 

A signal generator, when used to test an electronic device, is typically deployed in conjunction with some kind of measurement device. The signal generator is used to produce an electric signal, known as the input signal, that will elicit a response, known as the output signal, from the device under test. The output signal will be received by a measurement device like a protocol analyzer or logic analyzer, enabling the developer to see whether the expected output was, in fact, received. If the device responds as expected, the test was passed. Otherwise, the developer will have to further investigate the anomalous or unexpected behavior of the device.

Today's signal generators are designed with an intuitive user interface that makes it easy to adjust target variables based on project requirements. A series of knobs and switches on the face of the signal generator allows users to adjust the type of waveform, voltage level, frequency, signal inversion, and other characteristics. 

Different Types of Signal Generators

When we presented five categories of signal generators earlier in this piece, we included several signal-emitting devices alongside the standard signal generators that are used in electronics testing. Within the category of standard or "general purpose" signal generators, we can further divide signal generators into three sub-types: analog and vector (also called digital) signal generators and digital pattern generators.

Analog Signal Generator

An analog signal generator is a device whose construction is based on the sine wave oscillator. This device was also the first product ever sold by the Hewlett-Packard company in 1939. The term "analog" refers to the types of waveforms that can be produced by this device: continuous and sinusoidal. Analog signal generators effectively produce signals in the audio and radio frequency ranges and are effective for measuring sound distortion and other properties of electronic devices.

Vector Signal Generator

While analog signal generators are still in use, vector signal generators represent the next stage in the evolution of this technology. Vector signal generators are used to measure and test digital communications systems that can no longer be tested properly with analog equipment. They can generate digitally modulated radio signals across a variety of formats.

Digital Pattern Generator 

A digital pattern generator is a useful diagnostic tool for embedded systems engineers programming projects with I2C, SPI, or USB communication protocols. Digital pattern generators produce logic signals - square-shaped waveforms that represent ones and zeroes with changes in voltage level. Digital pattern generators can be deployed in testing applications for embedded systems and digital integrated circuits.

Conclusion

A signal generator allows embedded systems engineers to produce an electric signal according to their exact specifications and use it as an input signal to measure the response and performance of any electronic device. However, embedded systems developers will still need the right measurement tool to effectively capture and record the response from their device for function validation and performance verification.

That's where Total Phase comes in: our Beagle I2C/SPI Protocol Analyzer is the ideal bus monitoring tool for use with your chosen signal generator. You'll gain complete insight into the performance of your embedded system with real-time data capture and display, making it easy to measure performance and identify errors.

Need help optimizing your debug or testing process? We'll show you how to do it better.

Request a Demo

Question from the Customer:

For a project focused on SD cards in SPI mode, I am looking at the Aardvark I2C/SPI Host Adapter and the Cheetah SPI Host Adapter. To cut costs, I am also looking at using Beagle I2C/SPI Protocol Analyzers instead of oscilloscopes. Looking at the specifications, I want to confirm how the Aardvark adapter works.  Based on the article How Do I Set Up SDC or MMC Cards in SPI Mode to Verify Files were Successfully Programmed?, it looks like the Cheetah adapter would do a better job for me, at least for the verification part of the project. When it’s finalized, the verification process will be moved to the production floor, where speed matters.

This project does not require transferring files from an SD card or managing file systems. I need to handle block reads and writes of raw data. Here are my questions:

• Is there a specific step of the flow that does not work with the Aardvark adapter, or is it every single command?
  Set Up SDC or MMC Cards in SPI Mode
• In SPI mode, can the Aardvark and Cheetah adapters build up multi-byte transactions within a single chip select?

SPI clock pauses are acceptable for this application. My questions are based on the following SD card specifications:

• While the SD Memory Card channel is based on command and data bit streams that are initiated by a start bit and terminated by a stop bit, the SPI channel is byte orientated.
• Every command or data block is built of 8-bit bytes and is byte-aligned with the CS signal; the length is a multiple of 8 clock cycles.
• The card starts to count SPI bus clock cycles at the assertion of the CS signal. Every command or data token shall be aligned with an 8-clock cycle boundary.

Response from Technical Support:

Thanks for your questions! Based on your project requirements and the SD Card specifications, your plan to use the Aardvark adapter for development and the Cheetah adapter for production should work.

The following sections describe how the Aardvark adapter and the Cheetah adapter transmit data.

Aardvark Adapter Data and Timing

The Aardvark adapter supports your requirements for development.

• The Aardvark adapter can only send data in multiples of bytes. It is not capable of sending data bit by bit; each byte would be sent in 8 clock cycles.
• The Aardvark adapter has a td between two bytes of 8 bits: as an SPI Master, 7 to 9µs; as an SPI Slave, minimum 4µs.
• There is approximately 9µs of setup time required in between each byte. This results in a total transmission period of the byte transmission time plus 9 µs.

In summary:

• The Aardvark adapter can transfer up to 8 bits data without td delay.
• The Aardvark cannot transfer 16-bit data (or more) without td delay.
• The maximum bitrates are only achievable within each individual byte and do not extend across bytes.

The delay between each byte of data sent is due to the characteristics of the Aardvark adapter. For example, you can write two 8-bit bytes, AB CD, in the transaction log of Control Center Serial Software, and submit send: "assert SS, send AB CD, deassert SS". There will be gaps in the middle, but it is still a single transaction with slave select (SS) asserted at the beginning and de-asserted at the end – as specified in your requirements.

For more information, please refer to the Signaling Characteristics section in the Aardvark I2C/SPI Host Adapter User Manual.

Speed and Latency Advantages - Cheetah SPI Host Adapter

The Cheetah adapter actively communicates on the bus, operates at high speeds up to 40+ MHz, can provide gapless shifting, and provides control over the timing of the data that is shifted out.

• Since the Cheetah adapter uses a High-speed USB link, the 2ms USB latency seen with the Aardvark adapter would be reduced to about 250us. This advantage occurs when using the Cheetah adapter's synchronous interface.
• Using the asynchronous interface that may provide additional speed-up. The asynchronous interface allows you to queue the data to be sent by the Cheetah adapter, which allows gapless shifting.

For creating SPI transactions, the Cheetah Software API differs from the Aardvark Software API, and may provide more benefits for production. For information about the advantages of the Cheetah Software API, please refer to our article about Using Cheetah to Send Multiple SPI Packets with One Transfer.

We hope this answers your questions. Additional resources that you may find helpful include the following:

• Cheetah SPI Host Adapter User Manual
• Aardvark I2C/SPI Host Adapter User Manual
• Control Center Software User Manual
• Beagle Protocol Analyzer User Manual
• SPI Background

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo

The Control Center Serial Software allows users to easily control their I2C or SPI devices, including multi I/O SPI devices. In this blog, we’ll cover how to use the Multi I/O SPI Master Mode function to easily configure your master device to support dual and quad SPI modes.

What is Multi I/O SPI?

The Standard SPI protocol operates with bidirectional communication using the MOSI and MISO lines, but with Multi I/O SPI, the lines are reconfigured to allow the bus to operate at quicker speeds. Multi I/O SPI increases the supported bandwidth across the SPI bus by enabling parallel data lines in a half-duplex manner, meaning data is only sent in one direction. Compared to a standard SPI device, a dual I/O interface doubles the transfer rates using two data lines while quad I/O quadruples it using four data lines.

Using Multi I/O SPI Master Mode

Users who are looking to emulate a dual or quad SPI master device can easily do so using the Multi I/O SPI Master Mode feature in the Control Center Serial Software. This feature is only available on the Promira Serial Platform, with the SPI Active – Level 2 Application supporting Single/Dual I/O, and the SPI Active – Level 3 Application supporting Single/Dual/Quad I/O.

Promira Serial Platform

Using the Multi I/O SPI Master Mode, users can specify the I/O mode for sending and receiving Single, Dual, or Quad SPI data, but users can also be more flexible and specify the I/O Mode for bytes at different stages, including each byte sent on the wire as a master as seen here.

Multi I/O SPI Master Mode in Control Center Serial Software

Selecting IO Mode within the Multi I/O SPI feature allows users to select which type of SPI will be used for each phase of the transfer. The first mode in the parenthesis is the IO mode for Command, the second is IO mode for Address, and the third is the IO mode for either message to write when sending or message to read when receiving.

To configure Dual or Quad mode:

1. Connect the Promira Serial Platform to the Control Center Serial Software
2. Connect the Promira Serial Platform to the target device
3. Select Multi I/O SPI in the software
4. Configure the desired voltage level for powering the target device
5. Set the desired bitrate
6. Configure the Promira platform for Dual/Quad SPI Mode
7. Initialize the target device and read the device ID

To write to the slave device, users can enter the data in the “Data” text box and click “Send”. To read and verify the data, users can click “Read” and also specify the number of words to read. All data transactions can be viewed in the Transaction Log.

The Slave Select option also allows users to select the desired slave signal when communicating with multiple SPI slaves using separate SPI slave selects. The Promira Serial Platform supports up to 8 slave selects (when configured with SPI Active – Level 3 Application), however only some of them may be configurable based on the capabilities of the attached device.

To select which slave to communicate with:

1. Connect the Promira Serial Platform to the Control Center Software.
2. At the top menu bar, select Adapter and then click Multi I/O SPI.
3. In the Multi I/O SPI window, select the SSn for the desired slave. The number of displayed Slave Select lines is dependent on how many slaves the attached device can support. You can also select the desired Bitrate.
4. Set the command and address values.
5. Insert the data to send in text box. Transactions can be viewed in the Transaction Log.

For a detailed example on how to Program a Dual SPI Flash Using the Promira Serial Platform and the Control Center Serial Software please visit our Knowledge Base Article.

For any additional questions on the Multi I/O SPI Master Mode functionality in Control Center Serial Software, please contact us at sales@totalphase.com.

Question from the Customer:

I am using the Aardvark I2C/SPI Host Adapter in I2C mode to perform a Master Register Read. Normally, I can do that with Aardvark Software API, but this time I’m using LabVIEW and it’s not working for me. How do I successfully implement I2C Master Register Read with LabVIEW?

Response from Technical Support:

Thanks for your question! The Master Register Write-Read, also known as Master Register Read, is actually a combination of two I2C transactions.

Master Register Write-Read

You can implement this transaction by calling two functions directly: aa_i2c_write() and aa_i2c_read().

• The first API call is aa_i2c_write(). This call is used with the AA_I2C_NO_STOP flag, and contains the device register address from which to read.
• The second API call is aa_i2c_read(), which sets the number of bytes to read.

Depending on the how the NO_STOP flag is set, this can be implemented as a single transaction or a pair of transactions.

Single Transaction

Here is an example of a full I2C transaction:

[Start] [Device Addr][W] [Register Addr] [Start] [Device Addr][R] [data] ... [data] [Stop]

Using the NO_STOP flag on the write effectively combines the two API calls into a single I2C transaction.

Two Transactions

The same operation can be achieved with two transactions.  The only difference is excluding the NO_STOP flag. Here is an example of using two I2C transactions for Master Register Write -Read:

[Start] [Device Addr][W] [Register Addr] [No-Stop]

[Start] [Device Addr][R] [data] ... [data] [Stop]

We have articles about using LabVIEW that may interest you, such as Create a Custom LabVIEW Application. This blog is about testing and evaluating SPI devices, but you can still refer to it as an example.

More information is available in our Knowledge Base, such as Sending I2C Messages Between Two Aardvark adapters Using Aardvark LabVIEW. This article is a good example for learning how to install the LabVIEW driver package, see the GUI interface, and send I2C data between two Aardvark adapters.

We hope this answers your questions. Additional resources that you may find helpful include the following:

• Aardvark I2C/SPI Host Adapter User Manual

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo