Still analyzing the software functionality. Thor poses an interesting problem since it has 7 stepper motors involved that all must behave like one entity.

It is tempting to experiment with software to control the robot but forget that this robot is not a toy and could be pretty harmful.

First of all fire hazard, big motors in a confined space that may cause toxic fumes or start a fire hazard. Don't forget that the main body of this robot is plastic!

Secondly these are powerful mechanical devices and one wrong bit can can make the robot go into the wrong way hurting people, kids, pets and the payload. Just one tiny bit!

In order to gain CPU speed and less calculating when creating the FIFO memory to execute the stepper motors playbook made me realize that I need to define a static memory block. And use pointers to point to the next part to execute.

The idea is that the robot is executing pre-calculated steps while the other part is busy calculating new points for the next block. This avoids thread locks because you never read and write in the same memory space at the same time. The only thing that needs thread protection is when you switch the execution pointer.

And here is the main safety issue. A bug in the software could point to the wrong memory location and the robot starts to execute the wrong commands. The robot could suddenly move into the wrong direction or erratically.

If this was a none mechanical device then there would not be an issue. But in a real world mechanical device, we have inertia to think of and we want to move our mass as smooth as possible.

I am thinking of additional bit patterns that must or must not occur at predefined places in the FIFO indicating that the executing stepper commands are wrong and the robot must come to a safe positron.

Because I am using an Timer1 interrupt driven execution FIFO, I can also play with the interrupt timer interval and actually slow it down when an error occurs. I have to read up if I can modify the timer interval dynamically.