Hey, Good Idea! Why didn't I think of that....Originally Posted by Ted's
So far, so good...To me an interrupt means:
-Stop the current main program.
-Execute the interrupt routine
-Go back to where you came from in the main routine.
Basically interrupts should show a possible way to create the impression of multithreading. But.
You're thinking too linearly...stuck inside a box.But imagine there is a servo motor. The motor needs a signal every 20ms to keep it's torque. So the interrupt starts the interrupt routine. The interrupt routine should take say 2 seconds. And within these two seconds there is the action of force onto the motor.
This is what I was alluding to when writing about the pauseus issue. This stands for reserving time within the interrupt routine.
Or do DT's includes make the pic execute the code (even the main code) by cycling through each interrupt each cycle of code execution? So using a 20Mhz quarz leads to processing a portion of each code every 0.2 us?
Keep track of a timer/counter that gets tipped much faster than every 20ms. Hit the servo, wait 20ms later (and servo's don't NEED exactly 20ms), hit the servo again.
If those LEDs I eluded to earlier miss a pulse completely, I'll see flickering. If one of those pulses is just a bit off, I most likely won't see anything...but quite frankly, they're solid, nice and smooth. So, from THAT programming standpoint, there isn't much of a difference between LEDs and Servos. Interrupts work great for me and a load of other people. You aren't any different.
I don't want to. Just making a point based on your last 'thread' (if we can call it that)....I appreciate that you want to answer my questions to my satisfaction. Then give me a code example showing how to do that with DT's includes.
And it's YOUR job to give US a code example of how to do anything with DT's Instant Interrupts...and WE will HELP YOU figure out why it doesn't work the way YOU want it to work.
And what's wrong with the examples in the instant interrupt threads?
Bookmarks