The Internet of Things (IoT) refers to the billions of devices around the world that are now connected to the internet and capable of uploading sensor data and other information through wireless networks and into the cloud. In addition to residential applications like smart home security systems and washing machines, IoT devices have made their way into the workplace where they promise to enhance workplace safety and efficiency across industries and around the world.

In this week's blog post, we're breaking down the impact of the IoT on workplace safety. We'll look at how current applications of IoT devices are keeping workers safe and how the same technology is being used to drive worker productivity gains. Finally, we'll explore the potential of IoT technology to help organizations predict dangerous conditions and prevent occupational injuries before they happen.

How IoT Devices are Impacting Worker Safety

Connected devices are playing an increasingly important role in worker safety, especially in industries that traditionally have higher rates of accidents and injuries. Through devices that monitor and report on environmental conditions, as well as the physical health of workers, organizations are better able to limit worker exposure to hazardous conditions and avoid accidents.

The construction industry has struggled for years to drive down rates of occupational injuries. Among the ten most dangerous jobs in the United States, at least two can be considered construction jobs, including roofers and first-line supervisors of construction and trade workers. In hopes of decreasing occupational injury rates, construction companies are adopting hard hats with embedded sensors that monitor the physical condition of workers, including heart rate, fatigue, temperature, and oxygen level. 

These metrics make it possible for a computer or human supervisor to identify unsafe circumstances before they lead to injury. On hot days where heat stroke is a genuine threat, a construction foreman can assess whether workers are overheating and need time to cool off. A worker with elevated heart rate can be prompted to take a break if they have a history of cardiac issues. If a worker falls unexpectedly or loses consciousness, an alert can be generated that ensures they are quickly found and given the appropriate medical attention.

In addition to connected wearable devices that monitor the physical condition of the user, IoT devices can also be configured to monitor the environment for hazards that could harm workers. In construction, manufacturing, and raw materials processing, companies are using IoT devices with sensors that monitor air quality and equipment temperatures to help ensure worker safety on the job site. IoT devices with fire safety sensors can be used to detect increased temperatures that could indicate a fire and trigger preventive actions or the timely evacuation of workers.

A smart hard hat can detect environmental hazards or physical problems with the user, helping to initiate an early response to potentially harmful situations on the job site.

Image courtesy of Unsplash

Can the IoT Contribute to Improving Workplace Productivity?

The construction and manufacturing sectors face similar long-term challenges when it comes to ensuring worker safety: how is it possible to reduce accidents and improve safety outcomes without sacrificing productivity? With the IoT, companies in these industries may finally be coming close to solving this problem.

In addition to worker safety benefits, the IoT promises to increase efficiency and productivity in many different ways.  For starters, connected wearable devices that track the physical condition of workers can detect signs of fatigue, dehydration or exhaustion that would result in reduced productivity. Workers can gain valuable feedback on when to take breaks and how to minimize overexertion to accomplish the most during their shift.

In other industries, the IoT is playing a much greater role in driving productivity gains. The largest car manufacturers and technology companies are working to develop fleets of autonomous vehicles that will play a massive role in shipping, transportation, ride hailing, and other transportation-related markets. These vehicles will be massively productive as they can stay on the road all day (the driver never needs to rest). In addition, automated collision avoidance will reduce the number of traffic accidents and fatalities. Driving is probably the most dangerous task that workers engage on a regular basis, so we can expect autonomous vehicles to have a large positive impact on overall worker safety. 

IoT Devices and Future Workplace Injury Prevention

In addition to directly enhancing worker safety and contributing to worker productivity gains, connected IoT devices will also empower organizations to predict and prevent accidents through early detection of potential safety issues. We're already seeing several exciting new applications of embedded IoT devices and sensors in acting as early warning systems, detecting unsafe circumstances before an accident ever occurs.

In underground industrial mining operations, smart sensors are used to measure seismic activity such as earthquakes that occur tens or even hundreds of miles below the Earth's surface. Still, this activity can cause soil to shift and make tunnels unsafe for workers due to the increased likelihood of collapse. Measuring seismic activity makes it possible to predict when and where it might be unsafe to dig and empowers companies to appropriately protect their workers when the safety status of the job site is compromised or uncertain.

Predictive maintenance is another area of opportunity for reducing workplace injuries. Equipment that is poorly maintained may be more likely to malfunction in a way that negatively impacts worker safety. IoT devices can be used to monitor environmental conditions over time and better anticipate when machine or equipment parts must be replaced to ensure safe operation.

Summary

Are you designing an IoT-enabled device that will positively impact worker safety?

Total Phase designs and manufactures test and debugging equipment for embedded systems, including devices made for the IoT. With our protocol analysis tools for the most popular embedded protocols, engineers can speed up the debugging process, gain critical insight into the functioning of their product and reduce overall time to market.

Want to learn more about how Total Phase can support your next IoT hardware project?

Request a Demo

Question from the Customer:

I am using the new Advanced Cable Tester v2 to test our USB 3.2 Standard-A to Type-C cables and am running into some problems after creating a custom profile. So far, I have not been able to modify the setting for the ground resistance to fit the specification. Here is where the test report shows failure:

ACT Test Report

How do I adjust the ground resistance settings for GND and GND+Shield A-Side Link?

Response from Technical Support:

Thanks for your questions!  There are some steps to follow when you modify a profile, including loading in the new parameters and restarting the test profile. In your case, there are measurements to consider. We’ll start with updating the test profile, how cables and plugs (shells) are typically designed, then move into measurement guidelines, and how to address any issues that may occur during measurements.

Updating the Customized Cable Test Profile

After modifying the test profile with the new parameters, the test process much be restarted.

1. If needed, clone the existing profile.
2. Enter the new parameters.
   ... DCR: GND Wire Resistance
   … DCR: GND+Shield A-Side Link (true/false, as explained below)
3. Click the Save button
4. On the main screen of the Advanced Cable Tester v2, click the Change button and select the new profile. Note: Even if the profile seems to be in-process, you still need to press the Change button for the Advanced Cable Tester v2 to load the updated profile.

Analyzing the GND+Shell Link

According to the recent USB Type-C specification, Standard-A to Type-C cables must tie GND+Shield together within each plug so that the shield braid can carry some of the return current. It can also help control electro-magnetic interference (EMI) by ensuring the shield braid is well grounded. Typically, the shell contact is not optimal on USB Standard-A cables.

• The classic USB Standard-A plug mechanical designs typically have separate GND and Shield connections. This design makes it difficult to physically tie them together within the Standard-A plug. The wires can be soldered directly to the lead of the plug, but that makes it difficult to cleanly tie GND+Shield.
• The GND and Shield wires must also be tied together within the Type-C plug.
• The Type-C plug has a paddleboard, a printed circuit board (PCB). This is easier and cleaner because GND and Shield are tied together on the PCB.

With the physical challenges of the USB Standard-A plug wiring, many cables have only the Type-C plug paddleboard GND+Shield tied together.

Guidelines to Differentiate GND+Shield Methods

It can be difficult to differentiate the two cases: simple continuity checks would show "continuous" if either spot had the GND+Shield connection. Therefore, it is necessary to confirm that the USB-A side actually has a connection. This check is performed with the GND+Shield A-Side Link test.

Measuring Resistance

The GND+Shield A-Side Link test is unique from other DC resistance measurements. The upper limit is calculated at each test run. It is important to note, this calculation will not work with an extremely high Shell DCR; in that case, the calculated values would not be correct. The report that you provided shows 5.115 ohms, which is significantly high.

Here are two measurements to take:

Measurement 1: Standard-A Shell to Standard-A GND: the current path through the A-side link.

