HALifying/32bitting the Portable module

What’s ROOL’s preference for how I should manage the source code for the HAL/32bit version of the Portable module? Stick it under a new HAL branch in CVS, or just overwrite what’s already there?

For the moment I’m just aiming for a Portable_Idle implementation that uses the WFI instruction, so not much (if any) of the original code will make it into the first version of the 32bit version.

I suspect as it’s not even 32-bit, you may as well develop the trunk version. If we ever need to create a version for older architectures but that’s also 32-bit, then we’ll either do it with conditional assembly of your version or branch off.

What you can’t see from the public repository is that various (unreleased) variants of the Portable module in directories alongside it. A bit like Sound0 has been handled recently.

IIRC, the one in the public CVS repository is the one for the Stork (the unreleased Risc PC portable). As such it’ll have all the functions for battery management, LCD control etc. However, I think its only purpose in current builds is to provide its header file.

There’s also PortableA4 – the version for the A4 (the Archimedes portable), which is fully featured. I believe all the other variants only implement SWI Portable_Idle – separate modules in each case because traditionally the way you suspend the CPU is different in each implementation, so it’s nice to see ARM standardising it with the WFI instruction. I remember discussing the lack of HALization with someone once, and the answer was it’s just laziness – since it’s only a matter of changing a single poke, nobody could be bothered to go to all the trouble of defining a HAL API for it.

I’d suggest putting PortableHAL alongside, if only because the initial implementation will be so cut-down. The original Portable module serves as an illustration of how the battery/LCD SWIs are meant to operate, which may be useful if they are implemented in HAL machines in future.

Note to self: we should probably add Portable75 (the variant for the 7500FE, the only IOMD machine with a CPU suspend function) to the list of things to release.

OK, I’ll add the new version as PortableHAL.

Having the other versions released into CVS would certainly be useful. The Stork version of the module in CVS has a couple of SWIs that are commented out, and a couple more that have been disabled via conditional assembly – it would be good to know if they were ever used, and if so, how. Likewise for the other modules – I don’t want to go adding a new SWI ontop of an existing one.

Just to complete Ben’s little list for other uses of the Portable module:

The A9 has a Portable module for something, though I’m not entirely sure what. It might be something to do with Portable_Idle again, I don’t know.

VRPC has a Portable module that talks to Windows to read things like battery state etc. Uses exactly the same calls as the A4.

RPCEmu gained a Portable module this afternoon. Only for Portable_Idle support for the moment.

I’ve now got a rough plan on how to extend the HAL version of the Portable module to deal with all the power management things that are needed by the OMAP port (CPU speed control, battery charging/monitoring, suspend-to-RAM, etc.). I’ve also put together a rather large feature matrix showing which features are implemented by which variant of the Portable module. With any luck I’ll have both of the above up on the wiki in the next day or two.

Right, here’s my plan for how I’m going to extend PortableHAL to deal with the OMAP power management stuff.

CPU speed control

The existing Portable_Speed SWI only provides two speed choices, “slow” and “fast”. This isn’t as flexible or as informative as I want it to be, so I’m proposing the following:

• A new SWI, Portable_Speed2, which will accept a reason code. Supported reason codes will be:
  • Report current CPU speed in MHz
  • Report min & max CPU speed in MHz
  • Set ‘slow’ and ‘fast’ speeds in MHz
  • Report current ‘slow’ and ‘fast’ speeds
• Portable_Speed will be implemented as per the current specification, and will simply set the CPU speed to the configured ‘slow’ and ‘fast’ speeds as appropriate

Note that there’s no ‘set CPU speed’ call; this is to avoid confusion/conflicts with Portable_Speed. If software wants to set the CPU speed to a specific value (or even disable Portable_Speed entirely) it can simply set appropriate ‘slow’ and ‘fast’ speeds instead.

HAL interface

The module will most likely defer to a HAL device for all activities – setting the clock speed, reporting current/min/max values, etc. But I haven’t yet read up on the full details of what’s required in writing a SmartReflex driver, so this plan may need to change a bit.

