This was originally a lesson in the Designing Embedded Software for Change course. Version 2 resulted in a refactoring of the module. The original lesson is preserved in the Field Atlas for those who want to reference it.
Another source of embedded software tight coupling is external libraries and frameworks. Using existing external libraries and frameworks significantly reduces your up-front development efforts, but it can also create problems for you in the future if you do not manage how your software interacts with these dependencies.
Some problems that can arise from tightly coupling your software to external libraries and frameworks are:
- Tight coupling to external dependencies can make code difficult (or impossible) to test in isolation
- External dependencies that use non-standard language features force you to use specific compilers or operating environments
- External dependencies may have dependencies of their own – transitive dependencies may end up tightly coupling your hardware to a specific platform
- Using dependencies that are coupled to a target processor architecture or SDK further couples your software to that environment
- Some dependencies will be tightly coupled to a specific environment, such as the Arduino SDK
- Some dependencies may assume a 32-bit processor
- You may use a dependency like CMSIS, which provides an abstraction layer specifically targeted for ARM Cortex-M and Cortex-A5/A7/A9 processors
- Frameworks are “intrusive”. Applications built using a framework will usually become tightly coupled to the framework
- External dependencies are developed and maintained by third parties who are not aligned with your vision
- APIs can change or become deprecated, forcing you to update the interacting code when updating dependency versions
- Changes in the upstream project may cause you to change dependencies
- Maintenance or development may also stop altogether, forcing you to change
You must pay careful attention to the libraries and frameworks you select for your systems. Libraries targeted just for one platform, such as Arduino-specific libraries, may do exactly what you need, but they will tightly couple your implementation to a single platform. Ideally, you will select libraries that are already designed for use on multiple platforms. These libraries often provide an abstraction layer that you must implement to get the library working on your target system. But no matter how portable the dependency is, ensure that your software is not tightly coupled to external dependencies so that they can be easily swapped out in the future. Based on the systems we have worked on, odds are low that all of your external dependencies will remain fixed throughout your system’s entire lifetime.