Measurement 2: Standard-A Shell to Type-C GND & Shell) + (Type-C GND & Shell to Standard-A GND: the roundtrip path the current would take through the entire cable.

Here is what the measurement results may indicate:

• If Measurement 1 measures less than half of Measurement 2, it probably indicates that the current path is only through the Standard-A plug
• If Measurement 1 measures more than half of Measurement 2, it probably indicates that the current path goes through to the Type-C plug and back.
• Note: The measurements are divided in half to move the decision point. This provides some margin for noise or poor connections.

This evaluation is not effective when the shell contact resistances are very high relative to the roundtrip wire DCR. As the test results indicated your shell contacts were several ohms, this algorithm will not work. We recommend a physical examination based on these test results. The resistance of the shell may be reduced by cleaning the Standard-A plug.

Evaluating Physical Design

Although a high resistance shell contact is not ideal, it probably causes no harm in actual use. However, this information may be useful should a performance issue occur. To confirm a design, you can also review the design specifications, and/or disassemble the connector for physical analysis.

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

• Advanced Cable Tester v2 User Manual
• Advanced Cable Tester v2 User Quick Start Guide
• USB Documents

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

About the SPI Protocol

SPI, Serial Peripheral Interface bus, is a synchronous serial data protocol that was developed by Motorola in the 1970s. The protocol was developed to replace parallel buses and provide high speed data transfers over short distances.

It is a full-duplex protocol that requires four signals: clock, master out/slave in, master in/slave out, and slave select. Data is simultaneously transmitted and received. SPI allows for multiple slaved devices to be controlled by a single master and each slave device has an individual slave select line.

Figure 1. Example configuration of Single SPI with 3 slaves

The Differences Between Single, Dual, and Quad SPI

Single SPI

Single mode SPI works for most use cases such as rapid prototyping, device programming, and automated testing. SPI is fast, with most single SPI serial throughput rates reaching around 10 Mbps. Single SPI parallel throughput rates ranges from 10 – 24 Mbps. However, a single data line will not be able to send data at SPI’s fastest speed.

Multi I/O SPI are capable of supporting increased throughput from a single device. SPI itself is full-duplex. Dual and Quad SPI are both half-duplex due to using 2-4 pins to send and receive. Switching to Dual or Quad SPI is done via sending a command byte while in Single SPI. The command byte will request a response in either dual or quad mode.

Dual SPI

Dual SPI has a dual I/O interface that enables transfer rates to double compared to the standard serial Flash memory devices. The MISO and MOSI data pins operate in half-duplex mode to send two bits per clock cycle. The MOSI line become IO0 and the MISO line becomes IO1. Dual SPI serial throughput rates reach around 20 Mbps.

Quad SPI

Quad SPI is similar to dual, but improves the throughput four times. Two additional data lines are added, and there are 4 bits transferred every clock cycle. The data lines are now IO0, IO1, IO2, and IO3. Quad SPI Serial throughput rates reach around 40 Mbps.

Figure 2. Example Quad SPI setup with single slave

Benefits of Dual and Quad SPI

Multi I/O SPI is especially useful with memory-intensive data. Compared to classical SPI, which only uses one data line, Dual and Quad SPI use 2 and 4 data lines which will increase the data throughput 2 or 4 times.

Before Dual and Quad SPI was created, earlier solutions used parallel memory. Parallel memory would use 8-, 16-, or 32- pins to connect the external memory device to the microcontroller. When compared to parallel interfaces, Dual and Quad SPI allows for external flash memory chips to come in smaller packages. These small packages reduce PCB space on a board which helps simplify PCB design and reduces GPIOs.

The decision to use Dual or Quad SPI is based on pin count and the data transfer speed that developers wish to use. Flash chips that support Quad SPI generally support Dual SPI. Single, Dual, and Quad SPI are also pin-compatible.  More information about the flash chip can be found on its respective datasheet.

Total Phase Tools That Support Different SPI Configurations

Total Phase offers a variety of tools for different SPI configurations.

Our Aardvark I2C/SPI Host Adapter, Cheetah SPI Host Adapter, and Beagle I2C/SPI Protocol Analyzer support SPI Single I/O.

The Promira Serial Platform can support Single, Dual, or Quad I/O depending on the SPI Application. For a comparison of our SPI tools and whether it supports Single/Dual/Quad SPI, please the chart below:

Total Phase provides socket boards, like the Flash SOIC-16 Socket Board - 10/34 to help quickly program flash chips. Our Flash Center Software also allows users to quickly erase, program and verify EEPROM and Flash memory chips. To learn more about how Total Phase tools can verify and program Dual/Quad SPI Modes, please visit our blog: “What is the Easiest Way to Program and Verify a New SPI Memory Chip in Duo-Quad SPI Modes?”

For more information on how our tools can support Single, Dual, and Quad SPI, please contact us at sales@totalphase.com.

Question from the Customer:

 I am working on a new project and after reading your article Did You Know That a Beagle Protocol Analyzer Can Be Integrated with Wireshark or ARM-based Hosts?, it looks like the Beagle I2C/SPI Protocol Analyzer could do the job. To be sure this is the right tool, I have some questions:

• For IPMI analysis, can I export data from the Beagle I2C/SPI analyzer into Wireshark?
• Could I use the Data Center Software for sending the data in the format of ASCII HEX? I didn’t find that option. It looks like I could use the open source srec utility to convert the data from binary to ASCII hex.
• What is the process for exporting IPMI data from the Data Center Software into Wireshark?

Response from Technical Support:

Thanks for your questions! Many customers have successfully used the Beagle I2C/SPI analyzer to import data into Wireshark.  Wireshark's wiki provides information about transporting byte-level data. Here is a diagram that provides an overview about IPMB packets:

Format of IPMB Packet

Source: Wireshark

Wireshark also provides a utility that enables you to capture IPMB bus data with the Beagle I2C/SPI analyzer, and then load the resulting file into Wireshark. The utility file you will need is beagle_i2c_analyzer.tar.gz, which includes an informative readme.txt file. You will not need the open source srec utility.

Using the Wireshark Patch File

This section shows you how to set up and start using the patch file (beagle_i2c_analyzer.tar.gz). We recommend opening two terminals.

• The first terminal is for setting up and running the program.
• The second terminal is for displaying the data captures by Beagle I2C/SPI analyzer. Without a second terminal, the captured data will instead be printed to a file; it will not be displayed for viewing.

Set Up and Execute

Download the file, then compile the program with the following command:

make

Afterwards, to remove all the executable files, enter:

make clean

Execute the program i2c_analyzer with the following command:

./i2c_analyzer  -[option]  [option argument]  max_packet_len  num_even  0  1...

-[option] is the option that you choose to use, such as quiet mode, debug mode, etc. Where to access information about the options is provided in a following section, “More Information About Wireshark”.

[option argument] is the argument that will follow after the -[option] is made. Here are some examples:

 ./i2c_analyzer -v 3 0 1 2

./i2c_analyzer -q 0

./i2c_analyzer -h

max_packet_len is the maximum size of the packet that you want to capture in bytes, such as 32, or 64 or other size values

num_even is the number of the packets that you want to capture.

0 indicates an infinite number of packets.

0 is the Beagle I2C/SPI analyzer on port 0. If you have using only one analyzer, your command may stop here.

1 … indicates the next port number(s) for the other Beagle analyzers that you are using. The port number increases sequentially according to the device that is connected to the program.

Stop Capture and Read Data

To stop capturing, simultaneously press the keys Ctrl and C

After completing the last capture, the Beagle I2C/SPI analyzer(s) will stop sniffing and create the file hexdump_bg, which will be stored in your current directory. With the following command, hexdump_bg is used with Wireshark to generate a pcap file:

text2pcap           -t            "%D %H%M%S."              -l 199     hexdump_bg               ipmbfile.pcap

This command builds a file that contains IPMB matching packets that were captured from the Beagle I2C/SPI analyzer. The name of this file is ipmbfile.pcap and is stored in your current working directory. This file can be opened with Wireshark to see the detailed information of your packets.

More Information About Wireshark

To learn more about text2pcap, enter the command:

text2pcap -h

To learn more about the sniffing device aasniff enter the command:

 ./i2c_analyzer -h

This command populates a list of user manuals on the screen that provide details about using each option.

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
• Wireshark Bug Database
• IPMB Protocol
• Wireshark PCAP documentation

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

Digital signal processing (DSP) represents an exciting area of computer science and a world of possibilities for engineers designing new embedded system products. DSP technology uses specially designed programs and algorithms to manipulate analog signals and produce a signal that is higher-quality, less prone to degradation or easier to transmit. 

In this blog post, we explore some of the technology behind digital signal processing. We'll look at typical components, the key differences between analog and digital signals and the most common use cases for DSP.

What is Digital Signal Processing (DSP)?

Digital signal processing, or DSP, is a powerful technology with applications in many areas of science, engineering, health care, and communications. DSP technology enables the processing and manipulation of sensory data obtained from a variety of real-world sources. Visual images, sound waves, and even seismic waves can all act as inputs for digital signal processing. 

The general function of a DSP is to measure, compress, or filter an analog signal. This typically requires the DSP to perform a large number of simple mathematical functions (addition, subtraction, multiplication, division, and the like) within a fixed or constrained time frame. To achieve this, companies like Texas Instruments have developed specialized microprocessor chips that are optimized for the task of digital signal processing.

Digital signal processing technology is used wherever there is a need to compress, measure, or filter audio or another type of signal. The development of DSP began in the late 1960s and early 1970s when digital computers were first made available to governments and the largest corporations, but not yet to the general public. At this time, the application of DSP technology was focused on the military and government sectors, in areas like radar and sonar, space and oil exploration, and medical imaging.  As personal computing became commonplace through the 1980s and onward, digital signal processing saw a wider range of commercial and consumer-focused applications. Mobile phones, movie special effects, and mp3 files all depend on DSP technology.

Components of Digital Signal Processing

A typical digital signal processing system follows a basic architecture that facilitates the digital conversion and manipulation of an analog signal. The first requirement for DSP is always a signal source - there must be a signal to filter, measure, or compress. The first step in processing the signal is to convert the analog signal into a digital signal using an analog-to-digital converter (ADC). An ADC converts an input analog voltage to a digital measurement of that voltage. 

Following the conversion of the signal to the digital format, the data can be passed through a DSP microprocessor chip where the signal may be filtered, compressed or otherwise manipulated according to application-specific requirements. Once the digital signal has been suitably modified, it may be converted back into analog format with the use of a digital-to-analog converter (DAC). The end result will be a new analog signal that represents a digital modification of the original input signal.

A digital signal processing chip contains four main components:

• Program Memory - DSP chips contain two types of memory. The first type, the program memory, stores the programs and algorithms that the chip will use to process data. Programming for DSP chips varies significantly by application.
• Data Memory -  The second type of memory used in DSP chips is known as data memory. This is where the chip stores the data it receives and that will be processed on the chip. Data is typically received as a digital signal that was previously converted from an analog signal.
• Compute Engine - The compute engine is the central processing unit of the DSP chip. This is where the computational power for the chip lives and where the algorithms from program memory will be applied to process data.
• Input/Output - A DSP chip may possess a number of different types of ports, including serial ports, timers, host ports, external ports, LINK ports, and other types. Ports allow the DSP to send and receive data transmission from other devices, such as ADC or DAC converters. A DSP may also be incorporated into a larger computer system by port connections.

Audio that is recorded using a microphone is captured in an analog format. A professional sound engineer will manipulate the sound using DSP before incorporating it into a final mix that will be released to listeners.

Image courtesy of Unsplash

How is DSP Different from Analog Signals?

Now that we've shed some light on how digital signal processing works, you might be wondering about various applications of DSP and the real value of converting analog signals into a digital format. To address this question, we need to understand more about the definitions and differences between analog and digital.

An analog signal is a continuous signal whose time variable is analogous to some physical quantity that changes over time, such as tone, voltage, or pressure. An analog signal depicting changes in voltage over time might reflect an amplitude of +/- 120 V, with the signal expressing all values within that range. In contrast, a digital signal would represent the same voltage as a sequence of discrete values, often coded for computers using the binary number system. 

Analog and digital signals contain the same information, but formatted in different ways. Analog signals reflect the reality that we live in a world where we can see an infinite number of different colors, hear an infinite number of tones and even smell an infinite number of smells. We can convert these data into a digital format that expresses each color, smell or sound as a combination of ones and zeroes. Then, we can write programs that manipulate the data in different and useful ways with the help of digital signal processing. As a final step, we can convert the digitally manipulated data back out of computer language and into analog form where we can hear or see the results.

Why Use Digital Signal Processing?

To demonstrate the versatility and usefulness of DSP, we can briefly explore just a few of the many applications for digital signal processing technology.

DSP in Audio Processing

Digital signal processing technology plays a major role in processing audio signals that are produced for human consumption. These generally appear in two forms: music and speech.

The process of recording music depends on DSP to produce a final mix that is optimally pleasing to the human ear. In the recording studio, the various components of a track are recorded in analog and converted into a digital format where they can be manipulated for volume, tonality, and a range of other features. DSP can assist with filtering, signal addition and subtraction (adding new sounds or subtracting unwanted sounds), editing, and more.

DSP is used in computer-generated speech applications, which combine digital recording technology and vocal tract simulation to replicate human speech patterns using a computer.

DSP in Echo Location

Digital signal processing plays a significant role in the functioning of modern radar systems. DSP can be used to compress a pulsed radiofrequency, increasing the accuracy of distance determination for objects detected on radar. A DSP chip can also increase the effective range of radar systems by filtering noise, and it may allow the operator to transmit radio waves pulses of varying shapes and lengths, enabling pulse optimization on a per-case basis. 

Conclusion

Are you building an embedded product that uses digital signal processing to solve real-world problems? Total Phase is committed to supporting the most innovative engineers and product developers with product testing and debugging tools that help reduce development costs and time to market for your DSP product. 

Our I2C and SPI tools offer full insight and transparency into the functioning of your device, streamlining the process of investigating, isolating, and rectifying unexpected errors and software anomalies. 

Learn More

Question from the Customer:

I’m looking at the A2B Bus Monitor - Level 1 Application for an audio system.  I have some questions:

• How many total channels are available? Our system has multiple channels per board.
• How is the SigmaStudio® software used within the system?
• Can we capture data in formats other than .WAV file?
• Could I monitor the phantom-power values?

Response from Technical Support:

Thanks for your questions!  The A2B Bus Monitor - Level 1 Application is designed for bench top prototyping and in-vehicle field testing. It is a passive monitor that non-intrusively sniffs A2B data, providing real-time access to the data traffic. This access to data supports analysis, troubleshooting, and validation. For more information, please refer to this datasheet.  Please note the A2B Bus Monitor Application runs on the Promira Serial Platform.

A2B is a proprietary protocol developed by Analog Devices.

What the A2B Bus Monitor Supports

The following sections describe what the A2B Bus Monitor provides for your setup.

Number of Channels

The A2B Bus Monitor supports 16 channels upstream and 16 channels downstream concurrently. Here is how the channels are used:

• The ADI sniffer chip (which is on the A2B adapter board), will use the first two channels (numbers 0 and 1), both upstream and downstream for the Synchronization Control Frames (SCF) and Synchronization Response Frames (SRF).
• The .wav file will have 14 channels of upstream and 14 channels of downstream audio.

Note: You can export less than the maximum number of channels, but that would not affect the maximum length of the .wav file.

Using SigmaStudio

SigmaStudio is a graphical development tool that is provided by Analog Devices. One of our KB articles, Using Total Phase I2C Tools with the A2B Bus Monitor for Full System Emulation, provides guidelines about using SigmaStudio with Total Phase tools.

For detailed information about using SigmaStudio, please refer to SigmaStudio and SigmaDSP Documentation.

Data Capture Formats

• Up to 15 seconds of audio data can be exported as a multi-channel WAV file.
• When using the Data Center Software, captured bus data can be exported as a CSV file.

Monitoring Phantom Power

The A2B Bus Monitor can monitor a phantom powered slave; however, the A2B Bus Monitor cannot trace the specific power values.

About Phantom Power

In automotive technology, phantom power is used to deliver power to remote nodes. The power source is effectively “invisible”; a distinct power supply is not connected to any of the nodes. Instead, power is delivered from the power source up the same wires that are used for delivering audio signals. This saves the cost, labor, and design of adding more wires to the automotive head unit. Because the power is DC (direct current), the signals delivered on the A2B bus are not distorted.

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
• Promira Serial Platform User Manual
• A2B Audio Bus

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 Promira Serial Platform is Total Phase’s most versatile and powerful tool with a breadth of capabilities to support advanced I2C, SPI, eSPI, and A2B applications.

For engineers in need of a customizable, high-quality host adapter tool and are still considering which one is most suitable per project requirements, we’ve put together some reasons why the Promira Serial Platform is a tool fit for a variety of different applications.

1. Downloadable Applications for Flexibility and Instant Upgrades

The Promira Serial Platform offers a unique field upgradeable design that allows users to select from a range of downloadable applications, providing accessibility to different protocols (I2C, SPI, eSPI, and A2B), speed, and other additional features. Depending on the requirements, users can select between multiple applications including:

• I2C Active - Level 1 Application
• I2C Active - Level 2 Application
• SPI Active - Level 1 Application
• SPI Active - Level 2 Application
• SPI Active - Level 3 Application
• eSPI Analysis Application
• A2B Bus Monitor - Level 1 Application

This tool was intended to be “future-proof”, so if project requirements change or new projects start, users can instantly add new applications as needed.

2. Support for Multiple Speeds

When choosing a host adapter, one of the most pertinent features to consider is its ability to support a system’s master and slave clock speeds. The Promira Serial Platform offers a high range of supported signaling speeds for I2C and SPI systems, supporting up to 80 MHz as an SPI master and 20 MHz as an SPI slave device, and up to 3.4 MHz as an I2C master or slave device. It is a flexible tool that can not only be used for the intended application, but can be used for future applications with other signaling requirements. Whether it be prototyping systems that require lower speeds to high-speed flash programming, the Promira platform is able to cover a variety of use cases.

Depending on the I2C or SPI application level, the Promira Serial Platform is able to support:

I2C

• Up to 1 MHz Master/Slave: I2C Active – Level 1 Application
• Up to 3.4 MHz Master/Slave: I2C Active – Level 2 Application

SPI

• Up to 12.5 MHz Master + Up to 8 MHz Slave: SPI Active – Level 1 Application
• Up to 40 MHz Master + Up to 20 MHz Slave: SPI Active – Level 2 Application
• Up to 80 MHz Master + Up to 20 MHz Slave: SPI Active – Level 3 Application

3. Integrated Level Shifting

Host adapter tools provide power to downstream devices, but sometimes, certain devices can only handle lower voltages. In these cases, users may require the ability to adjust the signaling voltage levels to accommodate. The Promira Serial Platform offers integrated level shifting that allows users to easily choose from a range of voltage levels between 0.9V to 3.45V; and unlike other host adapters that require a separate board to achieve voltage levels lower than 3.3V or 5V, level shifting capabilities come prebuilt into the platform.

4. High-Power Providing Capabilities

The Promira Serial Platform can be used as a high-power source to power downstream devices.

Both the Aardvark I2C/SPI Host Adapter and Cheetah SPI Host Adapter report themselves to the host as low-power devices (<100mA), but the Promira platform is capable of supplying up to 200mA of supplemental power. This allows users to exploit the Promira platform as a high-power source needed to power systems.

5. Multi I/O Support

Unlike other host adapters that simply support single SPI modes, the Promira platform supports multi I/O SPI modes, allowing it to emulate a Dual or Quad SPI master device. This allows users to double or even quadruple the SPI data rate within their system. When configured with the required Promira applications, the Multi I/O SPI Master Mode in the Control Center Serial Software provides users the ability to send and receive Dual or Quad I/O SPI commands quickly and easily:

• Single/Dual/Quad: SPI Active – Level 3 Application
• Single/Dual: SPI Active – Level 2 Application
• Single: SPI Active – Level 1 Application

6. Increased Number of Slave Selects

For users who need to send or receive data from multiple slave devices or chips on the same bus, the Promira platform is a great tool for this purpose. For larger setups, the Promira Serial Platform supports an even greater number of slave select lines:

• 8 Slave Select signals: SPI Active – Level 3 Application
• 3 Slave Select signals: SPI Active – Level 2 Application
• 1 Slave Select signal: SPI Active – Level 1 Application

By using the Promira platform with the Control Center Serial Software, users can easily communicate to multiple slaves at once by performing read/write commands or batch scripting to send a sequence of commands.

7. Increased Number of GPIOs

For further customization in setups, the Promira platform allows users to control an even larger number of GPIO pins compared to other Total Phase adapters. Depending on the Promira application, users can access:

I2C

• Up to 12 GPIOs: I2C Active – Level 2 Application
• Up to 6 GPIOs: I2C Active – Level 1 Application

SPI

• Up to 16 GPIOs: SPI – Level 3 Application
• Up to 12 GPIOs: SPI Active – Level 2 Application
• Up to 6 GPIOs: SPI Active – Level 1 Application

8. Support for Variable Word Length

Sometimes, certain SPI devices may have nonstandard word lengths. Users who need to customize the word length transmitted by an SPI host adapter can do so using the Promira Serial Platform. By supporting variable word lengths, the Promira platform allows users to perform read/write customizations that would otherwise not be possible.

9. Ethernet for Remote Connectivity

The Promira platform can connect to an analysis computer via Ethernet or Ethernet over USB. This allows the host software to connect to the adapter via an IP address, making it useful for operating tasks over longer distances and performing task automation. Ethernet connectivity also allows users to expand the range of production and prototype units beyond interfacing to a computer via USB, making it more adaptable to different environments.

10. Free Promira Serial Platform API for Enhanced Customizations

And finally, although all Total Phase tools include a free API, it is worth mentioning that the Promira Software API I2C/SPI Active is available for users to control the Promira platform, write custom programs, and achieve unique user goals. The API comes with support for multiple OS (Windows, Linux, and Mac) and multiple languages (C, Python, Visual Basic, and C#), and includes examples.

Many customers who take advantage of the API and have used it for multiple purposes. Some examples include:

• Deploying Multiple Queues
• Sending a Stream of Continuous SPI Data
• Running Parallel SPI and GPIO Scripts

Click here for a guided flowchart that provides insight into which Total Phase host adapter is best for certain needs.

Still considering if the Promira Serial Platform is the right tool for your project requirements?  Schedule a demo with us to learn more:

Request a Demo

Question from the Customer:

I am starting to use the Advanced Cable Tester v2. I find the signal integrity eye diagrams easy to understand. The diagrams make sense to me as they correlate with the scope measurements in the lab.

I am curious about the accuracy of the GND/Shield resistance measurements. For example, one cable design has a frequent failure with the "GND Cable" test. Are there sensitivities of GND and Shield that I should look into?

Many failures that I have seen are marginal. Looking at the measurements I have taken, a lot of failed cables are over the expected value by just .040 ohms. How significant is this problem and what is the cause?

Another failure occurs with the E-Marker quiescent current. Is this due to the tolerance of Ra, or could something else be the cause?

Response from Technical Support:

Thanks for your questions! Some of test results that you see may be based on the version of the cable design. For example, the type and/or version of the electronic marker chip (E-Marker) can affect how the profile should be set up to run tests more accurately. There are other possible issues, such as the condition of the cable, the shell and plug materials, and more, which we will cover in the following sections.

Testing per Type-C E-Marker Requirements

It is good to review the cable profile with these questions:

• Are the cables recent?
• How current are the E-Marker specifications that were applied?

The requirements for Type-C cables have evolved, and there are requirements for specific performances (level of power delivery, speed of data transmission), which can greatly affect test requirements.

Adjusting Profiles per E-Marker

The values that are accepted can vary per version of requirement. For example – originally, the Quiescent Current "Initial" value was the only Type-C requirement, from r1.0 to about r1.2. Later, a new requirement was added to reduce the current consumption within 500ms.

In this case, many perfectly good cables will fail this requirement, especially when the cable is assembled with older designs. Such cables can still be "Certified", but that certification would be based on an earlier specification. It may be possible to get a waiver for a new cable design if that cable uses an earlier version of Certified E-Marker chip requirements.

Ra Resistance and Rp Pullup Current

In the current design, the E-Marker presents its Ra resistance and is detected by using the Rp pullup current. The port then turns on VCONN, typically between 3V and 5V. At this point, the E-Marker should power up, remove its Ra resistance (which is no longer needed) and reduce its current consumption below the steady-state threshold.

In earlier designs, Ra was often left enabled because the MCU was insufficiently optimized, or it took too much time to initialize. There are ways to modify the test for older designs:

• In many cases, changing the Delay Time to 1s would allow this type of cable pass.
• In other cases, it is desirable to simply disable this test.

Both changes can be implemented by creating a custom profile for the cable. Here is a summary of how to do that:

1. Clone the "USB Full-Featured Type-C Cable, SuperSpeed Gen1, 3A" profile
2. Set an appropriate Profile Name field
3. Edit the E-Marker Quiescent Current section of the profile

GND Shield and Shell Resistances

There are factors that affect GND, SHIELD, and SHELL resistances, which are discussed in this section.

The plug shell and the receptacle shell do not mate with a gold-plated contact surface – which is how the other pins are built.  Instead, the shells can be plated with any metal - the stated requirement for the shell material is "shiny”. The shell is then covered in oils from manufacturing and subsequent handling. With this setup, the plug and the receptacle shells make contact with less than ideal results.

In addition, the shell specification does not require defining a maximum value of resistance. Total Phase has SHELL to SHELL profiles set to 1.5ohms, which is a high resistance value. This is an arbitrary default value that you can modify for your cable test.

Why GND Cable Failures Occur

The cables should have 100% gold-plated contacts. In most cases, factory fresh cables pass the first test, and only fail if allowed to oxidize during weeks of non-use, or from the normal wear that occurs after substantial insertion cycles.

When a GND Cable failure occurs for a new cable, most likely there is physically problem. In some cases, dirt is on the contacts of “factory fresh” cables. In this situation, the cables can be worn after light use, such as 10-20 insertion cycles.

GND Cable Measurements

The GND cable measurement is performed as follows:

1. Source current on 4 pins and sink on the opposite 4 pins.
2. Measuring the voltage at each of the tails of the receptacle pins.
3. Calculate the resistance based on the measured actual current low and the voltages at each pin.

This measurement is very stable. As it is a small value, deviations can easily occur. Such measurements indicate a physical problem has occurred with the cable, such as oxidization or wear from use.

Single Pin Measurements

Measuring single pins is substantially more difficult than measuring GND cable. For measuring single pins, we recommend using a simplified version of a full cable measurement:

1. Source only into 1 pin
2. Sink from all 4 opposite pins
3. Instead of measuring the source pin's voltage vs. the sink pin's voltage, measure the source pin vs. each of the other same-plug pins.

As no current is flowing through unused sense pins, this method allows measuring the voltage on the command area of the on the plug paddleboard. This way, you can determine the resistance of an individual pin.

Please note: This is not an official technique for measuring plugs; we developed this method at Total Phase to assist customers with their manufacturing. This technique has some caveats:

• How PCB traces are routed on the paddleboard can skew this measurement.
• Our 0.040 ohm threshold may be too strict for some scenarios in this situation, but it does allow new, good plugs to pass this test with acceptable margin.

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

• Advanced Cable Tester v2 User Manual
• Advanced Cable Tester v2 Data Sheet
• USB Test and Compliance information

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

Embedded systems are devices that perform a specific, dedicated function within a larger electronic system. As they contain both hardware and software, embedded systems have grown in complexity over the past fifty years as these areas of technology have developed. To cope with the growing complexity of these systems, it has become increasingly common for embedded systems engineers to customize embedded operating systems that facilitate efficient hardware and software interactions on their devices.

In this week's blog post, we're taking a closer look at the history of embedded operating systems. We'll flesh out the differences between embedded and computer OS and their applications, describe the impact of hardware and software industry development on embedded operating systems and investigate the diversity of embedded operating systems that are deployed around the world today.

What are Embedded Operating Systems?

The core function of any operating system is to coordinate program access to computing hardware and resources. You are probably already familiar with many of the common desktop computer operating systems, such as Microsoft’s Windows, Apple's macOS, or the open-source Linux. Desktop operating systems provide a user interface that makes it easier for users to access applications. They also coordinate the allocation of hardware resources to each application a user wishes to run on their computer. 

In a desktop computer, the operating system is stored in non-volatile memory such that it is retained in memory when the computer is turned off. When the system is booted, the OS is copied into working memory called RAM where it can be accessed more quickly by the CPU. 

As with desktop operating systems, the purpose of an embedded operating system is to coordinate program access to computing hardware and resources. The key difference is that an embedded operating system must be uniquely programmed to function effectively within the operational constraints or requirements that are often associated with embedded systems applications. These may include things like:

• Reliability - Many embedded computing systems are deployed in contexts or applications where absolute reliability is crucial, such as aircraft radar, traffic lights, and vehicle safety features. An embedded operating system that unexpectedly crashes, fails, or malfunctions could have life-altering consequences for the individuals depending on the information and feedback from the device. As a result, embedded operating systems are designed to never crash and to self-recover rapidly if interrupted.
• Power Consumption - Embedded operating systems are frequently deployed on hardware with a very limited power supply.  Some embedded operating systems are expected to run for up to a decade with little or zero human maintenance or interference.  A great example is the pacemakers used to treat cardiac arrhythmia - they run on a battery that lasts anywhere between 5 and 15 years. To make the battery life as long as possible, embedded engineers must design an operating system that makes efficient use of power and computing resources over time.
• Specificity - Due to the constraints of a limited power supply and the need for near-100% reliability, embedded operating systems are often customized for each specific embedded product. An embedded engineer building a pacemaker would carefully design the hardware to support operational and software requirements as efficiently as possible, using the minimum amount of power and processing capability that meets the design requirements. In many embedded systems, the executable application and the operating system are statically linked. This means that the OS does not have the capability to load applications - rather, the OS and application are loaded together and executed automatically. These embedded systems are only capable of running a single application.

Vehicles today contain up to 50 separate computerized systems, all powered by embedded microcontrollers. The most critical safety components will include a hard RTOS that supports long-term reliability and stable performance.

Image courtesy of Unsplash

Software Industry Impact on Embedded Systems

In the earliest embedded systems designs, software programs were relatively simplistic due to hardware constraints and it was more common for engineers to write application code as firmware, leaving out operating systems altogether. However, as microcontroller technology developed from 8-bit to 16-bit and later 32-bit, the increasing complexity of embedded computer systems meant that operating systems would be necessary to effectively manage the embedded software.

Today, there are hundreds of different embedded operating systems in existence. Development in the design and deployment of embedded OS has been driven by the need to support software applications that take advantage of rapidly advancing hardware. Over the past decades, both computing power and data storage have become more compact and affordable for embedded systems engineers. This means that smaller devices with lower power consumption can support more complex applications and store more data.

The Different Types of Embedded Operating Systems 

Embedded operating systems can be customized and configured according to the unique specifications of each embedded project. Depending on how the operating system handles multi-tasking, it may be referred to as a real-time operating system, or RTOS. An RTOS is an operating system that is capable of processing and responding to data inputs in real time, without any latency or buffer delays. Real-time operating systems are deployed in cases where time constraints are crucial and task delays may have catastrophic effects. Real-time operating systems can be classified in three ways:

Hard Real-time Operating Systems

A hard real-time operating system is deployed in applications where reliability is paramount and all tasks must be executed by the prescribed deadline. Hard real-time systems are precisely constrained such that timing, deadlines, and latency are all highly predictable. This is necessary, as any missed task in a hard RTOS is considered a catastrophic system failure.

Soft Real-time Operating Systems

In a soft real-time operating system, the goal is still to execute tasks reliably without missing deadlines. However, soft RTOS are typically deployed in applications where total reliability is unnecessary. As a result, soft RTOS are not constrained with precise operating rules to the same level as hard RTOS. A task whose deadline is missed will be completed later when the required computing power is available.

Firm Real-time Operating Systems

In a firm RTOS, some infrequent deadline misses are permitted. Still, the quality of the service may be degraded or nullified if too many deadlines are missed. 

Beyond these three classifications, there are additional ways in which we can characterize embedded operating systems. The simplest Embedded OS examples can be described as a single system control loop, meaning that the program application serves to control one specific variable within a process. This type of operating system might be used in a smart thermostat that measures environmental temperature using a sensor and adjusts the temperature accordingly via actuators. Some embedded operating systems manage tasks using rate monotonic scheduling, an efficient priority assignment algorithm for task scheduling.

Conclusion   

When the first embedded systems were developed in the 1960s, bare metal programming was often sufficient for the types of programs that needed to be executed. Today, embedded operating systems are used to facilitate effective task management and resource allocation as embedded systems contain more sophisticated hardware and more complex software programs. 

Total Phase creates powerful debugging tools that help embedded engineers manage the complexities of product development and embedded OS programming. With products like the Beagle I2C/SPI Protocol Analyzer, embedded systems engineers and designers can streamline the software testing process with full transparency and reduce time to market. 

Ready to learn more?

Request a Demo

Question from the Customer:

I am analyzing a device that supports NVMe MI 1.1, which also supports five Control Primitives.

To see how my device sends and receives MI Commands through the Side Band (OOB),

I am using two Aardvark I2C/SPI Host Adapters: one as a Master; one as a Slave.

My challenge is I am trying to work with a device that is in a constant IDLE state.  The device works very quickly with the MI Commands through the Side Band. Sending several MI Commands before Control Primitive does not hold the device in a state of TRANSMIT or PROCESS. Instead, the device is in IDLE state.

So far, sending PAUSE, RESUME, and ABORT Control Primitives has no effect. Using the Aardvark adapter, how can I get the devices out of the IDLE state?  Is there a way I can use the Aardvark adapter to send an INTERRUPT signal?

Response from Technical Support:

Thanks for your question! The Aardvark I2C/SPI Host Adapter does not have pins that are dedicated for interrupts. However, you can program the Aardvark adapter GPIO pins to mimic interrupt signals, which we’ll describe in the following sections.

GPIO and Interrupt Signals

When the Aardvark adapter is in either I2C or SPI mode, unused pins are available for use as GPIO. We provide the free Aardvark Software API, which you can use to mimic the desired interrupt signal via GPIO.  The API is provided with functional programs, one of which is aagpio.c. The complete program is included with the Aardvark Software API.

The aagpio.c function blocks until either a change occurs on the input GPIO lines or the function times out. With those attributes, it is possible to use any GPIO pin for an interrupt signal.

Interrupt Example

This is a summary of the information provided in the article Using the Aardvark I2C/SPI Host Adapter GPIO Feature to Support Interrupts.

Following is a code snippet that shows how the function aagpio.c can be used:

// Demonstrate use of aa_gpio_change
aa_gpio_direction(handle, 0x00);
u08 oldval = aa_gpio_get(handle);
printf("Calling aa_gpio_change for 2 seconds...\n");
u08 newval = aa_gpio_change(handle, 2000);
if (newval != oldval)
printf("  GPIO inputs changed.\n");
else
printf("  GPIO inputs did not change.\n");

How the “Interrupt” Command Works

The aa_gpio_change function takes two arguments:

• aardvark: the handle to the Aardvark adapter
• timeout: time to wait (milliseconds)

When a change occurs on the GPIO lines or the timeout elapses, the function returns the current value of the GPIO lines. Please note it is important that the code stores the old value of the GPIO lines for comparison.

For more information about aa_gpio_change and other details, please refer to the section API Documentation  and the subsection GPIO Interface of the  Aardvark I2C/SPI Host Adapter User Manual

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

• Aardvark I2C/SPI Host Adapter User Manual
• Using the Aardvark I2C/SPI Host Adapter GPIO Feature to Support Interrupts

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

What is a Host Adapter?

A host adapter, also known as a "controller" or "bus interface", is an active device that acts as an interface between a host system, like a computer, and peripheral devices. It allows the host system to interact with a device, where engineers can actively communicate over the bus using a communication protocol such as I2C or SPI.

Why is a Host Adapter Useful in Embedded Systems Development?

To understand why host adapters are useful for embedded systems development, it’s good to understand what embedded systems are and how they function.

Embedded systems are computer systems that incorporate hardware and software components, including a computer processor, memory, and input/output peripheral devices. Each component has a dedicated function within a larger mechanical or electrical system. Embedded systems are controlled by microcontrollers, which are essentially computers on a single integrated circuit that control the logic and functionality of a system, including the communication between peripheral devices.

Photo by Pok Rie

In embedded systems, communication typically relies on a master and slave configuration where one embedded system component is considered the master and another is considered a slave. Master devices are responsible for initiating communication to connected peripheral devices, while slave devices can typically only respond and transmit data on the bus when prompted by the master.

This master-slave configuration can be simulated through the use of a host adapter, where the host adapter can either represent a master or slave device. By using a host computer, users can initiate communication over the bus and test various master and slave setups.

Additionally, host adapters are useful for embedded development since embedded systems are not able to display its traffic without an external tool. By connecting the host adapter to a host computer, it allows the computer to act as a host system where users can actively inject messages onto the bus or program peripheral devices using an interface. By using a host adapter with a GUI, it make it possible to view and validate the transactions occurring on the bus for further debugging.

Host Adapter Applications

Host adapters provide access and visibility into a system, allowing engineers to perform a variety of different applications, including emulation and prototyping, and programming devices:

Prototyping

During product development, it is often difficult for engineers to fully validate an embedded system without the right tools to test and analyze each component. By using a host adapter, engineers can easily emulate a system by configuring the tool as a master or slave device. Setups can even include multiple host adapters that simultaneously emulate a master and slave device to test each component together. Having the ability to emulate an entire system is extremely helpful in test driving products in various environments and allows users to see what is working properly and what needs improvement.

Specifically, a host adapter will allow users to inject messages onto the bus in order to review communication and behavior between devices. It can also be used to emulate a master device to evaluate peripherals such as sensors and memory chips, and can also be used to emulate a slave device to test commands sent from MCUs.

Memory Programming

In order for the embedded system to have its dedicated function, it needs to be loaded with instructions that can be used to send and receive messages to and from other devices. By using a host adapter, embedded system developers can easily program instructions onto the Flash memory or EEPROM devices. Flash programming can be useful in multiple applications, whether it be for prototyping systems to assess how they perform in different environments or to mass program memory devices on the production line.

Total Phase’s Host Adapter Tools

Total Phase offers numerous host adapter devices that support I2C and SPI protocols including the Aardvark I2C/SPI Host Adapter, Cheetah SPI Host Adapter, and Promira Serial Platform. Each offers unique capabilities geared toward specific project requirements:

Aardvark I2C/SPI Host Adapter

The Aardvark I2C/SPI Host Adapter is a general-purpose host adapter that can emulate an I2C or SPI master or slave device. It can signal up to 800 kHz as an I2C master, up to 8 MHz as an SPI master, and up to 4 MHz as an SPI slave. It allows users to perform multiple applications including prototyping and production testing.

Cheetah SPI Host Adapter

 The Cheetah SPI Host Adapter is a fast and powerful USB-to-SPI host adapter, capable of communicating at up to 40+ MHz. It is an ideal tool to develop, debug, and program SPI applications, helping users focus on core competencies by minimizing debugging and programming time.

Promira Serial Platform 

The Promira Serial Platform is an FPGA-based platform that supports a variety of different protocols, speeds, and functionalities through downloadable applications. It is able to emulate an I2C or SPI master or slave device, and can signal up to 80 MHz as an SPI master, up to 20 MHz as an SPI slave, and up to 3.4 MHz as an I2C master or slave. It offers advanced features and capabilities that allow it to be a fitting device for a number of different applications, whether it be prototyping or Flash programming memory devices.

For a guided flowchart on how to choose the right Total Phase host adapter for your project requirements, click here.

Still have questions on which Total Phase host adapter will work best for you? Contact us at sales@totalphase.com for more information.

The Promira Serial Platform is Total Phase’s premier I2C and SPI development tool that is capable of advancing multiple projects and applications, including product development and production processes. Depending on the Promira Serial Platform I2C or SPI application, this tool supports more advanced features compared to other host adapter tools including:

• Higher speeds for interfacing with I2C and SPI devices
•     Up to 3.4 MHz as I2C master/slave
•     Up to 80 MHz as SPI master and up to 20 MHz as SPI slave
• Integrated level shifting to support a range of voltages from 0.9V to 5.0V
• High-speed USB connectivity to the host system
• Ethernet connectivity for benchtop work and remote-control access
• SPI Dual and Quad I/O support
• Ability to provide a total of 200 mA of power

Promira Serial Platform for Product Development

Developers can utilize the Promira Serial Platform in multiple stages of the product development lifecycle, including prototyping, testing, and debugging devices.

Emulation and Prototyping

Now more than ever, systems are rapidly evolving and are continually advancing in terms of speed and power. The Promira Serial Platform was designed to match the evolving needs of developers and to keep up with the latest advances in technology. It is capable of emulating I2C and SPI master and slave devices at top speeds, and depending the application, it can support I2C master and slave devices up to 3.4 MHz, and SPI master devices up to 80 MHz and SPI slave devices up to 20 MHz.

The Promira Serial Platform allows users to easily emulate various components within an embedded system. Because it can emulate a master device, engineers can utilize the tool to interface with sensors, memory chips, and other peripherals. This tool supports up to 8 slave select lines, so users can communicate with even more slave devices in the system. Users can also emulate an MCU (microcontroller unit) and actively poll sensors, and read/write from BIOS memory and control the bus.

The Promira Serial Platform can also be configured as a slave device, where it can be used to test the commands coming from the MCU. As a slave device, users can also simulate sensors and validate the commands sent by the master device.

Additionally, because it can provide up to 200 mA of power, it can supply power to the target system, simplifying connectivity and troubleshooting during these processes.

Programming Memory Devices

Programming devices during the product development process allows developers to load the master and slave devices with specific data and commands. This information is used by the devices to perform certain functions and interact with each other, and  also allows developers to test the code and evaluate the system’s overall behavior. Because this is such a crucial step in product development, having an efficient I2C or SPI programmer will help expedite testing.

The Promira Serial Platform supports high signaling speeds for I2C and SPI so it can rapidly program I2C- and SPI-based EEPROM and Flash memory devices in a matter of seconds. Product developers can utilize this tool in multiple different programming applications, including programming in-system I2C- or SPI-based memory chips, including dual and quad I/O SPI devices, or even burning firmware to EEPROM devices. Additionally, with the integrated level shifting capabilities, users can apply lower voltage levels to devices without needing extra accessory boards, simplifying set-up.

Promira Serial Platform for Production and Automated Testing

Like during the product development stage, developers can utilize a host adapter tool to help program and test devices coming off the production line.

Mass Programming

To quickly mass produce products, mass programming devices is commonly executed in production environments. Many developers take advantage of host adapters to accomplish this, and by using the Promira Serial Platform, users can quickly program firmware and other data onto memory devices. To further expedite the production process, users also can connect multiple Promira platforms to one computer (up to 127) to gang program multiple devices at once.

Production Line Testing

Testing devices is often performed during production to ensure quality. Developers often test their systems using host adapters to analyze the device’s contents and to test how the product performs under certain circumstances in regression testing. The Promira Serial Platform offers Ethernet connectivity, so performing tests and interfacing to the production line is possible. This helps automate the testing procedures and gives users visibility into systems without having to be present.

Software Used to Interface the Promira Serial Platform

When used with the right software, the Promira Serial Platform allows users to easily interact and interface with their devices. Total Phase offers the Control Center Serial Software, Flash Center Software, and free Software API as a way for users to access the features on the Promira platform and to easily customize product development and production processes.

Control Center Serial Software

The Control Center Serial Software provides easy access to all the features of the Promira Serial Platform (with I2C or SPI applications installed), the Aardvark I2C/SPI Host Adapter and the Cheetah SPI Host Adapter. Within minutes, developers can make full use of I2C, SPI, and GPIO functionality. This software also supports XML batch scripting, which allows users to create, run, and save custom batch scripts to automate tasks. I2C, SPI, and GPIO functions are available in the scripting language for maximum flexibility. It also supports interfacing with Multi I/O SPI devices, including Dual and Quad I/O.

Flash Center Software

The Flash Center Software allows engineers to quickly erase, program, and verify I2C- and SPI-based EEPROM and Flash memory chips that are interfaced through the Promira Serial Platform, Aardvark I2C/SPI Host Adapter, and Cheetah SPI Host Adapter. The Flash Center Software natively supports an array of popular memory devices, so getting started is quick and simple; but if a part is not already supported, users can easily upload the part in a few simple steps. This software supports ganging programming, allowing users to connect multiple device to program device in parallel.

Promira Serial Platform API

Total Phase offers free Promira Software API I2C/SPI Active to help users customize processes when using the Promira Serial Platform. The Promira API supports multiple OS (Windows, Linux, and Mac), multiple languages (C, C#, Python, Visual Basic, and C#), and provides API example for multiple customizations, including queuing I2C and SPI data.

For more information on how the Promira Serial Platform can advance your projects, read our article, “10 Reasons Why the Promira Serial Platform is an Essential Tool for Embedded Systems Engineers” or contact us at sales@totalphase.com.

In embedded systems, a memory device is a physical device that is able to store data that can be used to communicate or perform a certain function. Memory devices can be interfaced through multiple different serial protocols, including SPI, or Serial Peripheral Interface. There are multiple different types of SPI memory devices used in embedded systems, including Flash memory and EEPROMs. In this article, we’ll provide a background on their relationship and a comparison between the two.

Example of EEPROM on Circuit Board.  Photo by Micah Elizabeth Scott on Flickr.

Differences Between Flash Memory and EEPROM

SPI Flash memory and EEPROMs are both considered to be nonvolatile memory. Nonvolatile memory means the device is capable of retaining data without the need for constant power, allowing devices to save information even when turned off. They are both electronically writable and erasable memory and are microcontroller-based applications, which means they are used either on or off chip to store information.

While Flash memory and EEPROM devices are both able to store information used in embedded devices, their architecture and operations for reading, writing, and erasing data slightly differ.

EEPROM, which stands for Electrically Erasable Programmable Read-Only Memory,

is a type of memory where data is read, written, and erased at the byte level. Flash memory, on the other hand, which is a type of EEPROM, is architecturally arranged in blocks where data is erased at the block level and can be read or written at the byte level.

What are the Advantages and Disadvantages of Using Flash Memory vs EEPROM?

There are various advantages and disadvantages to using either Flash memory or EEPROM devices:

Because EEPROMs operate their erase functions on a byte-per-byte basis, this increases the time taken to clear and edit the device but it allows developers to edit specific parts if needed. Flash memory is able to erase the device in large chunks of data, which considerably improves the erase speed and allows the device to store information more compactly. However, because of this, it also loses its ability to edit certain bytes, forcing developers to rewrite entire blocks of data upon any changes.

Performing a number of erase and write cycles on a memory device will cause it to eventually degrade over time. One of the advantages of using EEPROM is its improved lifespan. EEPROMs are able to perform up to 1,000,000 erase/rewrite cycles in its lifetime. Depending on the type of Flash memory, Flash devices have a reduced lifespan where most flash products are able withstand around 10,000 to 1,000,000 erase/write cycles before the wear begins to deteriorate the integrity of the storage.

Additionally, in terms of size and cost, Flash memory has a smaller memory cell size than EEPROM and is cheaper to implement.

Flash vs EEPROM Applications

SPI Flash memory, also known as Flash storage, has become widespread in the embedded industry and is commonly used for storage and data transfers in portable devices. Common devices include phones, tablets, and media players, as well as industrial devices like security systems and medical products. Flash memory is particularly useful for static data applications like USB Flash drives.

EEPROMs are also very common in embedded applications, and are frequently used for storing minimal data quantities in computer and electronic systems and devices.

Types of EEPROM and Flash Memory

There are different types of EEPROM and Flash memory. EEPROM supports both serial and parallel access. Serial EEPROMs are interfaced through serial protocols like I2C or SPI. Because of this, it includes a limited number of pins and is able to operate over a minimum number of lines – typically two to four.

Parallel EEPROMs are interfaced using parallel communication using an 8-bit bus and require additional pins to operate – typically up to 28 to 32. While parallel EEPROMs operate faster than serial EEPROMs, serial EEPROMs, including SPI and I2C EEPROMs are preferred due to their simplicity and widespread adoption of I2C and SPI in numerous devices.

There are also multiple types of Flash memory, with NAND and NOR Flash being the most common. Both NOR and NAND Flash offer different advantages for certain applications. NOR Flash offers quicker read speeds and random-access capabilities, while NAND flash is more suitable for quickly writing and erasing data. NAND Flash is more commonly used compared to NOR flash, as it is optimized for high-density storage and is able to achieve a smaller chip size and cost-per-bit due to not having random-access capabilities.

How Total Phase Supports SPI Flash Memory and EEPROM Devices

Total Phase offers multiple host adapter tools that support reading, writing, erasing, and verifying SPI-based Flash memory and EEPROM devices. Depending on the speed and application, embedded system engineers can use the Aardvark I2C/SPI Host Adapter, Cheetah SPI Host Adapter, or the Promira Serial Platform to interface with such memory devices.

The Aardvark I2C/SPI Host Adapter is a general-purpose host adapter capable of signaling up to 8 MHz as an SPI master and up to 4 MHz as an SPI slave. It also can emulate an I2C master or slave device up to 800 kHz.

The Cheetah SPI Host Adapter is designed to support high-speed programming applications, allowing users to signal up to 40 MHz as a master SPI device. It is able to support up to 3 slave selects.  Additionally, it features a pipelined architecture that enables command queuing for maximum throughput.

The Promira Serial Platform is an advanced host adapter tool that is capable of signaling up to 80 MHz as an SPI master and 20 MHz as an SPI slave. It offers multiple other features for advanced programming which include supporting up to 8 slave selects along with support for Dual and Quad I/O.

The Flash Center Software is a software package that allows engineers to quickly erase, program, and verify I2C- and SPI-based EEPROM and Flash memory chips that are interfaced through Total Phase's Promira Serial Platform, Aardvark I2C/SPI Host Adapter, and Cheetah SPI Host Adapter.

Unlike other programmers which can take minutes to program a memory device, the Flash Center Software can program the same device in seconds. The Flash Center Software natively supports a wide range of commonly used I2C- and SPI-based Flash memory and EEPROM devices, but it also allows users to easily add new parts if not already supported.

See how to easily program a Flash memory device using a USB to SPI programmer in the Flash Center Software:

Have questions on how our I2C/SPI host adapters can support your Flash memory and EEPROM applications? Please contact us sales@totalphase.com to find out more.

What is the I2C protocol?

History of I2C

When connecting multiple devices to a microcontroller, the address and data lines of each device were conventionally connected individually. This would take up precious pins on the microcontroller, result in a lot of traces on the PCB, and require more components to connect everything together. This made these systems expensive to produce and susceptible to interference and noise.

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

I2C two wire bus layout.

The I²C communication protocol uses only two bidirectional open collector or open drain lines, Serial Data Line (SDA) and Serial Clock Line (SCL), pull up with resistors. Traditionally, typical voltages used have been 5V or 3.3V; however, recently 2.5V, 1.8V, and 1.2V have become more common.

I2C Theory of Operation

I2C is a master/slave protocol. The master initiates the communication and the slave responds accordingly. The sequence of events is:

1. The Master device issues a start condition. This condition informs all the slave devices to listen on the serial data line for instructions.
2. The Master device sends the address of the target slave device and a read/write flag.
3. The Slave device with the matching address responds with an acknowledgement (ACK) or negative acknowledgement (NACK) signal.
4. Communication proceeds between the Master and the Slave on the data bus. Both the master and slave can receive or transmit data depending on whether the communication is a read or write. The transmitter sends 8-bits of data to the receiver which replies with a 1-bit acknowledgement.
5. When the communication is complete, the Master issues a stop command indicating that communication is complete.

I2C theory of operation

The I2C protocol can handle up to 128 slave devices. It is a synchronous bus which means all devices on the bus are synchronized to a central clock signal. I2C is also a serial bus as opposed to a parallel bus so all data travels over a single data line and not over multiple wires.

I2C Speeds

I2C has five defined speeds: Standard, Fast Mode, Fast Mode Plus, High Speed, and Ultra-Fast Mode.

Maximum Speed:

1. Standard = 100 kHz
2. Fast Mode = 400 kHz
3. Fast Mode Plus = 1 MHz
4. High Speed = 3.4 MHz
5. Ultra Fast Mode = 5 MHz

I2C is often used in camera lenses.

Where is the I2C Protocol Used?

Common I2C Device

Some common devices that typically run I2C are OLED displays, accelerometers, certain pressure/temperature sensors, and EEPROMs. Anywhere a relatively simple transaction occurs is a great place to use I2C. Because I2C is a two-wire bus, if space is limited I2C is a good fit because of the small footprint required to execute commands. This is obviously true when thinking of a small pressure sensor. A pressure sensor is not an extremely complex system to run and sensors are typically very small. Because of this, I2C is an excellent protocol choice.

Specific I2C Applications

I2C is used in a variety of different applications as one of the most popular serial protocols. From IoT to programming memory devices, I2C is used almost everywhere. Since I2C requires only two wires, it is well suited for boards with many interconnected devices. This helps reduce the cost and complexity of the circuit as additional devices are added to the system. Common applications include serial data transfer to/from peripherals, programming EEPROMs, and retrieving polling/receiving sensor data.

Digi-Key I2C search. Devices that use I2C.

Working with the I2C Protocol

I2C Advantages

Typically, users of the I2C protocol are also familiar with the SPI protocol. I2C and SPI are very similar in nature but act different in actual use. Both of these protocols are used on simple applications and they both provide benefits and limitations when compared to each other.

Some benefits of I2C over other serial protocols include:

• Requires only two wires for relatively small system footprint
• Unique device addressing
• ACK/NAK allows for confirmation of successful transfers
• Ability to add multiple masters and slaves for increased functionality
• Simple master and slave relationship
• Industry standard and widely deployed
• Adaptable to work with both fast and slow ICs

I2C Limitations

I2C communication doesn’t have too many disadvantages. The fact that the protocol has been in use for over 30 years highlights this fact. However, it suffers from a few minor limitations.

Some of the limitations of I2C over other protocols include:

• Possibility of address conflicts due to the many slave/master devices on the bus
• Slower speeds when compared to faster protocols such as SPI
• Data frame is limited to 8 bits.
• Requires more space due to the need for pull-up resistors

Using a mac to debug embedded system

I2C Debugging Tools

When working with I2C it is important to have the right set of tools handy to ensure implementation of designs is done properly. The addition of oscilloscopes and logic analyzers are always helpful in the development process. However, these options can be cost prohibitive.  There are less expensive tools available, some are software based and others are hardware based.

An oscilloscope is an excellent tool to use when implementing and designing the I2C bus. A scope will provide a breadth of insight into the bus including the electrical and signal characteristics of a design. However, sometimes a scope is too expensive and out of reach for some developers. There are some great alternatives available for scopes, both in the hardware and software realm. Tools such as host adapters, programmers, protocol analyzers (hardware and software based), and logic analyzers are a few of the tools available.

The feature set of each of these devices ranges dramatically. Some tools encompass a breadth of capabilities whereas some focus on specific tasks such as only programming or sniffing.

Latest Developments in I2C

I2C has evolved in terms of speed over the past two decades. When introduced the only speed available was a standard mode maxing out at 100 kHz. As technology moved toward smaller and faster, I2C was forced to adapt. Over the years new modes were introduced and now I2C reaches speeds of up to 5 MHz.

The latest evolution of the protocol is a new bus called I3C. I3C takes what developers love about I2C and SPI and combines them in a conglomerate protocol. The I3C standard combines the advantages of the simplicity of the I2C two wire bus and the speed of SPI. The protocol is capable of speeds up to 12.5 MHz, more than doubling the speeds of the ultra-fast mode on I2C. I3C is also backwards compatible with most I2C applications.

I3C is still in the early stages of development and its applications do not range in the size and breadth of I2C or SPI. However, I3C is starting to crop up in engineering circles and making its way into future projects and implementations.

How Total Phase Interfaces with I2C

Total Phase has a variety of different tools that interface with the I2C protocol. All of the I2C tools that Total Phase offers will fall into two different categories: host adapters and protocol analyzers. Host adapters allow users to interface directly with an I2C system and program I2C data. Whereas protocol analyzers do not interact with the data but instead monitor traffic that is happening on the bus. Host adapters allow users to interact with the data while protocol analyzers allow the user to non-intrusively monitor the data in real time.

Total Phase Host Adapters

Total Phase offers two host adapters for I2C: the Promira Serial Platform and Aardvark I2C/SPI Host Adapter. Both of these tools interface with the I2C protocol with the main differentiators being in terms of speed and expandability.

The Aardvark I2C/SPI Host Adapter is able to act as an I2C master and slave up to 800 kHz.  If higher speeds are required, the Promira platform becomes the better option with the ability to signal at up to 3.4 MHz. With this type of speed, the Promira platform is better suited to interfacing with high-speed I2C devices.

The Promira platform also has an integrated level shifter built into the hardware allowing it to change voltage levels via software control, while the Aardvark adapter is limited to 3.3V (5V tolerant) without external accessories.  The Promira platform offers up to 12 GPIOs whereas the Aardvark adapter can enable up to 6 GPIOs.

Benefits of the Promira Serial Platform

The Promira Serial Platform is the most versatile tool Total Phase has ever made. Being a platform-based tool means that the Promira platform is never limited in capability. If more functionality is needed simply install the correct application to get the feature set needed to complete the task at hand. This is the most flexible development tool around. Some additional features that the Promira platform boasts are:

• Integrated level shifting - work with signal voltages ranging from 0.9V - 5.0V without additional accessory boards or external cabling.
• Remote control - run automated tasks over the Ethernet and expand the range of production and prototype units beyond interfacing multiple units to a computer via USB.
• More target power - provide up to 200 mA to target devices, which in many cases, eliminates the need for an external power source.
• Download new applications for the Promira Serial Platform - instantly obtain and use more features as project requirements change.

Benefits of the Aardvark I2C/SPI Host Adapter

The Aardvark adapter is the most popular Total Phase development tool. Engineers love the Aardvark adapter because of its low cost and high performance. When interfacing with I2C, the Aardvark adapter provides a breadth of capabilities.

• I2C Master clock speed up to 800 kHz
• I2C Slave clock speed up to 800 kHz
• Support 3.3V (5V tolerant)
• Offers up to 6 GPIO
• Small and compact design

Total Phase Protocol Analyzers

For bus monitoring, Total Phase offers protocol analyzers that provide in-depth information about a specific bus. For I2C, the Beagle I2C/SPI Protocol Analyzer is the perfect fit to analyze I2C data. Simply attach the Beagle I2C/SPI analyzer to an I2C bus and instantly watch as the tool streams, all of the traffic happening across the system in real time. The special thing about this bus analyzer is that it provides real-time analysis of bus data. As communication is happing on the bus the user instantly sees it in the Data Center Software.

.

Being able to analyze the I2C bus in true real time provides time-saving advantages to the engineer. Unlike many other bus sniffers that require long download times, the Beagle I2C/SPI analyzer gives the user the information as the transaction is taking place on the bus. This gives priceless insights into how the system is working giving engineers greater knowledge on how to debug their systems.

Benefits of Beagle I2C/SPI Protocol Adapter

The Beagle I2C/SPI Protocol Analyzer is a non-intrusive device that monitors the I2C bus up to 4 MHz. The versatile Beagle I2C/SPI analyzer is the ideal tool for the embedded engineer who is developing an I2C, SPI, or MDIO based product. The Beagle I2C/SPI analyzer provides a high-performance bus monitoring solution in a small, portable package. Perfect for engineers in the field and in the lab.

For more information on I2C and Total Phase solutions and tools see the below linking articles.

• I2C Background
• Protocol Analyzer: Must Know Advantages for Embedded Systems
• How to Identify the I2C Slave Addressing Standard for Developers

Question from the Customer:

We purchased four Aardvark I2C/SPI Host Adapters for programming SPI EEPROMs (AT25160A series).  I’m having problems getting started – can you help me read and write data to an SPI EEPROM?  I’ve tried using the Control Center Serial Software and Flash Center Software, but so far, no luck getting started.

After I verify the programs, I will need to set up the Aardvark adapters for automated programming. For that environment, I’ll be using LabVIEW.

Response from Technical Support:

Thanks for your questions! We have information about accessing EEPROMs for read/write functions, and how to do so using LabVIEW. We’ll start with enabling the chip for programming, then move on to using LabVIEW.

Enable EEPROM for Programming

To get started, it looks like you’ll need to “unlock” the chip to be able to read and write.  When a chip is inaccessible, it indicates a “restriction” or “protection” mode of the chip has been activated. The data sheets for the chips you are working with should provide information about deactivating the Block Write Protection, which may be through software or hardware. If you have been using a pull-up resistor to access the device, consider using the Chip Select pin of the Aardvark adapter.

For an overview of using Flash Center Software, take a look at Programming SPI Flash Using Aardvark Adapter and Flash Center. For an example of using Control Center Serial software, see Reading Device ID from SPI Flash Using Aardvark Adapter and Control Center.

Using LabVIEW

For your project, using the Control Center Serial Software or Flash Center Software will make it easy to test and verify your software, but neither application supports LabVIEW. Instead, you can create a script using Aardvark Software API and Aardvark LabVIEW drivers. For your automated process, the API allows customization for greater efficiency and speed.

The Aardvark LabVIEW Driver is a free open-source LabVIEW Instrument Driver, which is targeted for Windows. This driver package is based on the Aardvark Software Library, available in the C programming language.

Examples of Using LabVIEW

The Aardvark LabVIEW package includes a functional example, Aardvark Example SPI.vi, which you can customize for your requirements. For information about the API, please refer to the API Documentation section of the Aardvark I2C/SPI Host Adapter User Manual. To become familiar with using LabVIEW, you can use our example of using two Aardvark adapters to communicate with each other via LabVIEW. We have other articles about using LabVIEW. They may use different serial protocols or Total Phase host adapters, but you can adapt the examples as needed for your setup.

• How Do I Implement I2C Master Register Read through LabVIEW?
• How Can I Integrate the Cheetah SPI Host Adapter in an Automated Test to Accurately Record the Results?

Reading Error Codes in LabVIEW

If an error occurs while using LabVIEW, error codes will be remapped per LabVIEW conventions, so it important to note that the codes you see will not match what is listed in the Aardvark User Manual. However, there is a simple formula to translate the remapped codes:

] labview_error_no = 8000 + -1 * user_manual_error_no

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

• Aardvark I2C/SPI Host Adapter User Manual
• Aardvark I2C/SPI Host Adapter Quick Start Guide
• Sending SPI Messages Between Two Aardvark Adapters Using Aardvark LabVIEW

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

What is the SPI protocol?

Overview of SPI

The SPI protocol was developed by Motorola in the mid 1980s to provide a language for electronic devices to communicate. The communication typically happens over short distances used on a circuit board or in a small electronic device. SPI is a simple protocol in nature used in applications where there is a relatively low amount of data transmission. Often the protocol is used for the communication between a microcontroller and sensor. Take, for instance, a motion sensor light. When the sensor is activated it communicates with a processor that then turns the light on; this communication is likely happening over the SPI bus to almost instantaneously execute the command. Applications where there is a higher data transfer rate require a faster protocol such as USB or Ethernet to keep up with the higher volume of data.

SPI Theory of Operation

SPI is a serial protocol that requires the following four wires to operate:

1. SCLK (Serial Clock): The Serial Clock wire carries the clock signal from the master device to other devices on the serial bus.
2. MOSI (Master Output, Slave Input): The MOSI wire carries data output from the master device to the slave devices on the serial bus.
3. MISO (Master Input, Slave Output): The MISO wire carries data output from the selected slave device to the master device or micro controller on the serial bus.
4. SS (Slave Select): On an SPI bus, there must be one master device, but there can be multiple slave devices. The master device can exchange data with all of the slave devices, but the slave devices can only send data to the master - not to each other. The master devices uses the Slave Select wire to select which slave device on the bus it will be communicating with before sending a data transmission.

Three of these lines are shared by all devices on the SPI bus: SCLK, MOSI and MISO. The SCLK is generated by the master device and is used for synchronization. The MOSI and MISO wires are the data lines. The direction of transfer is indicated by their names. SPI is a full duplex protocol so data is always transferred in both directions in SPI, but a SPI device interested in only transmitting data can choose to ignore the receive bytes. Likewise, a device only interested in the incoming bytes can transmit dummy bytes.

Each device has its own SS line. The master pulls low on a slave's SS line to select a device for communication. Data transmission can only occur between one slave device and the master at a time.

Each slave device requires a separate slave select signal (SS).

The exchange of data itself has no pre-defined protocol. This makes it ideal for data-streaming applications. Data can be transferred at high speed, often in the range of the tens of MHz. The master simply pulls low on an SS line indicating the specific slave device that the Master is expecting to either send or receive data. Pulling low on the SS wire wakes the slave up and initiates the flow of data. However, there is no acknowledgment or flow control, and the master may not even be aware of a slave's presence.

The SPI protocol is poorly suited to applications requiring multiple slaves to interact with the master at the same time. Since each slave has its own wire connecting it to the master, communication can happen much faster than other basic protocols, namely I2C, but the protocol still lacks when it comes to asynchronous transmission of data.

SPI is used in LED lights, monitors and in mice and keyboards. Photo by Josh Sorenson from Pexels

SPI Applications and Devices

Devices using the SPI protocol include sensors, memory devices, clocks, and LCD screens. Other common devices include home and automotive thermometers, vehicle tire pressure sensors, and video game controllers. Devices that are capable of producing a multitude of different responses in a quick fashion often run on the SPI bus.

List of all SPI Digi-Key Applications.

Another common SPI application is a video game controller. When the user presses a button on the controller a response is expected to happen in-game. The protocol that is being used here is typically SPI. SPI enables developers to create an environment that feels instantaneous for the gamer.

Flash memory is another popular SPI device. The speed of the SPI protocol and the master and slave bus design make the protocol a perfect fit for data streaming to memory devices. Writing, reading, and erasing memory can be performed in a simple, but fast manner making SPI a go to protocol for memory programming.

PS4 Dual-Shock controller. This controller is likely using the SPI protocol to communicate button presses.

Working with the SPI Protocol

Common SPI Errors and Development Issues

SPI is a great protocol to use when needing a fast, reliable, and easy-to-use protocol. Although one of the most popular serial protocols, it does come with some drawbacks as mentioned above.

One of the biggest issues arise when there becomes a need to have more than a few slave devices connected to the master. Since there is a need to have a SS (Slave Select) line for every individual slave device on the bus, the board design can get very complex. Developers often run into this issue during design implementation. They find out that the original design does not work for their application and thus need to add additional slave devices to accomplish the job. The addition of multiple new slave devices can start to complicate things.

Another issue that arises when working with SPI is cross talk or noise on the bus. Since there are multiple lines on the bus there is a high chance of interference across the wires. This issue can be alleviated with proper board designs but still remains front of mind and a common issue when working with the SPI protocol.

SPI Advantages Compared to other Protocols

SPI has many benefits when compared to other protocols. Some of the main advantages include:
• Less power consumption than I2C
• Full duplex communication
• Support for multiple slaves
• Faster speeds than I2C
• Simple implementation and low protocol overhead
• Ability to span greater distances than I2C

SPI Limitations and Drawbacks

Some of the main draw backs to SPI include:
• No flow control or acknowledgement
• Requires more signal lines than I2C
• Master must control all communication, slaves cannot talk to each other
• Board complexity arises when multiple slaves are needed
• Higher chance of noise/crosstalk due to the many wires needed

SPI Debugging Tools

When working with SPI it is important to have the right set of tools handy to ensure implementation of designs is done properly. The addition of oscilloscopes and logic analyzers are always helpful in the development process. However, these options can be cost prohibitive. There are less expensive tools available, some are software based and others are hardware based.

Computer code on a computer screen. Photo by Markus Spiske from Pexels

An oscilloscope is an excellent tool to use when implementing and designing the SPI bus. A scope will provide a breadth of insight into the bus including the electrical and signal characteristics of a design. However, sometimes a scope is out of reach for some developers and too expensive to have. There are some great alternatives to scopes, both in the hardware and software realm. Tools such as host adapter, programmers, protocol analyzers (hardware and software based), and logic analyzers are a few of the tools available.

The feature set of each of these devices ranges dramatically. Some tools encompass a breadth of capabilities whereas some focus on specific tasks such as only programming or sniffing.

Another thing to keep in mind is the operating systems on which these tools run. Most development tools require Windows OS. Alternatively, the Total Phase line of tools works as a truly cross platform solution. The Aardvark and Cheetah adapters, Beagle analyzers, and Promira platform work on all major operating systems including Windows, Linux, and Mac OS. Oscilloscopes typically do not require a computer OS to run as they simply operate on the built-in software/GUI.

Latest SPI Developments

SPI has taken on different forms and adapted over the years. The biggest evolutions in the SPI protocol come in the form of speed. Far surpassing speeds seen in I2C, SPI is now being used in implementations with speeds above 100 MHz, possible because SPI does not technically have a defined speed limit.

The protocol currently can be configured to send data in a few different formats including Single, Dual, and Quad I/O SPI. The more I/O being used to send and receive data, the faster the data transfers can happen. Dual and Quad SPI are additions to the protocol that introduce more data lanes and more data lanes mean faster communication and data transfer rates.

Single SPI

Single mode SPI works for most use cases such as rapid prototyping, device programming, and automated testing. In Single I/O, SPI operates in full-duplex mode sending data bi-directionally on the MOSI and MISO lines.

With Multi I/O SPI, systems can increase throughput by increasing the number of data wires.. Switching to Dual or Quad SPI is done via sending a command byte while in Single SPI mode. The command byte will request a response in either Dual or Quad mode.

Dual SPI

Dual SPI enables transfer rates to double compared to the single I/O. The MISO and MOSI data pins become unidirectional wires operating in half-duplex mode to send two bits per clock cycle. The MOSI line become IO0 and the MISO line becomes IO1.

Quad SPI

Quad SPI is similar to Dual I/O, but doubles the throughput again. Two additional data lines are added to transfer 4 bits every clock cycle. The data lines are now IO0, IO1, IO2, and IO3.

The protocol continues to adapt with the introduction of Octal SPI. Octal SPI enables the use of eight I/Os. This doubles the available lanes from Quad SPI meaning Octal SPI will introduce speeds never before seen on the SPI bus. Over the next few years we will see Octal SPI make its way into applications and its use become more main stream.

Graphic of the bus layout for an Octal SPI bus configuration.

Total Phase SPI Tools

Total Phase has a variety of different tools that interface with the SPI protocol. All of the SPI tools that Total Phase offers will fall into two different categories: host adapters and protocol analyzers. Host adapters allow users to interface directly with the SPI system and program SPI devices. These tools allow for interaction with the SPI protocol. Whereas the protocol analyzers do not interact with the data as much as they do monitor the traffic that is happening on the bus. Host adapters allow users to interact with the data whereas protocol analyzers allow the user to non-intrusively monitor the data in real time.

Total Phase Host Adapters

Total Phase offers host adapters including the Promira Serial Platform, Aardvark I2C/SPI Host Adapter, and Cheetah SPI Host adapter. All three of these tools interface with the SPI protocol with the main differentiators being in terms of speed and expandability.

Aardvark product image

Promira product image

Cheetah product image

The primary difference among these tools is speed. The Aardvark I2C/SPI Host Adapter is able to act as an SPI master at up to 8 MHz and slave at up to 4 MHz. For higher speeds, the Promira platform and Cheetah adapter offer more options. The Cheetah SPI Host Adapter is able to act as a SPI master at up to 40 MHz, but does not offer any slave capabilities. The Cheetah adapter is well-suited to SPI programming applications as it features a High-speed USB connection with a pipelined architecture for maximum throughput. For maximum master and slave speeds, the Promira Serial Platform can act as an SPI master at up to 80 MHz and slave at up to 20 MHz.

Another differentiating factor among these tools is their functionality. All three tools can emulate an SPI master from 8 MHz all the way up to 80 MHz. However, only the Aardvark adapter and Promira platform are capable of emulating a slave device at maximum speeds of 4 MHz and 20 MHz respectively. The Cheetah adapter is strictly an SPI master device and does not have any SPI slave capabilities.

The Promira platform also offers an integrated level shifter allowing it to change voltage levels via software control. It also provides up to 8 slave selects and up to 16 GPIO(s). The Aardvark adapter only supports one slave select and Cheetah adapters supports three slave selects. The Aardvark adapter can enable a maximum of 6 GPIOs while the Cheetah adapter does not have any GPIO capability. The Aardvark comes with the ability to interface with I2C as well whereas the Promira and Cheetah do not support I2C natively. The Promira requires an additional application and the Cheetah simply doesn’t have the capability built into the hardware.

Benefits of the Promira Serial Platform

The Promira Serial Platform is the most versatile tool Total Phase has ever made. Being a platform-based tool means that the adapter is never limited in capability. If more functionality is needed simply install the correct application to get the feature set needed to complete the task at hand. This is the most flexible development tool around. Some additional features that the Promira platform boasts are:

• Integrated level shifting - work with signal voltages ranging from 0.9V - 5.0V without additional accessory boards or external cabling.
• Remote control - expand the range of production and prototype units beyond interfacing with units remotely.
• More target power - provide up to 200 mA to target devices, which in many cases, eliminates the need for an external power source.

Benefits of the Aardvark I2C/SPI Host Adapter

The Aardvark I2C/SPI Host Adapter is the most popular Total Phase development tool. When interfacing with SPI, the Aardvark adapter provides a breadth of capabilities. Some additional SPI features include:

• Operates in Master or Slave mode
• Up to 8 MHz Master signaling rate
• Up to 4 MHz Slave signaling rate
• Offers up to 6 GPIO
• I2C functionality included

Benefits of the Cheetah SPI Host Adapter

The Cheetah™ SPI Host Adapter is a high-speed SPI adapter that is capable of communicating over SPI at up to 40+ MHz. The Cheetah adapter is specifically designed to communicate with high-speed, SPI-based Flash memory. It is an ideal tool to develop, debug, and program SPI-based systems.

• High-Speed SPI Master signaling at up to 40+ MHz.
• Transaction Queuing for Maximum Throughput
• Supports up to 3 slave devices

Total Phase Protocol Analyzers

Total Phase also offers a protocol analyzer that provides in-depth information for the SPI bus. The Beagle I2C/SPI Protocol Analyzer analyzes the SPI bus by simply attaching to the SPI lines. The analyzer will capture and stream all of the traffic happening across the system in real time. As communication is happening on the bus, the data will instantly be displayed in the Data Center Software.

Being able to analyze the SPI bus in true real time provides time saving advantages. Unlike other bus sniffers that require long buffers and download times, the Beagle analyzer presents the data to user as the transaction is taking place on the bus.

Benefits of Beagle I2C/SPI Protocol Adapter

The Beagle I2C/SPI Protocol Analyzer is a non-intrusive device that monitors the SPI bus up to 24 MHz. Captured data is streamed via High-speed USB directly to a computer. The amount of data captured is limited only by the amount of RAM available on the PC. The versatile Beagle analyzer is the ideal tool for the embedded engineer who is developing an SPI-based product.

For more information on Total Phase solutions and tools see the below linking articles.

• Understanding the Internet of Things (IoT) and Big Data 
• What is IoT Data Analytics (Internet of Things)
• Can the Promira Serial Platform Support and Generate the Master and Slave SPI Waveforms that I Need? 

Question from the Customer:

I’m testing an LED Driver for a rear lamp project. The LED is a slave device. The master device is an Aardvark I2C/SPI Host Adapter. I started the tests using the Control Center Serial Software. The slave device responded correctly and the delay between writes and reads was very small, as expected.

After that, I started using the other tests. Initially, the slave device was in timeout and not answering. I fixed that by including the NOT STOP flag. However, the timing between the master device writing to and reading registers was too long – 300-400us.  Here are views of the timing per Control Center Serial Software and LabVIEW.

Control Center Serial Software Timing

LabVIEW Timing

How can I improve the timing performance with LabVIEW?

Response from Technical Support:

Thanks for your question! We provide functional examples with our Aardvark LabVIEW drivers. However, the examples we provide only use i2c write and i2c read: two separate functions that affect the timing in your setup.  Based on your information, if looks like you need to use register read in a program sequence, which is described below.

Write-Read Sequence

As previously stated, our examples use i2c write and i2c read. However, you can create a script that should produce the speed that you need for your setup. Here is an overview of the recommended read-write operation:

Start -> Address (Write) ->Register Offset -> Restart -> Address(Read) -> Read data from slave register -> Stop

How it works:

1. Call the I2C write function aa_i2c_write() with the AA_I2C_NO_STOP Specify the device register address from which you will read the data.
2. Follow with the I2C read function aa_i2c_read(). Specify the number of bytes to read.

This sequence combines the write-read together; effectively, this operates as a single register write-read function, which should greatly improve your write-read timing.

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

• Aardvark I2C/SPI Host Adapter User Manual
• Aardvark I2C/SPI Host Adapter Quick Start Guide
• Sending I2C Messages Between Two Aardvark Adapters Using Aardvark LabVIEW
• Control Center Serial 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

The History of CAN

CAN (controller area network) is a serial bus protocol created in 1986 by the German company Bosch. This protocol was created to address the growing need for devices to effectively communicate over longer distances within automobiles. CAN is optimized for sending small amounts of data between multiple nodes, or devices, on a single line without the need for a centralized host computer; and while the CAN bus can only support signaling speeds up to 1 Mbps, this allows the bus to span over longer distances and remain reliable against electrical noise. Additionally, CAN eliminates the need for excess wiring due to its single multiplex architecture.

The CAN specification does not define standard CAN voltages or connector interfaces, but standards organization, including the International Organization for Standardization (ISO), have defined multiple physical standards for CAN. In 1993, the ISO released the CAN standard ISO 11898, which has since undergone multiple revisions, including ISO 11898-1 which describes the CAN data link layer, ISO 11898-2 which standardizes the “non-fault-tolerant” CAN physical layer, and ISO 11898-3, which is defines the “fault-tolerant” CAN physical layer.

Physical Layer Standards

High Speed CAN

High-speed CAN, or ISO-11898-2, is one of the most common types of CAN standards and uses two dedicated wires for communication, which allows the bus to support transfer rates up to 1 Mbps. This standard is commonly used in applications including antilock brake systems, engine control modules, and emissions systems.

Low Speed/Fault Tolerant CAN

Low Speed/Fault Tolerant CAN, or ISO-11898-3, supports lower bus speeds and fault tolerance, reaching signaling rates of 40 kbps up to 125 kbps. Due to its two-wire balance scheme for lower speeds, it is able to continually operate in the event of a faulty wire. This standard is frequently used in applications such as opening and closing doors.

Single Wire CAN

Additionally, for network applications with low bit rate and bus length requirements, the SAE J2411 single-wire specification uses just one bus line with a data rate of 33.3 Kbps, and is designed for vehicles.

Higher Layer Protocols

CANopen

The CAN protocol defines several higher layer protocols (built on CAN). One example includes a widely used protocol called CANopen. The objective of CANopen was to develop control architectures and devices to enable flexible and modular combinations of existing manufacturing cell units. In 1993, CiA, or CAN in Automation, published the very first version of the CANopen specification: CiA 301. Over the years, there have multiple published revisions of CiA 301, many of which are still used in applications today.

Today CANopen is used in industrial applications including medical equipment, automated building machinery, railway applications, and much more. These applications benefit from its configurability and standardized embedded network.

CAN Protocol Extensions

CAN-FD

Over the years, CAN has also introduced extensions to the CAN protocol, with one being CAN-FD. CAN-FD, or CAN flexible data-rate, was introduced in 2012 as an extension of the CAN protocol. Using dual-bit rates, this new extension offers the ability to transmit data up to 5 Mbps, five times greater than the initial 1 Mbps supported by the classical CAN protocol. CAN-FD also extends the bit length of a message from 8 bytes to 64 bytes, and includes improved error detection using extra bits in the CRC frame to improve the performance of the CRC-algorithm, better protecting the data content.

CAN-FD was initially created to address the bus limitations in automobiles, but has quickly been adopted by other industries as well, including industrial. This protocol allows for a larger payload, which is a major benefit in operating machinery as it results in reduced overhead and allows the bus to operate more efficiently.

CAN Bus Applications

When CAN was first introduced, it was initially designed for use in vehicles, but has since grown to be widely implemented in many industrial applications due to its various advantages, including its robustness and flexibility.

For use in vehicles, including passenger cars, trucks, boats, and spacecrafts, CAN is the preferred protocol for many reasons. For one, CAN functions over minimal wiring using a twisted pair system. This greatly reduces the overall weight of the vehicle. Additionally, CAN uses arbitration methods that allow devices to prioritize messages for safe and efficient communication. In cases where multiple devices are trying to access the bus at once, the message with the highest priority will be transmitted while the other devices go into “listening” mode. This can be helpful for applications including power steering or brake controllers.

CAN is also heavily used in other industries, including industrial and factory automation, and medical, mining, and laboratory equipment. These industries often produce equipment that benefit from CAN’s fault and electromagnetic noise tolerance, as well as its ability to operate over longer distances while maintaining error checking mechanisms. For instance, many applications like hospital rooms use CAN in many devices, including cameras and x-ray machines. Even industrial applications including elevators often use CAN for these reasons.

How Does the CAN Protocol Work?

Nodes

CAN allows multiple nodes, or devices, to connect to the bus on a single line, where each node can operate as a transmitter or receiver at any time.  CAN nodes do not have strict master/slave roles and can operate without the need for a centralized host; instead, data messages are broadcasted across the bus and each node determines if the message is relevant based on the frame “identifier”, which describes the message’s contents.

Diagram of the CAN Bus

Collision Detection and Arbitration

CAN uses collision detection and bus arbitration to address when multiple nodes transmit data simultaneously. During collision detection, nodes are able to detect data collision on the bus, at which point they are required to stop transmitting data. Arbitration is then used to prioritize messages sent on the bus and uses recessive and dominant bit states to determine which messages are handled first. Messages with a dominant bit are considered to be a high priority message, while messages with a recessive bit are least prioritized. As soon as the bus becomes available again, low-priority messages will start a new arbitration, ensuring a non-destructive bus arbitration.

CAN Frame Types and Format

There are four different message types, or frames, on a CAN bus:

1. Data Frame: carries 0-8 bytes of data, along with an identifier and CRC check
2. Remote Frame: requests a data frame transmission with a certain identifier node
3. Error Frame: transmitted when an error is detected
4. Overload Frame: provides extra delay between data and remote frames

Data Frame

CAN 2.0A is the standard CAN format that uses an 11-bit identifier, while CAN 2.0B is the extended CAN format which uses a 29-bit identifier. In CAN 2.0B messages, both standard and extended frames are supported and may exist on the same bus.

A Standard CAN Data Frame uses an 11-bit identifier and is composed of the following fields:

An Extended CAN Data Frame uses a 29-bit identifier (two identifier fields (A & B) combine to form a 29-bit identifier) and is composed of the following fields:

Remote Frame

A remote frame is broadcasted by a transmitter to request data from a specific node. It is only available in Classical CAN and has the same field structure as the data frame, but without a data field. Remote frames also have an RTR bit, but it is set to recessive.

Overload Frame

If a CAN node receives messages faster than it can process them, an overload frame is used to inject an additional delay between data or remote frames. An Overload Frame has two fields, including an overload flag consisting of six dominant bits and an overload delimiter consisting of eight recessive bits.

Error Frame

If a transmitting or receiving node detects an error, this will cause the node to stop transmission and broadcast an error frame on the network, subsequently causing all other nodes on the bus to send error frames as well. An error frame consists of two fields, including an error flag field, with a maximum of 12 bits (six dominant and 6 recessive bits) and an error delimiter consisting of 8 recessive bits.

Types of CAN Bus Errors

CAN Bit Errors

A CAN bit error occurs when the monitored value is different than the value being sent. For instance, if a node is transmitting dominant (0) to the bus and recessive (1) is detected, this will cause a bit error. A bit error can also be detected by stuffing.

CAN Bit Stuffing Error

To help ensure synchronization of the bus, bit stuffing is performed. Meaning, after 5 consecutive identical bits have been transmitted, a 6th opposite bit will be inserted by the transmitter into the bit stream. If any node detects that the 6^th consecutive bit remains of the same level, this will cause an error to be broadcasted on the bus.

CAN ACK Error

During proper CAN transmission, a receiving node will write a dominant bit into the ACK slot and the transmitting node will acknowledge this message. However, if perhaps the receiver has failed, and the transmitting node doesn’t monitor a dominant bit and doesn’t acknowledge the message, an ACK error is flagged.

CAN Form Errors

In CAN, the End of Frame, ACK Delimiter, and CRC Delimiter are all fixed format fields that are always recessive. If a node detects a dominant bit in any of these, a form error will be flagged.

CAN CRC Error

The transmitting node calculates a 15-bit CRC value and then transmits this value in the CRC field. All nodes will receive this message, calculate a CRC itself, and compare the values to determine if they are indeed the same. If not, this will produce a CRC error.

Which Tools Can Debug and Develop CAN Applications?

Developers looking to debug CAN data can do so using a few different tools, including protocol analyzers, CAN interfaces, or oscilloscopes.

Debugging and Developing CAN Devices Using an Oscilloscope

Oscilloscopes allow engineers to monitor and analyze waveforms on electrical signals. Many oscilloscopes can monitor and decode the CAN bus, providing visibility into CAN bus traffic and CAN bus errors. This is generally performed by acquiring the CAN High and CAN Low lines with single-ended probes on separate oscilloscope input channels. The differential waveforms can be determined by subtracting CAN Low lines from CAN High lines.

Oscilloscopes can decode CAN bus data using a bus signal, and can often filter for specific criteria relating to the bus traffic. These tools also provide hardware triggering capabilities, capable of performing triggers on specific CAN bus errors including ACK errors and CRC errors.

The eye diagram function on an oscilloscope provides visibility into any signal integrity issues on the CAN bus that stem from voltage and/or timing issues. They are useful in detecting jitter, glitches, reflections, crosstalk, noise, and more.

Debugging and Developing CAN Devices Using a CAN Bus Interface

CAN Bus Monitor (CAN Bus Sniffing)

A protocol analyzer, or bus monitor, is a tool commonly used by hardware, software, and firmware developers to analyze and debug embedded systems in all stages of the product lifecycle. Protocol analyzers connect between the host computer and peripheral devices to capture and decode raw bus data and events into human readable format, often flagging bus errors for easier troubleshooting.

There are a variety of protocol analyzers, each specific to analyzing certain data protocols, including I2C, SPI, USB, CAN, and eSPI. A CAN protocol analyzer, also known as a CAN bus sniffer or CAN bus monitor, will specifically capture and decode CAN communication, allowing developers to visualize the CAN bus and more easily debug CAN bus data.

A CAN bus monitor can analyze messages being shared between network nodes and provide the user with specific information occurring on the bus at a high level. Users can view the various nodes/devices on one or more CAN buses, as well as CAN bus data including decoded CAN data, the record or frame type, and bitrate. CAN bus monitors also provide insight into error frames, so finding the source of the bus error and gathering the statistical error rate can be easily performed.

Additionally, some CAN bus monitors can provide triggers to create specific responses to network events and filtering capabilities to more easily pinpoint certain data events, frame types, or error types.

CAN Adapter for Active CAN Transmission

CAN development tools such as host adapters can act as CAN node devices, allowing developers to read and write to the CAN network. This provides a way to test the validity of each individual node and verify that the bus is operating correctly. CAN development tools can include active CAN transmission capabilities as well as bus monitoring capabilities that allow users to actively send and receive CAN data on the bus while also monitoring these messages simultaneously.

Overview of Total Phase’s Komodo CAN Solo/Duo Interface

Total Phase offers CAN development tools that include the Komodo CAN Solo Interface and Komodo CAN Duo Interface.

Komodo CAN Solo Interface

The Komodo CAN Solo Interface is a powerful USB-to-CAN adapter and analyzer. It offers one configurable CAN channel to perform active CAN data transmission or non-intrusive CAN bus monitoring. This interface supports high-speed and fault-tolerant CAN bus speeds up to 1 Mbps and includes 8 GPIOs to connect external logic. This tool also provides real-time data capture and filtering capacities.

Komodo CAN Duo Interface

The Komodo CAN Duo Interface is a powerful USB-to-CAN adapter and analyzer that includes two configuration CAN channels. It is an all-in-one tool capable of simultaneous active CAN data transmission and non-intrusive CAN bus monitoring.  It can also be configured to allow users to monitor multiple independent CAN buses at once. This interface supports high-speed and fault tolerant CAN bus speeds up to 1 Mbps, and includes 8 GPIOS to connect external logic. This tool also provides real-time data capture and filtering capabilities.

For more detailed key features and abilities of the Komodo CAN Interface, please visit the Komodo CAN Interface Datasheet.

Additionally, for a demonstration on how to use the Komodo CAN Duo to write to a device and monitor CAN activity, please visit our video Using the Komodo GUI Software to Interface with the CAN/I2C Activity Board Pro.

Question from the Customer:

I am using the Aardvark I2C/SPI Host Adapter with an Excel VBA (32-bit Excel) script. I have questions about using the function aa_i2c_read for data arrays:

If I have the array of data_in defined in Integer type (i.e. Dim data(512) As Integer), would I have the problem to pass my data array of Integer type to ByRef data_in() As Byte defined in the function?

• For reading: Public Function aa_i2c_read (ByVal aardvark As Long, ByVal slave_addr As Integer, ByVal flags As Long, ByVal num_bytes As Integer, ByRef data_in() As Byte) as Long
• For writing: Public Function aa_i2c_write (ByVal aardvark As Long, ByVal slave_addr As Integer, ByVal flags As Long, ByVal num_bytes As Integer, ByRef data_out() As Byte) as Long

Response from Technical Support:

Thanks for your question!  The VB6 aardvark.dll can be directly used, as it uses the same data as VBA. For more information, please refer to this article about data types in VBA and .NET.

VBA Script for Integer Type

Note: This example was created for 32-bit Excel; 32-bit Aardvark VB6 DLL was used.

Private Declare Function vb6_aa_find_devices Lib "C:\User\Downloads\aardvark-api-windows-i686-v5.15\aardvark-api-windows-i686-v5.15\vb6\aardvark.dll" (ByVal num_devices As Long, ByRef devices As Integer) As Long
Sub Button2_Click()

Dim num As Long
Dim devices(15) As Integer
Dim nelem As Long
num = vb6_aa_find_devices(16, devices(0))
End If

End Sub

Additional Code Examples

There are more code examples in the VB6 folder. These 32-bit Aardvark API scripts can be used as-is or modified for your specifications. This folder also has a VBA example that is equivalent to aalights.c, which integrates VB6 dll with VBA. This example uses the I2C/SPI Activity Board. The GPIO lights on the Activity Board flash when you click Button 1 in the Excel sheet.

VBA Excel Start Button

You can see the VBA code behind the button click event. To do so, right-click the Button 1 on the Excel sheet, and then Select Assign Macro and Edit.

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

• Aardvark I2C/SPI Host Adapter User Manual
• I2C/SPI Activity Board User Manual

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

An Introduction to the USB Protocol

The History of USB

The USB protocol, also known as Universal Serial Bus, was first created and introduced in 1996 as a way to institutionalize a more widespread, uniform cable and connector that could be used across a multitude of different devices. With the increase in technological devices during this time, having a universal cable would help reduce the confusion and inconvenience of having a collection of cables needed for each individual device.

The USB architecture was conceptualized with the juncture of companies including Compaq, Digital Equipment, IBM, Intel, Microsoft, and Northern Telecom, and is currently maintained and regulated by the USB Implementors Forum, or USB-IF. USB-IF enforces the standards and specifications that USB device manufactures must comply with in order to a be verified as a trusted USB source. Devices that are compliant to both the USB standard’s physical layer (mechanical and electrical) and software layer are approved to use the USB logo, informing consumers and other USB adopters that their cables or devices are safe to use.

How Does USB Transmit and Receive Data?

How does the USB standard define how a USB cable or device should operate? There are a variety of mechanisms that must be adhered to, including how various USB devices should interact with each other upon enumeration and communication.

USB hosts are also known as master devices, and they initiate all the communication that occurs over the USB bus. Typically, a computer or other controller are considered to be the master, only responding to other devices if requesting certain information. The peripheral device, or the slave device, is connected to the host device, and is programmed to provide the host device with the information it needs to operate. Typically, peripheral devices include USB flash drives, computer mice and keyboards, cameras, and other such devices.

It is important for host and peripheral devices to be able to effectively communicate with each other. If either one isn’t able to perform its job function, the communication between two devices would falter. For instance, if a user plugs in a flash device on their host computer and nothing happens, this would likely indicate a problem with the communication over the bus. Which leads into how communication takes places over the USB bus. How is USB data transmitted and received? This can be better understood by getting to know the theory of operation on how USB data is sent over the bus, the different USB data packet fields and packet types, and the types of USB data transfers.

USB Data Packet Fields

The USB data packet fields are what make up a USB packet, consisting of individual bits.

USB data packet fields include a Sync field, a Packet ID (PID) field, ADDR (Address) field, ENDP (Endpoint) field, CRC (cyclical redundancy check) field, and EOP (end of packet) field.

• The SYNC field is used to synchronize the clocks from both the receiver and transmitter.
• The PID field provides information on what type of data is being sent. The below table presents the PID Type, the PID Name, and what its purpose is the packet:

Table 1: USB Packet Types

• The ADDR (Address) field includes the address of the device the packet is being sent to.
• The ENDP (Endpoint) field specifies the Endpoint number
• The CRC field is used to check the data in the packet for errors
• THE EOP field indicates the end of the packet

USB Data Packets

These fields are used to form data packets, which define the various transactions. There are four USB packet types including:

Token Packet, which is initiated by the host and determines if the host will send or receive data.

Data Packet, where the Data is sent by the transmitter, and a device can return a NAK or Stall packet to indicate if they are not able to respond.

Handshake Packet, used for acknowledging data or reporting errors.

Start-of-Frame Packet, splits the USB bus into time segments and schedules the data transfers.

These packets are formed into frames and sent through a USB transaction. The length and frequency of the transaction depends upon the transfer type being used for an endpoint.

Types of USB Data Transfers

All communication between a USB host and a USB device is addressed to a specific endpoint on the device. Each device endpoint is a unidirectional receiver or transmitter of data; either specified as a sender or receiver of data from the host.

Each endpoint is different, specified through their bandwidth requirements and the way they transfer data. The four types of USB data transfers include: Control, Isochronous, Interrupt, and Bulk transfers.

Control: Non-periodic transfers. Typically, used for device configuration, commands, and status operation.

Interrupt: This is a transaction that is guaranteed to occur within a certain time interval. The device will specify the time interval at which the host should check the device to see if there is new data. This is used by input devices such as mice and keyboards.

Isochronous: Periodic and continuous transfer for time-sensitive data. There is no error checking or retransmission of the data sent in these packets. This is used for devices that need to reserve bandwidth and have a high tolerance to errors. Examples include multimedia devices for audio and video.

Bulk: General transfer scheme for large amounts of data. This is for contexts where it is more important that the data is transmitted without errors than for the data to arrive in a timely manner. Bulk transfers have the lowest priority. If the bus is busy with other transfers, this transaction may be delayed. The data is guaranteed to arrive without error. If an error is detected in the CRCs, the data will be retransmitted. Examples of this type of transfer are files from a mass storage device or the output from a scanner.

The Different USB Connectors Types and Signaling Rates

What are the Different USB Connector Types?

USB cables and connectors create an interface as a way for computers and peripheral devices to connect with each other and transfer data. There are numerous USB connector types that have been used to interface the USB 1.1/2.0 and USB 3.0 protocols. Some of the most commonly used connectors include USB Standard-A, USB Standard-B, USB Mini-B, USB Micro-B, and USB Type-C.

Milos634 / CC BY-SA

USB Type-A: Is the most widely used connector type. It is primarily used on host controllers in computers and hubs and is more commonly used as a downstream connection.

UBB Type-B: is mainly used for connecting USB peripheral devices including printers and compact devices like mobile phones. It is commonly used as an upstream connection.

USB Type-C: is an advanced connector type that uses a reversible design, and is intended to replace other connectors in the hopes of there being one cable to function with a variety of different devices.

Over the years, there have been multiple USB revisions and specifications that have been introduced to support the development of the USB standard and its ever-improving signaling speeds.

The USB Specifications and Their Signaling Rates

Full Speed USB (USB 1.1)

The first USB specification, USB 1.0, was introduced in 1996 and initially supported a Low-Speed transfer rate at 1.5 Mbps. This specification was later revised in 1998 to USB 1.1, also known as Full-Speed USB. This updated specification supports a bandwidth of 12 Mbps and power levels up to 2.5W. USB connectors supporting this spec include USB Type-A and USB Type-B.

High-Speed USB (USB 2.0)

In 2001, the USB 2.0 specification was introduced. USB 2.0, also known as High-Speed USB, supports a transfer rate of 480 Mbps and is backwards compatible with USB 1.1. USB 2.0 also uses the same USB Type-A and USB Type-B cables and connectors, as well as the same software interfaces as USB 1.1, but substantially increases the support for higher bandwidth peripheral devices, such as video camera devices.

SuperSpeed USB (USB 3.x)

USB 3.0

The USB 3.0 specification, also known as SuperSpeed USB, was first released in 2008 to address consumers’ growing needs for USB devices that could handle even more power and faster transfer speeds. USB 3.0 supports transfer rates up to 5 Gbps and power levels up to 4.5W, making it ten times faster and twice as powerful as USB 2.0. Like previous USB specifications, SuperSpeed USB is also backwards compatible with its predecessors and is supported on cable and connector types including USB Type-A and USB Type-B.

Over the years, SuperSpeed USB has undergone numerous revisions to reflect its constant speed improvements.

USB 3.1

In 2013, SuperSpeed USB 3.1 was introduced to reflect its support for transfer rates up to 10 Gbps by using a dual-lane operation within a USB Type-C connector.

USB 3.2

In 2017, USB 3.2 was released, further increasing the signaling rate. This revision supports USB transfer rates up to 20 Gbps, which is possible due the specification signaling 10 Gbps over 2 lanes in a USB Type-C cable.

Throughout the years, there have been numerous updates to the naming conventions and branding of the various releases of USB 3.0, USB 3.1 and USB 3.2. Today, USB 3.2 encompasses all prior USB 3.0 and USB 3.1 specifications, supporting signaling rates at 5 Gbps, 10 Gbps, and 20 Gbps.

• USB 3.0 is now USB 3.2 Gen 1 (SuperSpeed USB) and has a maximum throughput of 5 Gbps.
• USB 3.1 is now USB 3.2 Gen 2x1 (SuperSpeed USB 10 Gbps) and has a maximum throughput of 10 Gbps.
• USB 3.2 is now USB 3.2 Gen 2×2 (SuperSpeed USB 20 Gbps) and has a maximum throughput of 20 Gbps. This is also known as SuperSpeed USB 20Gbps.

USB4

The USB4 specification was released in 2019 and offers users some of the most robust features and capabilities, including the ability to transfer data up to 40 Gbps using a dual-lane operation within a Type-C cable. USB4 permits the highest USB bandwidth available with multiple data and display protocols to efficiently share the maximum aggregate bandwidth over the bus. USB4 also has backwards compatibility with USB 3.2, USB 2.0, and Thunderbolt.

USB Power Delivery

USB Type-C cables are known for their ability to supply high power levels, up to 100W of power, which is possible due to its power negotiation capabilities known as USB Power Delivery (PD). The USB PD specification was released in 2012 as an extension of the USB specifications.  USB Power Delivery is a protocol that is implemented within USB Type-C cables on the communication channel (CC) lines to safely manage power contracts between source and sink connections. Once power negotiations between devices have been established, the correct current and voltage levels are supplied through the VBUS.

Common USB Traffic Errors in USB Device Development

When developing USB devices, it is common for developers to experience bus issues that can lead to USB communication errors. While some errors will cause system failures, other issues may still allow the system to operate, but with potentially erratic behavior. Below are examples of some USB bus issues that can occur:

Improper USB Packet Data and Data Sequencing

USB packets contain error checking mechanisms, including a CRC bit to ensure data validity and a toggle bit in the PID packet to ensure correct data sequencing. Sometimes during USB data transmission, even these can become compromised if there an error in this mechanism, causing individual USB transactions to be dropped or causing reduced throughput.

For instance, if the data packet is corrupt and the CRC is invalid, the receiver will send a NAK bit to the transceiver, informing of an erroneous data packet. Transceivers will then resend the data multiple times, but this can in turn cause data packets to drop as the receiver may consider this to be duplicate data.

One example of an incorrect sequence includes incorrect data bit toggling. In a normal data transaction, the data PID will toggle between DATA0 and DATA1 consecutively, however, if there are issues with this, data retransmission can occur where the toggle bit does not update correctly, causing a repetition of the same toggle bit. In these cases, sequential DATA0s or Data1s are not passed to the application because the receiver will ignore packets that are repeating. This will cause data to not be passed to the application.

USB Transmissions/Retransmissions

In a normal USB transaction, host and peripherals send and receive data, acknowledging (ACK) or denying (NAK) certain transactions, allowing for effective communication. In one example of effective USB transmission, the host will send an IN token to the peripheral, and the peripheral will respond with a data packet. The host will acknowledge this and respond with ACK packet, which will let the device know it received the data correctly and is ready to send another transaction.

However, sometimes transmission can be faulty. If a data packet is corrupted, the host may discard this packet will not send an ACK. The peripheral will then receive another IN token, but since there was no ACK, it will resend the same data. This can be categorized as a retransmission.

Some data retransmission can be okay, but if there is an overflow of retransmission on the bus, this can cause slow performance and/or packet loss.

Power/VBUS Related Issues

Another common USB bus error is related to power and VBUS issues. The VBUS is a wire within the USB connector that supplies power to devices. Host and peripheral devices have specific upper limits on current supplementation or consumption, so if there is detection of an overdraw of current from the device, the system can shut down when testing or operating.

Systems can also react to an over-draw of current by not connecting or enumerating correctly. If the host or device detects high current levels, either one can disconnect and enumeration will not fully complete.

Problems with Enumeration

Enumeration within a USB system is a process where the host detects the presence of a device, and determines what type of device is connected and the speed at which to communicate. This is when the handshake token takes place, as both devices are learning about each other’s capabilities.

Upon enumeration, the host will reset the device in order to read its descriptors and identify it. However, if the device descriptor is incorrect, for instance it is not the correct bit length, this can cause errors in enumeration, causing improper connection between the devices.

High Speed Negotiation Issues

High speed devices can also support low and full speed signaling as USB 2.0 is backwards compatible with previous specifications. When devices are first connected, the full-speed capabilities are initially used until the High-speed capabilities can be confirmed from either device. In order for USB 2.0 devices to perform High-speed negotiations, a protocol known as chirping is performed.

USB defines two data bus states during this stage, J and K chirps. When a High-speed USB host connects to another device, the host will reset the device and wait for a K chirp in return, which will signify that the device is High-speed capable. If it does not reply with a K chirp, the High-speed host device will terminate the handshake. However, if the device does return a K chirp, the host will respond with alternating pairs of Chirp K and Chirp J to tell the device it is High-speed capable. Once this transaction has been recognized, the High-speed connection is established.

Having speed negotiation issues can cause signaling issues between devices, leaving the devices to operate incorrectly. For instance, if a full speed device ends up responding with the K chirp by error, the host will think it is capable of handling High-speed. This can result in corrupt packets because the device does not understand High-speed.

Reset, Suspend, and Resume Events

Certain types of low-level bus events including reset, suspend, and resume events are vital to successful communication between two high speed devices, and any disruptions during these events can cause abnormal behavior in USB devices.

The reset event occurs when the host wants to start communicating with a device. This will allow the device to reset to a default unconfigured state to allow for seamless communication. If this event does not occur correctly, the devices may not be able to affectively enumerate or exchange USB data correctly.

USB devices are able to power down if they are not being used which is performed using a suspend event. During this time, a suspended device must recognize the resume signal and reset signal. If the host wants to wake a device back up, it can issue a resume signal. If there is an issue sending or receiving these signals, the USB device may not wake up correctly and can become unresponsive during or after these events take place.

What is a USB Protocol Analyzer (USB Sniffer)?

A protocol analyzer is a tool commonly used by hardware, software, and firmware developers to analyze and debug embedded systems in all stages of the product lifecycle. Protocol analyzers connect between the host computer and peripheral devices to capture and decode raw bus data and events into human readable format, often flagging bus errors for easier troubleshooting.

There are a variety of protocol analyzers, each specific to analyzing certain data protocols, including I2C, SPI, USB, CAN, and eSPI.

A USB protocol analyzer, also known as a USB bus sniffer or USB bus debugger, will specifically capture and decode USB bus data at the protocol level, including enumeration, USB data packets, individual USB transactions, timing and data events, speed negotiations, and much more. Engineers turn to protocol analyzers to get enhanced insight into the bus and to uncover errors that might otherwise be overlooked.

Software vs Hardware USB Protocol Analyzer

There are two different kinds of USB protocol analyzers that are used to debug USB devices:

• Software USB Protocol Analyzer
• Hardware USB Protocol Analyzer

A software protocol analyzer is a software-only based analyzer that replaces the USB software stack on the host machine under test in order to monitor USB data. Software USB protocol analyzers allow users to see data sent to and from the host controller, but because these analyzers rely on the host computer hardware to perform analysis, this can often limit what USB information is available for analysis.

Contrarily, a hardware analyzer is a hardware-based tool that operates separately and independently from a host computer. Hardware analyzers connect in between the host computer and peripheral device to non-intrusively monitor the communication between the two. They allow users to accessibly debug the embedded host and view specific data and events including speed negotiations, timing issues, and transmission errors.

One significant advantage of using a hardware protocol analyzer as opposed to a software protocol analyzer is its ability to capture, decode, and debug low-level bus events and errors. Low-level bus events include K/J chirps, Reset, Suspend, Resume, In/NAKs, SOF.

While software analyzers provide certain levels of visibility into a USB system, it cannot replace a hardware protocol analyzer. Often, USB developers will use both types of analyzers to ensure their system is operating optimally.

Things to Consider when Choosing a USB Protocol Analyzer

While many of the USB protocol analyzers available on the market provide analyzing and debugging capabilities of the USB protocol, each one is different in terms of how it is able to do so.

When choosing the right USB protocol analyzer, the user must consider which use cases the analyzer will be used for and if there are certain features that are vital to making this happen.

USB Capture Rates

In order to effectively analyze and debug USB devices, the protocol analyzer must be able to successfully capture the USB traffic at the rate it is being signaled. Ensuring an analyzer that can meet the signaling requirements is a vital first step in choosing the right one.

Real-Time Capabilities

Real-time monitoring capabilities allow the user to capture, decode, and analyze USB data in real time, meaning that it is possible to view the data as it occurs, not by capturing, downloading, and then displaying the data. This can be extremely helpful in reducing the time to pinpoint errors and allows users to get better insight into how the bus is behaving.

Memory

The data captured by a hardware protocol analyzer is generally saved in memory storage on the device and on the RAM in the host PC for even further storage space. A larger memory can be greatly beneficial to users who perform long-term data captures that need to record data traffic for multiple days at a time.

USB Class-level Decoding

USB defines class code information to identify a device’s functionalities and to group similar devices that allow them to share a common USB Class Driver. USB class-level decoding is the translation of the low-level USB data into human-readable USB class-level commands and instructions. Having this capability on a protocol analyzer is greatly beneficial for better understanding the data quickly and easily rather than trying to make sense of raw USB data format.

VBUS Current and Voltage Monitoring

Within a USB connector, there are multiple pins that transfer certain data across the cable, but there is also a VBUS wire that is used to transfer power between devices. Having an issue with the VBUS can be result in the devices not powering correctly or disconnecting from each other due to overdraws of current. Having a protocol analyzer that allows for VBUS current and voltage monitoring can help determine any power related issues upon enumeration and connection of devices.

Hardware Triggering

Advanced triggering capabilities can add another dimension of USB debugging that allows users to trigger a capture when certain criteria are met, like matching specific packet types, data, or bus states.

Digital I/O

Having the digital I/O functionality allow users to sync USB traffic with external logic.

Having this functionality also supports performing triggers and synching with external test systems.

Multi-Analyzer Synchronization

Synching multiple protocol analyzers is sometimes needed so you can reliably monitor both sides of a USB hub, or any number of points in a USB system. Having this capability with allow the synchronized capture of events, start, trigger, and stop, on multiple analyzers.

Cross Platform Support

Having a protocol analyzer that is supported on multiple different operating systems offers a more flexible and convenient debugging experience. Having the ability to use on an already familiar operating system also reduces the learning curve on using the tool.

Overview of Total Phase’s Beagle USB Protocol Analyzers

Total Phase offers a variety of USB protocol analyzers that support numerous different project requirements.

Beagle USB 12 Protocol Analyzer – USB Full Speed 1.1 Analyzer

The Beagle USB 12 Protocol Analyzer monitors Low-/Full-Speed USB traffic, up to 12 Mbps. This analyzer offers real-time display, search, and filtering of captured data, as well as descriptor decoding.

For more detailed key features and abilities, please visit the Beagle USB 12 Protocol Analyzer Datasheet.

Beagle USB 480 Protocol Analyzer – USB High-Speed 2.0 Analyzer

The Beagle USB 480 Protocol Analyzer non-intrusively monitors High-/Full-/Low-Speed USB 2.0 traffic, up to 480 Mbps. This analyzer offers real-time display, search, and filtering of captured data, and also offers descriptor decoding and USB class decoding.

For more detailed key features and abilities, please visit the Beagle USB 480 Protocol Analyzer Datasheet.

Beagle USB 480 Power Protocol Analyzer - USB High-Speed 2.0 Analyzer

The Beagle USB 480 Power Protocol Analyzer non-intrusively monitors USB 2.0 traffic, up to 480 Mbps. This analyzer offers real-time display, search, and filtering of captured data, and also offers descriptor decoding and USB class decoding. The Standard and Ultimate versions provide real-time monitoring and graphing of VBUS current and voltage values, while the Ultimate version also provides advanced USB 2.0 triggers that allow users to create state-based and flexible trigger conditions based on data patterns, packet types, error types, events, and other criteria.

For more detailed key features and abilities, please visit the Beagle USB 480 Power Protocol Analyzer Datasheet.

Beagle USB 50000 v2 SuperSpeed Protocol Analyzer – USB SuperSpeed 3.0 Analyzer

The Beagle USB 5000 v2 SuperSpeed Protocol Analyzer non-intrusively monitors SuperSpeed/High-/Full-/Low-Speed USB traffic, up to 5 Gbps. The Standard version can monitor either USB 2.0 or USB 3.0 traffic at one time, while the Ultimate version can monitor USB 2.0 and USB 3.0 traffic simultaneously. This analyzer offers real-time display, search, and filtering of captured data, and also offers descriptor decoding and USB class decoding. It also offers users the ability to perform USB 2.0/USB 3.0 advanced triggers, including state-based and flexible trigger conditions based on data patterns, packet types, error types, events, and other criteria. Additionally, it provides enhanced visibility into the USB 3.0 bus, detecting low-level bus events including link training, LFPS polling, training sequences, and provides a view into the LTSSM which tracks upstream and downstream link state transitions.

For more detailed key features and abilities, please visit the Beagle USB 5000 v2 SuperSpeed Protocol Analyzer Datasheet.

USB Power Delivery Analyzer

The USB Power Delivery Analyzer is a tool used to record the Power Delivery (PD) protocol traffic on the USB Type-C connector. It connects in-line between two Type-C products, and passively captures all communication between them on both the CC1 and CC2 (communication channel) signals. While connected, it does not disturb any USB 3.2 Gen 2 or USB 2.0 signals, enabling capture of PD negotiation for power, USB data roles, and DisplayPort, or other Type-C Alternate Modes. This device also supports Power Delivery 3.0, extended messages, handling of new messages, and DisplayPort VDM decoding.

For more detailed key features and abilities, please visit the USB Power Delivery Analyzer Datasheet.

For a complete overview of all our USB products and how they compare, please visit our USB Product Guide.