Random Insights Channel

Sometimes a topic is just too good to ignore, and it does not map cleanly into any specific embedded design principle. The Random Insights series is the place where you can find a smattering of interesting and thought provoking topics that do not map to the focus of any of the other channel series.

Do you ever think about endianess?

Wednesday, February 8th, 2012 by Robert Cravotta

I remember when I first learned about this thing called endianess as it pertains to ordering higher and lower order bits for data that consumes more than a single byte of data. The two most common ordering schemes were big and little endian. Big endian stored the most significant bytes ahead of the least significant bytes; little endian stored data in the opposite order with the least significant bytes ahead of the most significant bytes. The times when I was most aware of endianess was when we were defining data communication streams (telemetry data in my case) that transferred data from one system to another that did not use the same type of processors. The other context where knowing endianess mattered was when the program needed to perform bitwise operations on data structures (usually for execution efficiency purposes).

If what I hear from semiconductor and software development tool providers is correct, only a very small minority of developers deal with assembly language anymore. Additionally, I suspect that most designers are not involved in driver development anymore either. With the abstractions that compiled languages and standard drivers offer, does endianess affect how software developers write their code? In other words, are you working with datatypes that abstract how the data is stored and used, or are you implementing functions in such a way that require you to know how your data is internally implemented? Have software development tools successfully abstracted this concept away from most developers?

Are software development tools affecting your choice of 8-bit vs. 32-bit processors?

Wednesday, February 1st, 2012 by Robert Cravotta

I have always proposed that the market for 8-bit processors would not fade away – in fact there are still a number of market niches that rely on 4-bit processors (such as clock movements and razor blades that sport a vibrating handle for men when shaving their faces). The smaller processor architectures can support the lowest cost price points and the lowest energy consumption years before the larger 32-bit architectures can begin to offer anything close to parity with the smaller processors. In other words, I believe there are very small application niches that even 8-bit processors are currently too expensive or energy hungry to support just yet.

Many marketing reports have identified that the available software development tool chains play a significant role in whether a given processor architecture is chosen for a design. It seems that the vast majority of resources spent evolving software development tools are focused on the 32-bit architectures. Is this difference in how software development tools for 8- and 32-bit processors are evolving affecting your choice of processor architectures?

I believe the answer is not as straight forward as some processor and development tool providers would want to make it out to be. First, 32-bit processors are generally much more complex to configure than 8-bit processors, so the development environments, which often include drivers and configuration wizards, are nearly a necessity for 32-bit processors and almost a non-issue for 8-bit processors. Second, the type of software that 8-bit processors are used for are generally smaller and contend with less system-level complexity. Additionally, as embedded processors continue to find their way into smaller tasks, the complexity of the software may need to be simpler than current 8-bit software to meet the energy requirements of the smallest subsystems.

Do you feel there is a significant maturity difference between software development tools targeting 8- and 32-bit architectures? Do you think there is/will be a widening gap in the capabilities of software development tools targeting different size processors? Are software development tools affecting your choice of using an 8-bit versus a 32-bit processor or are other considerations, such as the need for additional performance headroom for future proofing, driving your decisions?

Are you using Arduino?

Wednesday, January 4th, 2012 by Robert Cravotta

The Gingerbreadtron is an interesting example of an Arduino project. A Gingerbreadtron is a gingerbread house that transforms into a robot. The project was built using an Arduino Uno board and six servo motors. Arduino is an open-source electronics prototyping platform intended for artists, designers, hobbyists, and anyone interested in creating interactive objects or environments. The project began in 2005 and there are claims that over 300,000 Arduino units are “in the wild.” 

According to the website, developers can use Arduino to develop interactive objects, taking inputs from a variety of switches or sensors, and controlling a variety of lights, motors, and other physical outputs. Arduino projects can be stand-alone, or they can communicate with software running on a computer. The boards can be assembled by hand or purchased preassembled; the open-source IDE can be downloaded for free. The Arduino programming language is an implementation of Wiring, a similar physical computing platform, which is based on the Processing multimedia programming environment.

