Counterpoint: Why Is Hardware So Easy and Software So Hard?

Software Is Easier than You Might Think

I recently read fellow Design News contributor Warren Miller’s article entitled “Why Is Hardware So Easy and Software So Hard?,” with great interest. Warren suggested that the design flow for software should mimic that for hardware, which has, for the most part, become an exercise in connecting components and existing hardware blocks. The exciting part about Warren’s request of “Why can’t we do it for software?” is that at this very moment it is coming true.

Embedded software development has traditionally been a ground-up approach. A developer starts with creating drivers for the various peripherals of the microcontroller, such as the UART, and builds the software up from there. Many of the peripherals that are included in an embedded system have existed for many years and have well-known design patterns, for which silicon vendors commonly release example code. Part of the problem with the traditional approach, as Warren pointed out, is that it is still a ground-up exercise, but even worse, example code usually isn’t even componentized or intended for production.

Silicon vendors have recognized the lack of software components, reuse, and modularity over the last few years and started to take steps to improve design flow. For example, STMicroelectronics has been growing and improving its STM32CubeMx, which provides a visual design flow for configuring the software stack of its microcontrollers.

From within the design flow, just enabling a peripheral automatically generates driver blocks with configuration that provides an API with which developers can utilize with little knowledge of the lower-level drivers. Developers are then able to create their own components and then interface to the APIs, allowing them to essentially get their systems up and running far faster.

STMicroelectronics is not alone in this effort. Nearly every silicon vendor has been developing some sort of configuration tool. Freescale has its Processor Expert tool chain, which has software componentization.

Developers who want to use FreeRTOS, for example, can download a FreeRTOS component that allows them to drop the RTOS into the software stack. Need a buffer on the UART? Drop that component in, too. How about a stack monitor? There is also a component for that!

Another great example is the recent announcement by Renesas of its Synergy platform. Renesas has created a platform with out-of-the-box production-intent drivers, APIs, and software components that should allow software to be developed in a componentized manner. Having production drivers, components, and drivers should drastically decrease time and cost to market, and it could help revolutionize the way embedded software is developed.

One of the greatest drawbacks in the embedded software world is that the componentization and creation of software blocks has no widely accepted standard to fall back on like in the hardware world. Every silicon vendor is creating its own proprietary tools, components, and APIs, which are not cross-compatible.

MORE FROM DESIGN NEWS: Why Is Hardware So Easy and Software So Hard?

For developers, once they select a platform, that is it! There won’t be any mid-design-cycle shift; switching from one vendor to another will require a developer to start from scratch with a completely different set of tools that have different components that do the same thing but are not directly compatible with the previous platform. One can image that once you’re hooked within the tool chain and proprietary design flow, costs will eventually increase just enough to hurt but not enough to justify changing vendors and tools.

Componentization and the development of software from a hardware “flow” are possible without the use of vendor tools, through the use of design patterns. Using a good hardware abstraction layer, along with modular and configurable components, is a critical step in this effort. Unfortunately, this also involves the development of proprietary components and tools with a greater level of control for portability and across multiple silicon vendors. Porting and testing design patterns also takes some time and aren’t part of the traditional hardware flow of development.

To answer Warren’s question of why can’t we componentize and develop a hardware flow of design for software, we can and are. The maturity of that flow is dependent upon the processor manufacturer. The implication of developing software in this manner -- how it will affect design and cost -- is currently up for debate.

Is becoming locked into a silicon vendor’s development tool chain and ecosystem necessarily a bad thing in order to simplify software development? What do you think? Let us know in the comments.

Jacob Beningo is a Certified Software Development Professional (CSDP) whose expertise is in embedded software. He works with companies to decrease costs and time to market while maintaining a quality and robust product. He is an avid tweeter, a tip and trick guru, a homebrew connoisseur and a fan of pineapple! Feel free to contact him at [email protected], at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter here.