<img height="1" width="1" src="https://www.facebook.com/tr?id=1101141206686180&amp;ev=PageView &amp;noscript=1">


Transitioning from LabVIEW Developer to Firmware Developer

When I started at Erdos Miller, I did LabVIEW development for clients. One day, my boss asked how I would feel about doing a firmware project. I didn’t have any experience with firmware development but was up for the challenge. This transition hasn’t been easy, but I have learned a lot. I’d like to share what I use to do and what I have learned on my path to become a firmware developer.

Most of the applications I developed as a LabVIEW developer were for surface systems, labs, and manufacturing environments. The applications would either run on a Windows machine or National Instruments CompactRIO. In both scenarios, it didn’t really matter what environment the application was running in, LabVIEW took care of the low-level hardware interfaces. The development environment was graphical and required connecting wires. I created various user interfaces to display live and saved data for verification and analysis purposes. This was going to be quite different from what I would be doing as a firmware developer. I would now be programming in C, would not be creating user interfaces, and managing all the low-level hardware interactions.

Verify test board against the schematic

One of the best ways to gain experience is by working on an actual project. My first task was to setup a filesystem on a TI MCU. Luckily, I had example code from a different project to review and file system libraries to work with. Because the filesystem would span multiple flash chips, I had to review the board schematic to see how things were connected to the MCU and what communication protocol was needed to communicate with the flash chips. When I went to test the code, Interrupt 19 was triggered. I was able to use breakpoints while debugging to figure out the flash chips weren’t installed on my development board. Takeaway from this was to always check the board and schematic to make sure all parts have been installed.

Limited Memory

When working with MCUs, memory is very important and limited. This wasn’t a concern when developing in LabVIEW. There was a module I updated that required allocating a very large character array. Turns out I didn’t have enough memory and could not build the code. The reference guide for the MCU helped with increasing the RAM allocated. That still wasn’t enough and so I had to modify the code to work with smaller chucks of the character array.

Hardware Interrupts, Software Interrupts, Tasks, and Priority

User control of Interrupts in LabVIEW are nonexistent. The OS manages multiple threads and hardware interrupts. At most, we can create timed loops with a particular core affinity and priority. With MCUs, the programmer is responsible for setting up hardware interrupts, software interrupts and tasks. Hardware interrupts are typically triggered by external devices or CPU timers. They are time critical tasks. Software interrupts are requested by the processor itself and typically process data from a hardware interrupt. Tasks threads are lower priority then a software interrupt and can wait until resources are available to execute. As an example, a semaphore can be used to pause a task until data is available for it to process. Part of my file system development, I needed to periodically log to files as well. Because logging wasn’t extremely critical, I set it up as a task. What I didn’t realize is I gave it a priority greater than a more important task. This caused other functionality to break because now this task was blocking the other tasks from executing.

My journey as a firmware developer will continue; I have more to learn. With any career change, there are challenges, but with the right attitude and determination, they can be concurred.

Recent Posts:

The Absolute Necessity of Goals
Publish Date 14 Jan 2021 Cameron BashamRohama Khadija

The Biology of Goals  

Nyquist Rate and Antialiasing Filter Explained
Publish Date 14 Jan 2021 Jason ThaiRohama Khadija

In mud pulse telemetry, we use a sync signal for synchronization. A commonly used [..]

Good Firmware Programming: Quantitative vs Qualitative
Publish Date 14 Jan 2021 Yifang YangRohama Khadija

Write Software for others as you wish they would write for you.

Simulations and Data Driven Approach for Improved Code Deployment
Publish Date 14 Jan 2021 Saravanan PandiyanRohama Khadija

  Introduction At Erdos Miller, we are firm believers in making data-driven [..]

Wireframe, Mockups, and Prototypes
Publish Date 14 Jan 2021 Ashton ScaliseRohama Khadija

Before implementing a new feature in an application, it is common practice to create [..]

Simple Practice of Time Management
Publish Date 14 Jan 2021 Bryce UrestiRohama Khadija

Time Management can be very easy but also complicated based on schedules. But with [..]