Should it be the same or different?

The language of the unit test framework is extremely important. It is just as important as the language of the software module. In fact, the test scripts that are written is a piece of code that needs to be managed. So ideally, the principles of software engineering also applies to the test scripts as well.

To reduce the complexity in your test scripts, it would be ideal if the test scripts are written in the same language as the software module under test. If you are writing your software module in C, your test scripts should also be written in C. If you are using rust, then rust should be used for the test scripts.

The advantage of using the same language for both the software module and test script, it is compiled for testing on the target. The big assumption is that the language is already supported by your target. In some cases, this is not. If you are developing using embedded Linux and your test scripts are in written in python, the chance of your version of python being supported on your target is pretty good. However, if you are targeting an 8bit Atmel AVR, getting python support on the target is pretty slim. If the test script is in the same language as the software module for your target, you are pretty certain that test on target is possible.

The other advantage of using the same language is the ability to debug. In a mixed language environment, the chance of debugging your test script as well as your software module is pretty small. For example, the software module is written in C and the test script is also written in C. When the binary is created and executed, it can be easily debugged using gdb or another debugger. It can be debugged from entry into main() until it exits main(). The variables can also be inspected and modified during debugging quite easily. In a mixed language environment, the variables public names may be mangled and that would make it difficult to find for inspection or even to modified.

To sum up, if you have no compelling reason to not keep all of your test script and software module in the single language domain such as C, do not mix your language.

---

I am writing a Guide to Successful Unit Tests, you can get it here at Leanpub.

Blinking LEDs

In the embedded world, blinking a LED is the equivalent to the “Hello World” program. The simple task of blinking a LED goes a long way to proving that you have work flow that works. It is a huge milestone for the project. This activity is sometimes known as bringing up the board. It is when a new board is provided and software is executed on it.

For those who are not familiar with the embedded concept, blinking a LED proves that your tool chain is good, your understanding of accessing the hardware is sound as well.
The most simple implementation of the blinking led application is

int main(void)

{

    PORTA.0.cfg = PUSH_PULL_OUTPUT;

    while (1)

    {

         PORTA.0.data ^= 0X01;

    }

    return 0;

}

The code will exclusive ORed the current value on PORTA.0, effectively flipping the bit. If are able to build this code and programmed it into your board, you can put a CRO on pin PORTA.0 and see a nice signal toggling up and down. The frequency and duty cycle are defaulted to the fastest setting possible.
If you able to see a toggling signal, you have reached a significant milestone. The hardware is considered good enough to start developing code upon. Lets break it down.
Your compiler and linker setup. By seeing the toggling signal on PORTA.0, it means that your tool chain has created binary code that your microcontroller can understand. It also means that your tool chain has linked all the binary, resolved the addresses in your code correctly, and that your specified memory map allows the microcontroller to boot. Getting the memory map is a tricky task as you have address locations and sizes correct for items such as stacks, heap, constant data etc.
Your debugging setup. By seeing the toggling signal, it shows that you can program the microcontroller with your debugger setup and trigger the code. If your debugger setup to the microcontroller is via JTAG, you can set break points and inspect variables and memory addresses. This is a big confidence booster to the developers as it provides them the tools to work on the problem.
Your hardware. By seeing the toggling signal, it shows that your hardware platform is powered correctly and is able to provide you with a stable platform to start developing code.
If you are wondering if the above code will actually blink a led. Well, unless the frequency of your microcontroller is quite low, it will probably not illuminate a LED. The frequency of the output is probably way too high. To have it blink, replace the while(1) loop with code that is tied to a timer event that occurs every 500ms. This will prove the hardware further. You will also have to check if the output pin can drive enough current it to the LED for illumination. Otherwise, you will have to drive transistor or a FET to drive the LED. 

One critical thing to remember when bringing up your board; the project is still very young. Even though you have proved some parts of your development flow, tool chain and development hardware, the rest of pieces of the puzzle are yet to be solved. However, it is a big step just to be able to blink a led. 

---

I am writing a Guide to Successful Unit Tests.
You can get it here at Leanpub. or here at Gumroad. and read about these topics and more.

Can a unit test replace a debugger?

I started working in embedded systems in 1992. At that time, I have wondered if it is possible to get your code working without the need of a debugger.

The debuggers I was using when I started was ICE [0]. By this I meant that the microcontroller was replaced with a special bonded out chip, and its clocking was controlled. The ICE allow me full access to microcontroller’s operation and peripherals, almost down the controlling each clock cycle. I was able to see everything the microcontroller was able to see. Sometimes, the cache on the ICE was large enough that I was also able capture a log of the instruction sequences. This is very helpful when I had to double check the execution part leading up to a beak point.

These days I work in a large engineering team with 32bit devices. The debuggers are usually interfaced via the JTAG connector. Although I can use it to debug my code, the control is not as fine as that of an ICE. The direction seems to be heading towards higher level of abstraction. Only use a debugger when it is necessary to. With a typical layered architecture, this is workable.

Extrapolating it further, is it possible to do a full project without any access to a debugger? In many projects, these is already occurring. The large amount of work from the ESP8266 [1] scene, the majority of the code are developed without a debugger. Yet this is in the hobbyist or prototype domain. What about the professional domain? To remove the debugger from the development tool chain would be difficult, especially if I am debugging code that is close to the metal. However, the higher up the software stack my code is residing in, reliance on it is getting smaller.

Using a unit test frame, the main advantage is to de-couple its dependency from the hardware and its maturity level. It may be possible for the software to be completed and released before the hardware is manufactured. Provided the behavior of the hardware is well known, this is a good strategy for reducing development time.

For the debugger, its major strength is to allow the code to be debugged close to the microcontroller. If I need to double check any data from the hardware, a debugger is essential. This is one area a unit test framework can never accomplish. The hardware may be mocked, but the mocked behavior will need to be verified against the hardware.

[0] – In circuit emulator. http://www.ganssle.com/articles/BegincornerICE.htm
[1] – https://en.wikipedia.org/wiki/ESP8266

---

I am writing a Guide to Successful Unit Tests.
You can get it here at Leanpub. or here at Gumroad. and read about these topics and more.