HALifying/32bitting the Portable module

ChargeCycles – How many charge/discharge cycles the battery has gone through

What would constitute a “charge cycle”? What if the user plugs in for 10 minutes and then pulls the power? Would you say a charge cycle is a complete change from <=10% full to >=90% full and back to <=10% full or something?

It’s quite loosely defined, but AFAIK the battery’s microcontroller keeps track of it. Good for keeping track of the battery’s age.

http://batteryuniversity.com/learn/article/discharge_methods

In any case, nominal versus usable capacity is a very useful figure – you can calculate a wear percentage from it, and alert at a certain percentage when it’s time to replace the battery.

It’s quite loosely defined, but AFAIK the battery’s microcontroller keeps track of it.

Yes, so far all the BMU variables that the new code supports are values that come directly from the microcontroller. Well, apart from the nominal capacity, but that’s a simple hardcoded value rather than any dynamic value that needs to be tracked even when the machine is off.

The first version of the new BMU code and the first version of my new BatMgr are now in CVS, and Pandora/TouchBook users should be able to see it in action in a few hours time once the new ROMs have been built. Since I’m interested in feedback on the look of the new BatMgr, here are a few screengrabs:

The third pic is for the TouchBook, hence the two batteries. And as you’ve probably spotted there’s no charge percentage for the top battery (tablet battery) or time remaining displayed – although the TPS65950 is OK for charging batteries, it’s a bit lacking when it comes to reporting on their state to the host. Hopefully I’ll be able to find a way to improve things in the future.

Updated documentation for the Portable module should come in the next few days.

Very nice work. It looks and works fine on my Pandora

Many thanks.

I assume there’s no hope for a Lapdock version.

Looks like the Lapdock doesn’t report its charge to the USB host (and you have to manually check the battery level by pushing a button on it, even if you’re actually using a Motorola phone), so no.

As far as the styling, I’d say that on a single-battery system, the battery icon should be higher – probably halfway between the two positions – to make the whitespace look less wasted. On the Touch Book, though, I’d have a way to indicate that the dock battery is gone, but still have a place for it.

@Jeffrey: Very nice indeed. Not got any hardware to try it on, but from the screenshots it looks great.

On the Lapdock, I guess it would be possible as a far-from-ideal alternative to create a sort of dummy battery monitoring device that reports a linearly diminishing state of charge to the BatMgr, and has a bit of additional software to kick the charge state back up to the max. that you manually trigger through a UI when you know the battery is fully charged. Perhaps not worth the effort, but would give you a vague idea of where you’re at as long as you always start from a state of full charge.

As far as the styling, I’d say that on a single-battery system, the battery icon should be higher – probably halfway between the two positions – to make the whitespace look less wasted.

Noted.

On the Touch Book, though, I’d have a way to indicate that the dock battery is gone, but still have a place for it.

Already handled; any batteries which are reported as missing will be shown dark grey.

Does the Pi have any voltage monitoring on the power rail?

I would assume not.

Even if it does, it won’t be useful, as the rail that it would even be able to monitor will be after a voltage regulator.

That said, if you’re directly attaching a battery, you might get lucky and have an I2C battery controller or something.

Had the opportunity to play around with Raik’s Pandora a bit yesterday. While it’s not the sort of hardware I’d be interested in for myself I was quite impressed by how well everything seemed to work. Especially the battery monitor, well done Jeffrey!

Thanks! I’m just glad that I can get the battery level, time remaining, etc. straight from the BMU instead of having to employ lots of guesswork like the A4/Stork versions of the Portable module did. Of course there’s still the TouchBook tablet battery to sort out – if the worst comes to the worst, I think I’ll have to try using a voltage → charge level lookup table to at least get something better than the 4 voltage thresholds which BatMgr will currently show.

The wiki docs are now (I think) fully updated:

• BMU variables
• BMU status flags (aka BMU variable 10)
• BMU device flags (not to be confused with status flags!)
• Portable_ReadBMUVariable and Portable_ReadBMUVariables for reading variable(s)
• Portable_EnumerateBMU for discovering BMUs and their basic functionality
• HALDevice_SysPeri_BMU should anyone feel like implementing support for a new BMU.

Features still todo, in no particular order:

• Better TouchBook support
• BMU event generation, with associated BatMgr bits (updating immediately when charger connected/disconnected, low battery warnings, etc.)
• BMU device implementation for the OMAP3 RTC backup battery. Preferably with Portable_WriteBMUVariable used to control the charge settings, although that may require some further API tweaks so that a fairly generic configure plugin would be able to determine which voltage/current settings are supported by any particular RTC BMU.