See comments for r1577 for details. Short version is that I found
a deeper root cause for the problem and corrected that instead
of the previous fix, which turned out to be a band-aid only.
I found that wdt_reset() was not being called in the scheduled interrupt
iservice routine because HEART_TIMER_PULSES was not being flagged in
serial transmit interrupt. This is needed because in DSM2=SERIAL mode,
there are no bit-bang functions being used and thus no HEART_TIMER_PULSES
'heart beats' to record.
I am at a loss as to how or exactly when this bug crept in. I have gone
over everything I committed since r1380 but cannot find anything
directly related. So I just don't know. But it's fixed now. Yay \o/
I also added/edited a bunch more code comments along the way to finding this.
-#if defined(PCBGRUVIN9X)
+#if defined(PCBGRUVIN9X) && defined(DSM2_PPM)
DSM2=SERIAL mode continuous WDT reset problem still present. Still
can't figure out why. Still working on it. :-/
Gruvin.
output frame, where correct pulse polarity was not always set
until the second call to setupPulses, from within the PPM mode
pulse train interrupt handler.
I tested proper function in PPM mode on the logic analyser
before committing.
adjustment is NOT required for the stock board. Thus, all the problems Cam and
I have witnessed appear to apply only to the ATmega2560 chip -- bringing the
total number of design bugs in said chip that we alone have now found to 3.
I do not have any ATmega128 based boards to runs tests there-on.
The only change here is to the code comment on the same topic.
only, until more timing tests on stock board can be done.
In case you're wondering, I'm planning on using the PB7 back-light
conection on an otherwise unmodified board, for those tests --
since PORTH isn't available and all. ;-)
and compensated for main clock synchronisation to get accurate 8us bit
lengths, as measured on the logic analsyser.
Specifically, all 1 and 0 bits now measure 8.000us in length, instead of
varyting from 6.250us to 10.750us, as before.
NOTE: A similar len-5 / len+3 compensation is almost certainly required
to improve bit timing on the stock board, in software bit-bang mode,
but I did not want to commit such a change to trunk without being
able to bench test it first. The values might differ slightly, due
to the number of instruction cycles executed before the actual
PORT B bit toggle code is reached. But it will NOT be the same for
both 1 and 0 bits.
ztrojanek@gmail.com