Recently, William Lamie published a mythbusting piece that examined the use of an RTOS in IoT devices on Electronic Design. His insightful comments apply to most device designs complex enough to use a microprocessor. Which, these days, is pretty much all of them. We’ve run into a lot of the same myths around one crucial component of the RTOS – the file system.
For example, the file system equivalent of the polling-loop architecture is logging software that writes to the device flash media. Without a file system, a single task could write data to a particular flash address, incrementing it afterwards and handling any overflow. This process doesn’t have any provisions for handling power interruption, data communication with an external device, or changes in the amount of data stored. Additional routines could be written for those situations, of course, or the designer could just choose the appropriate file system.
A file system also helps keep the RTOS from becoming too complex, and the right interface results in smooth portability. The balance of memory overhead and processing cycles is always a consideration in IoT devices. One point I heartily agree with is the cost – many decent RTOS solutions are available for free, with licensing only an issue once the design is finalized. Perfect for prototyping!
There are a few myths the article didn’t touch on, and I’d like to examine them for both the RTOS and the file system
12) Having no RTOS or file system is enough security
So-called security by obscurity has been disproved countless times, from early video game companies to the latest port availabilities on the Raspberry Pi. A big part of the problem is that we now have the processing power to try thousands of attacks per second. Both the RTOS and the file system can contain the security muscle to protect your data with public key encryption, AES and 256 bit keys, and that code has been optimized by some of the best programmers on the planet.
13) Reliability won’t affect my design, because it won’t lose power
This is more a myth for the file system than the RTOS, but it is one we hear all the time. Yes, the designer could write code to gracefully handle data storage and errors without a file system, but even then there are issues that can cause unexpected failures. For instance, the flash media takes longer to write and triggers a watchdog timeout which reboots the system. The battery or solar power feed ends up in a brownout situation which doesn’t provide enough power to write to the flash media. Not to mention trashed pointers which end up overwriting system files, turning the device into a brick.
A file system designed to handle power interruption can avoid all of these problems in the short term, allowing time for a long term solution without having to RMA a bricked device. The costs saved in support easily outweigh the fees for licensing a decent RTOS and IoT File System solution.