Stephen,
Quote:
|
Originally Posted by stephenthe1
I've been going through a tutorial for using interrupts ("interrupts for dummies") and another one titled ("quadrature encoders"). this may be a vague question,
|
No, they're great questions. I'll update the source code with additional documentation.
Quote:
|
Originally Posted by stephenthe1
I'm not sure. but what is "Port_B"? and what is "0xFF".
|
Assuming you're referring to my code, here's a description of the three variables:
"Port_B" is a working copy of the input port where the state of the interrupt bits can be read. You need to take a snapshot because their value may change at any time. If, for example, interrupt 6 changes from a zero to a one and then quickly changes back to a zero before you get around to checking it's state, you're stuck servicing an interrupt without knowing which of the four inputs caused it. This is why I grab a copy of PORTB first off.
"Old_Port_B" is the state of the port the last time an interrupt was generated. Because four inputs are mapped to one interrupt, you need this information to determine which of the four inputs changed and caused the interrupt.
"Port_B_Delta" is the exclusive-or of the above two variables. The exclusive-or of two bits returns a one if the two bits are different, zero if they're the same. Later on, I check all four bits to see if they're a one, meaning that they've changed since the last interrupt was generated. You need to check each bit because one may have changed between the time another bit caused the current interrupt and the time you sampled PORTB. If you didn't do this, you might miss a valid interrupt-causing event, which is a really bad thing to happen.
Quote:
|
Originally Posted by stephenthe1
...what are state machines (based on the current encoder position). are they used to determine what part of the "cycle" the encoder is going through.
|
Yes, exactly. A state machine is a construct that allows software (and hardware) to keep track of what's happened in the past. To use an analogy, it's kinda like Drew Barrymore's character in
Fifty First Dates, who doesn't remember what happened the day before when she wakes-up the following morning. If she just left a note to herself each evening with her current marital state <unattached/dating/engaged/married>, she wouldn't have a problem the following morning <grin>. It's the same thing for software. By just changing the state variable (think Drew's note) before leaving a function, you'll be able to pick up where you left off the next time the function is called.
Quote:
|
Originally Posted by stephenthe1
...lastly, just a thought, is does Port_B tell which of the 4 interrupts (4-7 was fired?), because these particular four are all identified under the "same name."
|
Yes, as I described above.
Quote:
|
Originally Posted by stephenthe1
...and then the 0xFF, where "FF" identifies which of those four ports was interrupted?
|
If nothing is attached to the PORTB pins, their state will be read as all ones, the 0xFF is just my best guess of the state of PORTB when software starts execution. If you take a look at the Initialize_Interrupts( ) function, you'll see that I initialize Old_Port_B with the real state of PORTB just before I initialize the interrupt.
-Kevin