Quantcast
Channel: Total Phase Blog
Viewing all 822 articles
Browse latest View live

What is a CRC (Cyclic Redundancy Check)?

$
0
0

Successful communication between devices is key to having a properly functioning embedded system. Embedded systems rely on and function using protocols, or a set of rules that govern the transmission, synchronization, and error checking of data sent and received between devices. Because the protocol is an essential component to a working embedded system, it is crucial that it operates properly. Because communication errors do occur, many protocols, including USB, CAN, and A2B, include error checking mechanisms such as a Cyclic Redundancy Check, or a CRC.

A CRC is used to flag corrupt data and prevent it from being sent over the bus. With today’s protocols often supporting higher bandwidths and speeds, the CRC is fundamental to keeping data clean and reliable within an embedded system. In this article, we’ll cover the different ways the CRC is used in various protocols and how Total Phase tools help spot communication errors in such events.

CRC in Communication Protocols

Communications protocols often use two CRCs in a packet - one to protect the header of the packet and another to protect the data portion of the packet. While the implementation of the CRC varies between protocols, the purpose remains the same – to create a method for the system to detect errors and initiate a request to retransmit the data or ignore it.

How does the CRC get generated and how does it work? It is all based on an algorithmic calculation that is used to detect inconsistencies between the data being transmitted and received. Essentially, the CRC is a value calculated from a number of data bytes to form a unique polynomial key which is appended to the outgoing message. The same process is performed on the receiving end. The receiver then divides the message by the same polynomial the transmitter used and if the result of this division is zero, then the transmission was successful. However, if the result is not equal to zero, this would indicate that an error occurred.

CRC in the USB Protocol

The USB protocol, or Universal Serial Bus, uses Cyclical Redundancy Checks during transmission to protect all non-PID fields in token and data packets from errors. In USB 2.0, the token and start-of-frame (SOF) packets include a 5-bit CRC (CRC5), while the data packet includes a longer 16-bit CRC (CRC16) to provide adequate support for data payloads reaching up to 1024 bytes.

In USB 3.1 packets, the CRC can be found in the header packet, which consists of the header packet framing, packet header, and link control word. The header is protected by a 16-bit CRC (CRC16) and the link control word is protected by a 5-bit CRC (CRC5). The Data Payload Packet includes a 32-bit CRC (CRC32) to accommodate the large data payloads. Additionally, the Link Command Packets that are used to control various link-specific features also include a 5-bit CRC (CRC5).

USB Data Packet

USB 2.0 data packet including a 16-bit CRC

USB Start-of-Frame Packet

USB 2.0 Start-of-Frame packet including a 5-bit CRC

USB Token Packet

USB 2.0 token packet including a 5-bit CRC.

CRC in the CAN Protocol

The CAN protocol, or Controller Area Network, is known for its robust and reliable communication, as it contains multiple error checking mechanisms, including bit error detection, format error detection, fill error detection, response error detection, and CRC error detection. The CRC fields are contained within the data and remote frames.

The CRC error detection works by including a 15-bit CRC in the data frame to verify that messages are properly sent over the bus. Like discussed previously on how CRC operates, 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 reciprocally, and compare the values to determine if they are indeed the same. If not, the receiving nodes will send an Error Frame over the bus. Additionally, the CAN protocol includes a recessive CRC Delimiter at 1-bit which helps prevent form errors and ensures that the bits are properly broadcasted on the bus and received correctly on the receiving end.

CRC in the A2B Protocol

The A2B protocol, or Automotive Audio Bus, is another protocol that uses error checking mechanisms to verify proper communication. One of the measures includes CRC that is used within specific frames to help detect errors over the bus.

A2B Superframe

A2B Superframe including Synchronization Control and Response Frames

The Synchronization Control Frame (SCF) acts as the control frame for nodes, or the control header, and the Synchronization Response Frame (SRF) acts as the response frames from nodes, or the response header. The entire A2B frame structure is known as a Superframe, which starts with an SCF, includes optional data slots, and ends with an SRF. These frames both include cyclic redundant codes (CRC) to help detect upstream and downstream data errors.

For the downstream data error detection, a 16-bit CRC is used within the SCF where it determines any SCF data errors occurring during transmission on the receiving side. The SCF includes a preamble that indicates the start of a Superframe and provides a bit pattern used by slaves for clock and frame synchronization. If the slave does not detect a frame sync, the slave will indicate a CRC error.

For the upstream data error detection, a 16-bit CRC is also used within the SRF to determine any SRF data errors occurring during transmission on the receiving side. The interrupt request fields have an additional CRC inside the SCF to avert false interrupts from being triggered. The SRF also has a preamble to indicate the start of a response frame, and provides a bit pattern used by upstream nodes for clock and frame synchronization. If the upstream node does not detect the frame sync, CRC errors will be indicated.

Detecting CRC Errors with Total Phase Tools

Total Phase offers numerous debugging tools for I2C, SPI, USB, CAN, eSPI, and A2B protocols that can be used in conjunction with the Data Center Software to capture, decode, and analyze data occurring on the bus in true real time. The USB, CAN, and A2B protocols that incorporate Cyclic Redundancy Checks can benefit from our tools to capture and analyze data and bus errors in a variety of ways.

Our line of Beagle USB protocol analyzers, Komodo CAN Interfaces and the A2B Bus Monitor used in conjunction with the Data Center Software allows users to detect, flag, and filter data errors, making it easy to evaluate errors detected by CRC.

The Data Center Software also incorporates numerous ways to interact with USB data specifically, including performing advanced triggers using USB CRC conditions. Depending on the Beagle USB Protocol Analyzer tool, users can perform simple and complex USB 2.0 and USB 3.0 triggers. Simple triggers for USB 2.0 and USB 3.0 can trigger on high-level packet types (including header packets, data payload packets), data patterns, and CRC errors, while complex triggers for USB 2.0 and allow users to match on specific state-based transactions, errors, events, and timers. Complex triggers for USB 3.0 include triggering on a specific packet type or data pattern, in addition to bus events and timers.

Below are examples of the Complex Data Match Configurations for USB 2.0 and USB 3.0 data that are based on Error Packet Types.

USB 2.0 Error Match Action Unit      

USB 3.0 Error Data Match Action Unit

This allows users to match on any packet type which exhibits an error. For USB 2.0, this can match on specific error types on any packet that appears on the bus, including matching criteria include CRC errors, corrupted PIDs, jabber, and general PHY receive errors. For USB 3.0, the errors which can be matched are a CRC error, framing error, or any unknown packet.

For more information on how our tools can help analyze data and bus errors, including CRC errors, please contact us at sales@totalphase.com.

Request a Demo


What is an E-Marker and How Does It Work?

$
0
0

What is an E-Marker

An E-Marker (electronic marker) is a chip that is used in the latest USB connector iteration, USB Type-C, to communicate between power source and power sink devices. The chip is used to communicate with connected devices to ensure safe data and power delivery to and from the source and sink. The E-Marker provides the cable characteristics including the cable length, the maximum supported current and voltage, the type of USB signal, the vendor and product ID, any alternate mode support, and much more. An E-Marker is required on all USB Type-C cables that support 5 amps and/or exceed 60 watts of power carrying capability. USB Type-C cables that are expected to have data transfer rates above 480 Mbps, or High-speed USB 2.0, are also required to have an E-Marker chip embedded in the connectors of the cables. Applications that exceed 480 Mbps fall in the USB 3.1 realm, meaning any USB 3.1 cable is going to, with very minimal exceptions, be required, by the USB-IF community, to include an E-Marker in the Type-C cable.

USB Type-C cable with the e-Marker chip visible E-Marker on a USB Type-C cable

 

USB Type-C and Thunderbolt

Since the introduction of USB 3.0 version of the USB protocol and Type-C connectors, there has been a need to regulate how a cable works across all available applications. The Type-C cable was developed to simplify device connectivity and to create a cable that could be “universally” used across the majority of common applications. With its blazing fast transfer speeds of up to 10 Gbps, ability to continuously support up to 100W of power, and ultra-high video bandwidth capabilities, USB Type-C was built to make all other cables obsolete.

cable and power banks on a table USB Type-C cable and power adapters

With such an ambitious mission the Type-C cable had to be made in a way to work across a multitude of different applications. For instance, HDMI has been the protocol that is used primarily in the transfer of video data. The USB protocol was not originally designed to handle the display and broadcast of video streams to a monitor or TV so originally this application used, almost exclusively, an HDMI cable. Now however, USB Type-C and Thunderbolt are taking on the challenge of not only adding video streaming capabilities to the protocol but simultaneously powering the TV or monitor through a single cable input. This is an incredible feat and is extremely complex technically. With a single cable connection, one can not only stream ultra-high video content while also powering the device but they can also use that same cable to charge a smaller less demanding device such as headphones or a tablet. These two applications are governed by the same USB Power Delivery, or PD, protocol but require drastically different things from the same cable.

The Enumeration Process

Whenever a USB device is connected to a host device there is a communication that takes place called the enumeration process. The enumeration process is the initial “handshake” of the host and device. During enumeration the host device communicate with each other through the transfer of descriptors that inform the host what type of device has been connected, the device’s power requirements, and how to transfer data. For instance, when a USB mouse is plugged into a computer, during the enumeration process, that mouse sends information to the computer telling it that it is a HID (Human Interface Device) device, that it is bus powered, and that it is an optical mouse. The computer will then know how to interact with the mouse properly. All of this communication happens in a fraction of a second and is invisible to the user.

Connecting USB Type-C Devices

When a USB Type-C device is connected the initial enumeration process happens, like mentioned above, but this time there is an added step. Since Type-C devices can vary drastically in capability it is important that the cable is also included in the decision-making process. If the source and sink device are asking for 100W of power but the cable is only capable of a max of 10W then an issue arises. If the source and sink supply the full 100W of power, the cable will malfunction and things can get dangerous.  Now, prior to the enumeration process, a power delivery negotiation must occur that includes the source, sink, and the cable. This communication is made possible because of the microchip on the connector head of the cable, the E-Marker chip. The cable is able to tell the source and sink device what it is capable of doing and then the source and sink device adjust accordingly. The E-Marker acts as a middle man in the negotiation process and typically has the last word on how the source and sink device are going to communicate.

Structure of PD Transactions

When a Type-C cable is connected between a source and sink device, data packets are exchanged to define how power delivery, or PD, will be handled. PD transactions share a similar structure:

1. The Preamble allows the receiver to lock onto the carrier by sending a series of 1s and 0s enabling the receiver to sync to the transmitted clock.Preamble Power Delivery data packet structure

2. The SOP defines the type of communication that is going to take place. This portion indicates whether a packet communication is between ports or a cable and a source. The SOP is used to identify the direction and participants in the power conversation. For transfers between two devices, SOP packets will be used.  For transfers between a source and a cable, SOP’ will be used.SOP Power Delivery data packet structure

3. The next part of the packet is called the header sequence. The header sequence indicates what originated the request (upward or downward facing port), the ID number of the transmission, and how many data packets will follow.header sequence Power Delivery data packet structure

4. Data packets are sent next. These data packets contain information regarding Vendor ID, Product ID, and specific capabilities. This is the information that the E-Marker contains.Power Delivery data packet structure

5. After the E-Marker is read a Cyclic Redundancy Check (CRC) packet is sent to ensure that data being sent is not corrupted and is received properly. This check confirms the integrity of the data packets being sent over the bus. At the end of this packet, there is an “end of packet” symbol (E) that confirms the end of the PD packet being sent.CRC Power Delivery data packet structure

PD Negotiation

These PD transactions make up the power delivery negotiation process. The PD negotiation process must first address the cable, this is called SOP prime. Fully featured Type-C cables are required to have an E-Marker that indicate power carrying capabilities. The SOP’ negotiation is required for any power contracts above 3 Amps or 60 watts. Once the cable capabilities are determined, the PD negotiation process can continue. The PD negotiation process can be simplified into eight stages.

  1. The Source declares its power capabilities as constrained by the cable.
  2. The Sink issues a CRC confirming receipt of the message.
  3. The Sink then issues a request for the appropriate power option.
  4. The Source issues a CRC confirming receipt of the request.
  5. The Source accepts the Sink request.
  6. The Sink issues a CRC confirming receipt of the acceptance.
  7. The Source issues the PS ready.
  8. The negotiation power level is delivered.

A device can fail at any of the above steps. If a failure occurs, power will not be delivered and the device may not be recognizable to the source or sink device. This process ensures the safety and reliability of the connected devices enabling safe usage. Luckily there are some tools to help engineers and developers ensure and guarantee that the cables they make are safe, reliable, and ready for manufacturing.

Type-C Testing Tools

The Advanced Cable Tester v2

Total Phase has seen the rapid adoption of the Type-C connector and has built a tool to help manufacturers ensure the safety and reliability of their cables. The tool is called the Advanced Cable Tester v2. The Advanced Cable Tester v2 is the quickest and most convenient way to comprehensively test USB, Lightning, and video cables. It provides:

  • Short testing - Dynamic visualization of test results
  • Open testing - Dynamic visualization of test results
  • Continuity testing - Dynamic visualization of test results
  • DC resistance measurement for most wires, with milliohm precision on ground and power wires, ohm resolution on most other wires, continuity check only on high-speed data lines
  • Signal integrity testing of data lines up to 12.8 Gbps per channel
  • E-Marker verification
  • Lightning plug bring up/function (Apple Lightning Cables)*
  • Over-voltage protection (Apple Lightning Cables)*
  • Voltage recovery testing (Apple Lightning Cables)*
  • Quiescent current consumption (Apple Lightning Cables)*
Advanced Cable Tester v2 face plates Advanced Cable Tester v2

