Quote:
|
Originally Posted by IrisLab
Actually, that 17ms contol loop is just off the top of my head. I can't remember the time, but I believe that's close. However, that number is only approximate. The control loop is not guaranteed to be every 17ms. If your code becomes too long, you'll stretch beyond that 17ms cycle easily. The 17ms is NOT guaranteed.
|
The 17ms figure is correct for the EDU bot (it's ~26ms for the full size)
However your code should NOT take that long to execute. If it does you will start having problem with missing communication packets from the OI. If you take too long (not sure of the exact time) the master microprocessor will shut down the robot (since it figures that the user code is stuck in an infinite loop).
That being said, assuming you keep your user code relatively compact. The user code (specifically the function Process_Data_From_Master_uP() ) should execute fairly close to every 17ms. From what I can determine, the timing is controlled by the reciept of data from the master micro.
Quote:
|
Originally Posted by Anthony Kesich
Thanks IrisLab. Thats exactly what i thought it was, but i wanted to confirm. Seeing as 17ms is just faster than 1/59th of a second, it seems to me that interupts are overkill and you could make much better use of your programming space (800 lines), but i'll still keep them in mind if they ever become a necessity.
|
I'm not quite sure where you are getting that 800 lines from, would you care to elaborate on it?
Also, while 17ms is approaching the upper limit of human reaction times, it can be, (though not always) an eternity in a computer. For instance in 2002 I was trying to design a system to keep track of what zone the robot was in at all times. (If you're not familiar in 2002 the playing field was divide into 5 sections by 1" strips of tape). However, one of the problems that cropped up was that if the robot was moving at any sort of reasonable speed, the sensor would not detect the crossing of the line becuase it would only be high for a really brief period (5-6ms I think).
So unless the program just happened to be checking the sensor during that brief period, it would never know that there had been a line. Now, If there had been interrupts on that controller, I could have used those to immediately (well within a microsecond or so) known that I had crossed the line.
And while you could design some external hardware involving a latch, to detect the pulse, it would add complexity and additional things to fail.