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