HP Forums

Full Version: WP 34S: Power saving revisited
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

The latest build of WP 34S has a new algorithm for speed switching. Testers (on the real hardware) are welcome.

Background: Running at full speed is hard on the coin cells which are not rated for the 10mA current draw (20mA total) at 37MHz. We want the speed but we probably do not want it all the time.

  1. When a program is started, the processor is immediately switched to full speed.* Label search would be too slow otherwise.
  2. When numbers or commands are input, the processor runs at about 2MHz. You may notice this, it's a little less snappy than it used to be. This change was introduced earlier with the NULL option.
  3. When a command is executed, speed switching is delayed about 0.1s. In a first step, speed is increased to 20MHz. 0.1s later, the calculator switches to full speed.*

* With SLOW in effect or with the battery symbol lit, this is 20MHz, 37MHz otherwise.

The main consequence of (3) is that many commands never switch to 20MHz or higher because they finish before the 0.1s elapse. This should reduce the stress on the batteries in normal manual operation. But some commands (try the factorial or LN) take noticeably longer in manual mode because they really need the full speed and do get it only after some delay.

I'd like to hear your comments on this.

As a side note: The power drain in idle mode (e. g. during a PSE) should be lower then it used to be (0.2mA instead of 0.4mA). I found some pull-up resistors which were unnecessarily left active. I still need to verify this but I have to modify my calculator first for the measurements.

Edit: Just fixed a bug with the latest changes.

Edited: 23 Oct 2011, 2:26 p.m.

Hello Marcus:

I presume that this is the '1767' build. I've just downloaded and flashed a 20b.

TomC

Quote:
I presume that this is the '1767' build. I've just downloaded and flashed a 20b.

There's already a bugfix 1769.

1767 has issues with the CONV catalog.

Just downloaded what appears to be 1769, but the VERS command on the calculator returns 1768... Please clarify.

TIA

That's a pretty typical source control problem. When the calc.bin was built, it was built using 1768 + changes. Only once the calc.bin was checked in did it become 1769.

So VERS always returns a revision behind.

This has to do with the way the revision number is calculated in the build process. Walter had updated the manual between my two commits. So adding one to the last checked out copy of the sources didn't work out this time.

Dominic, almost. I add one to the last checked out revision number during the build and compile it into the binary. No more $REV$ tags in the binary files.