SparkFun Forums 

Where electronics enthusiasts find answers.

Your source for all things Atmel.
By altontoth
#58840
After having just spent several hours picking my friend's brains about how we could go about this, we discovered a code sample based on a PIC controller that gave me a couple of ideas. The programmer chose to use his Timer to run a 1mS pulse, which would increment a base counter, and at every 1mS interval, take a snapshot of the PORTA and analyze each of the inputs, thus ensuring that you don't skew results by checking in order of 1-5.

We contemplated this idea, but ultimately decided that it wasn't that great a benefit. We also pondered the idea of waiting for a pin change ISR to trigger (to which all 5 lanes would be tied). At this point the ISR would check each of the 5 lanes and compute times and mask whichever one had finished.

What I think we're going to go with is pre-loading the Timer so that it runs in 100mS overflows. Every time if overflows, the ISR increases a variable by 1. In the main code it's only polling each of the unmasked lanes continuously, and in a rotating pattern. No other code involved in this loop. Both the ISR and the main loop are short enough that there shouldn't be issues with multiple lane finishes at once, especially at 8Mhz. Any abort commands issued by the computer would by in a USART ISR.

Ideas?
By signal7
#58877
Sounds to me like it would work fine. Don't worry about having a perfect design - we were all noobs at one point or another. If the design you go with doesn't work to your liking, you at least learn what doesn't work (and it's not too hard to change it and try something else).
By SecretSquirrel
#58960
altontoth wrote: What I think we're going to go with is pre-loading the Timer so that it runs in 100mS overflows. Every time if overflows, the ISR increases a variable by 1. In the main code it's only polling each of the unmasked lanes continuously, and in a rotating pattern. No other code involved in this loop. Both the ISR and the main loop are short enough that there shouldn't be issues with multiple lane finishes at once, especially at 8Mhz. Any abort commands issued by the computer would by in a USART ISR.

Ideas?
No need to rotate through the lanes. Assuming all the lane inputs are connected to one port, read the port value and you have capture the the state of all the lane sensors at that point. You can then process the saved value.

Make sure and disable interrupts while reading your time values. You are still going to face a problem when reading your timer values. What happens when the timer rolls from 0xFFFF to 0x0000 right in the middle of the read? The best you can do is to read the TH byte first, followed by the TL byte. In this case, the worst you count will be off is by 256.

Also consider when you are figuring out the maximum time span you are trying to measure, your first lane trigger may not be at time 0. It may very well be at 10 seconds after you actually start measuring time.

--SS
By signal7
#59497
SecretSquirrel wrote:
Make sure and disable interrupts while reading your time values. You are still going to face a problem when reading your timer values. What happens when the timer rolls from 0xFFFF to 0x0000 right in the middle of the read? The best you can do is to read the TH byte first, followed by the TL byte. In this case, the worst you count will be off is by 256.

--SS
There is a slightly better solution to the rollover problem. Read the timer value, delay for 10 or 15 core clock cycles, and then re-read the value. If the difference in the values shows that a roll over happened, you can then just use the larger of the 2 values.

... or, thinking about it some more, you could just use the larger value in all cases since it's kind of like a double buffer operation. You don't need to test for rollover.

--Darrin