An Interview with Datalight

Summary: Here's part 1 of an interview with Datalight, a long-time provider of software products to the embedded industry. Old-timers will remember their ROM-DOS.

How many 1980s-era embedded software startups are still around? Not many. Remember Sophia Systems? Phar Lap? Software Development Systems? I have a copy of the very first issue of Embedded Systems Programming, and perusing the advertiser's list is rather like a stroll through a cemetery.

Then there's Datalight. Founded in 1983, they initially sold Datalight Small C compiler. C had almost zero presence is the firmware landscape back then. It was years away from getting ANSI recognition and there were so many dialects that portability between compilers was impossible. Later they released ROM-DOS, which for a number of years was their claim to fame. Their C_thru_ROM made it possible to embedded x86 Microsoft C code.

Datalight is still thriving. I had a chance to banter with Kerri McConnell and Ken Whitaker, and was intrigued by their filesystem products. They also told me they use an agile methodology with great success, so thought readers would be interested. They agreed to an interview, and this is part 1. Part 2 will run next week.

Jack: Tell me about your products.

Datalight: The primary focus of our product line today is power failsafe and high performance software for preserving data integrity with the Reliance family of file systems and FlashFX family of flash management software. Back when flash memory first started gaining a foothold in embedded devices in the late 1990s, we seized the opportunity to enable it with drivers in our then flagship product, ROM-DOS. As the FlashFX family was deployed by customers on a variety of other operating systems we heard loud and clear the concerns about data reliability of this new storage technology. As is our habit, we first assumed that our product was somehow at fault, but the root cause turned out to be file systems that didn't properly handle unexpected shutdown. So we built our own Reliance file system that could deal with the power uncertainty that is part and parcel of embedded systems.

Both of these product families have evolved over time into the current product line up:

 Reliance Nitro is a transactional power failsafe file system for sophisticated embedded systems.

 FlashFX Tera provides comprehensive software management for raw NOR/NAND flash that makes flash memory look like a hard drive to the OS.

 Reliance Edge is a tiny MISRA C:2012 compliant file system for decision-quality, real-time data in micro-controller based designs.

Jack: What kind of industries and customers do you typically sell into? Datalight: Our customers come from all segments of the embedded market-anywhere data is important. I frequently state that our products are used from the bottom of the ocean, to the depths of space, from the factory floor, and to your hip pocket. Leaders in IVI and fleet management gain fast boot time. Four of the top five ruggedized handhelds gain data integrity across their product lines. The worldwide leader in automation has kept HMI devices reliable for three generations. The international space station has recording devices that use our products to capture data. And recently, both Reliance Nitro and FlashFX Tera were adopted for an innovative smart grid platform which gained decades of product lifespan increase from using our technology.

Jack: I have a hard time telling the difference between Reliance Edge and Reliance Nitro without digging deeply through the verbiage. What's your elevator story about these two products?

Datalight: I can understand the confusion, both file system products are power failsafe transactional file systems, but they serve different markets. Reliance Nitro supports a higher end, more sophisticated environments that need features like true multithreading and use complex operating systems like Linux, VxWorks, Android, and Windows Embedded Compact. Reliance Edge, our newest offering, differs in a couple of significant ways. First of all, the Reliance Edge code base is very compact-designed for a microcontroller-based system with limited RAM and code space. Second, it is fully MISRA C:2012 compliant. Reliance Edge is offered under both an open source GPLv2 and a proprietary commercial license model. It is built to be portable for different RTOSes and Datalight prepackages a port on the popular FreeRTOS with the initial release.

Jack: Transactional file systems are the rage, at least in the literature. I don't see so many in practice. Some readers may not know what this is. Can you explain their purpose and general implementation?

Datalight: One reason you don't see many transactional file systems in practice is that they are complicated to build correctly. We're excited that the growth in the importance of data means that more folks are starting to appreciate a technology we've been perfecting since the beginning of this century. Transactional file systems operate to a high power failsafe reliability standard-we use the ACID standard of atomicity, consistently, isolation, and durability.

One way to explain how transactional file systems work is to compare them to the more common journaling file systems (like ext4). Journaling file systems use a logging approach to record file system changes prior to making the actual change to the file system. File system operations are recorded as entries in a circular buffer known as a journal. After a power fail event or other unexpected shutdown, the journal is replayed and inconsistencies in the file system structure are attempted to be repaired, if possible. However, user data is usually not protected from loss or corruption because changes to it are made "in place."

In contrast, a transactional file system uses a dual-state set of data structures to manage transactions. The two states are referred to as the committed-state and the working-state. Changes to the file system structure and user data are recorded in the working state and when a transaction occurs-which is a fully atomic operation-the current working state becomes the new committed state (and vice versa). Much like flipping a switch. If an interruption occurs before the transaction is complete, the system can instantly recover to the original committed state without a loss of committed data.

The key differences between journaling file systems and transactional file systems fall into the following areas: user data integrity, performance, disk space efficiency, and programmability. In our opinion, transactional file systems have clear advantages for embedded systems. If you or your readers want to dive into more on this topic, we just published a new whitepaper that goes into further detail.

Jack: Is there much demand for ROM-DOS today? If so, what sorts of applications does it go into?

Datalight: We have customers who have been building devices using ROM-DOS for decades, continue to ship those solutions today. This includes devices like single board computers, infusion pumps, and controllers for factory equipment as well as office equipment applications like postage meters. ROM-DOS is a solid product with a reliable set of features and we continue to support customers developing new solutions requiring ROM-DOS. If someone needs a DOS-style OS, there's not too much out there that is as well supported.

Part 2 of the interview is here.

Published July 6, 2015