I haven't followed the description through fully but here's what seems sensible to me (but may, of course, not be). Motor rate for a given error should be constant in the absence of any new information re changes in the error. For a given error signal the motors are fed a constant frequency pulse stream. At the end of each pulse the processor reads an error signal and adjusts the frequency of the pulse stream accordingly. Simplistically one could imagine the error signal being provided as a parallel 8 (or more) bit word on a data port to be read in a single port read and used to reset the timer for the next pulse. If desired the changing error could be filtered, probably by the sending processor or the receiving processor to modify step changes in some manner (moving average, PID, whatever ...). The actual application of a pulse would seem to require the relatively trivial task of reading a parallel word and setting a timer appropriately. But perhaps I've missed the point fairly thoroughly. Russell McMahon ----- Original Message ----- From: "Jinx" To: Sent: Monday, June 24, 2002 11:21 PM Subject: [PIC]: Serial timing dilemma > I've got a head-scratcher in the last stages of a gyro project > > The gyro puts out 38k4 data bursts at the rate of 75 - 77 bursts > per second. The information in the data is converted to a number > of pulses that are sent to motor drivers. Everything is working.... > > .....except. The motors really perform best when supplied with > evenly-spaced pulses. At present each motor is set to require > 1200 pulses to move a gearbox 1 degree > > The problem is that the bursts (as measured from the end of the > fifth byte in one to the end of the fifth byte in the next) are not evenly > spread, and can be anywhere from 11 to 14ms apart. > > The first version used a single F877 to read the data and generate > the pulses. To do this I had to take the worst-case timing of 8ms free > time for motor pulses (which may be only a few us apart) before the > micro had to return to picking up data. This meant there could be up > to 6ms when the motor wasn't receiving pulses, which caused very > unacceptable jittering. Now the circuit has been split up into an F628 > to read data and 3 others - one for an LCD and one each for taking > the calculated spacing from the reader to generate pulses. However, > as can be seen in this diagram > > http://home.clear.net.nz/pages/joecolquitt/timeline.html > > the problem has arisen again, although hopefully there is better > hardware in place now. I'm trying not to think of it as "re-arranging > the deck chairs on the Titanic". What will happen is that a short > interval following a long interval will cause a driver PIC to still be > in the throes of putting out pulses when it is told to stop that and > pick up new data > > The only way I can see out of this is to cause an IRQ on the driver > PIC and temporarily suspend its pulse activities whilst it picks up > that data, and then uses the new spacing at the end of the current > run of pulses > > This sounds workable. Any reason why not, or better solutions ? > > Losing a few pulses here and there shouldn't (touch wood) be too > much of an issue. I thought of taking the serial data and re-transmitting > it at a more regular rate, but I don't think that will work out because > of the unpredictable nature of the gyro's timing. Sooner or later the > PIC and gyro will get out of synch > > TIA > > -- > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > email listserv@mitvma.mit.edu with SET PICList DIGEST in the body > > > -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body