Embedded hardware typically includes an application processor and one or more adjacent processor(s) attached to the printed circuit board. The firmware that resides on the adjacent processor(s) responds to instructions or commands. Different processors on the same board are often produced by different companies. For the system to function properly, it is imperative that the processors communicate without any issues, and that the firmware can handle all types of possible errors.
Formal requirements for firmware related projects may include the validation and verification of the firmware on a co-processor via the application programming interface (API). Co-processors typically run 8, 16, or 32-bit embedded operating systems. If the co-processor manufacturer provides a development board for testing the firmware on a specific co-processor, then the development board may have it's own application processor. Familiarity with all of the applicable bus communication protocols including synchronous and asynchronous communication is important. High-volume testing of firmware can be accomplished using function-like macros and arrays of function pointers. Processor specific firmware is written in C and assembly - 8, 16, 32, or 64-bit. Executing inline assembly from C is straightforward and often required. Furthermore, handling time-constraints such as real-time execution on adjacent processors is easier to deal with in C and executing syscalls, low-level C functions, and userspace library functions, is often more efficient. Timing analysis is often a key consideration when testing firmware, and executing compiled C code on a time-sliced OS, such as Linux, is already constrained.
To read tests based on a custom grammar, a scanner and parser in C can be used. Lex is ideal for building a computationally efficient lexical analyzer that outputs a sequence of tokens. For this case, the tokens comprise the function signatures and any associated function metadata such as expected execution time. Creating a context-free grammar and generating the associated syntax tree from the lexical input is straightforward. Dynamic arrays of function pointers can then be allocated at run-time, and code within external object files or libraries can be executed in parallel using multiple processes or threads. The symbol table information from those files can be stored in multi-dimensional arrays. While C is a statically typed language, the above design can be used for executing generic, variadic functions at run-time from tokenized input, with constant time lookup, minimal overhead, and specific run-time expectations (stack return value, execution time, count, etc.).
At a high level, lists of pointers to type-independent, variadic functions and their associated parameters can be stored within multi-dimensional arrays. The following C code uses arrays of function pointers to execute functions via their addresses. The code uses list management functions from the Linux kernel which I ported to userspace.