printf(“Hello World!!! \n”);

I have been putting off launching my corporate blog for what seems like months. So today, it is with great excitement I say "hello" to the extended Wind River community! The issue of trying to chose what to write about in my first post has been a bigger challenge than I expected. I chose the "printf" title for two reasons:

  • it seemed like a cute and natural way to test if my blog account was set-up correctly;
  • the continued popularity of printf statements for debugging embedded systems, and the motivations behing this popularity, is a topic worth touching on.

Using printf statements to debug software has been around forever and will probably never disappear completely. A quick google survey uncovered the colourful quote from ariels that says "I'll give up printf() when you pry my cold dead fingers from it". Ariels posting also highlights some of the challenges leading embedded software developers to resort to using printf for debugging.

When I talk with some of our clients and our sales team, the thing that often surprises me is not that developers use printf debugging, but the extent to which these developers are dependant on printf debugging – especially when other alternatives are available and qualify. I think back to my own experiences early in my embedded software development career and I wonder if a developers preference for printf debugging has less to with technical factors and more to do with preconceptions about using real debuggers to improve our effectiveness in developing embedded software.

If preconceptions have a role to play in how embedded software is developed, I believe that we are now in a period of change where these preconceptions will be challenged and refined. I also believe that the migration to multicore devices will be a driving factor for software engineers to revisit the way that things get done. Earlier this week, David Stewart from Critical Blue (and not of Eurythmics fame) reminded me that "software developers did not ask for multicore". Very true. Software developers have had the benefit of riding the power-performance curve to get more CPU power to handle new features and capabilities. Multicore is a result of us having hit the frequency ceiling combined with the pressure of embedded applications that consume less power and dissipate little heat. As a result the concerns of multicore – parallelism, concurrency, partitioning, and virtualization – have now becoming pervasive in the discussion with embedded software developers.

I think this is an exciting time in our industry and I look forward to a open discussion around an approach to development tools and education that will lead to an improved effectiveness in developing device software in the multicore era.


[You can follow me on Twitter – "enwafor"]