PPMIN captureRing buffer overflowing

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Plug in an external PPM source (another switched-off 9X will do)
2. Observe PPM calibration screen is working
3. Enter Model programming menus, change some mixes etc

A (n often long) error beep is emitted fairly often. Diagnosis confirms this is 
the PPM_IN captureRing buffer overflow warning tone ... 

gruvin9x.cpp:
ISR(TIMER3_CAPT_vect, ISR_NOBLOCK) //capture ppm in 16MHz / 8 = 2MHz
{
...
  if(nWr == captureRd) // ring buffer overflow
  {
    captureRing[(captureWr+DIM(captureRing)-1) % DIM(captureRing)] = 0; // destroy last value
    beepErr(); <========= HERE
...
}

Such an overflow should ideally never occur. Perhaps the call to evalCaptures() 
should be moved out of perMain() and into the already pretty busy per10ms()? 
Another option is to increase the buffer size (currently 8 x uint16_t)

I have noted that the main loop can take up to 38ms to complete, under certain 
(hitherto unknown) circumstances, as reported by the tmain value on the STAT2 
page. Hmmm.

(Note also however that the same issue occurs under ER9X on a stock radio.)

Original issue reported on code.google.com by gru...@gmail.com on 21 Dec 2010 at 7:53

[GoogleCodeExporter]

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

[GoogleCodeExporter]

This issue was closed by revision r423.

Original comment by gru...@gmail.com on 23 Dec 2010 at 5:06

• Changed state: Fixed

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Original comment by gru...@gmail.com on 23 Sep 2011 at 1:52

• Changed state: Verified