My first exposure to the platform was from a friend that was using the platform to offer a product to control a lighting system. Since then, I see more examples of people using the platform in hobby projects – which leads to this week’s question – Are you using Arduino for any of your projects or production products? Is a platform that provides a layer of abstraction over the microcontroller sufficient for hardcore embedded designs, or is it a tool that allows developers that are not experts at embedded designs to more easily break into building real-world control systems?

Is the rate of innovation stagnating?

Wednesday, December 28th, 2011 by Robert Cravotta

Around this time of year many people like to publish their predictions for the next year – and according to an article, the “experts and analysts” do not see a lot of innovation coming out of the United States soon. The article mentions and quotes a number of sources that suggest the rate of innovation is going to be sluggish the next few years. One source suggested that “bigger innovation labs and companies are holding back on numerous innovations until they can properly monetize them.”

I wonder if these observations and expectations are realistic. I see innovation every time I see some capability available for less cost, training, or skill than before. I am constantly amazed at the speed at which new technology reaches the hands of people in the lowest quartile of income. More significantly, I am amazed at how these new technologies appear in everyday activities without a fanfare. For example, my daughter who is learning to drive has pointed out features that she really likes about the car she is driving – features I never gave any thought about either because I did not notice them or because noticing them would be analogous to noticing and commenting on the air we breathe.

My daughter received a Nintendo 3DS as a present this Christmas. The 3D part of this product goes far beyond the display as it enables her to move the device around and interact with the software in new and meaningful ways. These “invisible” types of innovations do not seem to make big headlines, but I suspect they are still sources of technology disruptions.

As for a company holding off on an innovation, is such a thing possible in a highly competitive world? Can any company afford to hold off on an innovative idea and risk another company beating them to the punch in the market?

Is the rate of innovation stagnating? Is the marketing hype around innovation just not getting the return on investment and so companies are backing off on how they hype it? Are you aware of anyone holding back on innovative ideas waiting for a better consumer market to release them?

What embedded development tool do you want?

Wednesday, December 14th, 2011 by Robert Cravotta

Over the years, embedded development tools seem to deliver more capabilities at lower price points. Over the years, $40,000+ development workstations and $10,000+ in-circuit emulators have given way to tools that are lower in cost and more capable. Compilers can produce production quality code in record compilation times by arming the compilation activity across a networked farm of workstations with available processing bandwidth. IDE’s (integrated development environments) greatly improve the productivity of developers by seamlessly automating the process of switching between editing and debugging software on a workstation and target system. Even stepping through software execution backwards to track down the source of difficult bugs has been possible for several years.

The tools available today make it a good time to be an embedded developer. But can the tools be even better? We are fast approaching the end of one year and the beginning of the next, and this often marks an opportunity to propose your wish items for the department or project budget. When I meet with development tool providers, I always ask what directions they are pushing their future tools development. In this case, I am looking for something that goes beyond faster and more towards assisting the developer with analyzing their system.

One tool capability that I would like to see more of is a simulator/profiler feedback based compiler tool that enables you to quickly explore many different ways to partition your system across multiple processors. Embedded systems have been using multiple processors in the same design for decades, but I think the trend is accelerating to include even more processors (even in the same package) than before to squeeze out costs and energy efficiency as well as to handle increasingly complex operating scenarios.

This partition exploration tool goes beyond those current tools that perform multiple compilations with various compiler switches and presents you with a code size versus performance trade-off. This tool should help developers understand how a particular partitioning approach will or will not affect the performance and robustness of a design. Better yet, the tool would assist in automating how to explore different partitioning approaches so that developers could explore dozens (or more) partitioning implementations instead of the small handful that can be done on today’s tight schedules with an expert effectively doing the analysis by hand. I suspect this type of capability would provide a much needed productivity boost for developers to handle the growing complexity of tomorrow’s applications.

Is there an embedded development tool that lifts your productivity to new heights such that you would recommend to your management that every member of your team had it? Is there a capability you wish your development tools had that isn’t quite available yet? What are the top one to three development tools you would recommend as must-have for embedded developers?

