Unit Testing Firmware

benjamin.forest

@JoergS5 great, let me know if you have some results, i'm quite excited by Klipper as well.

benjamin.forest

@dc42 Thanks. So how do you perform your tests ? only manually ? you don't have too much regressions ?

dc42

@benjamin-forest said in Unit Testing Firmware:

@dc42 Thanks. So how do you perform your tests ? only manually ? you don't have too much regressions ?

I put together a test schedule based on what I have changed. I test new and modified functionality. I also review the code changes carefully before committing. Finally, I do tests prints on Cartesian and Delta machines. I used to include SCARA too.

Occasionally, for critical stuff that is easy to get wrong and difficult to test thoroughly, I run a formal verification tool to prove that the code conforms to the specification. That's why header file ecv.h is #included and many functions have declared preconditions. A few (e.g. function TemperatureSensor::GetPT100Temperature in src/Sensors/Temperaturesensor.cpp) have additional annotations to facilitate formal verification. The fast integer square root algorithms in RRFLibraries/src/Isqrt.cpp were also verified using the same tool, but I did that offline so the formal annotations are not in the code.

I'd like to run formal verification on the entire source code, but RRF uses too many C++ features that the tool doesn't yet support.

In practice, most of the bugs that crop up are specification errors, not coding errors. Sometimes this is because there is no clear unambiguous specification for GCode commands. Other times it's because I hadn't forseen some particular combination of conditions.

infiniteloop

@dc42

So how do you perform your tests ? only manually ?

In your reply, didn’t you forget to mention your Agile Error Production Device whose distributed RT-Java AI, equivalent to the wisdom of 10k zen buddhists, intercepts any bug before you can even think of it? – TBH I still like to invent my errors manually

oliof

Releasing beta versions and RCs and collecting community feedback is also part of the testing regimen by the way (-:

benjamin.forest

great, thank you. I'll keep that in mind.

benjamin.forest

Hi,

Has anyone made any progress on isolating parts of RepRapFirmware ? I'm struggling to create a new kinematics, and the debugPrintf debugging method is not my favorite ...

On the other side, my quick tentative to extract a few cpp files from Movement folder lead me to Core.h and other deeply target-related files, so it seems quite intricated. Am I missing something ?

All the best,

JoergS5

@benjamin-forest unfortunately you're right, and it is even worse, because of CoreNG, which has references to the ASF libraries. Maybe you can get some ideas if you look into the LPC port of RRF what can be isolated and how.

dc42

There are other ways of debugging:

Later Duets (Duet 3 and Duet 3 Mini) have a SWD port, which a debugger can be attached to. That said, I rarely use it unless I am debugging a startup problem.
When debugging kinematics, enabling Move and DDA debug using M111 will produce quite a lot of useful debug output.

CoreN2G already replaces CoreNG for the Duet 3 Mini and the Duet 3 expansion boards, and will do so eventually for Duet WiFi/Ethernet and Maestro too.

benjamin.forest

@JoergS5 Thanks a lot. I've seen it was a popular fork, I'll look into it.
@dc42 Thanks as well. I'll try to get something out of Movement / DDA debug.