Saturday, August 18, 2007
Modeling firmware behaviour
What hasn't been fun, however, is trying to get the extruder head to follow a path properly from one point to another. Now that I have an absolute positioning readout it becomes obvious that my firmware routine for running the x and y axes is just a little short of nice.
Armed with all of my new understanding, on Thursday I started trying to write a new xy movement routine. I have an IDE to check my code against which lets me trap a lot of problems. I even have an API that will let me build forcing functions and quite complicated models of device behaviour to test my firmware.
The IDE, however, simulates every clock cycle of the CPU, which means that if you have an instruction like...
...in your firmware code, you can cook and eat supper without having to seriously worry about missing anything when you are simulating an 18F4610 running at 20 MHz. The net result of all that is that while the IDE is useful for preliminary debugging of firmware it is of limited use for detailed testing of complex firmware.
What I had been doing was to write my firmware code and use the serial link to output data about system operation on the fly. The problem with this is that the time that it takes the 18F4610 to transmit serial data about system performance is large with respect to the operations that I am attempting to do. That makes error trapping of real-time operations operating in the millisecond range more than a bit difficult.
(Read the whole story)