Unit testing for embedded system

[NorthGuy]

In contrast, testing more product-level properties may be much more interesting. E.g. something like this: https://medium.com/tado-product-development-blog/building-an-iot-product-continuous-battery-lifetime-testing-3245b6cdfa40

This is just amazing. A simple thought of measuring motor energy consumption separately from the electronics didn't even cross their mind.

BTW: If they wanted less consumption in the stepper motor, then instead of thinking about "atomic operators to lock the threads in our operating system", they would be much better off developing a custom energy-saving driver for their stepper motors.

[SiliconWizard]

One of the neverending stream of examples of the "law of the instrument".

[hans]

Yep.. when stuck on a problem..

A hardware engineer will take out the DMM/scope and doubts the software last
A software engineer will take out the debugger and doubts the hardware last

Poor hardware engineering choices aside, for illustration purposes, I think the utility of a CI/CD pipeline is quite neat for embedded. But I doubt whether thats a good idea for any embedded device, considering some are worked on only intermittently. Many software products may have an infinite release cycle, while many hardware products certainly don't. No code change=no need to rerun tests=no need to keep such a hardware setup alive, unless you have enough money in which you can tie down (expensive) measurement equipment forever.

[Siwastaja]

A hardware engineer will take out the DMM/scope and doubts the software last
A software engineer will take out the debugger and doubts the hardware last

This is why I want full responsibility for both hardware and firmware. Obviously doesn't work for massive megaprojects, but with suitable KISS attitude, for something surprisingly big (medium complexity projects). Drawing the line between the firmware and cloud, or between firmware and UI, is much simpler IMHO, and forces you to write good abstractions for working in teams. On the other hand, hardware-firmware interactions are sometimes weird and ugly so one person needs to understand both.

[PlainName]

A software engineer will take out the debugger and doubts the hardware last

Actually, I think the software engineer will suspect the hardware. If the code was a problem it'd've been fixed, after all. Similarly, the hardware engineer will suspect the software is doing weird things with the decent hardware.

Were that not the case we'd all be able to spot our own bugs as we put them in the code, not much later when a colleague (or worse!) points out the simple and obvious typo.

[AVI-crak]

The scenario and application area are not defined and therefore:
Military and space equipment performs mutual testing of modules and units.
In the case when one part of the complex is missing or critically malfunctioning - the report is performed by the remaining parts of the system, including for the malfunctioning part. And after that, one of the many emergency state scenarios is performed.
It looks like this - you will die after the task is completed, but now work.

[SiliconWizard]

A software engineer will take out the debugger and doubts the hardware last

Actually, I think the software engineer will suspect the hardware. If the code was a problem it'd've been fixed, after all. Similarly, the hardware engineer will suspect the software is doing weird things with the decent hardware.

Yes, that's rather common too. It just all depends on how humble said engineer is. Young engineers tend to suspect anything but their own work, the exception being a minority IME.

[Siwastaja]

Yes, that's rather common too. It just all depends on how humble said engineer is. Young engineers tend to suspect anything but their own work, the exception being a minority IME.

I have learned to always suspect both my work and that of others are broken. Usually this is the case. The issue with code/hardware of others is that it's usually impossible or harder to fix and needs to be worked around, which is more work than fixing my own work. Therefore, having as much in my hands is helpful - I still do mistakes but can fix them faster - unless it's too much to handle within realistic timeframe.

[Nominal Animal]

I do more unit testing in the design phase than in the implementation phase.

I also usually create several test "firmwares" for the target hardware, using the algorithms and approaches verified in the design phase, to discover the behaviour and real world implications of the choices (mostly in isolation, thus "unit" testing).  Sometimes this yields a "no, that's not going to work", so I have to go back to the design phase.

Thus, the implementation phase for me is mostly about integration, and testing combined features and their interactions; much more integration and user testing than unit testing.

[hans]

A software engineer will take out the debugger and doubts the hardware last

Actually, I think the software engineer will suspect the hardware. If the code was a problem it'd've been fixed, after all. Similarly, the hardware engineer will suspect the software is doing weird things with the decent hardware.

Were that not the case we'd all be able to spot our own bugs as we put them in the code, not much later when a colleague (or worse!) points out the simple and obvious typo.

But as a first hypothesis? Code doesn't get magically fixed neither, so one would have to investigate that first. I wrote "last" in that sentence on purpose, as a final conclusion if all "own" aspects of a problem have been exhausted. E.g. some MCU firmware that occasionally locks up could also be caused by a failed (extended) memtest to external RAM. It's very hard to fix that with unit tests!

I think what younger engineers typically do, is they don't exhaust all their own options before pointing at something else. Ignorance is usually present for both, but I think one tilts more to arrogance ("Mount Stupid" of Dunning-Krieger curve in full swing), and the other is simply inexperience e.g. seeing your own mistakes is harder if you don't know about failure modes XYZ or what exact behaviour you're looking for.

[PlainName]

A software engineer will take out the debugger and doubts the hardware last

Actually, I think the software engineer will suspect the hardware. If the code was a problem it'd've been fixed, after all. Similarly, the hardware engineer will suspect the software is doing weird things with the decent hardware.

Were that not the case we'd all be able to spot our own bugs as we put them in the code, not much later when a colleague (or worse!) points out the simple and obvious typo.

But as a first hypothesis? Code doesn't get magically fixed neither, so one would have to investigate that first.

I wrote it as a bit tongue in cheek. Another way of looking at it is the classic man with a hammer way - the software guy is going to think in software terms; the hardware guy in hardware terms.

However, in reality I think it depends on where it is in the development cycle, ranging from first blood to "2m with customers". If you're actually writing the code then you will likely think that some problem is a result of what you're writing. And even if eventually it turns out it isn't - that is, it's a hardware issue - you'd probably still be thinking in terms of a software fix because the hardware is what it is and a change would range from 'not easy' to 'never happen'.