What embedded device/tool/technology are you thankful for?

Thursday, November 24th, 2011 by Robert Cravotta

In the spirit of the Thanksgiving holiday being celebrated in the United States this week, what device, tool, or technology are you thankful for making your life as an embedded developer better? This can be anything, not just the newest developments. The idea is to identify those things that made a material impact during your embedded career.

As an example, my own introspection on the topic yielded a somewhat surprising answer for me – I am thankful for the humble USB port. I remember when my mentor came to me one day with a spec sheet and asked me what I thought about this thing called the Universal Serial Bus specification. We talked about that specification on and off over the course of a year or so, but never did I imagine the larger extent of the impact of so small a change.

Not only did USB simplify and make connecting and powering devices simpler and more reliable such that everyday technophobes could successfully use those devices, but it simplified development boards and workbenches all around because more and more of the new development boards that included a USB port no longer required a separate source for system power. As a consumer, I have recognized that I have not crawled under my desk to plug in a transformer in years – and for that, I am thankful.

There are many things I am thankful for, and these opportunities for introspection are valuable because they increase the odds of recognizing the mundane and nearly invisible changes that have permeated our environment – just like the invisible embedded devices that populate our everyday lives. What embedded device, tool, and/or technology are you thankful for?

Do you receive too much email?

Wednesday, November 9th, 2011 by Robert Cravotta

During a recent conversation I heard someone share a “good” thing about emailed newsletters – it is easy to sort the email list and block delete all of them. This got me thinking about how much time I spend managing emails each day, and it got me wondering, does anyone/everyone else receive on the order of 100 emails a day too? Mind you, these are the business relevant emails versus the countless spam emails that several layers of spam filters intercept and dispose of for me.

Email allows me to work with dozens of people asynchronously throughout the week without having to spend time identifying a common time that we can work together. However, I receive way too many newsletters such that I do not have time to open them all. On the other hand, many of them are not worth opening most of the time, but the few times they are worth opening make it worthwhile to receive them. A good subject line goes a long way to signaling whether a particular issue of a newsletter might be worth the time to open and read it. And that identifies one of the problems of receiving a constant stream of information – a majority of it is not relevant to what you need at the moment you receive it.

On the other hand, I do not like block deleting these emails because used correctly, they can provide a sort-of customized and pre-filtered search database for when I need to research something. I think this works because I choose which newsletters to receive, and it is easy (usually) to stop receiving a newsletter. When I do a search on this informal database, I sometimes find a pointer in a newsletter that helps me find the material I am looking for from sources that generally have earned my trust as being reliable.

The downside or cost of having these newsletters to search is that too many show up in my mailbox each week. Automatic email filtering rules that moves newsletters into folders are helpful, but they usually take place as the emails arrive in my mailbox. I prefer to have the newsletters pop up in my inbox so that I can see the subjects in them before they are shunted into a newsletter folder. To date, I have not seen an email tool that will move emails into appropriate folders after they have been in the inbox for a day or week.

Do you receive too much email? Or is your email box not overflowing with information? Are you receiving so many newsletters that aim to consolidate information for you but end up flooding your mailbox with too much information that is not immediately relevant? What strategies do you use to manage the influx of newsletters so that they do not interfere or possibly hide important emails?

What advice would you give to an embedded newcomer?

Wednesday, October 19th, 2011 by Robert Cravotta

Developing embedded systems is different from developing end applications. For one, when done correctly, no one knows or cares about the embedded system when deciding whether to buy the end device. I remember having to adjust my own expectation and method of describing what I did for a living. Saying I worked on the control system for a part of a larger project, I learned to accept telling the slightly less accurate answer to people about what I worked on – “I work on the Space Shuttle, or the Space Station, or a particular aircraft.” I know I am not alone in this sentiment based on the responses from our first question of the week more than a year and a half ago – “You know you’re an embedded developer when …

