|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
|||||
|
|||||
|
streamlining IR code
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?
-Kesich |
|
#2
|
|||||
|
|||||
|
Re: streamlining IR code
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!
|
|
#3
|
||||
|
||||
|
Re: streamlining IR code
Quote:
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. |
|
#4
|
||||
|
||||
|
Re: streamlining IR code
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. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| What is your most prefered programming language? | Hailfire | Programming | 156 | 19-01-2005 21:42 |
| Interrupt timer, executing code asap? | SeanCassidy | Programming | 10 | 07-03-2004 01:47 |
| Updated Infrared Tracking Code | Kevin Watson | Programming | 0 | 18-02-2004 21:41 |
| Inserting Naviagation code into Default code? | actorindp | Programming | 3 | 28-01-2004 18:12 |
| Does your team use the Default code. | Jeff McCune | General Forum | 2 | 09-01-2003 14:46 |