Thanks Alan, I’ve read the sensor manual now. And noted that the Gyro and Accelerometer are to be mailed to us.
Does anyone think that any rule prevents use of last year’s gear tooth sensors in this year’s robot??
Bud - yes, your routine is quite clever and provides a two-priority interrupt priority scheme, that is not quite as recursive as I had thought on first glance, and that would reduce jitter caused by ISRs that consume larger quantities of instruction cycles (by placing less-frequently-called ISRs containing large code-blocks inside your slow_isr loop).
The result could be more accurate pulse-length measurements - the topic of this thread. Thanks for sharing the code with us.
Last year’s GTS board is not available for purchase. It does not meet the requirement for an off-the-shelf component or assembly. But you could create your own equivalent custom circuit this year using the actual sensor from Allegro. You’d have to account for the cost of it, though (even if you got it donated).
To be even more clever…
Now that you have code executing asynchronously from user code driven by interrupts it is an easy matter to also add a general event handler, to say run something every 10ms or to run a routine every 10th time a sonar sensor completes a measurement… You can still starve off the real user code that is waiting for all this processing to complete, but it does make some things like collision detection a lot easier without having to poll and without further impacting interrupt latency. And besides, by the time slow isr is run you’ve already paid the penalty for saving off the .tmpdata and other sections.
I happen to have an asynchronous event handler written and bench tested…
Bud