Do You Need the Flexibility and Transparency of Source Code?

Posted by: Thom Denholm

Acquiring software components for your embedded design can be a time consuming task. Sometimes you spend weeks narrowing in on just the right libraries that have the combination of hardware support and features that you need. Once you find it, you eagerly head down the path to purchase. But wait…what if something in the hardware design changes before you've completed the software integration? If the component you've chosen was delivered as a library, you must go back to the vendor and request a change. What if there's a bug and the vendor isn't responding quickly enough to fix it? These types of challenges are a big part of the reason that open source software has gained such wide adoption.

At Datalight, we have always delivered our file systems and flash management software in source code form. The well-commented source provides transparency and gives you the ability to tailor the software to your specific needs, using a robust set of compile-time switches and configuration options. Our thorough documentation and award-winning support team will guide you through the choices you need to make. This flexibility also means that you can (depending upon your purchase option) reuse the software for multiple projects, even if you change processors, compilers, or storage media, without having to request a different library from Datalight.

But what if you just want to plug in a pre-compiled library and leave all those configuration decisions to someone else? There are situations when a binary distribution may be the best approach. When software has already been crafted to fit the specific hardware, from NAND flash to controller and processor, then that library can be used as the basis of a solid design with no guesswork. If your design is not going to change at all over the course of development, and software reuse is not a priority, this might be a good option for you.

Not having the source does impose some limitations - some things must be set at compile time and perhaps what you thought you knew when you ordered the binary turned out to be a best-but-not-quite-right guess. In the case of our FlashFX Tera product, block device size and NAND access are two big ones, both related to optimal hardware access and it's not at all uncommon for NAND parts to go EOL before a complex design is ready to ship. Other customizations come back to performance  vs resource use tradeoffs- and sometimes the best raw performance by the block device doesn't always match the requirements of the file system.

Which approach works best for your use? Leave us a comment and let us know whether pre-configured libraries would be a good option for you.

Explore the resources available


Comments (0)


Add a Comment





Allowed tags: <b><i><br>Add a new comment: