more pcf50606 patches

Andy Green andy at openmoko.com
Fri Jan 25 18:00:05 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
>>> 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).

Sounds like a good test to me.

>> - - 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

OK

>> This didn't make any sense to me... the ADC values are u16s, how can we
>> overflow a u32 multiplying them by 2400?
...
> 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.

Wouldn't be the first time gcc surprised me but doesn't stuff get
promoted to int before any arithmetic happens?

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHmhWVOjLpvpq7dMoRAu2IAJ0fOe1Quc5UwXJnO+9xhtnNK3fxWACfZobF
EApiXlLuoWYos/WF9Ht8uFs=
=fpax
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list