Category: News

MCCI has released a new version of our open-source Python API library for RedwoodComm RWC5020B and RWC5020M testers. The MCCI rwc-python-api library, available on GitHub, gives Python programs full access to all the features of the RWC testers, using either serial port or Ethernet connections.

The library supports RedwoodCommm firmware versions v1.150 to v1.305.

Contact MCCI via email for more information.

In a previous post, we discussed MCCI’s USB C® support in TrueTask USB, our embedded USB host and device stacks. This post covers some features of our implementation.

Our Type-C implementation approach emphasizes reliability and robustness.

• We avoid conditional compiles (#if) in our code. We allow them in our header files to adjust to the target processor using abstract types; and we have certain macros for debugging that expand differently in debug builds than in release builds. But product configuration is generally accomplished at link time rather than at compile time; this greatly reduces the number of separate compiles needed for checking the configuration space, and greatly increases the readability of code by reducing the compile-time configuration parameters.
• We implement our finite state machines as tables of functions, rather than as large switch statements. The Type C Connector specification has seven state diagrams for different kinds of products (Source, Sink, Sink with Accessory, DRP, DRP with Accessory and Try.SRC, DRP with Accessory and Try.SNK, and Charge-Through). Implementing the FSM with a giant switch statement would be less typing, but doesn’t allow the compiler to discard unused states unless we use #if. Using function tables allows different FSMs to share functions as needed.
• We further harden the implementation by representing the allowed transitions in the state tables, rather than embedding them in the code. For clarity, the state functions still request the next state by name; but this state must be one of the transitions allowed in the FSM description; otherwise the Type C FSM goes to error recovery (which puts the Type C port into a safe state).
• We are very careful to keep layers separate. The Type C layer knows nothing about the TCPC; code in that layer can’t include the header files because they’re not in the #include path. The TCPC implementation, in turn, is unaware of how registers are accessed at the low level; it uses an asynchronous abstract driver to reach its hardware.
• As mentioned in the previous post, we use a micro virtual-machine to access the TCPC registers. This allows simple register operations to be chained together, with simple logic operations, without the tedious and error-prone process of writing callbacks for each asynchronous register access. Programmer tedium is important to minimize in software of this complexity; otherwise, attention will wander and errors will occur. Writing asynchronous code with lots of callbacks is in any case hard to do, and hard to maintain; it becomes very hard to figure out what is going on.
• We implemented a TCPC register-access log recorder and a careful log display routine, to make it easier to debug problems.

Interested in embedded USB Type C support? Mail us at sales@mcci.com, and our engineers will help you understand all the options.

We’ve recently added complete USB C® port support in the TrueTask® USB / MCCI USB DataPump® portable USB host/device software platform.

Here are some of the key features:

• Explicit finite state machines that are identical to the FSMs in the USB Type C Cable and Connector Specification Revision 2.0. Why? It makes it much easier to debug systems if you can refer back to the canonical specification. Interesting because? Many port controllers, including those based TCPC, incorporate parts of the canonical FSM in their own function. It’s tempting to elide the standard state transitions, but this makes problems much harder to debug, because you can’t refer back to the specification.
• TCPC separated from Type-C FSM. Why? Type C and TCPC are different specs, and keeping them separate makes it easier to correlate code to the relevant spec. Interesting because? The TCPC spec doesn’t really have this concept of separation; see previous point. Further, there’s no requirement to conform to TCPC in implementations; by keeping TCPC separate, we can easily implement drivers for different port-controller models.
• TCPC implementation separated from register access mechanism TCPC can be implemented with direct register accesses or via serial register access busses such as I2C or SPI. This complicates abstraction a lot, if you’re designing a software package to operate in environments from bare iron to sophisticated kernel environments like Windows or Linux. MCCI uses a micro-VM to handle register accesses, which conveniently hides all the details from the TCPC driver.
• Ready for USB Power Delivery. PD depends very much on the Type-C implementation. Our architecture explicitly allows for activating (and deactivating) PD behavior at the appropriate moments in the Type-C FSMs.

Our first customers are using the Faraday FUSBTCPD210 IP and the Maxim Integrated MAX25430 IP blocks.

Interested in embedded USB Type C support? Mail us at sales@mcci.com, and our engineers will help understand all the options.