Hybrid Software Design

In choosing a language, I typically make this decision based on the needs of the project. An example of this approach was used in 2012 when I designed our MX1090; A product + app “pair” running in a real-time environment. Time-critical functions were written using inline assembly to ensure every clock cycle is accounted for during specific ISR events. Core functionality, DSP operations, 3rd-party communications, and hardware drivers were written in C. Additionally, an Android app, which received the data via an 802.15 Bluetooth or 802.11 WiFi module (a hardware option selected by the customer at the time of ordering), was written in Java to accomplish test and verification stages. To broaden market reach, I worked with many integration partners to establish protocols and algorithms by which our data could be sent and used on their GPS-based aviation mapping systems. One such example was the Garmin aera® 795 (shown on the right), which used a full duplex RS-232 protocol to connect to the MX1090. Additional options included the MX1090 creating a secure server for WiFi-based partners and a Bluetooth option for further additional partners. None of these solutions would have been possible without the broad selection of programming languages, new development platforms, and the experience I've gained through years of test-driven development (TDD) to achieve the results and quality our customers came to rely on from me.

Embedded Linux

Working with the Linux kernel and designing device drivers is very rewarding, however, to do so successfully has taken the bulk of my career in embedded development to do it well. The increased cohesiveness of post version 2.6 combined with the rich set of API’s make it the premier OS outside of the RTOS environment. I’ve had the privilege of designing a variety of device drives including i2c, SPI, UART, custom platform drivers, network interface, and several others. Some of the primary differences between writing drivers for non-Linux and Linux, from a driver development perspective includes the overall theme that writing drivers is a part of a greater community and thus, some of the shorthand styles used for creating other drivers are avoided. Another difference is the overall concept of a device, a driver, and a user. Each of which are viewed differently. Without going into the whole minutia of kernel vs user space, the objective is abstract layering so that user applications are separated from the actual direct hardware involvement. I am considering starting a blog so that I can dive in a little more deeply with these concepts to help other engineers who are just starting out.

Microcontrollers, FPGA, and DSP devices.

In addition to Linux, I have also developed countless microcontroller applications, bare-metal designs, and have utilized FPGA devices more as of recently. With this variety comes the experience of working with countless platforms, debugging tools, and a wide range in software languages, including assembly, C, C++, Java, Python, and many others. Many of the microcontroller-based products I have designed included a custom RTOS system to juggle the large number of IRQs and critical timing considerations typically found in Avionics and RADAR systems.

I have enjoyed designing a wide variety of applications and program using 8, 16, and 32-bit microcontrollers and DSPs from a variety of manufacturers. For example, I am highly familiar with Microchip (using MPLAB-X), Texas Instruments (using Code Composer Studio), and many others. Typically, most of my designs are programmed using C/C++ and often utilize inline assembly for time-critical operations or special chip features when recommended. With a broad range in microcontroller platforms and chips comes a broad range in experience with different emulators, debuggers, and flash memory programming devices. While the manufacturers may differ, I have found that the underlying functionality is very similar moving from one set of tools to the next. In many cases, projects can perform proof-of-concept stages simply by using the built-in debugging features included with either the device its self or with built-in features found on the demo boards, of which, I have no shortage of in storage!