Introduction and Problem:
As Embedded software engineers, we often work on various projects and modules, leading to complex codebases and build systems. When making changes, it can be challenging to determine if the code is compiling as expected, especially in Linux-based systems or in AMP (Asymmetric Multi-Processing) applications, as we are often developing or testing a change across more than one target. We may for example be creating an append to a Yocto recipe, a change to a Linux driver, an addition of a device tree file all in pursuit of a single higher level goal. This is further complicated as codesets may be “ifdeff’d” in U-Boot or kernel land to provide various functions based on specific config functionality. It is not uncommon that we are presented with a new situation in which we do not have all the details on how a particular module is compiled.
When implementing new changes, you may encounter situations where your modifications appear to have no effect. This can be time-consuming during development, as a full build and deployment cycle can take several minutes or more. Multiple factors can contribute to this lack of visible impact. Instead of immediately questioning whether a function is called as expected, a more effective initial approach is to determine if the function, file, line, or other relevant elements are actually being compiled or built.
One Simple Solution:
To address this challenge, a straightforward but effective technique is to inject a piece of code to the area of question that is known to cause a compilation error. For example, if I am creating a new addition to what I think is the correct target driver, board file, etc. in U-Boot or say a new device tree file I have added, I will simply type in a line with “Is this compiling?” in it. Since that is not valid C, if the module at hand is being built like I think it is, I should get a compile error.
This is very simple, takes very little time to implement and quickly results in feedback on whether my module is being built as I think it is. It serves simply as a quick “sanity check” before investing further time and analysis in debugging.
In Closing:
This simple sanity check can be a valuable tool for embedded software developers. By injecting a piece of code that is known to cause a compilation error, developers can quickly verify whether their code is being compiled as intended, saving time and effort during the development process.
Call to Action:
Have you used similar techniques in your embedded software development? Share your unique solutions and sanity checks in the comments below!