Friday, June 29, 2007

 

Breaking Programmer's Block

Last time I'd posted, I'd managed to build myself a minimal comm protocol for my control modules, text-based, so that I could communicate with them using a keyboard and a terminal program. This solves the chicken-or-egg problem of which comes first -- the protocol, or the program to communicate with the protocol; but crafting lists of raw packets like
418000f
4190001
41a0002
4111007
...to control the device clearly left much to be desired. It's easy to script a simple program to translate "MOVE 5 37" into raw packets, but more is needed of a control program than that; it has to parse replies from the nodes, and know when it has to wait for them to finish. This is the problem I spent the last few months banging my head against.

The breakthrough happened when I realized I could make the translator program and the control program seperate. The control program doesn't need to figure out when to wait, the translator program can tell it to wait.



418 sets the final motor position, 419 and 41a set the numerator and denominator of the movement speed. 14c is an acknowledge, 14e is "Operation Complete". @SLAVE tells the control program to expect "operation complete" in addition to the ack packets the control program always expects. 4111007 actually starts the motor moving. Finally, @SYNC waits until all expected replies have been recieved.

It works. I discovered a few obnoxious firmware bugs in making this -- deadlocking after 127 commands is a bug you're unlikely to discover when typing in commands by hand -- but now that they've been dealt with, communication with the motor control nodes is finally easy and reliable.

(There, I've replaced the obnoxious table with an image. Blogger should really fix the table problem someday...)

Comments: Post a Comment

Links to this post:

Create a Link



<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to
Posts [Atom]