Also I know that people like to overclock their OMAPs, due to them being rather overclock-friendly. To cater for this I’m thinking of adding a call to the HAL device which will allow people to overwrite the table that the HAL uses to determine the frequency/voltage values. This will allow people to overclock their OMAPs at will, without polluting the Portable’s SWI interface with something very CPU-specific. Obviously people will have to be careful with what they’re doing, but it shouldn’t be any more dangerous than what they’re doing now if they’re using modified versions of my ‘opp.bas’ program.

Battery management

The existing BMU API is poorly documented (no mention of what units any of the measurements are in!) and inappropriate for some machines (the interface only supports one battery, but the Touch Book has 2 and the Smart Book has 3). So with this in mind, I’m proposing the following:

• Only a small part of the existing BMU interface will be implemented. Mainly varibles 10 and 18 (the status flags) and perhaps 21 and 22 (if I can work out suitable battery life estimates).
• Since BMU variable 10 is going to be implemented, so will the BMU event, and the related Portable_CommandBMU reason codes.
• I’m in two minds about how to handle multiple batteries. Should we extend Portable_ReadBMUVariable/Portable_WriteBMUVariable (i.e. encode the battery number in R0), or add extra reason codes to Portable_CommandBMU for reading the state of each battery, or add an entirely new SWI?

HAL interface

Each battery will be a seperate HAL device, and the module will defer to those devices for all status updates, etc. However this won’t work too well with BMU variables 21 & 22, so it might be that some extra magic is needed for that. I might just make it so that the module asks the primary battery and assumes that the device knows how to take into account the effect of the other batteries in the system.

The “lid open” flag in BMU variable 10 obviously isn’t anything to do with the battery, but it should be easy enough for the Portable module to report on it via a suitable HAL device.

Suspend to RAM (aka Portable_Stop)

The Stork version of the Portable module supports this, with keyboard wakeup, and seemingly unimplemented/nonfunctional RTC wakeup. My plan is to support both, using the existing Stork APIs:

• This would involve implementing Portable_Stop, *FreezeTime, and the related Freeze/Unfreeze/FreezeRequest service calls.
• Although I haven’t seen any docs about it, I think it’s safe to assume that it would have been Acorn’s plan that individual driver modules would listen out for the Freeze/Unfreeze service calls and take the appropriate action to suspend/resume their hardware devices. So there are a few modules I’ll have to update to deal with these service calls.
• Although the Stork version (kinda) supports wakeup from an RTC event, there was no API defined to allow people to program when the wakeup time should be. So I’m proposing a new SWI, Portable_WakeTime, to allow the wakeup time to be read/written, using a standard RISC OS 5 byte time.

HAL interface

• The Portable module will defer to a HAL device in order to perform the last steps of the suspend/unsuspend operation. This device is also likely to contain the code that’s responsible for determining the wakeup reason.
• Individual driver modules will perform suspend/resume manually or via a HAL device, as appropriate.
• For programming the RTC wakeup time, I’m thinking it’s best if it’s handled by the HAL RTC device. All the Portable module would do is contain similar code to the kernel to convert the 5-byte RISC OS time to a BCD time for passing to the RTC.

General hardware monitoring

I think it would be nice if the Portable module was able to report things like the CPU temperature, system power consumption, etc. This would be done via a new SWI (Portable_Status2? Portable_Monitor? Portable_Sensor?) which would provide a list of the detected sensors and allow their description, data type, and value to be reported. Internally each sensor would be a seperate HAL device.

Other

