Having been around long enough to witness the birth of the Internet and its rapid evolution over the past few decades, I’ll be the first to advise newcomers to technology fields that one of the keys to maintaining relevance is the ability to adapt to change. While most developers that I knew in the early 90’s were C or C++ programmers, these skills are much less relevant now. That’s not to say that working with these languages isn’t potentially beneficial to any self-starting software developer, but it’s obvious that software engineers working mainstream technology jobs are less likely to actually use languages such as these in the typical workplace. A quick job search using any popular website with reveal that the majority of software developer positions available are looking for applicants with experience in languages such as .NET, JavaScript, PHP, and Java. Looking back on my own development career, the evolution of technologies with which I worked is obvious as I see transitions from Intel 8088 assembler to C++, Java, Perl scripting while keeping up with changes to HTML standards as well as an ever-evolving JavaScript language and its related extensions. I’ve worked with Web Services on a number of platforms and eventually found myself honing my skills with AJAX and dynamic content.

Electrical Engineering and embedded development has experienced its own evolution over the years, but to me these changes seem to have taken hobbyists as well as professional engineers in a slightly different direction. That is to say that, while today’s enterprise software engineer is working with different technologies that could be considered similar to those used two decades ago, the embedded developer’s life has gotten much easier, comparably speaking. The latter seems like a good thing, right? Many would consider such evolution a proverbial ‘step in the right direction’. Well, yes and no. With the introduction of rapid prototyping platforms such as Arduino and Raspberry Pi, the younger generation of ‘Makers’ now has the opportunity to focus immediately on solutions rather than implementation details. The byproduct of utilizing such technologies are obvious: Innovative projects originating from universities as well as garage workshops are popping up constantly. Combined with the wealth of information available via the Internet, there is little standing in the way of the aspiring embedded developer’s idea and a working prototype. This is great right? Well again, yes and no.

The ability to assemble parts and ‘sketches’ into a working prototype quickly, rather than weeding through datasheets and learning much of the nuance associated with embedded development has many benefits which are obvious. What may not be immediately obvious are the side-effects of over-simplification of what is, by nature, a complex and detail-oriented hobby or profession. It’s very important that entrepreneurs be able to demonstrate feasibility quickly and adapt to changing requirements and the introduction of new ideas on the fly. Once an idea has evolved into a working prototype, engineers must be prepared to plan a path to a commercial product. In many cases, such a product will need to be mass-produced. Herein lies the problem as I see it: If you’ve developed a product prototype using pre-built Arduino modules and code Sketches, you are likely to find that the production version of your prototype using similar tools is not cost-effective or easily maintained. Additionally, I’ve found that many hobbyists as well as new engineers are missing out on fundamentals associated with their own ‘Work’. What I mean by this is that having used pluggable modules and software, largely copied from a various websites does not prepare someone to work the design to production cycle. Do you know what’s on that Arduino module and why? What about time-critical sections of logic? Are you prepared to track down bugs originally discovered with a digital oscilloscope by stepping through disassembly? What about implementing time-critical code from scratch using basic assembly instructions?

Once upon a time, I designed an RF project that used a basic FM transceiver. All devices that were present on the RF network work operating at 20MHz driven by a crystal oscillator. It didn’t take me long to realize that, as accurate as my crystal oscillators were, I was unable to establish reliable communication between devices at 9600 baud data rates. I realized quickly that, while my transceivers used built-in PLL, I was still losing syncronization over time due to subtle differences in the device’s oscillator frequencies. Naturally, this was more likely to occur when sending data that was non-conducive to maintaining locked phase between RF-linked serial devices. I realized that I needed a more neutral DC bias in my data in order for the transceiver’s PLL to be effective. This was when I first discovered Manchester Encoding. The challenge associated with implementing neutral DC bias was timing: Microcontrollers using these transceivers needed to not only encode and decode bias-neutral data that was being sent and received respectively, but the process needed to always fit within 104 microseconds per encoded bit, regardless of what was contained within the data (sending a set (1) or clear(0) needed to consume the same number of instruction cycles). This requirement was largely due to the fact that the part that had been spec’ed only contained a single ESUART and the RF serial logic was implemented in program code rather than having the data sent through a serial peripheral. This presented additional challenges as now I was dealing with writing an encoding algorithm that was also operating within a timing-critical branch of logic.

If you made it though the previous paragraph, let me explain why this is all relevant. First though, let me address some of the more obvious arguments that a new design engineer might make regarding the problem and my solution:

• Why not just find a code snippet or example that uses and adequate encoding mechanism rather than writing your own?
  I did thoroughly search for Manchester Encoding examples written for PIC Microcontrollers, but was unable to find anything that written with timing-critical applications in mind.
• You could have gotten around your timing-critical code requirements by using a device with two ESUARTS, allowing the peripheral to worry about baud rate.
  This is true, but the closest match in a mid-range device would have cost me twice as much. Spending a few hours implementing this myself would more than offset the additional costs associated with spec’ing a larger microcontroller.

Ok, so those are the first two obvious arguments that could be made and the reasons why I chose the solution that I did. Like it or not, cost is going to be very important when considering the production version of a prototype. Maybe I could have accomplished everything I needed to using a rapid prototyping product, but when it came time to justify costs I would have most likely run into trouble. Additionally, understanding how the application functioned right down to the instruction fetching, clock to oscillator frequency relationship and how it effects branching logic would later become critical.

The short version of this already long post is simple: With simplification comes limitation. The deeper you are willing to go in implementation, the more flexibility you’ll find at your disposal. Additionally, you will learn more about solving problems that might otherwise stump a junior engineer that relies on pre-fabricated boards and example, high-level code to develop prototypes.

So, does this mean that I feel Arduino and Raspberry Pi are tools to avoid? Absolutely not. It is, however, important that you understand what you are giving up or side-stepping in terms of flexibility and knowledge by using these tools and prepare yourself accordingly. Being able to accomplish the same tasks using discrete components and C or ASM code that you are currently tackling with rapid prototyping systems is very important. If you’re there, then you’re doing it right. Unfortunately it seems that, more often than not, the hobbyists and students are piecing together ‘Electronic Legos’ and very high-level software consider themselves to be adept with respect to embedded design and electrical engineering. Nothing could be further from the truth.