Last year was a very busy year for us in the IoT area, as well as in our USB System Software and Development Tools. High points include:
This business has really expanded over the last few years. In addition to offering specialized USB test tools, we now have additional tools for Bluetooth and video testing.
- USB Switches
- Model 3411 8 Gbps Loopback Device
- Traduci Bluetooth Test Platform
- Microsoft Ambient Light Test System
- Tanager Video Display Path Tester
2021 is behind us, and 2022 is ahead. Here’s what’s going on at MCCI.
Our activities right now are divided into three main categories:
- USB system software (TrueTask® USB / MCCI USB DataPump®)
- Development Hardware (mostly for USB)
- Internet of Things (IoT)
Many of the items in these categories merit blog posts of their own. Some of them already have but many do not.
To keep the length a little more tolerable, I’ve broken this up into a series of posts, one for each major topic. To make the reading a little more interesting, I’ve added some teasers about our plans for 2022.
If you have any questions or want more details, please send us an email, and one of our engineers will get right back to you.
Want to move LoRaWAN traffic for an IoT project while earning a little cryptocurrency on the side? Or want to jump into the world of Helium HNT Mining, backed by expert support? Want a greener approach to blockchain than burning electricity for proof-of-work?
We might have the product you need.
Introducing the Heltec HT-M2808 Helium Mining Hotspot, a small (less than 5″ x 5″), professional, all-in-one hotspot with everything you need to get started. After a simple setup with the Helium phone-based app, the hotspot will start moving LoRaWAN traffic and mining Helium Network Tokens (HNT). Designed by LoRaWAN hardware experts at Heltec Automation, it’s backed by MCCI’s team of LoRaWAN system and deployment experts. We can’t guarantee your earnings, but we can guarantee that we’ll help you get the best possible results from your hotspot.
- A Sensirion SHT31-DIS-F temperature/humidity sensor, with PTFE membrane protection.
- A Sparkfun Qwicc connector, allowing access to a large variety of sensors, LCDs, relays and more, via I2C.
MCCI has added support for the Nvidia Tegra Jetson Nano XUSB device controller to the MCCI USB DataPump®. We support the full feature set of the XUSB IP block, including bulk, interrupt and control transfers, including superspeed, high speed and full speed operation. Combined with MCCI’s UVC 1.5 support, multi-stream support, and multi-function support, this makes an excellent platform for implementing advanced webcams. The DataPump allows zero-copy video streaming data paths, for maximum throughput. High-level APIs separate kernel and user mode functionality cleanly and efficiently.
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
switchstatement 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
#includepath. 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 email@example.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.
Interested in embedded USB Type C support? Mail us at firstname.lastname@example.org, and our engineers will help understand all the options.