• The Portable_CommandBMU ‘remove power’ call can easily be reimplemented as a call to OS_Reset “&OFF”
• Portable_Status and Portable_Control will likely be left unimplemented, due to being too hardware-specific. Although Portable_Control could be used to control the backlight of the Touch Book/Pandora/etc. LCD, I think it’s better if that job is left to the new GraphicsV API. All the other bits (audio power, floppy/HD power, etc.) should really be managed by HAL devices owned by the relevant hardware driver modules.
• Not entirely related to the Portable module, but I’m thinking that the HAL RTC device should have code added to it for programming the RTC battery charger. The Configure plugin for setting the RTC battery charger parameters can then look for a supported HAL device and allow the user to choose the appropriate settings, which will then get saved to NVRAM. On boot the Portable module (or perhaps the Kernel?) will then just need some RTC-agnostic code to load a set of parameters from NVRAM, validate the machine ID, and pass the parameters onto the RTC device for programming.
• The A4 and Stork Portable modules both contained code to deal with the extra keys that controlled the backlight, contrast, etc. At the moment I’m not planning on implementing anything like that in PortableHAL.

For anyone wondering when this new stuff will appear, I’m going to be implementing it all in steps, in roughly the following order:

• CPU speed control via Portable_Speed/Portable_Speed2
• SmartReflex driver for 1GHz on the xM
• Battery management API + TouchBook support. Pandora support will obviously have to wait for my Pandora to arrive.
• Suspend to RAM. BeagleBoard/xM will be first since they’ll be easiest, TouchBook afterwards, then the other machine types
• General hardware monitoring

And finally, here’s the big scary feature matrix that I mentioned earlier. I’ve also updated the existing pages to cover the full feature set, but haven’t yet added any pages for stuff that the wiki didn’t previously cover (e.g. all the Stork SWIs)

Looks like I may have spoken too soon about my plans for the CPU speed interface. Existing code seems to use Portable_Speed to slow the CPU clock in the same situations in which Portable_Idle is used. Using them both together like that may give less power savings than if just Portable_Idle was used by itself, so it looks like I’ll have to do some experiments to find out whether that’s the case or not as far as RISC OS is concerned.

Also since reducing the clock speed reduces the effectiveness of stuff like Portable_Idle, TI recommends that the clock speed should always be kept at the maximum speed supported by the chosen OPP (i.e. core voltage). So instead of giving people the freedom to chose exact MHz values it may make more sense to only allow them to choose values that match the limits of each OPP - if it makes sense to give them CPU speed controls at all.

Jeffrey, this is a dream (or a potential nightmare, although I hope not).

• Only a small part of the existing BMU interface will be implemented. Mainly varibles 10 and 18 (the status flags) and perhaps 21 and 22 (if I can work out suitable battery life estimates).

Would variable 6 also be appropriate (particularly if Portable_WriteBMUVariable will be extended)?

And regarding battery charging, did you see these threads on the forums for the Smart Book and Pandora? The features are probably too much for anyone to consider implementing in the initial stages… but if you think they’re valid, perhaps some pertinent points could be included as comments in the code for possible additional functionality.

Would variable 6 also be appropriate

If we can find what measurement unit that it’s meant to be in, then yes.

And regarding battery charging, did you see these threads on the forums for the Smart Book and Pandora? The features are probably too much for anyone to consider implementing in the initial stages… but if you think they’re valid, perhaps some pertinent points could be included as comments in the code for possible additional functionality.

I haven’t seen those threads, no. They certainly aren’t on my list of things to do for this initial implementation, but I’ll make a note of them so that they don’t get forgotten.

The existing BMU API is poorly documented (no mention of what units any of the measurements are in!)

If we can find what measurement unit that it’s meant to be in, then yes.

I guess your search already turned up this non definition. Is there a way to find out what nturton was thinking? (How often does this occur – implementing features already partially documented? I guess it wouldn’t really do to go chasing former developers/staff for every little bit of info they didn’t fully document or hadn’t even finally decided upon at the time!)

[Edit: I’ve got an A4 - would that help? Perhaps not, as I’m pretty sure the battery holds no chrage whatsoever. But maybe it’d help with the other BMU variables in the future, e.g. 7, 8 and 9.]

Is there a way to find out what nturton was thinking?

Tim Dobson and Christopher Partington, actually. nturton is just the one who imported the file into CVS.

How often does this occur – implementing features already partially documented?

Very rarely, I’d say. Usually you can work out what something does just be looking at the source code, but in this case all the Portable module does is read/write values over an IIC interface. The BatMgr source code, or specs for the battery manager IC, or the microcode that runs on it, would be the most useful.

