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.
