Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
This is an archived, read-only copy of the United-TI subforum , including posts and topic from May 2003 to April 2012. If you would like to discuss any of the topics in this forum, you can visit Cemetech's z80 & ez80 Assembly subforum. Some of these topics may also be directly-linked to active Cemetech topics. If you are a Cemetech member with a linked United-TI account, you can link United-TI topics here with your current Cemetech topics.

This forum is locked: you cannot post, reply to, or edit topics. Z80 & 68k Assembly => z80 & ez80 Assembly
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
Sven.Thomas0


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 Smile
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
Sven.Thomas0


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. Smile
Back to top
Sven.Thomas0


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
Sven.Thomas0


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
Sven.Thomas0


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 Sad 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
Sven.Thomas0


Active Member


Joined: 19 May 2009
Posts: 520

Posted: 11 Apr 2011 07:33:23 am    Post subject:

Ah, cool, thanks Smile 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
Display posts from previous:   
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
    »
» View previous topic :: View next topic  
Page 1 of 1 » All times are GMT - 5 Hours

 

Advertisement