But since the units that the old variables used were never documented, it’s not like there’ll be any software that will attempt to use those variables (except perhaps BatMgr, which we currently don’t have the source to). So there’s no real harm in inventing a new API/set of variables which is better documented.

Usually you can work out what something does just be looking at the source code

And as proof of that, here’s what I’ve been able to determine from the A4/Stork BatMgr sources that Ben added to CVS earlier on today:

• ‘Instantaneous current’ is in units of 10.3mA
• ‘Charge estimate’ is in units of 11.7mAh, clamped to a maximum of 254 (i.e. 2971.8mAh). 255 is used to indicate that the estimate is unknown/invalid.
• The estimate seems to be calculated purely based upon periodically measuring the instantaneous current and using it to adjust the previous charge estimate.
• There was also a menu item to allow the user to manually set the charge estimate (e.g. if they’ve just replaced the battery with one which has a known state)
• ‘Used capacity’ seems to be in the same units as the charge estimate variable. I’m not entirely sure how it functions though; it appears to go up or down depending on whether the battery is charging or not.
• ‘Usable capacity’ is in 11.7mAh units too. By the way that it’s used, I’d guess that it’s the total design capacity of the battery.
• The Stork ‘Charge current’ and ‘Discharge current’ variables are simply tested against zero to work out whether the battery’s currently charging or discharging – so no indication of what units (if any) they are measured in.
• There’s some code in s.Task to examine the A4 ‘charge rate’ bits to work out whether the battery is charging or not. However it doesn’t reveal the exact meaning of the bits.
• If the ‘charge state known’ flag in variable 10 is set, the code calculates the charge percentage as follows:
  • Stork: ‘charge level’*100/’battery capacity’
  • A4: (‘measured capacity’-’used capacity’)*100/’usable capacity’
• If the ‘charge known’ flag isn’t set then in the above calculations it will use the estimate charge variable instead of the charge level/used capacity. Which makes me wonder how that could work, since ‘used capacity’ and ‘charge estimate’ must surely count in opposite directions.
• The ‘Connect charger’ and ‘disconnect charger’ commands are used to enable/disable the charging circuit to allow the battery to be cycled to restore its health (similar to the improved Pandora battery charger that Trevor linked to above). In BatMgr the battery cycling was available as a menu option rather than being something that happens automatically after the machine’s been left charging for too long.
• The module also provided a frontend to some of the Portable_Control power bits, allowing the user to power up/down the serial & parallel interfaces via the iconbar menu, along with a “stop discs” option that would call ADFS_PowerControl to spin down the HD.
• There are also a couple of other interesting things the program did, e.g. make the machine beep every so often if it was left turned on with the lid closed.

Overall I don’t think this has much impact for my plans for improving the BMU interface. The battery life estimation code is something that should really be handled by the Portable module instead of BatMgr. Plus the Touch Book uses 6000mAh & 12000mAh batteries; there’s no way we’d be able to represent those values within the limits of the original A4 BMU variables.

(A little) OT:

Tim Dobson and Christopher Partington, actually.

APIs look generally sensible. Can I make a couple of suggestions, feel free to ignore if they complicate things:

SWI    XPodule_Speed2
SWIVS  XPodule_Speed

Have you thought about an API for dynamic voltage scaling? It’s used quite a lot, but I don’t know how much that’s exposed to the user. However it’s not inconceivable that the CPU may be able to turn up or down the core voltage under software control, possibly independently of the clock frequency. I’ve certainly used that on my own test chips.

If you’re completely redoing BMU variables, perhaps measure energy in joules rather than mAh if you can? It’s not implausible for a machine to be fitted with batteries of different voltages dependent on the number of cells that can be fitted in the physical space… a 1500mAh battery at 3.7V has rather less energy than a 1500mAh battery at 10.8V. You could, I suppose, provide fake old-style BMU variables to keep old software happy (CryptRandom is one module that reads the BMU data as a source of entropy).

