more pcf50606 patches

Andrew Paulsen andrew.paulsen at gmail.com
Fri Jan 25 17:32:52 CET 2008


> > Bugzilla Bug 1181 - Battery temperature is incorrect
> > http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1181
>
> Is it for sure true that the 10K does not exist INSIDE the battery unit?

I would say that it has to be true, but I don't know what is actually
in there.  If you take an Ohm measurement from the thermistor terminal
to the ground terminal on a battery, you can get numbers higher than
10k.  I put a known thermistor next to the battery and let it run at a
few different loads and the new calculation tracked the reference
measurement correctly (there was a +4C offset, which seems reasonable
since the thermistor is inside the battery packaging and my reference
was outside).

> > Bugzilla Bug 1182 - Charging current measurement is incorrect
> > http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1182
>
> ''- Least significant bits of ADCIN1 were not shifted correctly
>
> +               *data2 = (adcs1 << 2) | ((adcs2 & 0x0c)>>2);
>
> OOOH yes it was definitely broken, good catch.
>
> - - A 6V reference voltage was assumed, but a 2.4V reference is actually
> used
>
> Don't have time to examine this, sounds credible.
>
> - - Math could result in negative values, but unsigned types were used
>
> OK.. I guess this means that -mA means charging.

It's the other way, actually.  We're measuring charging current so -mA
indicates discharge or pushing current back to the charger.  While
this isn't possible due to a diode, there is enough noise in the
measurement circuit that you could get slightly negative numbers when
the real current is near zero.  Rather than truncate or underflow an
unsigned integer in this case, we should simply used signed numbers.
That way, if we want to add a software filter, it will work as
expected.

> - - Explicit type casting was added to the calculation to correct a
> possible overflow''
>
> This didn't make any sense to me... the ADC values are u16s, how can we
> overflow a u32 multiplying them by 2400?

Here is the section of code in question:
-	u_int32_t res = ((adc_adcin1 - adc_batvolt) * 6000);
-	return res / (pcf->pdata->r_sense_milli * 1024 / 1000);
+	int32_t res = ((int32_t)(adc_adcin1 - adc_batvolt) * 2400);
+	return (res * 1000) / (pcf->pdata->r_sense_milli * 1024);

adc_adcin1 and adc_batvolt are both u_int16_t.  Multiplying them by a
large number before implicitly casting them to a u_int32_t is what
could cause the overflow.  That is why I made an explicit caste before
the multiply.  Again, I changed it to a signed type.

Andrew


> - -Andy
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFHmgkKOjLpvpq7dMoRAiaIAJ9r/g2aFBfWODeNWcOlsZ5KZGxmvgCeKG9d
> O/sQBtDDcqAtGBniln60QXU=
> =ho4p
> -----END PGP SIGNATURE-----
>




More information about the openmoko-kernel mailing list