The Advanced Cable Tester v2 is the fastest, most comprehensive cable tester on the market. With its rugged design, low cost per test, and easy to understand reports, the tool is ideal for lab and production environments. Regardless of the application, the Advanced Cable Tester v2 will provide high precision test coverage without the need for custom tools, highly trained personnel, or expensive oscilloscopes. This tool has the potential to save hundreds of thousands of dollars in overhead and recall costs.

The tester runs a series of different tests when a cable is connected including continuity, DC resistance, E-Marker reading, and signal integrity.  During the signal integrity test, the Advanced Cable Tester v2 is able to test signal integrity up to 12.8 Gbps per channel and render eye diagrams typically only seen with expensive scopes.

Advanced Cable Tester v2 Signal Integrity test eye diagrams Advanced Cable Tester v2 Signal Integrity test eye diagrams

Another important test ensures the presence of an E-Marker on a USB Type-C cable. The E-Marker test takes the expected values of the USB specification and compares those values with the actual values programmed into the cable’s E-Marker to ensure a match in data. If the measured values do not match, the Advanced Cable Tester v2 will fail the cable. The E-Marker test also presents a few additional fields including Product ID, Vendor ID, and Test ID.

USB Power Delivery Analyzer

For engineers looking to debug the PD negotiation process, the USB Power Delivery Analyzer is the right tool. Combined with the Data Center Software, all power delivery transactions are captured, both SOP’ and SOP, and displayed in real-time for quick debugging of messages. Additionally, VBUS and VCONN current and voltage are measured and graphed with one-click correlation to the PD data packets. This allows engineers to confirm that the power delivered meets the negotiated levels.

Total Phase USB Power Deliver Analyzer Total Phase USB Power Deliver Analyzer

 

Summary

The E-Marker is an extremely important component to be considered in all USB Type-C cables. It ensures that connected devices are operating at a level that is safe and reliable. With tools like the Advanced Cable Tester v2 and USB Power Delivery Analyzer, engineers are able to dive into test results and create the best cables for the market while ensuring safety and reliability.

 

How Do I Set Up the Timing for SPI Slave and SPI Master Devices to Communicate?

$
0
0

m

Question from the Customer:

I am streaming 5.56 MHz SPI data over the MOSI line. I am using the Aardvark I2C/SPI Host Adapter as the slave device in SPI + GPIO mode with the Control Center Serial Software. My problem is I do not see data at either 4 MHz or 8 MHz in the transaction log window.  I see that the master sends out data every 1ms. The setup for both views:

  • The master I/O level is 3.3V
  • The SPI master clock rate is 5.568 MHz

What I see on the oscilloscope:

View of timing and data on oscilloscope Data View on 'Scope

What I see in the Control Center Serial Software:

View of SPI data transmission on Control Center Serial Software Data View on Control Center Serial Software

Response from Technical Support:

Thanks for your questions! Here are some details about communication between SPI slave and master devices, as well as some diagnostic tips and suggestions. We can start with two essential check points:

  • Is the operation voltage of the master device compatible with the Aardvark adapter?
  • What is the bitrate at which the master device operates?

We will continue with more details in the following sections.

SPI Slave to Master Communication and Timing

For communication to occur, a delay is required between bytes. The timing requirements are a bit different for slave to master (MISO) and master to slave (MOSI) communication.

MISO Timing

For transmitting data from the slave to the master, a minimum 4 µs delay is required between the end of byte n and start of byte n+1. This timing allows setting up the MISO data for byte n+1. Without that delay, the Aardvark adapter will simply return the data that it received.

MOSI Timing

For transmitting data from the master to the slave, a minimum 10 µs is required between the start of byte n and the start of byte n+1.

Technical Tips for Communication

Here are some tips for correcting the communication between SPI devices.

Timing between Transactions

When the Aardvark adapter is configured to act as an SPI slave and the slave select is pulled high to indicate the end of a transaction, there is a data processing overhead of sending the transaction to the PC host.

If the SPI master sends a subsequent transaction in rapid succession to the Aardvark slave, the data received by the Aardvark slave may be corrupted. There is no precise value for this minimum inter-transaction time. We suggest 100-200 µs between transactions, which is usually sufficient.

Incompatible Master/Slave Characteristics

There is a chance that the target system, the SPI master, may not follow the characteristic requirements of the Aardvark adapter in SPI slave mode. If necessary, modify the SPI target system so that it follows the Aardvark slave requirements. For more information, please refer to the section  SPI Signaling Characteristics in the Aardvark I2C/SPI Host Adapter User Manual

More Timing Control with Promira Serial Platform

Looking at the details of your setup and requirements, it seems that the tb (time between start of bytes) is 1.4µs. However, as previously discussed about signaling characteristics, the minimum time required between the start of each byte is 10µs.

For your system requirements, we recommend looking at our Promira Serial Platform, which can be used as an SPI master up to 80 MHz and up to 20 MHz as an SPI slave. The current release of the Promira platform supports SPI Active Level 1, Level 2 and Level 3 Applications.  Using the Promira platform gives the ability to more finely tune the timing requirements.

Monitoring Details with Beagle I2C/SPI Protocol Analyzer

The Beagle I2C/SPI Protocol Analyzer non-intrusively monitors SPI up to 24 MHz.  We recommend considering the integration of this tool in your setup for more detailed monitoring and diagnostics.  This may help diagnose the timing and data issues.

For a quick overview of our products, here is a table of our I2C/SPI devices:

Chart of Total Phase SPI and I2C Tools Total Phase I2C/SPI Tools

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

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

An Introduction to Embedded Systems Design

$
0
0

The design and development process for embedded systems is uniquely challenging. This is, at least in part, due to the complexity of systems that involve both hardware and software operating within tight resource and timing constraints. In truth, the need to operate within these constraints while reliably delivering functionality over long periods of time is exactly why embedded systems design is such an important process.

To make it easier, we've outlined a general introduction to embedded system design that explains, step-by-step, how to navigate the design process from collecting requirements to final product testing.

What is an Embedded System Design?

Embedded systems are self-contained computers that live inside other systems, usually performing a highly specific function or set of functions. They consist of a processor, communication interfaces, and peripherals used to implement specific features. Many types of embedded systems are expected to operate continuously for years or even decades at a time without interference from a human. Others use a system of sensors and actuators to respond to environmental situations in real time, or use internet connectivity to upload sensory data to a network.

Embedded systems engineers spend their time designing and implementing embedded systems for a variety of industrial and consumer applications. The goal of the embedded systems design process is to effectively translate project requirements into product specifications and eventually into a product that meets project objectives within the identified design constraints.

Phone

Image courtesy of Unsplash: Designing something new is an iterative process. It's always okay to go back and make changes until you get it just right. Engineers should be encouraged to make mistakes, learn lessons, and try again until they succeed in building something amazing.

What is the Embedded System Design Process?

Collect Project Requirements

The first step in the embedded system design process is to understand project requirements. The first step here is typically understanding user needs. Designers will ask questions like:

  • Who will use the product?
  • What features should the product have?
  • How will the product be used?
  • Where will the product be used?
  • Will the product have a human user interface? Will the user interact directly with the product?
  • Will the product generate data? If so, how will it be collected? How will it be accessed? How will it be secured?
  • What design constraints exist for the product? What design constraints emerge from other requirements?
  • Will data be processed in real time?
  • What kind of embedded operating system is needed?

Define System Specifications

Once the requirements for the project are clearly understood, embedded systems engineers can begin to define system specifications. This process essentially means translating the plain language of user requirements into technical requirements for manufacturing and building an embedded device.

It is often useful to implement a formalized design verification/validation process with the goal to ensure that the designed system effectively meets user needs.

Co-Design Hardware and Software Systems

The paradigm of co-designing embedded systems emerged in 1996, with the release of The Co-design of Embedded Systems: A Unified Hardware/Software Representation. This publication promotes a methodology for designing the hardware and software components of an embedded system in tandem, specifically by constructing a unified hardware/software representation of the device known as a decomposition graph. The key benefits of co-design are it enables a deeper understanding of hardware/software performance trade-offs and it helps to mitigate the challenges of system integration.

Choose Technologies

The next step in the embedded system design process is to choose the technologies that will be implemented in the final product. An embedded system will need some kind of processor, but you'll have to choose between a System-on-a-Chip (SoC), a microcontroller, digital signal processors, or a general purpose microprocessor. There are also field programmable gate arrays (FPGAs) and complex programmable logic devices (CPLDs) that may be appropriate for some applications.

You'll also need to choose what peripherals to include, which depends on the answers to questions like:

  • How much battery life will the product need?
  • Will the product run a real-time operating system?
  • What input or output devices are necessary for this product?
  • Will the product have a user interface?
  • What functions will the product support?

Allocate Resources

Allocating resources means procuring the necessary human and physical resources to support the product design process. Without the necessary resources, even a great project idea could be doomed to failure. The technologies that you choose for your embedded system will determine the skills and expertise you will need to execute on the project. You may want to recruit team members with complementary skill sets in various areas of embedded systems hardware design and implementation.

Select Tools and Components

In this step, your design team will work together to choose the tools and components that deliver optimal performance given the feature requirements and design constraints for the system. This step includes choosing specific vendors, suppliers, or brands that will provide components for both the product itself and for the testing and debugging process. Tool selection can depend on many factors, including the desired technologies for the implementation and the expertise available on the design team.

Design and Manufacture Hardware

Hardware design includes the preparation of schematics and design drawings, creating an efficient layout and physical design for the product, manufacturing printed circuit boards (PCBs), and design verification.

Develop and Test Software

Embedded system software development encompasses a whole set of tasks, including writing code, configuring peripherals to run the code under the desired conditions, testing and refining code to make it functional and as efficient as possible, debugging to remove errors, and ultimately verifying that the code does everything it is supposed to do. Up to 50% of total project resources can be expended in the testing phase, so it is important to choose the most appropriate testing tools that can help to streamline the testing process.

System Integration and Integration Testing

Once the hardware and software components have been developed, the system needs to be integrated. System integration is the process of combining hardware and software systems and ensuring that the component parts are all still functioning as expected. The co-design process for embedded systems is helpful for maximizing efficiency and minimizing compatibility issues or other conflicts between hardware and software.

Final Testing

Any final testing for the product is concluded in this stage. Once testing is finalized, the project manager certifies that the product has been completed according to the system specifications.

Embedded Systems Hardware Design and Implementation

Hardware design and implementation is an extremely broad area of expertise for embedded systems engineers. To effectively design an embedded device, engineers must understand the subtle differences between different kinds of components, along with their requirements, advantages and disadvantages as they pertain to the task at hand. Choosing between different types of processors and peripherals, and planning how they will interface within the system are the main tasks of embedded hardware design. The 2012 publication Hardware Design of Embedded Systems for Security Applications provides excellent details and insight into the embedded hardware design process.

Summary

When executed in good faith, an effective embedded systems design process helps ensure that product development teams build products that satisfy user needs, providing the requisite features and functionality while operating within the identified and specified constraints. Following this process can help engineers build better products and reduce time to market while enhancing product quality and customer satisfaction.

 

How Do I Quickly Resume Using the Aardvark I2C/SPI Host Adapter when the Application is Restarted?

$
0
0

Question from the Customer:

I am writing a program to detect multiple Aardvark I2C/SPI Host Adapters and connect to them.

I want to ensure that when the application fails and is restarted, it can connect to the Aardvark adapters that were open and working. This is where I am having issues:

  • If I write some buggy application code that quits and I rerun it to find the Aardvark adapters, I get an error that the ports are wrong.

aa_find_devices_ext(16, 16)
Out[39]: (2, array('H', [32768, 32769]), array('I', [2238942396, 2238944444]))

  • If I unplug and replug the Aardvark adapters via USB, the correct ports are identified and the Aardvark adapters function again.

aa_find_devices_ext(16, 16)
Out[40]: (2, array('H', [0, 1]), array('I', [2238942396, 2238944444]))

Here are some details about my setup:

  • I leave the I2C ports open so that any function that wants to transmit and receive over I2C does not need the operations of aa_open and aa_close.
  • The problem that I am having only occurs when I have a coding bug that results in a failed transmit or receive.

How can I guard against incorrect ports being returned? Several workstations are involved in this project. It would really save me time to not have to physically connect and reconnect every host adapter on the floor.

Response from Technical Support:

Thanks for your question! The Aardvark Software API is provided with functional examples that you can use as-is or modified as needed.  The example aadetect should be a good starting point for your project. The API function aa_find_devices_ext searches for Aardvark adapters in use and the ports to which they are connected. Here is what the code looks like in Python (other programing languages are supported):

# Find all the attached devices
(num, ports, unique_ids) = aa_find_devices_ext(16, 16)

if num > 0:

print("%d device(s) found:" % num)
# Print the information on each device

for i in range(num):

port      = ports[i]
unique_id = unique_ids[i]
# Determine if the device is in-use
inuse = "(avail)"
if (port & AA_PORT_NOT_FREE):

inuse = "(in-use)"
port  = port & ~AA_PORT_NOT_FREE