I’ve also confused Portable_Idle and Portable_Speed before, so if you’re motivated I recommend fixing the OS to use one or the other. I’m not aware that much third-party software uses either.

Arrange the Podule_Speed2 API so the inputs are also meaningful for Podule_Speed. In other words, so that a fallback to _Speed works if _Speed2 isn’t present.

That could be a bit tricky, since Portable_Speed2 is designed to complement Portable_Speed, not act as a full-blown replacement.

Have you thought about an API for dynamic voltage scaling? It’s used quite a lot, but I don’t know how much that’s exposed to the user. However it’s not inconceivable that the CPU may be able to turn up or down the core voltage under software control, possibly independently of the clock frequency. I’ve certainly used that on my own test chips.

The OMAP does use voltage scaling. At the moment my code uses a lookup table to work out what core voltage is needed for each band of CPU frequencies. I don’t think it’s a good idea to have a voltage scaling API that’s readily accessible via the Portable SWIs – too much risk of people doing silly things. But you will be able to set custom voltage levels by finding the underlying HAL device and calling the ‘override’ function to specify a new lookup table (This is primarily there for people who want to overclock their machines). Hopefully the fact that this API is hidden away, and requires you to format the data in a way that’s compatible with the specific HAL device, will keep away anyone who doesn’t know enough about what they’re doing.

If you’re completely redoing BMU variables, perhaps measure energy in joules rather than mAh if you can?

I can certainly try!

I’ve also confused Portable_Idle and Portable_Speed before, so if you’re motivated I recommend fixing the OS to use one or the other. I’m not aware that much third-party software uses either.

I think the OS should still be capable of using both at once. But for systems where both calls are present, the Portable module should be made to provide a hint as to which usage pattern will save the most energy.

After spending a few days messing round with my TouchBook, I’ve discovered that, for the simple case of leaving the machine idle, allowing Portable_Speed to switch the CPU between min & max speed as it sees fit doesn’t hurt battery life. Obviously you could get better battery life by just leaving the CPU at its lowest possible speed, but in terms of answering the question as to whether Portable_Speed and Portable_Idle can sensibly co-exist, the answer is “yes”.

So today I’ve checked into CVS some changes to the Portable module & HAL to implement Portable_Speed and Portable_Speed2. The Portable_Speed implementation is 100% compatible with the original A4 version, but the Portable_Speed2 implementation differs somewhat from my initial plans. Instead of allowing you to set the speed to any integral MHz value between the reported min & max values, it only allows you to set the speed to one of a set number of presets. These presets are dictated by the HAL device and correspond to the different “OPPs” listed in the OMAP data sheets. Apart from providing compatability with systems that won’t allow full control over the CPU clock, the decision to do this was also based around the advice that TI give in the OMAP TRM.

By default the Portable module will use the maximum supported speed as its ‘fast’ setting and the minimum supported speed as its ‘slow’ setting. So for OMAP3’s this will be 600MHz (or 720MHz) for ‘fast’ and 125MHz for ‘slow’. For DM37x’s (i.e. BB-xM) it’ll be 800MHz for ‘fast’ and 300MHz for ‘slow’. See the docs for the Portable_Speed2 SWI if you’re interested in changing these defaults for whatever reason.

Also it looks like I don’t have any 720MHz OMAPs handy to test the code that detects whether it’s a 600MHz or 720MHz device. So can someone with a 720MHz OMAP (e.g. BB C4) please check that the following two lines of BASIC output ‘720’?

SYS "Portable_Speed2",1 TO ,,A
PRINT A

And finally, should anyone feel like overclocking their OMAP, you’ll be pleased to hear that I’ve added an ‘override’ entry point to the HAL device to allow you to specify a new table of supported values. The table format is device-specific, so see HAL.OMAP3.hdr.CPUClk and HAL.OMAP3.s.CPUClk for details of the required table format. To safely upload a new set of tables, it’s probably best to force the CPU to low speed by doing SYS "Portable_Speed2",8,0,0, upload the table, then call Portable_Speed2 again, to specify the new min & max speeds. And don’t blame me if you break your board by doing something wrong :)

