Closed GoogleCodeExporter closed 8 years ago
Nailed this down to two causes.
One is when EEPROM "file" writes take place. This is a definite and repeatable
thing (7 out of 10 times).
The other appears to be just general execution time glut occurring when using
PPM-in in classic trainer mode, with several mixs set up to make that work.
Capture ring overflows happen occasionally, seemingly due to mixer loop
processing time, among other things, of course. Anyway, this one was fixed by
double the captureRing size, from 16 to 32 uint16_t cells. However, even
quadrupling to 48 cells does not remedy the EEPROM issue. I'm thinking the
PPM-in ISR (interrupt) is probably being disabled during EEPROM file writes,
thus allowing the captureRd counter quickly catch up to captureWr -- and it
wouldn't matter how many cells were available, since nothing is being written,
if this is the case.
More investigation is required for that one.
Original comment by gru...@gmail.com
on 23 Dec 2010 at 12:52
This issue was closed by revision r423.
Original comment by gru...@gmail.com
on 23 Dec 2010 at 5:06
OK ... sometimes the problem is that the thing causing the problem just
shouldn't exist in the first place. That is IMHO the case here with the whole
captureRing thing.
Clearly, the original idea was to capture pulse-widths only, in the ISR
function, leaving analysis for some low priority main loop time -- thus saving
on CPU time during the ISR. HOWEVER, this scheme ultimately makes servo
response while under trainee control quite "jumpy" (not at all smooth), due to
the long time between each pulse-width update/process event.
So to cure that, and to eradicate the main cause of this issue in the process,
we now process each and every pulse as it arrives, inside the PPM-in ISR
function.
This is not as bad as it sounds, since it takes only a few micro-seconds to do
-- and the end result is not only worth it, but IMO, mandatory.
This fix committed to branches/frsky/ r423
Original comment by gru...@gmail.com
on 23 Dec 2010 at 5:11
Original comment by gru...@gmail.com
on 23 Sep 2011 at 1:52
Original issue reported on code.google.com by
gru...@gmail.com
on 21 Dec 2010 at 7:53