# Display device port number, in-use status, and serial number
print("    port = %d   %s  (%04d-%06d)" %  (port, inuse, unique_id // 1000000, unique_id % 1000000))

else:

print("No devices found.")

 

For more information about API code, please refer to the API Documentation section 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:

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 Signal De-Emphasis and When it is Used?

$
0
0

Signal de-emphasis is a signal-enhancing technique often used to improve the quality of electrical signals transmitting at gigabit rates over devices including PCBs and long cables. Signal degradation can be due to a variety of reasons, including long transmission lines and jitter, so this technique helps negate these issues by decreasing the low frequency data to minimize signal loss. Learn how de-emphasis works and how it is used to improve signal integrity issues.

Signal Loss Within Cables

Signal loss within cables is a naturally occurring effect, particularly within cables using copper wires. This signal attenuation, or reduction in signal strength throughout the cable, can be due to a number of factors, including resistance or impedance in the wire, and can be especially prominent with higher frequency signals. The high-frequency loss is also greater with longer cables and can lead to loss of bit data.

Within a receiver there is circuity that performs automatic gain control. This automatic gain can compensate for some of the signal loss as it is designed to keep a constant output signal despite any variations within the signal at the input of the amplifier or system. In other words, it essentially “turns up the volume” to make a weak signal louder, or reduces the amplification when it is too strong.

When the high-frequency loss is significantly different from the low-frequency loss, that gain will get set according to the stronger frequency and the weaker frequency will be unrecoverable. This poses a problem with outputting a quality signal.

How Does Signal De-Emphasis Work?

There are a few techniques that are used to compensate for such signal degradation issues, including pre-emphasis and de-emphasis. Both pre- and de-emphasis occur on the transmitter side. Assuming loss in the cable, the transmitter will boost the high frequency content (pre-emphasis) or decrease the low frequency content (de-emphasis).

Pre-emphasis works by boosting the high-frequency portion of the signal. This compensates for the high-frequency loss in the cable.

De-emphasis works by cutting the low-frequency portion of the signal. This may be coupled with an increased transmit voltage.

Pre-emphasis and de-emphasis provide essentially the same function, which is to provide a flat frequency curve on the receiver side. In actual implementation, de-emphasis can be technically simpler, so it is more often seen between the two.

While pre/de-emphasis helps to create a more stable signal, it can also create issues if the system applies too much of either. For instance, if you surpass the optimal amount, you can end up with too little low-frequency and too much high-frequency.

De-Emphasis in USB, HDMI, and DisplayPort Cables

Where do we often see the use of de-emphasis within the cables? De-emphasis is regularly used in high-speed systems, which are often classified as being 1 Gbps or more. Signal de-emphasis can be found commonly in HDMI and DisplayPort cables. HDMI cables are known to use signal de-emphasis the most aggressively, as they are frequently fabricated to be longer. Because SuperSpeed USB is a higher-speed interface than its USB 2.0 counterpart, it must consider transmission-line effects and use equalization to ensure there are fewer reductions in the signal integrity. Therefore, de-emphasis is also commonly used, but is used less compared to HDMI or DisplayPort.

Using De-Emphasis with the Advanced Cable Tester v2

Advanced Cable Tester v2 Front Panel

As explained previously, de-emphasis is commonly used to compensate for loss occurring along the transmission path within cables. This same concept is used within the Advanced Cable Tester v2 to provide insight into a cable’s signal performance.

The Advanced Cable Tester v2 is a comprehensive cable testing tool that tests USB, HDMI, DisplayPort, and Apple Lightning cables for quality and safety measures including pin continuity, DC resistance, E-marker accuracy, and signal integrity. The signal integrity test measures the quality of signal by essentially outputting a known-good signal and then measuring the signal received at the other end. The Advanced Cable Tester v2 signal integrity test provides a visualization of the signal in the form of an eye-diagram. It also includes masks calculated from the insertion loss values per cable specifications. Wider eye openings represent a better signal while a smaller opening indicates a lower quality signal. Any portion of the eye-diagram touching the mask will automatically fail the signal integrity test.

One of the features of the signal integrity includes applying de-emphasis. When enabled, this is applied on the data pairs when testing HDMI, DisplayPort, and SuperSpeed USB cables. The de-emphasis values for both DisplayPort and HDMI have been taken from the respective specification. The value, however, is adaptive and the Advanced Cable Tester v2 will choose the value that is ideal while running the tests. Values available include: 0 to -15dB. When multiple values are available, the Advanced Cable Tester v2 will start with the least de-emphasis value (closest to 0) and continually repeat testing until the best signal integrity is found. For USB, a fixed value of about -3.5dB is used.

By default, the Advanced Cable Tester v2 uses signal de-emphasis for the higher speed tests, but it can be disabled. By enabling this feature, it allows users to test worse-quality cables that otherwise would result in a “no lock” outcome. This is because applying de-emphasis allows the signal transmitted through the cable to successfully be locked at the other end. For this reason, cables with more loss are difficult to test without de-emphasis, even if the cable is within the relevant specifications. On the other hand, while disabling de-emphasis may result in a more closed eye, the results are more easily compared across multiple cable samples.

Below are examples of various passing signal integrity tests using de-emphasis values:

USB Type-C to USB Type-C Signal Integrity Test Signal integrity test for USB Type-C to USB Type-C cable

 

HDMI to HDMI Signal Integrity Test Signal integrity test for HDMI to HDMI cable

 

DisplayPort to DisplayPort Signal Integrity Test Signal integrity test for DisplayPort to DisplayPort cable

Summary

Because cables naturally experience signal loss, de-emphasis is a helpful technique in preserving the integrity of the signal throughout the cable. De-emphasis does this by decreasing the low frequency portion of the signal, which in turn allows the receiver to output a stable signal. The Advanced Cable Tester v2 offers the ability to apply de-emphasis values in order to test worse-quality cables, allowing users to thoroughly test USB, HDMI, and DisplayPort’s signal quality.

Why am I Missing ACK Signals with the Aardvark I2C/SPI Host Adapter Using the Python API?

$
0
0

Question from the customer:

I am using the Aardvark I2C/SPI Host Adapter to imitate a temperature sensor on an I2C bus and am experiencing problems with request replies. I am using the Python API to reply to I2C requests. Everything seems to work fine until I decrease the delay between the requests to 1 ms.

The ACK signal is not being sent once the request is received and I get “error: non-I2C asynchronous message is pending” immediately. Sometimes, I do get the correct responses. My questions:

  • What is the cause for not receiving an ACK signal?
  • Is there a lower boundary for delay between communication?

Response from Technical Support:

The cause for receiving an ACK signal some of the time is due to a limitation on the throughput of the Aardvark I2C/SPI Host Adapter.

Aardvark I2C/SPI Host Adapter as an I2C Master

The Aardvark adapter can act as an I2C master at 1 kHz - 800 kHz.  It is not possible to send bytes at a throughput of exactly 1/8 times the bitrate.  The I2C protocol requires that 9 bits are sent for every 8 bits of data.

There is also a finite time required to set up a byte transmission. The Aardvark I2C/SPI Host Adapter has been optimized to decrease the setup time. This allows byte throughput within each transaction to be very close to the theoretical maximum byte throughput of 1/9 of the bitrate.

The Aardvark I2C/SPI Host Adapter User Manual section 2.3 details the I2C signaling characteristics.

Aardvark API Latency

There is extra overhead introduced by the operating system between calls to the Aardvark Software API. The aa_i2c_write (or aa_i2c_read) call must complete before the next API call. Each time this function is called, a 2 ms round-trip latency is incurred caused by the full-speed USB link between the computer and the Aardvark adapter.

In addition, the target device may require some delay time in order to commit the write to a specific address, and before performing the next read for that address. Take a look at the target device datasheet in order to find the value of this required delay. The operating system may also add additional delays due to internal overhead.

For the Aardvark API functions, everything is a block function that waits for the response from the device, meaning any function has a USB latency around 1-2 ms. This is a bit slower than other devices since the Aardvark adapter is using USB full-speed (12 Mbps).

More Options with the Promira Serial Platform

The Promira Serial Platform is an advanced serial device with configurable I2C and SPI applications. With the I2C Active – Level 1 and Level 2 Applications, the Promira Serial Platform supports active communication on the I2C bus as an I2C master/slave up to 3.4 MHz, level shifting 0.9 V – 3.3 V, and USB High-Speed/Ethernet connectivity.

Please note: The maximum bitrates are only achievable within each individual transaction and do not extend across transactions. There can be delays across the Ethernet/USB bus within a transaction. The GUI and the OS may add delay due to internal overhead.

When using the Promira Serial Platform, the USB roundtrip latency is reduced to 250us when using the High-speed USB over Ethernet connectivity. The roundtrip latency is reduced further when using Ethernet connectivity. The Promira Serial Platform also offers an API queuing mechanism that may provide additional speed-up. For additional information take a look at the Promira Serial Platform User Manual and AC Characteristics.

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

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

Request a Demo

What are the Differences Between Serial and Parallel Communication?

$
0
0

In embedded systems, devices communicate by sending and receiving messages often via cables and wires.  The type of cable/wire and communication varies based on the specific application being used. In this article we will discuss the differences between two common modes of communication: serial and parallel.

How Does Serial Communication Work?

Serial communication can be best visualized using an analogy of a freeway or interstate highway. The lanes on the interstate will be representative of the individual lanes or wires being used for communication and the cars represent bits of data.

Serial communication takes place on a single wire, or in this case one lane on the road. Bits are sent sequentially with a start and stop bit placed at the beginning or end of the packet. All of the data is received and assembled one bit at a time by the receiving device.

Serial Communication example

How Does Parallel Communication Work?

Using the same imagery as before, parallel communication requires more lanes than serial. In parallel, devices send and receive multiple bits of information simultaneously. Each bit of data is sent over a single wire, so an eight-bit packet (or 1 byte) would require eight individual wires to carry the message. This means that the data packet is received by the endpoint device at once. All data is sent in unison in parallel communication and uses a one wire or lane per bit. All data must be received at the same exact time for the packet to be received properly and without error.

Parallel communication data flow example

Parallel vs Serial Cables

The cables used for parallel and serial communication look quite a bit different from each other. Parallel cables are generally thicker and shorter than serial cables, and typically have larger more complex connector heads.

Parallel Cables

Parallel cables are most easy to spot if you can see individual pins visible on the connector head as seen in the picture below. These pins are directly linked to an individual wire in the cable. For every pin on the male side of the connecter head, you can find an input slot on the female end of the cable. The connection is uninterrupted from one end to the other. The cable is generally thick and stiff feeling when compared to serial cables because of the number of wires that are in the cable.

Parallel style cable

Serial Cables

Serial cables are much more common to spot in everyday life. The USB cable is an example of a serial style cable. As you can see the connector head looks substantially different than the parallel cable simply because it is smaller and does not have visible pins. Another differentiating aspect is the thickness of the cable.

Serial communication cable

Benefits of Parallel Communication

Parallel communication, before the introduction of the USB standard, was much more common to see in everyday applications. From plugging in a printer to connecting an external monitor, parallel style communication was used almost exclusively with older PCs. The reason this standard was adapted so widely was because it generally is a fast standard to work with. Since data packets are sent simultaneously more data can be transferred in a shorter period of time. If using byte-level communication, parallel data can send 1 byte eight times faster than serial communication.  However, as cables became longer and applications became more data-heavy parallel communication started to see some limitations.

Drawbacks to Parallel Communication

Cross Talk

A common issue that engineers run into when working with wires is the issue of cross talk between the data lines. Cross talk, or noise, is caused by electromagnetic signals affecting another electronic signal.  This is very common when wires are too close to one another. Cross talk distorts data and causes errors when present.

Cross talk on electrical wires

Limitations at High Frequencies and Long Ranges

Another issue that arises with parallel communication happens at high-frequency data transfers. At higher frequencies, it is common for bits to get jumbled and arrive at the receiving device at different times. This is problematic since parallel requires that all bits of data are received at the same time. The receiver is required to slow down the messages to wait for all data packets to arrive before accepting the full data packet. If this happens it is common for the receiver to get backed up. If it cannot accept all the messages at a time, due to lagging bits of data, the incoming bits may run into the waiting packets, causing additional issues. Parallel excels when used is short distance applications.

Pins Susceptible to Damage

Another issue that arises when using connector heads with visible pins is the high potential for damage. A very common issue that people experience, especially with old printers, is the bending of connector pins when trying to connect devices. Lining up the pins in a connector like this can be difficult and requires more attention. Typical USB cables do not have this issue since there are no visible pins in the design.

parallel cable pins

Greater Physical Footprint

Space is one of the most valuable aspects of any modern-day PCB or device design. As designs get smaller, input and output connectors must also get smaller. Since parallel ports require individual pins for their connection, the space needed on a PCB or device gets bigger as more pins are added. This space requirement why it is very rare to see these types of ports on modern-day computers and monitors. There has been an adoption of smaller, serial style ports to save space and size.

More Expensive

Parallel cables and connectors are also more expensive to make and implement than their serial counterpart. Since more wires are needed for the application each wire adds to the overall cost of development. In parallel data communication, upwards of 34 wires can be needed for some of the more advanced operations. The difference between 1 and 34 wires can be exponentially more expensive and is often a huge factor in deciding to go with a serial vs parallel for an application.

Benefits of Serial Communication

Serial communication has become the universal standard when it comes to connections for devices. Because of its small footprint (cable and connector heads), ease of use, and reliability, serial has proven itself as the future of connected devices. Some of the many benefits of serial communication include:

Small Footprint and Ease of Use

Serial ports are most commonly known for their ease of use and small physical footprint. With a lot of serial ports now adopting the ability to be plugged in regardless of orientation, the effort needed for the user is now at an all-time low. Simplifying the connecting process has made interfacing with serial ports a lot more painless.

back of computer showing input and output ports

The connector heads and ports are also substantially smaller when compared to parallel. The ability to take up, sometimes, less than a quarter of the space on a PCB or device as is required for parallel is a major positive for modern-day device makers. This valuable space can be used for other features such as bigger battery, more memory, or be eliminated to push the boundaries on shrinking devices altogether.

This also means serial ports, cables, and connectors are also more cost-efficient. Less wires required for data transmission, means smaller and less complex traces. The simplified design saves manufacturing and design costs.

Increased Insertions

The connector heads for serial ports are also capable of many more insertions over the life of the connector when compared to parallel. Since the exposed pins have been removed and the process of plugging has become easier, the potential for damage in the port or connector head has nearly been eliminated. This means that these ports will now last longer than parallel.

plugging in USB cable to computer

Reliability at High Frequencies and Long Distances

The serial protocol is also much more reliable at high-frequency data transmission and long-distance applications. Since serial sends one bit at a time over a single wire it is very hard for data to get jumbled when speeds are increased. There is no way for data to reach the receiver before or after bits are sent by the source device. A fully optimized parallel application can indeed send more data at faster rates than serial but high levels of optimization take a lot of time to develop and perfect.

Serial is also much better to use for long-distance connections (greater than 3 ft). Since all data is being sent on a single wire, long-distance applications are much more reliable when using serial. Data does not get bunched up and can be sent at very high speeds with nearly perfect accuracy making serial ideal for reliable long-distance data transfer applications.

Draw Backs to Serial Communication

The main drawback of serial communication is the lack of speed potential. More wires generally mean more speed. If applications optimize for parallel communication and iron out all the issues with bit-level timing, the data transfer rate will far exceed that of serial communication. However, with modern technology advancements, many of the speed limitations initially found with serial communication have been overcome.  The need to reduce space and costs of designs led to a prevalence of serial protocols. As technology continues to develop, it is not uncommon to see serial communication above 10 Gbps are seen in USB 3.1.

Common Serial Protocols

Some of the most common serial protocols include SPI, I2C, CAN, and USB. From use in real-time clocks, LCD screens, automobiles, medical devices, and mobile phones, these protocols are used in a broad range of applications. One thing these protocols have in common is their communication style; they all communicate over serial.

Programming and Debugging Serial Protocols

Total Phase specializes in serial protocol analyzers and programmers. Two of the most popular Total Phase tools that are used for debugging serial protocols are the Aardvark I2C/SPI Host Adapter and Beagle I2C/SPI Protocol Analyzer.

The Aardvark I2C/SPI Host Adapter is a pocket-sized protocol programmer offered at an affordable price. Its ability to program SPI at up to 8 MHz and I2C at up to 800 kHz makes the Aardvark adapter a very attractive tool for embedded systems engineers. The adapter has free and easy-to-use software and is fully supported on Windows, Linux, and Mac operating systems. This tool is powerful, portable, and affordable making it a great tool for all I2C and SPI engineers.Aardvark I2C/SPI Host Adapter The Beagle I2C/SPI Protocol Analyzer is another Total Phase tool that embedded systems engineers know and love. Although very similar to the Aardvark adapter in size and price, the Beagle I2C/SPI analyzer is very different in how it is used. This analyzer is capable of non-intrusively monitoring the I2C and SPI bus at up to 5 MHz and 24 MHz respectively. The analyzer works with the free Data Center Software that is fully supported on Windows, Linux, and Mac operating systems.

Beagle I2C/SPI Protocol Analyzer

The Beagle I2C/SPI analyzer and Aardvark adapter are just a few of the many Total Phase serial protocol tools. Total Phase supports not just I2C and SPI, but also USB, CAN, eSPI, and A2B applications.

Conclusion

Serial and parallel communication have pros and cons when considering which standard to implement into devices and designs. The speed that parallel is capable of is attractive but complicated and expensive to pursue. Whereas the reliability and small footprint of serial communication makes it an appealing option. With advances in speed, serial communication is becoming the standard for data delivery applications and is the prevailing communication style being pursued today.

 


Control Center Software Series: General Purpose IO

$
0
0

The Total Phase Control Center Serial Software provides access to I2C and SPI functionalities of the Aardvark I2C/SPI Host AdapterCheetah SPI Host Adapter, and Promira Serial Platform, including reading and writing messages, XML batch scripting, and more. Additionally, this software allows users to access and interact with the GPIO functionality that is offered with the Aardvark adapter and Promira platform specifically. The GPIO functionality can be combined with I2C or SPI or it can be used as a standalone, which offers users flexibility when developing and testing devices as GPIOs bring additional uses for pins not otherwise natively available. In this article, we’ll provide more insight into the GPIO functionality that is offered within the Control Center Serial Software.

What is a GPIO?

For users new to General Purpose Input/Output, or GPIO, it is a digital signal pin located on an integrated circuit that can be configured as an input or output depending on the application. Unlike other pins that have a dedicated purpose, the GPIO pins can be customized by hardware and software developers for use with a variety of different purposes. Developers can use GPIO pins to connect microcontrollers to other devices such as sensors, LEDs, or system-on-chip circuits.

GPIO in the Control Center Serial Software

Within the Control Center Serial Software, there are six operational modes supported including I2C + SPI, I2C + GPIO, SPI + GPIO, GPIO Only, Batch Mode, and Multi SPI I/O. Depending on the device and selected mode, different modes will appear in the main display. In this article, we’ll focus on using the GPIO related modes.

The “GPIO Only” mode allows users to take advantage of the six GPIO pins available on the 10-pin header of the Aardvark adapter and Promira platform.  Those looking to combine I2C or SPI with GPIO concurrently can choose the “I2C + GPIO” or “SPI + GPIO” mode options.

When GPIO is combined with either I2C or SPI, only the unused pins are available for GPIO. For example, when using I2C + GPIO, only the SPI pins (5,7,8,9) are available for GPIO and when using SPI + GPIO, only the I2C pins (1,3) are available for GPIO.

When using the Promira Serial Platform, up to eight GPIO pins are available in the software. The Promira platform can be licensed for up to 16 GPIOs when using the 34-pin connector.  The remaining available GPIO pins can be utilized through the Promira API.

The figures below provide examples into the GPIO-related modes while using an Aardvark I2C/SPI Host Adapter. Pin assignments for using the Aardvark adapter pins for GPIO include:

  • GPIO SCL - signal pin 1
  • GPIO SDA - signal pin 3
  • GPIO MISO - signal pin 5
  • GPIO SCK - signal pin 7
  • GPIO MOSI - signal pin 8
  • GPIO SS - signal pin 9
Control Center Serial Software GPIO Only Mode GPIO Only Mode for Aardvark I2C/SPI Host Adapter

 

Control Center Serial Software SPI and GPIO Mode GPIO mode when using SPI + GPIO for Aardvark I2C/SPI Host Adapter

 

Control Center Serial Software I2C and GPIO Mode GPIO mode when using I2C + GPIO for Aardvark I2C/SPI Host Adapter

GPIO Parameters

When GPIO mode is selected, only the available pins are displayed in the window. The parameters of each pin can be set by the user.

Parameters of the mode include:

  • GPIO#: Number of each GPIO signal
  • Pin#: Pin position depending on t he10/34-pin socket connector for the Promira platform or in the 10-pin connector for the Aardvark adapter
  • Value: The bit value of each pin signal

The pins have the following values:

Signal Aardvark Promira
SCL 0x01 0x01
SDA 0x02 0x02
MISO 0x04 N/A
SCK 0x08 N/A
MOSI 0x10 N/A
SS0 0x20 0x04
SS2 N/A 0x08
SS1 N/A 0x10
SS3 N/A 0x20
SS4 N/A 0x40
SS5 N/A 0x80
  • Direction: Whether the GPIO pin is in or out
  • Pull-Ups: Whether a pin in active or inactive
  • Out Set/Out Value: “Out Set” arranges the levels of the output pins where 0" and "1 are accepted. “Out Value” indicates the last known values of the output pins.
  • In Value: Indicates the last known values of the input pins

Transaction Log and Batch Mode

By using the Transaction Log feature in Control Center Serial Software, users can review all I2C, SPI, and GPIO transactions. GPIO transactions are categorized under “Mod.” and are displayed in gray.

Transaction Log in Control Center Serial Software

Users can also utilize the Batch Mode feature to easily configure GPIO functionality within a system. GPIO commands for XML batch scripting include configuring the GPIO interface, getting the value of current GPIO inputs, and setting the value of current GPIO outputs. More on the GPIO commands can be found here.

Host Adapters that Support GPIO Functionality

Promira Serial Platform

The Promira Serial Platform is a versatile and powerful host adapter that supports I2C and SPI protocols. Through its field upgradeable design, users can select from different application levels, which provide access to varying speeds, the number of supported GPIO pins, and more. Depending on the application and level, this tool can support from six to sixteen GPIO pins that also include pins normally used for I2C to send and receive signals. The specific pin configuration can be found in the Promira I2C/SPI Active User Manual. The GPIO functionality can be combined with either I2C or SPI or can be used by itself.

The number of supported GPIOs per application include:

Promira Serial Platform

Aardvark I2C/SPI Host Adapter

The Aardvark I2C/SPI Host Adapter is a general-purpose host adapter that supports I2C and SPI communication. This tool offers GPIO functionality and allows users to use the six pins that are normally used for I2C and SPI to send and receive signals. These six pins are SCL, SDA, MOSI, SCLK, MISO, and SS. The GPIO functionality can be combined with either I2C or SPI or can be used by itself.

 

Aardvark I2C/SPI Host Adapter

For further details on the GPIO functionality within Control Center Serial Software, please visit the Control Center Serial Software user manual or contact us at sales@totalphase.com.

The High-Speed Advantages of the Promira Serial Platform Connectivity

$
0
0

The Promira Serial Platform was developed by Total Phase to meet the needs of customers in the field. They needed something fast, much faster than anything Total Phase had to offer. With projects starting to require higher frequencies and a need developing for multi I/O support with the rapid adoption of dual and quad SPI applications, the Promira platform was created to meet the rising requirements of the industry at large. The tool was created as an all-in-one platform that would expand in capability as applications evolved.

Promira Serial Platform

The Promira Serial Platform is capable of interfacing with I2C, SPI, eSPI, and A2B protocols. The platform can actively emulate a master or slave in I2C and SPI protocols and act as an analyzer for the eSPI and A2B bus. The Promira platform is also able to change voltage levels with its built-in level shifter feature.  Additionally, the back-end connectivity to the host compute was upgraded to High-speed USB and Ethernet.

High-speed USB and Ethernet Connectivity Options

During the initial research and design phase of the Promira platform, customers reported a desire for increased throughput over the USB connection compared to existing tools.  They wanted the ability to program larger sets of data at faster speeds. Additionally, the ability to control the device remotely, over large distances, or inside of a complex set up and test chamber was mentioned as an important feature. The previous generation tool, the Aardvark I2C/SPI Host Adapter, only offered a Full-speed USB connection. As technology progressed and  applications became more demanding, the need to reduce USB latency started to become more common.

The High-Speed USB Port on the Promira Serial Platform

The High-speed USB port allows users to interface with the Promira Serial Platform over a direct USB connection at up to 480 Mbps. This connection is much faster when compared to the Aardvark adapter connection speed of 12 Mbps.  Not only was the speed of the connection upgraded, but a pipelined architecture was implemented.  This new architecture allows for the queuing of commands for gapless shifting and a better data streaming experience.

The greater bandwidth and pipelined architecture allow for faster interaction and lower latency between actions taken on the host computer and the Promira platform. The roundtrip latency over the USB connection is reduced to approximately 250us compared to 2ms with the Aardvark adapter. This is an 8x reduction in USB delay allowing developers better access to the bus.

 

Promira Serial Platform I/O ports

The Ethernet Port on the Promira Serial Platform

The Promira Serial Platform also comes equipped with an Ethernet connectivity option. The Ethernet port provides two different benefits to the tool.

First, setting up an Ethernet connection allows for instantaneous interaction of the tool increasing its bandwidth from the 480 Mbps of the High-speed USB to 1 Gigabit. This added speed almost completely eliminates any time needed to queue scripts via the API to the Promira Platform and connected devices. The Ethernet connection also reduces latency beyond the 250us delay seen with the High-Speed USB connection.

Second, the Ethernet port allows users to connect the Promira platform to their LAN network for remote access to the tool. Simply connect the tool to your router and interface with the tool via a wired ethernet connection or over WiFi. This option is also useful when the host PC has a limited number of ports available. The Ethernet connectivity allows users to use the Promira platform wirelessly for a simpler and cleaner setup.  Users can now access the tool and test setup remotely by connecting to the network and seamlessly interact with the Promira platform from around the world.  Alternatively, if the test set up is complex or located in a chamber, the Promira platform can be included in the set up without needing to include a laptop or have easy access for control.

Inter-byte Delay Improvements

Another benefit the Promira Serial Platform connectivity compared to the previous generation of host adapters is its significant reduction in interbyte delays. The Aardvark I2C/SPI Host Adapter is able to send up to 8 bits of data without any delays in transfer. However, if users need to transfer more than 8 bits of data, the data transfer rate starts to slow down as delays are introduced. The Promira platform, along with the free API , introduces the ability to send up to 32 bits of data with no interbyte delays. The 32 bits of data are sent in a continuous stream over 32 uninterrupted clock cycles. This gives the Promira Serial Platform an edge over other Total Phase tools when it comes to interbyte delays.

The Promira Serial Platform Is the Future of Total Phase Tools

The Promira Serial Platform is the future of Total Phase development tools and is rapidly growing in popularity among embedded systems engineers. With speed and expandability at the center of the platform, it is no surprise that the Promira platform is quickly becoming the most popular Total Phase development tool on the market.  To learn more about the Promira Serial Platform give our technical sales team a call at +1 (408) 850-6501.

Control Center Serial Software Series: Enabling Slave Mode

$
0
0

The Control Center Serial Software provides an interface for Total Phase host adapters and allows users to control and interact with I2C and SPI devices.

Total Phase host adapters offer numerous ways to test and develop I2C and SPI systems, including support for master and slave configurations. In this article, we’ll discuss how users can enable slave mode for I2C and SPI in the Control Center Serial Software.

Background on I2C vs SPI Communication

Before delving into the slave mode functionality within the Control Center Serial Software, we’ll provide some background on the I2C and SPI protocols to get an idea of how communication is handled over the bus, as both I2C and SPI utilize a master and slave paradigm.

I2C

I2C is a two-wire communication protocol that is often used to connect low-speed microcontrollers to peripheral devices, including sensors and EEPROMs. The master device is the initiator of the communication. Once the master issues a start condition, the slave devices will “listen” on the serial data line for their respective address. The master device then sends the address of the target device and a read/write flag. The slave device that has the matching address acknowledges it has received this flag and then communication can proceed. Both the master and slave can send or receive data. If the master issues a read command, the master is requesting information from the slave device and if it issues a write command, the master will send data to the slave so it performs a function. Once the communication is complete, the master will issue a stop command.

SPI

SPI is a four-wire communication protocol often used to connect high-speed microcontrollers to peripheral devices, including sensors and flash memory devices. SPI offers a simpler architecture compared to I2C in that there is a single master and does not have a minimum or maximum speed. Because it is full-duplex, meaning data can be sent and received simultaneously over the bus, it allows the data to be sent more quickly.

Each of the four wires corresponds to a specific logical signal:

  • Serial Clock (SCLK) generated by the master for synchronization,
  • Master Out Slave In (MOSI) transfers data output from the master device to the slave devices
  • Master In Slave Out (MISO) transfers data output from the selected slave device to the master device
  • Slave Select (SS)

One SPI master can be connected to multiple slave devices and the SLCK, MOSI and MISO signals can be shared by multiple slave devices. Each slave device has a unique Slave Select signal, so the master pulls low on a slave’s SS line to select a device for communication.

Testing Systems Using Slave Devices

Slave mode in the Control Center Serial Software provides an interface for users who want to configure their Total Phase host adapter as a slave device. This means the host adapter will simulate a slave device and read/respond to messages from the external master device. Both master and slave devices can receive or transmit data depending on whether the communication is a read or write command. Configuring the host adapter as a slave is helpful in testing the validity of the system as a whole and ensures that the master device is operating as expected. For instance, having the slave send messages to a master, such as a microcontroller, will allow testers to monitor its behavior.

How to Enable Slave Mode in Control Center Serial Software

For developers utilizing Total Phase tools to test and develop I2C and SPI systems, the Control Center Serial Software provides an easy-to-use interface to do so. Particularly, it offers SPI and I2C Control Modules that can configure the host adapter to operate as a master or slave.

I2C Module

To set the host adapter as an I2C slave, users will find a Slave tab on the I2C Control Module. Here, users can input the required parameters needed to enable the slave mode including:

  1. Slave Address
  2. Max Tx Bytes – the maximum number of bytes to send
  3. Max Rx Bytes – the maximum number of bytes to receive

 

Slave Address

The slave address is the I2C address that the adapter will use an I2C slave device and it always uses a 7-bit slave address. The address is specified in the 7 least significant bits. The most significant bit is ignored.

Max Tx Bytes and Max Rx Bytes

The Max Tx Bytes and Max Rx Bytes indicate the maximum number of bytes the adapter device will send and receive respectively. The adapter will not exceed the maximum number of bytes that have been specified. Inputting a “0” into this field will set the number of bytes as unlimited.

Message Entry Field

The Message entry field allows users to input a slave response message once there is an I2C transaction. This field can be set in the adapter as a response to a write request and operates the same as the I2C master message field.

Loading Data

There are multiple ways to input data into the message field. Users can manually enter data into the field or upload a binary file into the software by using the “Load” button. Users can also save any entered data from this field into a binary file by clicking the “Save” button.

When clicked, the "Set Resp" button will set the response by the slave. It is advised to set the slave response before enabling the slave to ensure valid data to all requests.

Enabling the I2C Slave

To enable the adapter as an I2C slave, click on the "Enable" button. Once the slave is enabled, the status indicator will turn from "Disabled" in red to "Enabled" in green.

Slave Mode Enabled I2C Control Module Slave mode enabled in I2C Control Module

 

Transaction Log

As requests arrive for the slave, the transaction log will be updated with the read and write actions that the slave performed.

Disabling the I2C Slave

To disable the adapter as an I2C slave device, simply click on the "Disable" button. Once the slave is disabled, the status indicator will change from "Enabled" in green to "Disabled" in red.

Slave Mode Disabled I2C Control Module Disabled slave mode in I2C Control Module

For more in-depth details on enabling the I2C slave, please visit the user manual.

SPI Module

MISO Message

The MISO (Master In, Slave Out) message is the message that the adapter will return as its response to an SPI transaction. Like the MOSI message, this message is entered in hexadecimal format.

Loading Data

There are multiple ways to input data into the message field. Users can manually enter data into the field or upload a binary file into the software by using the “Load” button. Users can also save any entered data from this field into a binary file by clicking the “Save” button.

To set the MISO message, click the “Set MISO” button. It is advised to set the MISO message before enabling the slave to ensure valid data to all requests.

Enabling the SPI Slave

An adapter will not respond as an SPI slave device until it has been enabled. To enable the adapter as an SPI slave, click on the "Enable" button. Once the slave is enabled, the status indicator will turn from “Disabled” in red to “Enabled” in green.

Slave Mode Enabled SPI Control Module Enabled slave mode in SPI Control Module

 

Transaction Log

As requests arrive for the slave, the transaction log will be updated with the read and write actions that the slave performed.

When the MOSI message is received, a MISO message is sent to the master. The transaction log will log MOSI and MISO as two separate transactions that occur at the same time.

Disabling the SPI Slave

To disable the adapter as an SPI slave device, simply click on the "Disable" button. Once the slave is disabled, the status indicator will change from "Enabled" in green to "Disabled" in red.

Slave Mode Disabled SPI Control Module Disabled slave mode in SPI Control Module

For more in-depth details on enabling the SPI slave, please visit the user manual.

Which Total Phase Host Adapters Support Slave Mode?

Both the Aardvark I2C/ SPI Host Adapter and Promira Serial Platform are capable of simulating a master and slave device for I2C and SPI protocols. The Cheetah SPI Host Adapter only supports SPI master mode.

 

Aardvark I2C/SPI Host Adapter Promira Serial Platform

The Aardvark I2C/SPI Host Adapter configured as an I2C slave device can operate up to 800 kHz and up to 4 MHz an as SPI slave. This adapter has a slave response buffer of up to 64 unique bytes.

The Promira Serial Platform can operate at much quicker speeds compared to the Aardvark adapter. As an I2C slave, the Promira platform can operate up to 3.4 MHz, and as an SPI slave can operate up to 20 MHz. The slave response is supported up to 256 bytes, several times larger than the Aardvark adapter.

Whatever the project requirements, both tools offer great performance for simulating I2C and SPI slave devices.

To learn more about how these tools can advance your own I2C and/or SPI applications, please email us at sales@totalphase.com or request a demo.

Request a Demo

What are the Differences Between an Embedded System vs a Microcontroller

$
0
0

With the rapid evolution of electronics, it is important to stay up to date with the latest technologies. A common question that is asked is: “what are the differences between embedded systems and microcontrollers?”  In this blog post, we will discuss these two technologies and answer that question.

What is a Microcontroller?

A microcontroller unit, or MCU, is often thought of as a basic computer. It is viewed as a computer because of the fundamental components used in an MCU: CPU, system clock, memory, and peripherals, all of which computers use as well. A personal computer is capable of performing multiple functions simultaneously. A microcontroller is different than a computer in the sense that it typically has only one task to accomplish at a time. Simultaneous operations with a microcontroller is not common. If more operations are needed, more microcontrollers are required. A microcontroller is often used for one very specific function in a system.

 

Microcontroller

Microcontroller

 

Where are Microcontrollers Used?

Microcontrollers are used in a plethora of different environments. A simple application where a microcontroller could be used is to control the operation of an LED light. Every time a button is pressed, the LED light will turn on. But instead of just turning on when the button is pressed, the light should turn on and off five times in a row. A microcontroller can be programmed to perform this sequence of events. The MCU could also be programmed to track the time when the button is pressed or how many times it is pressed.  A microcontroller adds intelligence into an otherwise simple application making the application capable of performing more complex tasks.

What is an Embedded System?

An embedded system on the other hand is a bit different. An embedded system is a series of electrical components that comprise a larger system. These systems have specific functions. Embedded systems are like Legos that when put together correctly build something spectacular. A single Lego by itself doesn’t do anything special but when used in a bigger project adds value and complexity to the system or structure. Embedded systems are the same. They are small building blocks that when paired together correctly result in a functioning system or process.

Embedded systems on a circuit board

Embedded systems on a circuit board

 

Where are Embedded Systems Used?

Embedded systems are used in almost every electronic device around. These systems are used in unison to come together and create a larger functioning system. Take for instance a personal computer or laptop. A computer is made up of sometimes hundreds of different embedded systems to make a useful tool. Computers are known to do many things at once. Keeping track of time, reading and writing new memory, connecting to WIFI, power consumption and charging, the ability to connect different I/O, all of these tasks are done by individual embedded systems. The amazing thing about a computer is that all of these systems work together in perfect unison making the tool useful. These systems are not only used in personal computers but a variety of different devices including refrigerators, lights, phones, cars, modems, televisions, watches, vacuums, and the list goes on.

How are Embedded Systems and Microcontrollers Different?

At the heart of most embedded systems there is a microcontroller or microprocessor running the application. Embedded systems are generally more basic and rudimentary than microcontrollers since they often do not have logic to run the system.

Let’s go back to the Lego analogy for a second.  The Legos, when put together, create a larger more complete system. Each Lego however has a specific task and use case. The embedded systems are typically told what to do by the CPU or Central Processing Unit of a computer. When the CPU tells an embedded system to do something the CPU generally communicates with a microcontroller that is part of the embedded system. Think of the microcontroller as the brains of the embedded system. Once the CPU tells the microcontroller to do something the microcontroller then directs the components of the embedded system to execute its specific tasks.

Embedded system with MCU in the middle

Embedded system with MCU in the middle

Microcontrollers are very commonly found in the center of most embedded systems and can be thought of as the brains or decision-maker of the embedded system. The MCU is programmed to communicate and direct other components within the embedded system. In a sense, it is the gatekeeper for the embedded system that tells the system what and when to do something.

Working with Embedded Systems and Microcontrollers

When working with embedded systems engineers often run into issues because of the breadth and complexity of modern-day applications. People want more capability in smaller devices.  The physical engineering that goes into embedded systems nowadays is generally done under a microscope because these systems are so small and complex. Engineers often run into integration issues implementing the embedded systems software. This is where Total Phase has brought value to the market.

How does Total Phase Interface with Embedded Systems and Microcontrollers?

Total Phase was founded on the idea of simplifying the programming and debugging phases of embedded systems development.  With some of the most popular debug and analysis tools on the market, Total Phase has made a name for themselves. People know Total Phase for their industry-leading protocol analyzers and host adapters.

Protocol Analyzers

Protocol analyzers are tools made to non-intrusively monitor bus data to provide beneficial insights into embedded systems. Total Phase specializes in protocol analyzers for monitoring I2C, SPI, USB, CAN, and eSPI buses.

Beagle I2C/SPI Protocol Analyzer

The Beagle I2C/SPI Protocol Analyzer provides a high-performance bus monitoring solution in a small and portable package. Engineers of all experience levels enjoy the insights provided by the Beagle I2C/SPI Protocol Analyzer as it helps them better understand and debug their I2C and SPI bus embedded systems.

Beagle I2C/SPI Protocol Analyzer

Beagle I2C/SPI Protocol Analyzer

 

Beagle USB Protocol Analyzers

Total Phase also has a variety of different USB protocol analyzers that range in speed and capability. The Beagle USB 5000 v2 SuperSpeed Protocol Analyzer is an all-in-one analyzer that specializes in SuperSpeed USB analysis. Whereas the Beagle USB 480 Power Protocol Analyzer allows users to monitor current and voltage levels on the VBUS, along with USB data, for a more comprehensive understanding of power consumption on the USB bus.

Beagle USB Protocol Analyzers support LPM transactions at various speeds

Beagle USB 5000 v2 SuperSpeed Protocol Analyzer

Host Adapters

Host adapters allow engineers to program and interact with their embedded systems. Total Phase host adapters are used to program microcontrollers or other chips on the board. Engineers can upload software and code to their systems with ease and speed with the proper host adapter.

Promira Serial Platform

The Promira Serial Platform is Total Phase’s most advanced host adapter on the market. With its ability to act as an SPI master at 80 MHz, this tool has quickly made a name for itself as one of the best embedded systems host adapters in the industry.

Promira Serial Platform

Promira Serial Platform

Conclusion

In the extremely fast-paced technology environment we all live in it is important to continue to learn all of the latest developments and stay up to date. Although complicated in practice microcontrollers and embedded systems at their core are very simple technologies. They are small electronic systems/chips that perform very specific tasks. These systems are used in unison to come together and create a larger functioning system. Understanding how they work with each other is vital information for beginner and expert-level engineers alike.

What are the Differences Between an Integrated Circuit and a Microprocessor

$
0
0

The introduction of integrated circuits (ICs) has revolutionized the way embedded systems operate today. By integrating transistor circuits onto a single chip, electronics developers could create advanced computing devices like laptop computers and mobile phones. When discussing how embedded systems operate, we often hear about integrated circuits and microprocessors. So, what exactly are these components, how do they differ, and how do they relate to embedded systems? In this article, we’ll provide some background on their relationship and how they have modernized the embedded systems industry.

What is an Integrated Circuit

In the early days, computers were made using vacuum tubes that made up logic circuitry. Due to its large size and expensive assembly, the first computer was not ideal for use by the masses. The invention of the transistor, which regulates the flow of current or voltage and acts as a switch for electronic signals, helped to compensate for those setbacks, but it still had its own limitations.

The invention of the integrated circuit (IC) helped revolutionize the use of electronic signals like transistors into a much smaller and lucrative design. The integrated circuit, sometimes referred to as a chip or microchip, is a semiconductor wafer often made of silicon that integrates a collection of electronic circuits, including resistors, transistors, capacitors, and diodes that interconnect to perform a given function. One single integrated circuit can include thousands to millions of such electronic circuits depending on its computing power.

integrated circuit Integrated circuit

Integrated circuits are very important in embedded systems design as they helped revolutionize and improve how electronic circuits are used. Before the IC was used, components like transistors and resistors were wired together on a circuit board. But, with the introduction of the IC, these components are now formed on a smaller, singular chip.

Today, integrated circuits are frequently used in electronics design and can be categorized as analog, digital, or a combination of the two. ICs can be used for a variety of purposes including amplifiers, video processors, computer memory, switches, and microprocessors.

What is a Microprocessor

So, is a microprocessor an integrated circuit? The answer is yes, and it is considered to be one of the most complex of its kind. A microprocessor is a computer processor that incorporates the functions of a central processing unit (CPU) on a single integrated circuit, or a single chip. It is used in a computer system to execute logical and computational tasks so other external circuits, including memory or peripheral ICs, can perform their intended functions.

Microprocessor chip on green circuit board Microprocessor chip on a circuit board

Before the microprocessor was conceived, a computer’s control and processing unit of a CPU was constructed using transistors and eventually small-scale integrated circuits; all of which were attached to a circuit board individually. The invention of the microprocessor allowed for such components to integrate together on a single chip, scaling down such technologies.

Generally, microprocessors are used in applications where the task is not predefined, such as computers or video games where the task is dependent on the user. In these cases, microprocessors are suitable as they support a variety of computing applications.

How Integrated Circuits and Microprocessors Advance Embedded Systems

Integrated circuits have paved the way to the advanced embedded systems we know and use today. The semiconductor chips that are used in devices like smartphones, tablets, or laptop computers are all integrated circuits that provide the system with the electronic circuitry needed to perform its intended function.

Microprocessors specifically are fundamental integrated circuits that embedded system engineers often use in embedded designs. The microprocessor is used to control the CPU functions of an embedded system, which performs tasks like retrieving and decoding instructions from the main memory, and using those instructions to carry out arithmetic and logic operations for other memory or I/O devices.

Debugging and Developing Embedded Systems with Integrated Circuits

Integrated circuits, like microprocessors, require a communication protocol in order to “talk to” and exchange data between various components or even other ICs within a system. Microprocessors often use protocols including I2C, SPI, or USB to execute data exchanges. With so many interconnected parts, including the microprocessor/microcontroller, memory devices, and I/O peripherals, developing and designing embedded systems can be a challenge. It’s important to ensure that each of these components are operating together to establish a correctly working system.

To determine that each component is working as expected, host adapters and protocol analyzers are helpful tools that allow engineers to test and debug systems to verify their performance. By using such tools, users can easily emulate master or slave devices, quickly program memory, and monitor the bus to find communication errors.

Total Phase offers a line of host adapters and protocol analyzers fit for a variety of project requirements.

Host Adapters

Total Phase’s host adapters, including the Aardvark I2C/SPI Host Adapter, Cheetah SPI Host Adapter, and Promira Serial Platform, allow users to interface with their I2C and/or SPI systems, and can be used for a variety of applications, including prototyping, system emulation, or high-speed flash programming.

The Aardvark I2C/SPI Host Adapter is a general-purpose host adapter supporting I2C and SPI protocols and can operate up to 800 kHz as an I2C master and slave, up to 8 MHz as an SPI master, and up to 4 MHz as an SPI slave.

The Cheetah SPI Host Adapter is high-speed SPI adapter that is capable of communicating over SPI at up to 40+ MHz as a master.

The Promira Serial Platform is Total Phase’s most advanced serial device. It is built on a field-upgradeable platform that is configurable based on a user’s I2C and/or SPI project requirements, including speed, GPIOs, slave selects, and more. Depending on the application and level, this device can support up to 3.4 MHz as an I2C master and slave, and up to 80 MHz as an SPI master, and up to 20 MHz as an SPI slave.

Protocol Analyzers

Total Phase’s line of protocol analyzers, including the Beagle I2C/SPI Protocol Analyzer and collection of Beagle USB Protocol Analyzers, allow users to gain visibility into the bus and monitor I2C, SPI, or USB (USB 2.0 and USB 3.0) communication in real-time. Users can easily view low-level bus events, bus errors, and more.

Conclusion

Both integrated circuits and microprocessors are an essential part of understanding and creating embedded systems. Integrated circuits have allowed us to scale how we utilize and incorporate transistors and other electronic circuits into electronic designs. And without integrated circuits, we wouldn’t have microprocessors. Microprocessors allow us to place CPU functionality into devices, which has made our everyday devices capable of performing advanced computations and tasks. While these components make our lives easier, creating successfully working systems can be a challenge. Having the right debugging and development tools to test and validate systems can help simplify these processes.

To learn more about how our host adapters and protocol analyzers can help debug or develop your own embedded system, please visit our website or email us at sales@totalphase.com.

 

 

Understanding the Differences Between UART and I2C

$
0
0

Communication protocols are some of the essential building blocks of an embedded system. They are what governs how data is sent over the bus, including whether data is sent serially, parallelly, asynchronously, or through a master/slave paradigm.

There are multiple forms of communication that can be used in an embedded system, including a communication protocol, such as I2C, or through a physical circuit like UART. Both are often used for similar objectives, but do have some notable similarities and differences. In this article, we’ll cover the basics of I2C and UART communication, and the differences between them.

Understanding the I2C Protocol

I2C, or Inter-Integrated Circuit, is a communication protocol often used in embedded systems as a way to transfer data between a master (or multiple masters) and a single slave (or multiple slaves) device. It is a bidirectional two-wire serial bus that uses serial clock (SCL) and serial data (SDA) wires to send and manage data between devices connected to the bus.

Because I2C operates using a serial clock, it considered to be synchronous, which allows the output of bits to be synchronized to the sampling of bits by a clock signal shared between the master and the slave.

I2C two wire bus layout.

I2C is used to connect devices like microcontrollers, EEPROMs, I/O interfaces, and other peripheral devices in an embedded system. A microcontroller is often used as the master device, and other peripheral devices are used as slave devices. Because all communication takes place on only two wires, all devices must have a unique address to identify it on the bus. By using the unique address, the master device is able to signal its read/write command to exchange communication between the two over the bus.

Where is I2C Used?

What applications use I2C? I2C is a suitable protocol for connecting short-distanced, low-speed peripherals on printed circuit boards (PCBs). Common I2C applications can include reading memory, reading hardware sensors, and accessing DACs and ADCs.

Understanding UART Communication

UART, or Universal Asynchronous Reception and Transmission, is a physical circuit in a microcontroller or single integrated circuit (IC) that is used to implement serial communication between devices in an embedded system. It supports bidirectional data transmission, including half-duplex and full-duplex operations. Because it doesn’t include a clock signal to synchronize the output bits from the transmitting UART to the sampling bits on the receiving UART, UART is considered to be asynchronous. Without a clock, the receiving and transmitting UART need to be on the same baud rate, or bit rate. This allows the system to know where and when the bits have been clocked. Additionally, the transmitting UART adds a start and stop bit to the data being transmitted.

UART two-wire diagram UART device communication diagram

In UART communication, UART devices communicate directly with one another, where one device is the transmitter and the other is the receiver. UART uses a two-wire system where the Rx and Tx pins are used to transfer and receive data. A controlling device, such as a microcontroller, sends parallel data to the transmitting UART via a data bus. The transmitting UART then transmits the data into serial data using a shift register and sends it to the receiving device using the Tx pin. The receiving UART uses the Rx pin to receive the data and then converts the serial data back into parallel data using its shift register, which is then sent back on the bus to the receiving end.

Where is UART Used?

Primarily, UART was widely used for PC-device communication, allowing devices like a mouse and keyboard to communicate with the PC. While USB has replaced UART and standardized these connections, UART is still used in some applications today. Today, we see UART being used often in microcontroller-based devices including GPS receivers or Bluetooth modules.

What are the Similarities and Differences Between I2C and UART?

Both I2C and UART are similar in that their purpose is to transfer data serial data at low data rates between devices, and both use a two-wire interface to achieve this. Both are also commonly used for short/medium distanced data transmission. I2C, however, uses a master/slave configuration that uses clock signals to help synchronize the data being read or transmitted by the devices. UART, on the other hand, is hardware that is responsible for implementing asynchronous serial data streams for point to point connection and includes no clock signal.

So, what would be the advantage or disadvantage to using either?

Advantages and Disadvantages to Using I2C vs UART

While both I2C and UART offer similar objectives in data transmission, there are reasons why one might be best over the other. I2C is flexible and useful for connecting multiple devices. It allows users to integrate multiple master and slave devices – up to 128 devices on a single bus. I2C also has flow control and performs data validation, so the integrity of the data and how it was transferred is reliable. I2C is also generally faster than UART, and can reach speed of up to 3.4 MHz. Some of the disadvantages of I2C include its increasing circuit complexity with additional master/slave setups, and is only able to operate in half-duplex, meaning data can only be transmitted in one direction at a time.

UART is often used for its simplicity in hardware implementations. It doesn’t require a clock signal, and is ideal for systems that need to send data between devices without waiting for a master poll request and generating unwanted traffic on the bus. Some drawbacks are that UART doesn’t offer multiple master/slave support, which can limit how many devices are used on the bus. Additionally, each UART baud rate should be in 10% of each other or else data can be corrupted.

Debugging and Developing I2C Systems

Communication protocols, including the widely used I2C protocol, are an essential component to a system’s performance, and having bugs and transmission errors can cause erratic or erroneous system behavior. Without the right tools, finding bus and data errors can be challenging. That’s why using debugging and development tools are essential for an embedded system engineer’s toolbox.

Total Phase offers numerous tools to develop and debug I2C systems, including host adapters and protocol analyzers, including the Aardvark I2C/SPI Host Adapter, the Promira Serial Platform, and the Beagle I2C/SPI Protocol Analyzer.

The Aardvark I2C/SPI Host Adapter is a general-purpose host adapter supporting I2C and SPI protocols and can operate up to 800 kHz as an I2C master and slave. It is often used to test I2C systems by emulating master/slave configurations.

The Promira Serial Platform is Total Phase’s most advanced serial device. With its field upgradeable platform, users can configure the device with applications that allow users access to I2C and SPI protocols, various speeds, and other capabilities. Depending on the application and level, this device can support up to 3.4 MHz as an I2C master and slave.

The Beagle I2C/SPI Protocol Analyzer can non-intrusively monitor I2C and SPI traffic in real time. It can monitor I2C up to 4 MHz and offers flexible search and filtering capabilities.

Are you currently developing I2C systems or are considering a future I2C project? For any questions on how our I2C tools can resolve your project bottlenecks, we’re happy to help. Please email us at sales@totalphase.com to learn more.

Want to learn about the differences between UART and SPI? Check out our article, “Understanding the Difference Between UART vs SPI”.

 

 

 

How Do I Claim the I2C Bus with the Aardvark I2C/SPI Host Adapter?

$
0
0

Question from the Customer:

I am working with an I2C device that will be used for lengthy write and read transactions. There are multiple masters on this bus, any of which could send and start a command, thus taking ownership of the bus.

I am looking at using the Aardvark I2C/SPI Host Adapter for this project.  How would I “claim the bus” to prevent stops from occurring between write and read transactions? Which applications could work for me?

Response from Technical Support:

Thanks for your question! We have two software applications that could serve your purpose: the Control Center Serial Software and Aardvark Software API. Both applications can be used to run commands with the “no-stop” feature.

Run No-Stop with GUI or Batch Commands

The Control Center Serial Software is an easy-to-use application that provides access to all the features of the Aardvark adapter. You have the option to manually enter commands or run commands automatically by creating an XML batch script.

Manually Enter Commands

With the GUI dialogs, you can easily set commands. To set the no-stop feature, all you need to do is check the No Stop option as shown below.

Set no-stop for Aardvark I2C messages using Control Center Serial Software

For a complete example of executing the stop command, take a look at this article - In Batch Mode, How Do I Control Stop Bits when Sending Data to an I2C Device?  It also provides an example of using batch scripts.

Batch Scripts

You can create batch scripts in XML, which can be saved and run when needed. A built-in help system describes each command via GUI, as well as functional examples of batch scripts that can be used as-is or modified as needed for your specifications.

For more information about Batch Scripts, please refer to Control Center Serial Software Series: XML Batch Scripting for Automated Tasks.

API NO_STOP Flag

The Aardvark Software API library includes a command that combines write and read functions with the no-stop condition: aa_i2c_write_read.

This Master Write-Read command (also known as Master Register Read) is a combination of two I2C transactions. Using the AA_I2C_NO_STOP allows these two calls to operate as a single I2C transaction.

  • The first API call is aa_i2c_write(). The AA_I2C_NO_STOP flag is set, as well as the device register address from which to read.
  • The second call is aa_i2c_read(), which specifies the number of bytes you wish to read.

Using the stop flag results in a single I2C transaction:

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

If the AA_I2C_NO_STOP was not used, there were would two separate I2C transactions:

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

Single API Command for Non-Stop Write Read

Using the API command  aa_i2c_write_read() would be the easiest way to execute Master Register Read. This function writes a stream of bytes to the I2C slave device, which is followed by a read from the same slave device.

This is a combination of aa_i2c_write() and aa_i2c_read(), except that these functions are performed as a single operation. The AA_I2C_NO_STOP condition is taken care internally by the state machines; it does not need to be invoked.

The syntax:

int aa_i2c_write_read (Aardvark           aardvark,
aa_u16             slave_addr,
AardvarkI2cFlags   flags,
aa_u16             out_num_bytes,
const aa_u08 *     out_data,
aa_u16 *           num_written,
aa_u16             in_num_bytes,
aa_u08 *           in_data,
aa_u16 *           num_read);

Here is an example of values to apply. In this case, the command is to read 5 bytes from the register address 0x11:

  • flags - You may use AA_I2C_NO_FLAGS since you do not have special requirements listed under the "notes" section. This API is a combination of aa_i2c_write() and aa_i2c_read(), except that these functions are performed in one atomic operation. The AA_I2C_NO_STOP condition is taken care internally by the state machines, and hence need not be invoked in your case.
  • out_num_bytes – This is the address width of the register address. In this case, because it is 1 byte, the parameter must be set as 1).
  • out_data - The register address, which in this example is 0x11.
  • num_written - This is updated by the APIs about the total bytes of register address actually sent (this parameter is used to verify if the register address was sent properly on the bus)
  • in_num_bytes - Number of bytes to be read (5 in this case)
  • in_data pointer - The data read from the register location is stored in the pointer specified location.
  • num_read - The total number of bytes actually read from the register address is updated by the API. This parameter is used to verify if the function was successful in reading the desired number of bytes.

For more information, please refer the API Documentation section 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:

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


What is SMBus?

$
0
0

SMBus, or System Management Bus, is two-wire interface often used for low-speed system management communication between devices on a motherboard. This bus was developed using the foundations of the I2C protocol, so SMBus and I2C hold many similarities and can even inter-operate on the same bus. In this article, we’ll cover more on the background of the SMBus, how SMBus operates, where it’s used, and ways to debug and develop SMBus systems.

Background of SMBus

SMBus was originally conceived by Intel in 1995 and was initially created as a communication protocol for Smart Batteries and other system and power management components. While developing hand-held and mobile devices, Intel determined there was a need to extend the functionality of their chipset and attach batteries to the system, while also limiting the number of the pins. Intel determined a low-speed serial bus such as I2C would meet this requirement. By utilizing I2C’s core operations, including device addressing, start and stop conditions, and collision detection and correction, and further modifying certain electrical characteristics to meet the battery requirements, SMBus was developed.

Eventually, ten promoter companies, including Intel and Duracell, formed the Smart Battery System Interface Forum (SBS-IF), later renamed to System Management Interface Forum (SMIF), to further maintain and oversee Smart Battery System (SBS) specifications and SMBus specifications. SMBus was also incorporated into the ACPI (Advanced Configuration and Power Interface) specifications as the bus to communicate with the Smart Battery System and other system components.

How SMBus Operates

SMBus is used as a means for system component chips, including simple and power-related chips, to communicate between each other within a system. More specifically, it allows for batteries to communicate with other system components, such as the CPU or other power-related components.

Because SMBus is based on the I2C protocol and uses I2C as a physical layer, it uses a two-wire interface and device addressing to communicate; each device has a unique address and may be addressed by any other device on the network. Unlike I2C, SMBus provides a control bus in its communication scheme instead of using individual control lines, helping to reduce pin count and system wires.

In SMBus communication, there are three types of devices used: a host, a master, and a slave device. The host device is a specialized master that acts as an interface to the system’s CPU, but it is not always required; some systems, such as a simple battery charging system, can be host-less. A master device initiates the communication, drives the clock, and terminates the transfer. A device may be designated to be only a master or it may be a master-slave, in which it can act either as a master or slave device. There also may be more than one master on an SMBus, but only one may master the bus at any given time. In the instance that two devices master the bus simultaneously, SMBus provides an arbitration mechanism that relies on the wired-AND connection of all SMBus device interfaces to the SMBus. Slave devices respond to its address and commands, and can send and receive data to and from a master device. A device can be designated exclusively as a slave, or it’s possible for the slave to act as a master in certain instances.

Like I2C, each slave on the SMBus is assigned a unique 7-bit slave address. A read/write bit is also appended to the slave address to define whether the device is reading or writing the message being sent over the bus. Devices are required to acknowledge their own address, so when a device recognizes its address, it will respond to the command. In the case of SMBus slave address conflicts, SMBus supports Address Resolution Protocol, or ARP. When the host detects two devices with the same slave address, the ARP process will dynamically assign a new unique address to the slaves. ARP allows the devices to be used immediately, without the need to restart the system.

SMBus uses two wires for communication: the SMBDAT wire, which transfers serial data, and the SMBCLK wire, which acts as the serial clock. The master drives the SMBCLK, which can range from 10 kHz to 100 kHz, but either line can drive the SMBDAT. Both of these lines are bidirectional. SMBus also provides the option to add an alert signal, called SMBALERT, which allows devices to request attention from the host.

Similar to I2C, the SMBus data packet includes a Start bit, 8 bits of data (containing a 7-bit address and Read/Write bit), an ACK/NACK bit, and a Stop bit. SMBus data transfer can use all or some of the various different SMBus functions or protocols when transferring messages. Some include Quick Command, Send Byte, Write Byte, Write Word, Read Byte, Read Word, Process Call, Block Read, Block Write, and Block Write-Block Read Process Call. SMBus also supports packet error checking, or PEC, to improve communication reliability. This is performed by adding a packet error code at the end of each message.

As for the electrical component, SMBus devices may be powered by the bus Vdd (1.8 to 5 volts, ±10%) or by another power source, such as VBUS, and can operate coincidingly provided they adhere to the SMBus electrical specifications for their class.

Where SMBus is Used

SMBus technology is used in Smart Battery Systems, or SBS, which is often implemented in portable devices such as laptop computers, mobile devices, and cameras for efficient battery management. Smart Battery Systems consist of a host, smart charger, and a smart battery and uses SMBus in order for these components to communicate with each other and the rest of the system.

laptop with charger plugged in

Smart Battery Systems are often beneficial to the battery life in portable devices. By using SBS, the battery can inform the charger about multiple aspects, including its capacity, ideal charging current, maximum charging time, and much more. Plus, because there is more precision with these variables, a Smart Battery doesn’t require recharging as frequently.

SMBus is also commonly used in motherboards of personal computers for system management mode and is used for communication devices, including switches, temperature sensors, and smart batteries.

Developing and Debugging SMBus and I2C Systems

When developing SMBus systems, using the right debugging and development tools is crucial to ensure the system is operating as expected. Total Phase offers multiple tools to debug and test SMBus communication between devices.

Because SMBus is based on the I2C protocol, Total Phase I2C tools, including the Aardvark I2C/SPI Host Adapter, the Promira Serial Platform, the Beagle I2C/SPI Protocol Analyzer, and the I2C/SPI Activity Board, are able to assist with the development of your SMBus product or system.

I2C Host Adapters

The Aardvark I2C/SPI Host Adapter and Promira Serial Platform are host adapters that support I2C master and slave configurations to test and develop I2C systems. Because SMBus is a derivate of I2C, these host adapters also support interfacing SMBus systems. Users can utilize these tools to emulate a master SMBus device or communicate with a SMBus slave device.

Promira Serial Platform

I2C Protocol Analyzers

By using the Beagle I2C/SPI Protocol Analyzer, users can passively tap onto the SMBus and display and decode the bus traffic occurring between the Aardvark I2C/SPI Host Adapter and device. SMBus decoding can be enabled for the whole bus or for individual device, and users can perform transaction-level and class-level parsing of SMBus data using this tool with the Data Center Software.

I2C Activity Boards

The I2C/SPI Activity Board is a helpful tool for testing I2C and I2C-based protocols. By providing known working slave devices, this tool allows users to differentiate between hardware and software bugs. With the I2C port expander, this board can be used to test and develop SMBus devices.

I2C/SPI Activity Board

For more information on how Total Phase tools can assist with your own I2C/SMBus project, please email us at sales@totalphase.com.

I’m Having a Problem Writing to an I2C Device – How Can I Get the Details to Analyze and Fix the Problem?

$
0
0

Question from the Customer:

I am trying to use the Promira Serial Platform to talk to an I2C device.  I am following the instructions in the Promira Serial Platform Quick Start Guide, yet I cannot successfully complete a master write.

It appears that the data field is blank:

"2021-01-17 13:43:59.727","I2C","W","M","--S","400","0X49","0",""

However, I do see data in the fields when I try using SPI:

"2021-01-07 11:38:09.853","SPI","","","","","","","SPI Bitrate Set to: 1000"
"2021-01-07 11:38:09.888","SPI","","M","","","","","SPI Config: Mode = 0, Bit Order = MSB, SS_Polarity = Low"
"2021-01-07 11:38:14.350","SPI","","M","","","","","SPI Config: Mode = 0, Bit Order = MSB, SS_Polarity = Low"
"2021-01-07 11:38:14.405","SPI","W","M","M0ML","1000","","16","00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF"
"2021-01-07 11:38:14.405","SPI","R","M","M0ML","1000","","16","00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"

Maybe the software is not configured correctly - the Control Center Serial Software does not appear to write any data at all when using the I2C protocol; I can only get this to work with the SPI protocol. How can I find the cause so I can fix this problem?

Response from Technical Support:

Thanks for your question! There are a few possibilities of what may need to be resolved for your setup. With the information provided, we recommend two ways to look for the root of the problem: perform some basic checks, and if necessary, monitor the I2C bus traffic.

Basic Problem Check Points

A basic and essential starting point is verifying that the slave address, the operating voltage, and the operating bitrate are compatible with the target device.

For guidelines about configuring the Promira platform to provide the correct voltage level, take a look at our knowledge base article: Programming an I2C EEPROM Using the Promira Serial Platform and the Control Center Serial Software. This article explains how to program an I2C EEPROM using the Promira Serial Platform, and the Control Center Serial Software. Here is a summary of the steps to follow:

  • Use the specifications from the datasheet of the device, and then execute the appropriate commands in the Control Center Serial Software.
  • Write data to the device.
  • Read back data to verify the data is correct.

This article uses the Microchip 24FC512 I2C EEPROM with the EEPROM Socket Board - 10/34. You can modify the steps as needed for your setup.

Analyze Signal Integrity

Another possibility is that the data is corrupted, has some interference, or other issues that affect data.

For a close look at the data, including real-time diagnostics and analysis, we recommend using the Beagle I2C/SPI Protocol Analyzer and Data Center Software with your setup. Used together, these tools can monitor the flow of data on the bus, thus providing real-time monitoring along with diagnostics and communication.

For an example of sniffing data and running diagnostics, take a look at this video:

This video shows using the Aardvark I2C/SPI Host Adapter and the Beagle I2C/SPI Protocol Analyzer to monitor and prototype an I2C-based system.

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

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

How Do PMBus vs SMBus vs I2C Compare?

$
0
0

SMBus, PMBus, and I2C protocols are communication protocols used for inter-device communication in embedded systems. While these protocols are similar in many ways, including their physical layer, there are also multiple differences in how they operate and where they are used.

Because the SMBus standard is based on the I2C protocol, and PMBus is an extension of SMBus, you might be wondering more about the relationship between the three. In this article, we’ll provide a high-level overview of SMBus, PMBus, and I2C, and how they relate and differ.

About the I2C Protocol

The I2C protocol is a commonly used communication protocol in embedded systems. I2C communication requires two wires, including the Serial Data Line (SDA) and Serial Clock Line (SCL). This configuration reduces the cost and complexity of the circuit as additional devices are added to the system. Because only two wires are used, I2C incorporates device addressing and acknowledgments that allow the master and slave devices to effectively communicate. Each slave device is assigned a 7-bit address. By using this address, the master device can select which device to talk and can determine whether or not the slave device received the message.

Due to I2C’s benefits, including its simplistic two-wire interface and relatively low cost to implement, multiple other communication protocols are built using its foundation. For instance, SMBus, or System Management Bus, is a derivative of I2C and includes multiple similarities.

Comparing SMBus to I2C

SMBus is a two-wire interface often used for low-speed communication between devices within a system, including Smart Batteries and other system and power management components. SMBus was created as a means for expanding the functionality of chipsets and in-system batteries within hand-held and portable systems while also reducing the number of pins required for effective communication.

SMBus is based on the I2C protocol. SMBus utilizes the physical layer of I2C and uses its core operations, including the two-wire interface, device addressing, collision detection and correction, and start and stop conditions. However, SMBus modifies timing, protocol, and certain electrical characteristics in order to satisfy specific battery requirements.

green PC motherboard PC Motherboard

SMBus is a favorable communication protocol for system and power management components because of how data is sent over the bus and its need for a limited number of wires and pins. SMBus can often be used for PC motherboards, and Smart Battery Systems, or SBS, which is often implemented in portable devices such as laptop computers, mobile devices, and cameras. For SMBus communication, a host, master, and slave device are used. The host, which can sometimes be excluded in certain instances, is a specialized master that acts as an interface to the system’s CPU. Similar to I2C, the master initiates and terminates communication over the SMBDAT data wire, and also drives the clock over the SMBCLK clock wire. SMBus also includes an optional interrupt wire, SMBALERT#, so slave devices can initiate communication to the host. Each device also has a 7-bit unique address used to acknowledge commands from the master device.

Specific to SMBus, this protocol has functions or protocols used to transfer messages and more information on these can be found here. Additionally, unlike I2C, SMBus supports packet error checking, or PEC, to improve communication reliability and does this by adding a packet error code at the end of each message. SMBus can reach a maximum clock speed of 100 kHz and has built-in timeouts at 35 ms.

In terms on compatibility, I2C and SMBus can generally be implemented within the same system, but there are some differences in terms of speed and electrical characteristics that are important to note, as summarized here.

While SMBus is built on I2C, PMBus is another communication protocol often used for inter-device communication, and is based on SMBus. So, what is PMBus and how does it differ from SMBus?

Comparing PMBus to SMBus

PMBus is an extension of SMBus, and is a low-cost protocol used for communication between power-management devices. PMBus was created as power supply and semiconductor companies sought to redefine power management within embedded systems, including creating a more efficient way to communicate with their power systems. Additionally, they wanted a way to configure the power supply for a specific task and monitor the status/overall health of the power system. Thus, PMBus was created and defines a set of commands and data structures required by power control and management components.

Power supply Power Supply

Similar to SMBus, PMBus communicates bidirectionally over a two-wire interface, and includes a data signal, clock signal, and an optional alert signal. In addition, PMBus also specifies a control line for turning the slave device on and off. PMBus dictates a maximum bus speed of 400 kHz and has built-in timeouts important for critical systems.

A PMBus system includes a system host/bus master and slave device, or PMBus device. A host device can be a PC or microcontroller and a PMBus device can include an integrated circuit, power converter, or power supply. Like SMBus, a system can have multiple masters, as well as multiple slaves. A master directs communication to a single slave at a time by using a unique 7-bit address, similar to the slave addressing scheme in I2C and SMBus. For a more robust communication, PMBus also supports alert-based monitoring and PEC (packet error checking).

While PMBus uses some of the SMBus protocols, it adds multiple new functions. PMBus features support for configuration and control, monitoring, and fault management functions. The PMBus command layer provides a set of 256 commands that the host microcontroller can use to instruct slave PMBus devices.

Developing and Debugging I2C, SMBus, and PMBus Systems

Total Phase offers numerous tools for debugging and developing I2C-based systems, including the Aardvark I2C/SPI Host Adapter, the Promira Serial Platform, and the Beagle I2C/SPI Protocol Analyzer.

The Aardvark I2C/SPI Host Adapter and Promira Serial Platform are both host adapter tools that allow users to emulate both I2C master and slave devices to help test their I2C developments in a variety of ways. Additionally, because SMBus and PMBus are based on the I2C protocol, these tools are also compatible with SMBus and PMBus protocols.

This means users can use these tools to interface with their SMBus and PMBus systems, including creating and reading messages and validating system responses. For SMBus systems, users can emulate a master SMBus device or communicate with a SMBus slave device. SMBus commands can also be sent over the bus and validated. For PMBus systems, users can also emulate a master or slave PMBus device, but PMBus commands will need to be implemented by the user.

Aardvark I2C/SPI Host AdapterPromira Serial Platform

Additionally, users can parse and decode SMBus data using the Beagle I2C/SPI Protocol Analyzer. SMBus decoding can be enabled for the whole bus or for individual device, and users can perform transaction-level and class-level parsing of SMBus data using this tool with the Data Center Software. While PMBus decoding is not currently supported by this analyzer, users can monitor the I2C portion of PMBus by connecting the lines directly to the Beagle I2C/SPI analyzer and parse/decode them using the Beagle Software API. The other two lines CONTROL, SMBALERT# cannot be monitored.

Beagle I2C/SPI Protocol Analyzer

For more information on how our I2C host adapters and protocol analyzers can help debug and develop your own I2C, SMBus, or PMBus system or device, please contact us at sales@totalphase.com.

 

How Can I Filter Data to Only Grab the Data that Is Delivered to a Specific Endpoint?

$
0
0

Question from the Customer:

I am using the Beagle USB 12 Protocol Analyzer with Beagle Software API (python) to grab data. My device outputs data very quickly through Endpoint 1. However, I only need the IN data that is output by Endpoint 3, which delivers far less data.

The API example I started with is written very well, but I have not found information about grabbing IN data from a specific Endpoint. My questions:

  • Is there a solution to make this work?
  • As an alternative, is there another way to grab IN data from interrupts, rather than constant polling?

Response from Technical Support:

Thanks for your question! For your setup, hardware filtering would provide the results that you need. The Beagle USB 12 analyzer does not support hardware filtering. However, we have other protocol analyzers than can do the job for you. We will go over the advantages of hardware filtering, how it can be implemented with an API function or with another software tool, and recommend a protocol analyzer to support your goals.

Advantages of Filtering Data Packets with a Hardware Filter

Hardware filters provide the ability to suppress data-less transactions. When possible, the hardware filters discard all the packets that meet the filtering criteria. These filters can save a significant amount of capture memory when used. Filtering is highly recommended when the capture-memory capacity is limited.

Another benefit of using hardware filters is the ability to reduce the amount of traffic between the analysis computer and the Beagle protocol analyzer. This is useful when the analysis computer has a hard time keeping up with the bandwidth requirements of the Beagle protocol analyzer that is being used.

For your requirements, we recommend the Beagle USB 480 Power Protocol Analyzer for your project.

How the Beagle USB 480 Power Protocol Analyzer Works

The Beagle USB 480 Power Protocol Analyzer is a non-intrusive monitor for High-speed, Full-speed, and Low-Speed USB 2.0 (480 Mbps / 12 Mbps / 1.5 Mbps). You can implement real-time USB class-level decoding by using the Beagle USB 480 Power Protocol Analyzer with the Data Center Software. Two capture modes are available, as well as real-time and delayed-download, high-speed USB chirp detection, robust automatic speed detection, advanced triggering, multiple digital inputs and outputs for synchronizing with external devices, and VBUS current and voltage monitoring.

This Beagle 480 analyzer can also detect suspend/resume events and unexpected signals. It provides high-performance, real-time analysis, current and voltage monitoring, plus the option of advanced state-based triggering. These features enable correlating USB data transactions with current and voltage measurements in real time.

You can also call an API function, Enable Hardware Filter (bg_usb2_hw_filter_config, to invoke hardware filtering. For more information, please refer to the chapter API Documentation in the Beagle Protocol Analyzer User Manual. For an overview of using the Data Center Software for capturing and filtering data, watch this video:

There are two versions of the Beagle 480 Power Protocol Analyzer: Standard and Ultimate Edition. Both versions provide the following:

  • Current/Voltage Monitoring – this feature is available only in the Beagle USB 480 Power Protocol Analyzer Standard and Ultimate
  • Real-time graphing of VBUS current and voltage values
  • Interactive and bi-directional correlation of current/voltage values with USB data
  • High-performance HW buffer
  • 256 MB capacity, which can capture volumes of pre-trigger data.
  • Large circular buffer

In addition, the Ultimate Edition of the Beagle USB 480 Power Protocol Analyzer provides:

  • USB 2.0 Advanced Triggering Capabilities
  • Ability to create state-based and flexible trigger conditions based on data patterns, packet types, error types, events, and other criteria
  • Hardware packet filtering
  • Up to eight independent states and six matches per state for USB 2.0 captures
  • Digital inputs and outputs to synchronize with oscilloscopes or logic analyzers

For a quick view of the capabilities of other Total Phase analyzers and devices, you can compare your system requirements to the main features listed in our USB Analyzer Product Guide.

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

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

What is PMBus?

$
0
0

PMBus, or Power Management Bus, is two-wire interface that defines the management of power subsystems. This bus is an extension of the SMBus protocol, so PMBus and SMBus hold many similarities. In this article, we’ll provide a high-level overview of the background of PMBus, how PMBus operates, where it’s used, and ways to debug and develop PMBus systems.

Background of PMBus

The PMBus specification was released in 2005 as a way to help redefine power management within embedded systems. Before PMBus, many power supply and semiconductor companies felt there was a lack in ability to efficiently communicate with their power systems. As a result, various power supply and semiconductor companies collaborated to create the PMBus standard, which would allow system developers to configure the power supply for a specific task and to monitor the status/overall health of the power system. Currently, there are over 50 companies who oversee the development of PMBus specifications, and they are formed as PMBus-IF, or Power Management Bus Interface Forum. PMBus-IF is also a subgroup under the System Management Interface Forum (SMIF).

With the need for an industry standard protocol for power communication, PMBus developers determined that the SMBus protocol would be most efficient and cost effective to base the PMBus standard. SMBus it built on the I2C protocol and was created as a means to manage Smart Batteries and other system and power management devices. SMBus is low cost like I2C, but is more robust in its capabilities and features.

Because PMBus is an extension of the SMBus protocol, it shares much of its physical layer and how the bus operates. However, PMBus defines a specific set of commands and data structures required by power control and management components.

How PMBus Operates

Physical Layer/Transport

PMBus is a low cost, two-wire interface that is an extension of the SMBus standard, which is built from the I2C protocol. Similar to SMBus, PMBus requires a minimum of two wires for communication, including the clock signal, SMBCLK, and data signal, SMBDAT. Optional signals, which would be traded for two GPIO pins, include the CONTROL and SMBALERT# signals. The CONTROL signal acts as a hardwired on/off signal, and SMBALERT# is used to notify and get the attention of the master or system host; this alert signal is often used in the event of a fault condition. The Write Protect (WP) signal is an additional optional signal that is used to prevent unwanted data changes.

PMBus supports a more robust protocol compared to I2C since PMBus provides timeouts and optional packet error checking, or PEC, to enhance data integrity. Timeouts prevent slower slave devices from holding the clock line longer than the specified timeout interval, avoiding bus hang-ups. PEC bytes are generated using a CRC-8 algorithm used to validate the integrity of a transaction, which is often critical in power-management systems.

PMBus supports a maximum bus speed of 400 kHz, and because of the built-in timeouts, all PMBus devices support a minimum bus speed of 10 kHz.

Like SMBus, PMBus includes a system host/bus master and slave device (PMBus device) for communication. A master is any device that initiates transmission and drives the clock. There can be multiple masters on the bus, but only one device can master the bus at a given time. A master device can be a PC or microcontroller and a slave device can include an integrated circuit, power converter, or power supply. In certain instances, where a slave determines a fault, a PMBus device may temporarily become a master device and communicate with the host using the SMBus host notify protocol. A master directs communication to a single slave at a time by using a unique 7-bit address, similar to the slave addressing scheme in I2C and SMBus. This provides 100 possible device addresses after allowing for reserved addresses.

Data Formats

Similar to I2C, PMBus is a variable length packet of 8-bit data bytes. The basic data packet structure for PMBus includes an Address Byte which comprises of a 7-bit address, ending with a 1-bit Read or Write signal. Then follows an 8-bit Command Byte including the Command Code, following with one or more 8-bit Data bytes. Optionally, there may be an 8-bit PEC byte as well. Each byte includes their own receiver acknowledge, and each transaction is enclosed between a Start and Stop bit from the host.

Electrical

The PMBus electrical interface follows similarly to the SMBus specification. For supply voltage requirements, the operating voltage range (VDD) may be 3 V to 5 V ±10% (2.7 V to 5.5 V).

The required pull down current is 4 mA for 400 kHz PMBus devices.

PMBus Commands

PMBus defines a set of commands that are specifically targeted for power control and management components to ensure the system is operating correctly. These commands allow the system to perform configuration, control, status monitoring, fault management, and information storage (inventory, user data).

PMBus devices must support the Group Command Protocol, which is designed to allow several PMBus-compliant devices to simultaneously execute commands. With this protocol, devices can receive the same or different command, but only one command can be sent to any a device in one Group Command packet.

PMBus commands are one-byte command codes, which allows for 256 commands that can be sent and read over the bus. Every command packet contains an address byte, followed by a command byte, and then either followed with zero or more bytes of data. Optionally, there also may be an additional PEC byte.

Additionally, to support certain commands of the PMBus command language, devices must support the Block Write-Block Read Process Call. PMBus supports block writes and reads up to 255 bytes in length compared to the 32-byte limit of SMBus.

Where PMBus is Used

PMBus has been increasingly used for digital power management within systems. PMBus works with a variety of power management products, such as AC-DC power supplies, isolated DC-DC break converters, non-isolated point-of-load (POL) converters, supply sequencers and point-of-load voltage programmers, and monitors and fan controllers.

Close-up of a power supply device

Developing and Debugging PMBus and I2C Systems

Total Phase offers a variety of debugging and development tools for I2C-based systems, including the Aardvark I2C/SPI Host Adapter, the Promira Serial Platform, and the Beagle I2C/SPI Protocol Analyzer. And because PMBus is based on I2C, some of our tools offer certain capabilities in helping developers test and debug their PMBus systems.

By using the Aardvark I2C/SPI Host Adapter or Promira Serial Platform, users can emulate a master or slave PMBus device. PMBus commands will need to be implemented by the user.

Aardvark I2C/SPI Host AdapterPromira Serial Platform

While PMBus decoding is not currently supported by the Beagle I2C/SPI Protocol Analyzer, users can monitor the I2C portion of PMBus by connecting the lines directly to the Beagle I2C/SPI analyzer and parse/decode them using the Beagle Software API. The other two lines CONTROL, SMBALERT# cannot be monitored.

Beagle I2C/SPI Protocol Analyzer

Also wondering how we support SMBus? Learn how to get started debugging and developing SMBus systems using Total Phase tools here.

For more information on how Total Phase can help develop your I2C or PMBus applications, please email us at sales@totalphase.com.

 

 

Viewing all 822 articles
Browse latest View live