Quote:
|
Originally Posted by Larry Barello
According to the C compiler manual you need to save additional context when calling functions that return values. Specifically, for 8 & 16 bit return values you need to save 'PROD'. I believe it is page 28...
Team 492 samples the ADXSR150 at 100hz (10ms). Our basic logic is a 1khz timer that increments a byte counter (atomic operation). In the fast loop of the IFI code we check that counter and do stuff when it increments.
The fast loop is called often enough to sample the timer directly (e.g. no interrupts) but we used them anyway in case some code in the Autonomous routines took longer than a milli-second to run.
|
Yep, I'm saving PROD as well as .tmpdata. But Get_Analog_Value uses other SFRs which I'm not saving, and it would do no good anyway I guess, since if one Get_Analog_Value is interrupted by another, the first one will get a mangled value at best anyway. I suppose a possible solution is to disable interrupts in the main code while using Get_Analog_Value.
Your code suffers in a way I was trying to avoid, but may well be insignificant. But here's my issue with it anyway: the "fast" process executes really often, as you say, probably well in excess of 100 kHz, but clearly depending on what you do in it, EXCEPT when data is ready from the master processor. Then the "slow" process is called, and the "fast" process doesn't get called at all while that is happening. In my case that's about 10ms, so I miss a couple of the 4ms interrupts. You code partly deals with this problem, since it counts up 1ms interrupts and later uses them all up, even if more than 10 of them happened without any "slow" process service. So what will happen in your code, if the "slow" process is longer than 10ms, is that sometimes the 10ms code will get called at different than 10ms intervals, causing some jitter in your sampling rate. You'll get the right number of calls, just not at precise intervals. If your slow process does not exceed 10ms, your code is perfect. In my case the desired sample rate was 4ms, and I couldn't get the "slow" code to run that fast, so I miss samples. I should at least switch to your interrupt counting method so as not to miss samples, only have some delayed.
Hope this long post was not too incoherent. Thanks for the code snippet. Even though it's not what I wanted, it's an improvement over how I'm doing it and I'll use it if I can't solve the problem another way.
Bill