In addition to adjusting to a different way of describing my job to others, I learned a number of important concepts about designing embedded systems – many of which apply well to other aspects of life. For example, one lesson I learned the hard way is to avoid the urge to rewrite portions of a system just so it will operate “better”. Instead, make the smallest change possible to get the system to do what it needs to do correctly.

The value of this advice is most apparent when you are working on projects with aggressive schedules. There are usually so many things that absolutely need to be changed and added to a design that routing your effort to redesign and rewrite a portion of the system that is invisible to the end user anyway is a recipe for unhappiness and stress. Not only are you taking precious time away from doing what needs to be done to the system, but you are also producing new sources of errors into the system by touching parts that are not part of the scope of work you are supposed to be working on. The expression “If it ain’t broke, don’t fix it” captures the essence of this advice even if it does not impart why it is usually a good idea to adhere to.

I suspect that each of us knows a handful of good advice we could pass onto embedded newcomers or mentees. What advice would you give to someone learning the ropes of engineering and/or embedded design? Do you have a simple or catchy phrase that captures the essence of your advice? Or do you have an example that illustrates a non-obvious value of the piece of advice?

Is the collider closure cause for concern?

Wednesday, October 5th, 2011 by Robert Cravotta

Twenty-eight years of discovery is being marked by the closure of the Tevatron proton-antiproton collider last week. The closure of the collider is occurring while scientists around the world are trying to see if they can replicate measurements made by physicists at CERN of neutrinos traveling faster than the speed of light.

The Tevatron has been the most powerful atom smasher in the United States since 1983. Analysis work based on the data collected by the collider will continue for the next few years, but the lab will no longer be pursuing data for collisions of the highest possible energy. The Large Hadron Collider, an accelerator capable of pushing particles to even higher energies, is replacing the Tevatron. Instead, the scientists at the Fermi National Accelerator Laboratory (or Fermilab), the home of the Tevatron, will be pursuing the “intensity frontier” which will focus on working with very intense beams with very large numbers of particles.

To date, the United States government has been a primary source of funding for large and expensive research projects such as the Tevatron collider and the Space Shuttle – both of which have closed down their programs this year. It is unlikely that these are the only research projects operating with aging equipment. Do these two recent program closures portend a slowing down of research, or are they the signs that research efforts are progressing so well that closing these projects are part of refining and reallocating research resources to more challenging discoveries?

How important are reference designs?

Wednesday, September 28th, 2011 by Robert Cravotta

A recent white paper about a study exploring issues facing engineers during the design process identified a number of items that are “essential to the design process” but can be difficult to find. At the top of the list were reference designs and application notes. This is in spite of engineers being able to access a wider range of materials across multiple sources via the internet than ever before.

I think part of the reason why these two types of information are identified as essential and difficult to find stems from the growing complexity of contemporary processors. The number and variety of peripherals and special purpose processing engines that are being integrated into today’s newest processors create a steep learning curve for any developer trying to use these devices in their projects. Providing a compiler and debugger does not sufficiently compensate for the amount of effort to master the complexity of today’s processors without negatively impacting the project schedules.

The term reference design can apply to a wide range of materials. An article about reference designs presents a taxonomy for reference materials based on application complexity and design completeness versus broad to application-specific implementation details. If, as the article identifies, reference designs are a sales and marketing tool, why are such material difficult for developers to find?

One possible reason is that developers do not consider reference materials as essential. Another reason is that reference designs, by their nature, apply to a small swath of processors in a huge sea of options, and this makes classifying and getting these reference designs in front of interested developers challenging at best. Attempts by third-party information sources have had limited success at aggregating and connecting the appropriate reference materials with relevant processors. As evidenced by the conclusions of the referenced study, even processor vendors themselves are experiencing limited success getting word out about their own reference materials.

How important are reference materials in choosing and working with processors and other complex components in your designs? Are all types of reference materials equally important or are some types of information more valuable than others? Is aggregating reference material with the appropriate component the best way to connect developers with reference material? What good ways to classify reference material have you seen that help you better find the material you are looking for without having to wade through a bunch of irrelevant reference material?