Hi!1
Yes, but in that case you might as well just purchase a coulomb
counter with a built-in accumulator and an I2C/SPI/microwire interface
save yourself some PCB space and cost (maybe)
Hardware is already given.
Well, Pavel attempts to implement a poor man's Coulomb counter or at
least
On 12/15/09 23:32, Somebody in the thread at some point said:
Hi -
Yes, but in that case you might as well just purchase a coulomb
counter with a built-in accumulator and an I2C/SPI/microwire interface
save yourself some PCB space and cost (maybe)
Well, Pavel attempts to implement a poor
2009/12/15 Bill Gatliff b...@billgatliff.com:
Aras Vaichas wrote:
Unfortunately the simple coulomb counting chips have the disadvantage
that the CPU has to be running to accumulate the pulses. Of course,
the pulses could wake the CPU from a suspend mode, but I'd rather not
do that just to add
Aras Vaichas wrote:
Yes, but in that case you might as well just purchase a coulomb
counter with a built-in accumulator and an I2C/SPI/microwire interface
save yourself some PCB space and cost (maybe)
Well, Pavel attempts to implement a poor man's Coulomb counter or at
least poor man's Ampere
On Sun, Dec 13, 2009 at 02:19:22PM +0100, Pavel Machek wrote:
...but then there are all the systems that rely on /proc/apm
emulation, like openembedded popular on sharp zaurus...
OpenEmbedded is a meta-distribution so doesn't use any particular
software here - I suspect you're referring to
On Sun, Dec 13, 2009 at 02:24:14PM +0100, Pavel Machek wrote:
actual charger hardware. My main concern here is that battery
performance monitoring has no pressing need to be in kernel and that
pushing it into the kernel creates a barrier to implementing more
advanced schemes in
2009/12/15 Pavel Machek pa...@ucw.cz:
Hi!
I'm not sure how familiar you are with the issues surrounding trying to
do a voltage to charge mapping for a battery but it's much more complex
than a simple table if you want to get it accurate. There's a lot
of
Well... current zaurus
Aras Vaichas wrote:
Unfortunately the simple coulomb counting chips have the disadvantage
that the CPU has to be running to accumulate the pulses. Of course,
the pulses could wake the CPU from a suspend mode, but I'd rather not
do that just to add one to a counter ...
Could you have the
One of the things we're facing is Android, which has
its userspace in plain Java JNI at the end of this link:
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=s
ervices/jni/com_android_server_BatteryService.cpp;h=8e7cadc6b680fc420d34
1faa094c71922946fdab;hb=HEAD
If
Hi!
If you browse down to line 275 you can see it parse the sysfs
attribute capacity, then this propagates up to the battery
status indicator on *all* Android phones out there. So if
you want to run Android unmodified, this is what you need to
provide. They are effectively using the
On Mon, Dec 07, 2009 at 09:27:20PM -0800, Brian Swetland wrote:
On Mon, Dec 7, 2009 at 8:56 AM, Mark Brown
I don't think the existing Android devices are much of an issue here,
it's not as though end users have the ability modify the firmware on
them (modulo the fairly small number of ADP
On Sat, Dec 05, 2009 at 02:08:11PM +0100, Linus Walleij wrote:
[Mark Brown]
Isn't the standard thing here to handle this voltage to
capacity mapping in userspace if we're just extrapolating
from experimental results?
That's an easy solution of course, but then the sysfs files
specified
Thanks for all the great attention Mark!
[Mark wrote]
On Sat, Dec 05, 2009 at 02:08:11PM +0100, Linus Walleij wrote:
(...)
That's an easy solution of course, but then the sysfs files
specified by the power subsystem, i.e. all charge_*,
energy_*, capacity and time_to_* loose their meaning
On Mon, Dec 07, 2009 at 03:07:15PM +0100, Linus Walleij wrote:
[Mark wrote]
These files should only be present if we have data for them.
Userspace can't be reliant on them at present since relatively few
systems seem to implement them, for example none of my laptops
have time_to,
On Mon, Dec 7, 2009 at 8:56 AM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
One of the things we're facing is Android, which has
its userspace in plain Java JNI at the end of this link:
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=s
On Fri, Dec 04, 2009 at 11:42:22AM +0100, Linus Walleij wrote:
However we want to override the default table with one fed in
though e.g. sysfs, so calibration data for the battery can reside
in the file system. NOTE: this table is NOT of fixed length, i.e.
we don't know how many (x,y) pairs
Thanks Mark, prompt answers as always.
[Mark Brown]
[Linus Walleij]
In our code we have a number of (x,y) pair tables like this:
/* Vbat mV to Battery capacity % */
struct voltage_vs_capacity {
int voltage;
int capacity;
};
Isn't the standard thing here to handle this
On Fri, Dec 04, 2009 at 11:42:22AM +0100, Linus Walleij wrote:
Most devices of this kind does not need the stuff we're doing so we're
the odd bird here. Other batteries are smart (contain factory
calibration inside of them) or get calibration from some BIOS or such.
In our code we have a
Linus Walleij linus.wall...@stericsson.com wrote:
[snipped]
Is probably not very elegant. (Or is it?) Would it be permissible to
pass in a table like:
cat /sys/.../v_vs_cap EOF
x0,y0
x1,y1
x2,y2
EOF
And have the kernel parse x,y pairs up to EOF?
Or would it be preferable to do
On Fri, Dec 04, 2009 at 10:49:31AM +, Mark Brown wrote:
Isn't the standard thing here to handle this voltage to capacity mapping
in userspace if we're just extrapolating from experimental results?
Even with the smart batteries in PCs there are some accuracy concerns
and obviously the
20 matches
Mail list logo