(Portable_Stop…)

Although I haven’t seen any docs about it, I think it’s safe to assume that it would have been Acorn’s plan that individual driver modules would listen out for the Freeze/Unfreeze service calls and take the appropriate action to suspend/resume their hardware devices. So there are a few modules I’ll have to update to deal with these service calls.

Having just written the wiki page for Portable_Stop while using the Stork sources as a reference, I’ve spotted that the Stork module seems to handle a lot of the hardware power up/power down itself. So maybe the freeze/unfreeze service calls are only provided to allow software to react to the suspension? (e.g. filesystems will probably want to flush all pending writes). So if the service calls are targeted at software rather than hardware, we’ll probably want a new pair of service calls to instruct the hardware drivers to power up/power down their devices. The final bit which deals with the core chipset & PSU can be left to a HAL device, as planned.

I think I imagined that the kernel would be able to control sleepiness of HAL devices directly, but I think you’re quite right that driver modules should be given prior warning, to enable a clean shutdown. Given that the HAL device API was designed with multiple levels of “sleepiness”, I’d say you’d want to include the sleepiness level in the parameters to the service call, so that the modules know what level to request of the HAL device. And if there is such a parameter, I think it only really needs one service call, rather than two.

I’ve got a working implementation of a new BMU interface, and an almost working new version of BatMgr. So now I’m starting to think about nailing down some of the specifics of the new interface, and how it maps to the old interface. I’m currently thinking of going with the following approach:

• There’s a new SWI, Portable_EnumerateBMU to enumerate the available BMU’s and return basic information about them.
• Each BMU has a set of flags for what it provides power to – the main system, the RTC, and the NVRAM.
• Portable_ReadBMUVariable & Portable_WriteBMUVariable will be extended to take the BMU index in the high byte of R0.
• New BMUs will be numbered from 1 up; this allows a request for BMU 0 to automatically be remapped to whatever the main system BMU is (consider the case of a system where the only BMU is for the RTC, and some old code is trying to read the BMU variables – unless BMU 0 is treated specially, the code would end up reading the RTC BMU state, and could get confused). Treating BMU 0 specially also means we can fudge the variable units if necessary (although I’d hope not).
• There’s a new SWI, Portable_ReadBMUVariables. This allows multiple variables to be read at once, (potentially) providing better performance. Each variable will also return a status word indicating whether the variable is supported, whether the variable value is currently unknown, etc. Only one BMU can be queried at a time using this interface.
• Apart from BMU variables 21 & 22, the variable units have never been publicly documented, so (apart from variables 21 & 22) I’m going to ignore the units which the old variables used and stick to the following: mV, mA, mAh, and 0.1K for temperature. If we’re worried about compatibility we could fudge BMU 0 to return old style units, but that will rule out returning values for the variables we don’t know the units for (voltage, temperature, charge current, discharge current, etc.)

At the moment I’ve only been concerning myself with the main battery (or batteries), so some further tweaks may be necessary once I start looking at RTC/NVRAM batteries (in particular setting charge voltage & current for BB/PB/etc.) Also there’s no Portable_CommandBMU yet, and I haven’t hooked up the BMU event yet (I’ll probably leave that till after the first release).

On the subject of Portable, would this be a sensible place for more general system monitoring info, like CPU temperature, power supply voltages, fan speed, etc? At the moment Portable is squarely about battery and CPU management. It would be good to read things like CPU temp without having to resort to platform-specific hacks.

On the subject of Portable, would this be a sensible place for more general system monitoring info, like CPU temperature, power supply voltages, fan speed, etc? At the moment Portable is squarely about battery and CPU management. It would be good to read things like CPU temp without having to resort to platform-specific hacks.

I’d be more inclined to recommend that it doesn’t feature in the Portable module at all and that the System Environmental aspects feature in their own module. Much more innustry-stannard behaviour.

Yes… it might be more sensible to have a System Environmental API, for which different people can write modules for different platforms. For example, BeagleBoard folks can poke the registers of the monitoring chips, while Raspberry Pi people can talk to the GPU. Is this a HAL thing, or a higher-level module thing (most of this stuff isn’t vital for boot)?

