is there any reason why one can’t turn the 4 interupt handlers into function with an extra argument telling which ir sensor picked it up? it wouldn’t be that hard, but maybe two interupts may be caled at the same time and they might fight eachother. who knows? do you?
Wouldn’t it be that one is called, then in the middle of it the other is called? It would just bog down the proc, I think. try it!
It completely depends on your definition of “streamlined.”
Generally speaking, you want interrupt handlers to be as fast as possible and to do as little “work” as they can. From this perspective, duplicating large sections of code is more desirable than calling a subroutine, which will cause a “context switch” so to speak… Push the stack down, create new local variables, etc…
With that said, the overhead involved in calling a subroutine is very small, so it might be worth it to save code space by using a generalized function. As for two interrupts fighting with each other, the setup at present is that all 4 IR sensors are tied to the single low priority interrupt pin, so they’ll never fight each other.
Other than that… Try it and see. I’m about to massively re-work the IR tracking code to use a single tracker with 3 IR sensors rather than 2 dual sensor trackers. The idea will be to have the middle sensor have nothing but a very narrow tunnel vision. I’ll let you know if I run into problems generalizing the current implementation.
We don’t need 2 trackers to calculate distance, we’ll be using the tracker mostly for turning, so it’s more important for us to get a dead-accurate lock on one of the beacons.
I implemented my own receiver and tracker code last night and today, heavily modeled after Kevin’s code. I generalized the receiver code such that all receiver interrupt pins call the same function and just pass a pointer to an ir_receiver structure which has all the necessary elements in it.
The tracker code likewise takes a pointer to a tracker structure, which in our code contains pointers to 3 receiver structures.
There were no problems re-working kevin’s code to my own. He had already structured it well enough to be a single function, not quite sure why he didn’t just generalize it to being with. I guess it’s much more readable and understandable to people who aren’t familiar with multiple levels of pointer dereferencing and passing.