Picture of Catena 4802

Catena 4802 combines Qwicc, Temperature, Humidity with Modbus

Our new MCCI Catena 4802 builds on our popular MCCI Catena 4801 — a minimal RS-485/Modbus/Mbus device with LoRaWAN support — adding two important features.

  • 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.

Continue reading

Nvidia Tegra Jetson Nano support

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.
Continue reading

Open source Python API for RWC LoRaWAN Testers

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.

Type C Support in TrueTask® USB (part 2)

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.

Type C Support in TrueTask® USB

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.

MCCI supports pi64.win project with USB drivers

MCCI recently has invested a lot of energy supporting the pi64.win project. This project has a simple (and possibly silly-sounding) goal: get “real” Windows 10 running on a Raspberry Pi 3.

Many people have posted about the technical advances that have made this possible. Here’s a partial list.

  • The Raspberry Pi 3 supports the 64-bit ARM64 architecture.
  • Microsoft ported Windows 10 IoT Core (as a 32-bit operating system) to the Raspberry Pi, but targeted using the system for deploying embedded applications (kiosks, single-function computers). They omitted the features that make Windows 10 desktop a general-purpose system. (MCCI did the USB drivers for that project.)
  • Microsoft ported Windows 10 desktop to ARM64 systems. In this port, they included the key low-level drivers, apart from USB, needed for the Raspberry Pi.
  • Microsoft open-sourced the key ACPI / UEFI code needed to boot Windows 10 on a 32-bit Raspberry Pi.
  • Andrei Warkentin then adapted that and make a real ARM64 UEFI BIOS — this enables booting all kinds of “professional” operating systems on the Pi, not just Windows 10. He also managed to make USB work “well enough” to support keyboard and mouse — kind of important for setting up the BIOS!
  • José Manuel Nieto Sánchez organized a group of volunteers, and wrote an tool that would prepare an SD card with the required information from a Windows distribution, available through Windows Insider, MSDN, and other sources for non-commercial use.
  • Bas Timmer posted simple drivers that were enough to get Windows through the boot.
  • The group convinced Microchip to release ARM64 drivers for the USB Ethernet controller that’s on the Pi 3 mainboard.
  • Finally, the group hammered on me until I agreed to take the time to bring up the MCCI host stack (TrueTask USB) on ARM64.

The result was a flurry of world-wide attention. Perhaps predictably, there has been a lot of grumbling about performance. On the other hand, it looks a great demo for MCCI drivers; almost everything tested works. (It’s also a good demo for MCCI’s portability techniques; after four days of wrestling with the build system, the very first build we put on the hardware was the final version, apart from changing the version.)

MCCI has also put a lot of effort into organizing a website (pi64.win) and a discussion site (discourse.pi64.win) for the community, in collecting statistics, running the Twitter feed (@Pi64Win), and helping to publicize the effort.

So, the New York City question is: why do it? What’s your angle?

Of course, there is the basic commercial reason: to demonstrate that our drivers really are industrial strength in 2019. It was a big deal that our drivers were used in Windows 10 IoT Core, but that was a few years ago now. We can now point to a more recent success. In addition, there are a lot of device classes that were impossible to test on Windows 10 Core IoT, because of the difficulties in running regular Windows applications. It’s one thing for a webcam to enumerate; its another for it to actually stream interesting data to the application of your choice. It’s a lot easier to test if you can just spin up a video capture app. We can now point to public results from people testing our work. This is good, and so I thank the group for doing all the work to test and post results.

But there’s another reason, linked to MCCI’s social mission. We want to make a difference to people, not just to our customers.

Right now, cheap computing for people with few economic resources is subsidized (students are a prime example, but just one such group). Things like Chromebooks are subsidized by harvesting data; and they are limited in terms of what they can do (beyond the limitations imposed by their price).

That strikes me as wrong, and as a 19th-century way of solving the problem.

It’s already clear from group experiments that the Pi 3 is not that far away from being able to do significant work with Windows 10. If the group can make something useful to students and people with limited financial resources, it’s not a hobby: it can change lives.

The pi64.win project very likely will not, in itself, put a $35 computer in every student’s backpack (though I wish it would). But it demonstrates what can be done with very low-cost hardware, and it serves as a proof of concept. It may motivate some of the other (larger) members of the ecosystem (Microsoft, the Raspberry Pi Foundation, the Mozilla Foundation) to come together to create a production version.Sometimes a proof of concept is what’s needed to break through inertia and doubt.

TrueTask USB Host Provides Connectivity for Windows 10 IoT Core on Raspberry Pi 2

MCCI Supplies Quality USB Stack as part of Microsoft’s “Internet of Things” Platform

ITHACA, NY, July 8, 2015 – MCCI® is providing its TrueTask® USB Host stack as the connectivity engine for Windows 10 IoT (“Internet of Things”) Core operating system, targeting the Raspberry Pi 2 platform.

McKinsey Global Institute forecasts a $6.2 trillion annual IoT opportunity by 2025. The Raspberry Pi 2 is a very popular platform in the maker movement, providing remarkable computing power at a very low price. A high-quality USB host stack is a critical enabler for making Windows 10 on Raspberry Pi 2 a first-class platform for IoT development. MCCI’s TrueTask USB Host is proven technology that has been extensively tested, validated, and deployed on a mass scale by MCCI’s customers.

“With more than 10 billion USB devices shipped, and hundreds of thousands of different kinds of devices, USB is the most popular connectivity interface for device developers,” said Terry Moore, CEO, MCCI. “However, creating USB host stack is risky because of the testing and requirements needed to be compatible with the huge variety of devices. Our TrueTask USB platform is pre-tested and pre-verified so our customers can focus on enhancing their IoT products and don’t have to worry about USB connectivity.”

When preparing Windows 10 IoT Core for the Insider Preview release for Raspberry Pi 2 earlier this month, Microsoft Corp. needed a USB stack that could support the Synopsys USB core at the same level of quality as the Windows EHCI stack. The Raspberry Pi 2 SoC uses a Synopsys DesignWare USB 2.0 IP core to provide the USB host function, which is not compatible with the EHCI and XHCI register models used in traditional PCs, so the standard Windows stack could not be used. With 10 years of experience supporting the Synopsys core in deeply embedded systems, and 5 years of experience offering USB 3 host support for Windows 7, 8 and 10, MCCI readily ported its advanced USB stack to the Raspberry Pi 2.

MCCI’s TrueTask USB stack is based on the MCCI USB DataPump, which has been the “go-to” product for adding USB support to sophisticated consumer products for more than 20 years. MCCI’s TrueTask USB Host is platform agnostic, which makes it available for any hardware-software combination.

In addition to licensing USB system software, MCCI offers design consultation, integration and customization services as well as USB validation and hardware testing.