Software emulator?

gnydick

Hey, I've built 3.4-dev cleanly, now what can I do with it? is there a software emulator for the board?

dc42

@gnydick unfortunately there is no software emulator. Although emulators for ARM Cortex processors exist, there are no emulators available for the microcontroller as a whole including peripherals.

gnydick

@dc42 ok, so what kind of setup do you have that let's you test a new version by instrumenting the board?

dc42

@gnydick we test the firmware in various ways:

When we implement a new feature, or make major changes to an existing one, we exercise the corresponding M-codes, checking that they return the correct responses, update the object model as expected, and have the expected effect. An example is the new M291 features in RRF 3.5beta.
When we implement modules that perform computations that are critical to the system but do not perform I/O, we may write tests for them or perform formal verification on them using automated theorem proving. Examples are the binary search function that is used for decoding PT100 readings (formal proofs) and the fast 62-bit integer square root code (formal proofs and tests as M122 subfunctions) and the fast floating point square root function used on some processors (tests as M122 subfunctions).
In some modules we have built-in checks on the output of those modules, and flag error conditions if those checks fail. An example is the code that prepares a movement record for step generation.
Where code should ideally never be executed, but it is vital that it behaves correctly if it is, we add test commands to exercise that code. An example is the hard fault handler (tests as M122 subfunctions).
Before every release, and whenever we make significant changes to motion control, we run test prints to check that the print quality hasn't deteriorated unexpectedly and that the Cartesian, CoreXY and Delta kinematics are behaving correctly.
We have M111 debug features that we can enable to get better visibility of certain internal operations.
Additional debug features are present in the code but normally disabled.
For checking things such as the uniformity of step pulse generation, we use an oscilloscope and/or logic analyser.

gnydick

@dc42 thank you, that's great detail. Is the test code, theorem proofs, etc. all on GitHub?

dc42

@gnydick the square root test code is built in to RRF as M122 subfunction P102 (it checks the results as well as doing timing) and the exception handler tests are M122 subfunctions P1001 to 1006. See https://docs.duet3d.com/en/User_manual/Reference/Gcodes#notes-16. The P102 subfunctions.

Unfortunately I omitted to save the proofs to github but I'll do that next time I run them. However, the original square root specification file (.pd file) and proofs (PDF) are at https://www.dropbox.com/sh/gnmhtf4xupz8kyw/AAAkxrbVZzgpWAxEhxS5zLD6a?dl=0. They were done at the algorithmic level rather than the code level, that is why I added tests in M122 P102 as well.

gnydick

@dc42 very cool. I'm self-educated and work in tech, and when I come across the truly esoteric stuff, I always appreciate the opportunity to learn about it.

dc42

@gnydick my aim is to verify mathematically a lot more of RRF. Unfortunately the verification software doesn't support some of the more advanced features of C++ used by RRF yet, so this is for the future.

We've also looked at building a test rig that can capture and record step pulses etc. so that we can more easily compare the behaviour of different firmware versions.

gnydick

@dc42 I watch a lot of videos about electronics engineering and the stuff people are doing these days is pretty cool given the high level interfaces are available right at the hardware now.

I'm curious, my impression of the product line is that it's meant to be very stable, prioritizing it above everything else.

Do you think it would be beneficial to open up more of the toolset to people who want to develop, debug, etc. at a more causal commitment level? Just one example is to document how to build a test rig? Maybe that's too complicated, so the next best thing would be to figure out how to make it less complicated and start from there? I don't really know the subject material that well, so my suggestions could be way off, but I think you get the gist.

One of the great things about open source is the amount of human-power you can get for effectively free if you make it easy enough for people to contribute.

For myself,

I wanted to try to write unit tests for algorithms, but I couldn't find a way to "run" the code. I didn't know if there were any entry points already there to make it possible to write unit tests; aside from starting from scratch with some OTS unit testing framework and start figuring out how to mock, exec, etc. Any pointers?