Extruder temperature bug (almost) eliminated

For ages (sorry) the extruder's temperature measuring function hasn't been working properly, giving dud low readings intermittently.

I spent the weekend working on the code and have improved both the Java end and the PIC C end. (I have updated both in the svn trunk and also updated Simon's autoconf-firmware branch).

Here's a summary of what I've done:

JAVA:

The Java now takes a majority vote between the last three temperature measurements; this reduces the impact of isolated dud measurements (the temperature can never really change very fast, because of thermal inertia).

PIC C:

The PIC C code now detects when the capacitor charge/discharge timings are interrupted and discards such measurements, only keeping clean ones. Unfortunately, with largish capacitors, the measurements are always interrupted because of the times taken to charge and discharge, so this means reducing the capacitor otherwise one never gets a reading... For the standard thermistor (beta = 3480; Rz = 29K) this means a capacitor of 10nF. I have modified the calculator in the wiki to put in a fudge factor to give this and have changed the extruder controller PCB wiki page to say this, but more thought there is needed.

I have reduced the frequency of the heater PWM interrupts by reducing the value of HEATER_PWM_PERIOD from 255 to 253 'to calm things down'.

I have set the main loop so that it doesn't call the temperature measuring function each time round, as that used to mean that the PIC spent all its time in that function, making large the probability that it would be interrupted and cause trouble*. The heater pwm function now sets a flag, and the temperature measurement function just gets called once after that flag is set. (Having the function instead called as a result of the heater pwm interrupt would cause further trouble, I suspect, so I didn't do that, even though it's more obvious.) This means that the extruder PIC spends most of its time spinning in its main loop waiting for something to happen.

*Actually this is a statistically spurious argument: if interrupts occur in a Poisson distribution (which they don't, but never mind) then the function is just as likely to be interrupted, but any given interrupt is less likely to interrupt it. As it is, interrupts are quasi-regular, which has the same effect. But anyway it seems to work better...

RESULTS:

All this seems to make the temperature readings a lot more stable. But you still get the occasional dud. I suspect that this is a timing issue between my majority-of-three vote in the Java and the interrupt rate in the PIC. The Java is taking its readings too rapidly - more experiments will be done...

The much-reduced capacitor value means that the temperature auto-ranging runs vRefFactor up to 15, where it more-or-less stays. This is probably a bad thing - more experiments will be done...