Moderator
Right up front, let’s be clear about something. There is no right answer to the issue of monolithic vs modular. Here’s how I see it. Monolithic is good. Modular is better, at least when it comes to software. You may have a preference. I’d like to hear what you think.
Credits: stone moai in Santiago Chile, me; LEGO® moai art, Nathan Sawaya.
Monolithic is like the walled garden approach. Everything comes from one place, it’s all coherent. You know it works together (or at least it should). It is also all or nothing. Because it is a comprehensive solution, it is likely to have cool optimizations or shortcuts, assumptions based on the designers knowing in advance the boundaries and content of the monolith. If you write one of these, you can really polish the rough spots and in the end have a bespoke, smooth result. But it may not be modifiable or portable. Not to mention the “one-size-fits all” issue. A 14-ton monolith may not go with your decor.
A singular SDK designed to provide all things for a processor family is a large-grained solution. Break that same SDK into a bunch of independent pieces and you have multiple smaller-grained solutions. You no longer have an SDK. You have what I like to call "pieces parts." In the ideal you can mix and match pieces – perhaps substitute a piece from somewhere else that better suits what you want to do.
Modular doesn’t make problems disappear. You get a different set of problems, particularly making sure all the pieces fit. Dealing with those rough edges may be worth it. The flexibility and stability provided by using modules can shorten development time. A part can be individually stable, well-tested, and reliable. In the ideal each is a black box. You just use it. Stick with the published API, and you’re good.
W
OK, all nicely theoretical. Where are we going with this discussion?
I got some feedback on my previous blog about Eat Your Own Dogfood. "You have to develop frameworks that have the flexibility to work with all your chips - your backlog and those on the roadmap." (emphasis mine) And that is where we are going: ModusToolbox software from Cypress, an Infineon Technologies company. I think this is a good example of an ecosystem of “stuff” with modularity as its core principle. It is a design that gives you immense flexibility.
Pick your host OS. The installer gives you tools. All tools are available for Linux, macOS, and Windows 10(64-bit). Done. You get a project creator, a library manager, and other tools for creating and managing projects. All of them are cross-platform. You even get an optional Eclipse IDE.
Pick your build tools. The ModusToolbox make system supports GCC, Arm v6, and the IAR toolchains.
Pick your IDE. From the command line you can export the project to VS Code, µVision, IAR Embedded Workbench, or any Eclipse-based IDE. We also provide a customized Eclipse IDE for ModusToolbox, completely optional. See The March of IDEs.
Pick your target. We provide a board support package (BSP) for each of our kits. You aren't stuck with those. You can build your own BSP! It’s straightforward, and well documented. However, a target can be something much larger than a kit. It can be an entire ecosystem - Amazon Web Services, Mbed OS, or our own AnyCloud for example. See Make Your Own BSP for Fun and Profit
Pick your libraries. What kinds of libraries? A high-level overview is available here. There are dozens to choose from, USB device, capacitive touch, peripheral drivers, a hardware abstraction layer, WiFi connectivity, FreeRTOS, a Bluetooth SDK. Many are aimed at wireless connectivity. AnyCloud is really a collection of these libraries aimed at a specific target: Internet of Things applications running on any cloud service. Libraries are designed with minimal dependencies. It’s not zero, but in many cases you can use a library standalone, meaning there is no dependency on any other library. Sometimes a library requires other libraries. All the dependencies are handled automatically in the ModusToolbox build system. See Faster Leaner More Flexible – ModusToolbox v2.2, and Lock and Load.
For any supported host OS, tool, compiler, IDE, and target, it all just works. It really is an amazingly flexible mix and match approach. In upcoming articles I plan to dive more deeply into the ModusToolbox library mechanism – it’s really elegant. All of this sits on GitHub, and I want to dive into that too. See We Get Along with GitHub
For now, let me invite your thoughts on the topic of flexibility – do you have experience with an all-in-one SDK or a modular ecosystem where you can pick the pieces parts? What was it like, what was good, or not so good? Nothing is perfect. I'd love to hear your stories about ModusToolbox! I admit to an ulterior motive, I like good ideas and I will reuse them. 