| Author |
Message |
|
SuspendedFour
Newbie
Joined: 24 Feb 2011
Posts: 15
|
 Posted: 08 Apr 2011 04:39:12 pm Post subject: |
|
|
Two users have reported that they suspect my programs are draining battery. My programs are written in ASM; are these reports just coincidences or are my programs significantly reducing battery life?
How does ASM compare to BASIC compare to OS Home Screen as far as battery usage?
Are there any battery optimization tricks for ASM?
Does bcall(_grbufcpy) or accessing the LCD in other ways use more battery than a software instruction? |
|
| Back to top |
|
|
Xeda112358
Active Member
Joined: 19 May 2009
Posts: 520
|
| Posted: 08 Apr 2011 05:39:07 pm Post subject: |
|
|
I have never learned how exactly to implement this trick without causing my calc to freeze, but apparently using a halt to suspend the CPU every so often saves batteries  |
|
| Back to top |
|
|
cjgone
Aw3s0m3
Active Member
Joined: 24 May 2006
Posts: 693
|
| Posted: 08 Apr 2011 08:50:36 pm Post subject: |
|
|
I suppose if you're running your asm programs at 15 mhz rather than at 6 mhz, your calculator will die faster. But in general, obviously, running programs uses battery power.
Last edited by Guest on 08 Apr 2011 08:50:57 pm; edited 1 time in total |
|
| Back to top |
|
|
Xeda112358
Active Member
Joined: 19 May 2009
Posts: 520
|
| Posted: 08 Apr 2011 10:22:18 pm Post subject: |
|
|
| As a side note to that, I believe that using 15MHz mode will use less power to perform the same operation, too, but obviously 15 MHz goes through about 2.5 times the number of operations in the same time XD So don't be discouraged from using 15 MHz mode! |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 10 Apr 2011 11:11:44 am Post subject: |
|
|
The HALT instruction means simply "do nothing, and wait until an interrupt occurs." So if interrupts are disabled, it will wait forever. So it's a good practice to precede every HALT with an EI instruction (even if you don't ever disable interrupts yourself, there are many shell and OS routines that do so.)
While the CPU is halted, it consumes far less power than normal. (Michael V did some experiments to demonstrate this, but I can't find his results at the moment.) So any time you're waiting for something to happen (waiting for the user to press a key, waiting to receive data over the link port, waiting for some amount of time to elapse) - unless you're expecting to wait for a very short duration, it's best to halt the CPU in the meantime.
The CPU will consume somewhat less power in 6 MHz mode, but it will also take longer to perform calculations. So if you're actually doing useful work with the CPU, you don't gain anything by running at 6 MHz (and besides, it makes your program slower.) On the other hand, if you're not following my advice above, and busy-waiting for some event to occur, you may as well use 6 MHz mode and save some power. If you're copying a lot of data to the LCD controller, it may be beneficial to use 6 MHz mode (given that most of that process consists of busy-waiting, and anyway, that lets you use the same fast-copy code on both BE and SE.)
Apart from the CPU itself, various other parts of the hardware will also consume battery power if you leave them turned on: the LCD, the link port, the USB controller, programmable timers, and even the keypad. These are generally pretty negligible compared to the CPU, though (even the LCD comes nowhere near the CPU's power usage.) Having a USB peripheral connected and powered may be a substantial power drain. Writing to Flash can also consume a significant amount of power (one reason why it's recommended to test the battery before doing anything that requires writing to Flash.)
As far as how BASIC compares to (well-written) assembly programs: BASIC is awful in this regard, since you frequently have no choice but to use getKey in a loop to wait for user input. And BASIC programs normally run at 15 MHz. The only way it could be worse is if you had a USB device connected as well. |
|
| Back to top |
|
|
Xeda112358
Active Member
Joined: 19 May 2009
Posts: 520
|
| Posted: 10 Apr 2011 12:38:06 pm Post subject: |
|
|
| Ah, sweet! Thank you much! I finally got it to halt without freezing! Also, I always thought programs were executed at 6MHz (at lease asm programs run with the Asm( token). I say this because when I run BatLib code without changing the speed, it runs slower than if I set it to 15MHz mode (and it is executed from a BASIC program). |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 10 Apr 2011 02:17:15 pm Post subject: |
|
|
| Really? I was pretty sure they ran at 15 MHz by default. If you're using a parser hook, though (or any other hook, except the USB hook) then the OS will switch to 6 MHz mode while your hook is running. There's a flag that overrides that behavior, but I don't recommend using it because it's likely to break other programs. Instead, just be sure to set 15 MHz mode yourself if you need it, just like you would in an Asm( program. |
|
| Back to top |
|
|
Xeda112358
Active Member
Joined: 19 May 2009
Posts: 520
|
| Posted: 10 Apr 2011 02:50:32 pm Post subject: |
|
|
| Oh, cool, that explains it! Thanks much! |
|
| Back to top |
|
|
DrDnar
Member
Joined: 28 Aug 2009
Posts: 116
|
| Posted: 10 Apr 2011 10:06:35 pm Post subject: |
|
|
SuspendedFour wrote:
Two users have reported that they suspect my programs are draining battery. My programs are written in ASM; are these reports just coincidences or are my programs significantly reducing battery life?
How does ASM compare to BASIC compare to OS Home Screen as far as battery usage?
Are there any battery optimization tricks for ASM?
Does bcall(_grbufcpy) or accessing the LCD in other ways use more battery than a software instruction?
So, I got out my milliamp meter and did some tests, and wow!
Code:
TI-84+SE Current Draw at 6.25 VDC supply voltage
Program Current Notes
EOS (aka TIOS) 95.2 microamps "Off" state
EOS 1.9 mA Idle, Homescreen
EOS 16.1 mA TIOS while sorting programs
EOS 7.8 mA Idle, Homescreen after running MirageOS*
EOS 16.0 mA Graphing
EOS 15.8 mA Archiving program
EOS 15.8 mA Garbage Collecting, constant
EOS 30.0 mA Garbage Collecting, peak
Asm GetKey 1.9 mA Invariant of CPU speed
Asm Halt Loop 1.5 mA Invariant of CPU speed
Asm DNJZ $ Loop 5.5 mA Invariant of CPU speed
MirageOS Password 7.6 mA
MirageOS Idle 1.7 mA
Tetris Marathon 11.7 mA
The Impossible Game 5.2 mA Peaks at 5.9 mA ca. once per second
Asm FastCopy loop 6.0 mA for (HL = 0; ; HL+=768) FastCopy(HL); // Pretty fun to watch
Asm program holding ON 8.7 mA Running from MirageOS
Asm FastCopy loop 7.2 mA With MirageOS Interrupt at minimum (ON+GRAPH)
Asm FastCopy loop 6.4 mA With MirageOS Interrupt at maximum (ON+Y=)
BASIC Graphing Demo 15.8 mA BASIC runs at 15 MHz
BASIC Menu( command 5.7 mA
BASIC GetKey Loop 11.4 mA
BASIC For(A,1,1000):End 16.0 mA
BASIC seq(X,X,999,1,-1) 15.9 mA
BASIC SortA(above list) 15.3 mA This "blocks" the ON key
BASIC SortA(above list) 12.4 mA While rapidly smashing ON
Archive Undeleter 7.4 mA
Robot Finds Kitten 7.3 mA
The Missile Game 12.0 mA In game
The Missile Game 12.9 mA High Score display with noise
The Missile Game 16.3 mA Enter High Score screen
The Missile Game 1.8 mA Main Menu
Omnicalc Font Editor 7.1 mA
QWERTY 3.5 mA It behaved really funny
Galaxian 5.7 mA
Block Dude 4.0 mA Wins the "Most Environmentally Friendly Game" award
Axe Parser 15.7 mA Menu screen
CaDan 4.9 mA Title screen
CaDan 5.2 mA Easy mode
CaDan 5.9 mA Easy mode peak current
CaDan 4.9 mA Paused
CaDan 6.0 mA Lunatic mode
CaDan 6.5 mA Lunatic mode peak current
* I think that some of the hooks MirageOS installs causes this.
Last updated: 10 April 2011 @ 23:56
So, yes, it's actually possible that you're adversely affecting battery life, depending on what you're doing. It's especially bad if you're installing a hook that does something crazy.
Last edited by Guest on 10 Apr 2011 10:59:20 pm; edited 1 time in total |
|
| Back to top |
|
|
Xeda112358
Active Member
Joined: 19 May 2009
Posts: 520
|
| Posted: 10 Apr 2011 10:39:42 pm Post subject: |
|
|
Aw, I wish I could test stuff like that  I wonder what the difference is when polling port 1 if you add in a halt for each loop as opposed to not adding a halt? |
|
| Back to top |
|
|
DrDnar
Member
Joined: 28 Aug 2009
Posts: 116
|
| Posted: 10 Apr 2011 11:08:31 pm Post subject: |
|
|
RadioShack charges, like, $10 for a multimeter that can handle currents up to 200 mA.
Actually, my code for the HALT loop was this:
Code:
loop:
ld a, 0FDh
out (1), a
push hl
pop hl
in a, (1)
cp 0FEh ; ENTER
ret z
cp 0BFh ; CLEAR
jr z, quit
halt ; djnz $ ; And I replaced HALT with this for the DNJZ $ loop test
jr loop
Last edited by Guest on 10 Apr 2011 11:10:01 pm; edited 1 time in total |
|
| Back to top |
|
|
Xeda112358
Active Member
Joined: 19 May 2009
Posts: 520
|
| Posted: 11 Apr 2011 07:33:23 am Post subject: |
|
|
| Ah, cool, thanks I'll have to invest in one of those things, too XD I have a logic probe that I failed at making 4 years ago, too XD |
|
| Back to top |
|
|
SuspendedFour
Newbie
Joined: 24 Feb 2011
Posts: 15
|
| Posted: 12 Apr 2011 10:13:37 pm Post subject: |
|
|
Dr. D wrote:
SuspendedFour wrote:
Two users have reported that they suspect my programs are draining battery. My programs are written in ASM; are these reports just coincidences or are my programs significantly reducing battery life?
How does ASM compare to BASIC compare to OS Home Screen as far as battery usage?
Are there any battery optimization tricks for ASM?
Does bcall(_grbufcpy) or accessing the LCD in other ways use more battery than a software instruction?
So, I got out my milliamp meter and did some tests, and wow!
Code: TI-84+SE Current Draw at 6.25 VDC supply voltage
Program Current Notes
EOS (aka TIOS) 95.2 microamps "Off" state
EOS 1.9 mA Idle, Homescreen
EOS 16.1 mA TIOS while sorting programs
EOS 7.8 mA Idle, Homescreen after running MirageOS*
EOS 16.0 mA Graphing
EOS 15.8 mA Archiving program
EOS 15.8 mA Garbage Collecting, constant
EOS 30.0 mA Garbage Collecting, peak
Asm GetKey 1.9 mA Invariant of CPU speed
Asm Halt Loop 1.5 mA Invariant of CPU speed
Asm DNJZ $ Loop 5.5 mA Invariant of CPU speed
MirageOS Password 7.6 mA
MirageOS Idle 1.7 mA
Tetris Marathon 11.7 mA
The Impossible Game 5.2 mA Peaks at 5.9 mA ca. once per second
Asm FastCopy loop 6.0 mA for (HL = 0; ; HL+=768) FastCopy(HL); // Pretty fun to watch
Asm program holding ON 8.7 mA Running from MirageOS
Asm FastCopy loop 7.2 mA With MirageOS Interrupt at minimum (ON+GRAPH)
Asm FastCopy loop 6.4 mA With MirageOS Interrupt at maximum (ON+Y=)
BASIC Graphing Demo 15.8 mA BASIC runs at 15 MHz
BASIC Menu( command 5.7 mA
BASIC GetKey Loop 11.4 mA
BASIC For(A,1,1000):End 16.0 mA
BASIC seq(X,X,999,1,-1) 15.9 mA
BASIC SortA(above list) 15.3 mA This "blocks" the ON key
BASIC SortA(above list) 12.4 mA While rapidly smashing ON
Archive Undeleter 7.4 mA
Robot Finds Kitten 7.3 mA
The Missile Game 12.0 mA In game
The Missile Game 12.9 mA High Score display with noise
The Missile Game 16.3 mA Enter High Score screen
The Missile Game 1.8 mA Main Menu
Omnicalc Font Editor 7.1 mA
QWERTY 3.5 mA It behaved really funny
Galaxian 5.7 mA
Block Dude 4.0 mA Wins the "Most Environmentally Friendly Game" award
Axe Parser 15.7 mA Menu screen
CaDan 4.9 mA Title screen
CaDan 5.2 mA Easy mode
CaDan 5.9 mA Easy mode peak current
CaDan 4.9 mA Paused
CaDan 6.0 mA Lunatic mode
CaDan 6.5 mA Lunatic mode peak current
* I think that some of the hooks MirageOS installs causes this.
Last updated: 10 April 2011 @ 23:56
So, yes, it's actually possible that you're adversely affecting battery life, depending on what you're doing. It's especially bad if you're installing a hook that does something crazy.
Wow, this is a really neat post!
When you mention hooks, I wonder if NoShell is causing this. I did have my users install it in order to run my programs. |
|
| Back to top |
|
|
|
Z80 & 68k Assembly => z80 & ez80 Assembly