I was initially thinking that hardware monitoring would go in the Portable module. After all, there’s some crossover with what the Portable module already does – most of the BMU variables are for hardware monitoring, and there’ll be some crossover between controlling CPU speed and monitoring its temperature/voltage. But I guess there’s no reason why it can’t go into its own module, especially as “Portable” could become a misnomer if it’s used for too much stuff not related to portables.

Is this a HAL thing, or a higher-level module thing (most of this stuff isn’t vital for boot)?

Generally speaking the way things should work for any kind of hardware driver is that the HAL or the OS creates a HAL device, and then a suitable module detects that device, implements any extra functionality required, and exposes a consistent API to the rest of the OS & user apps. Although it’s usually the HAL that creates all the HAL devices, there’s no reason why a ROM module or softloaded module can’t create a HAL device which the “frontend” module can then pick up on.

The only thing that isn’t clearcut is exactly where the division of labour is between the HAL device and the frontend module – in particular whether the frontend module is a generic one which can cope with any HAL device of that type (DMAManager, Portable, SDIODriver, etc.) or whether it’s tied to specific HAL devices (OMAPVideo, VCHIQ, etc.). With generic frontend modules all of the hardware-specific stuff would be done in the HAL device, whereas with modules targeting specific devices the HAL device usually implements minimal functionality – sometimes none at all, and all the module does is look for the device as a confirmation that it’s running on suitable hardware.

For hardware monitoring you’d probably want a generic module with all the hardware-specific bits implemented in the HAL device. On Pi the hardware monitoring would be dependent on the mailbox property interface, so (assuming BCMSupport gets implemented) it would make sense for the HAL device to be created by a module sometime after BCMSupport in the ROM chain – or perhaps by BCMSupport itself.

I’ve been trying to work out a way of mapping my new BMU variables to the old BMU variables. While doing this I’ve discovered a couple of things:

• On the Stork, the only A4 variable Acorn were going to support was the flags variable. All the other Stork variables were assigned new allocations, even if they had the same function as existing A4 ones (voltage, temperature, current, capacity, etc. all have two sets of definitions)
• It’s hard to tell what the A4 capacity values actually mean. About all I can say for certain is that NominalCapacity, MeasuredCapacity and UsableCapacity are different measures for the total capacity of the battery, while UsedCapacity and ChargeEstimate are all values that increase as the battery discharges, and decrease as it charges.

Taking the above into account, I’m proposing the following mapping of BMU variables:

• All Stork variables are to be ignored
• The following A4 variables will be supported (using the new units of measurement):
  • NominalCapacity – Battery design capacity, mAh
  • UsableCapacity – Actual capacity when full, mAh (i.e. after taking into account wear-and-tear)
  • Voltage – Instantaneous voltage, mV
  • Current – Instantaneous current, mA
  • Temperature – Temperature, 0.1K
  • Flags – Status flags
• The VirtualRPC BatteryTimeRemaining variable will be supported (in seconds, even though I think it’s a bit ambitious to try and measure with that much granularity)
• There’ll be the following new variables:
  • BatteryPercentRemaining – % charge remaining
  • ChargeTimeRemaining – How long until the current charge completes, seconds
  • ChargeCycles – How many charge/discharge cycles the battery has gone through
  • SmoothedVoltage – A smoothed/average voltage reading, mV
  • SmoothedCurrent – A smoothed/average current reading, mA
  • NominalAvailableCapacity – How much charge is currently left, mAh
  • CompensatedAvailableCapacity – As NominalAvailableCapacity, but compensated for current temperature & voltage, mAh

Any thoughts on this arrangement? My main thought is that I’m not sure if there’s much point supporting the A4 NominalCapacity & UsableCapacity, since there’s no UsedCapacity or ChargeEstimate to use to measure how much charge is remaining (plus I’m still not 100% sure what all the different values represent). So maybe those two should be ignored and added as new variables instead?