@mooselake Good thinking but there is very little constructing\deconstructing going on in this code. Almost all objects are created at startup and used throughout. See my earlier related post in this topic (though that post is more about dynamic memory use).
I do have a debugger, but can’t simulate what is being experienced as I am one of those without hardware yet. I have the arduino and can run the code but without encoder feedback, things get stopped up quickly. Anybody have any spare motors\encoders they want to loan me?
Not to mince words or cause a stir, but to be clear, just because it is firmware does not make it “real-time” code. Real-time is a term applied to code that is most often characterized by being deterministic (or very nearly so)… that is, the time required to execute a task will meet it’s deadline each and every time. Real-time code has very little variability in execution timing. Very often real-time is achieved through the use of a real-time OS that is specialized for switching task contexts using priority scheduling. The Maslow firmware does not utilize tasks nor scheduling, but is rather AFAICR (“As Fast As I Can Run”) code. One very useful thing about an RTOS is the protected access of shared resources (e.g. motors, memory, queues) such that they are accessed atomically, that is, a task owns the resource until it is completely through with it. Resource access is protected by using the semaphore and mutex constructs, that ensure multiple tasks cannot preempt each other until the shared resource is released by one task or the other.
Consider two timer ISRs that each fire a task, very closely one after another, that both want to access the same motor. Task 1 begins its movement of the motor to position X. The command to do so, may appear to be one pseudo-line-of-code: “Move motor 1 to Position X.” Beneath the covers of the high-level language though, that one line might be 50 lines of assembler code. The execution of the statement begins, but can only get through say 25 of its assembler lines of execution, before it is interrupted by Task 2 that wants to execute “Move motor 1 to Position Y”. What about the 25 lines of as of yet unexecuted code and the state of all of the registers when Task 2 begins? Chaos and unpredictable behavior ensue. This is why I advocate for anything that either task-switches or is interrupt-driven and uses shared resources, to be coded using an RTOS that can protect those resources and guarantee the atomic execution of the high-level code statements.
But I digress without adding any more value, so I’ll stop here. 