Difference between revisions of "83Plus:OS:Power Usage"
(clarified something) |
(→Notes About Power: Added information about the specific voltage regulators used.) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 9: | Line 9: | ||
The TI-83+/SE/84+/SE family of calculators test the batteries by reading the voltage with the CPU in a busy-loop (which raises the current draw; also, this loop should be in flash or else you might not see a low-battery voltage drop). The TI-83+ was originally based on 5.0 V logic, and the CPU specifically tests for voltages around this level. The newer TI-83+s and the SE/84+ series of calculators are based entirely around 3.3 V logic, but the OS still expects at least 5.0 V, even though the hardware (except for the USB port +5 V power rail) technically does not need it. (If you write your own OS, you can see that the calculator will run fine on as little as 3.5 V, and even flash write/erase operations will complete correctly.) | The TI-83+/SE/84+/SE family of calculators test the batteries by reading the voltage with the CPU in a busy-loop (which raises the current draw; also, this loop should be in flash or else you might not see a low-battery voltage drop). The TI-83+ was originally based on 5.0 V logic, and the CPU specifically tests for voltages around this level. The newer TI-83+s and the SE/84+ series of calculators are based entirely around 3.3 V logic, but the OS still expects at least 5.0 V, even though the hardware (except for the USB port +5 V power rail) technically does not need it. (If you write your own OS, you can see that the calculator will run fine on as little as 3.5 V, and even flash write/erase operations will complete correctly.) | ||
| − | The calculators use linear voltage regulators, which convert the extra voltage supplied by the batteries into waste heat. Consequently, the calculators are fairly flexible with respect to the voltages they can accept. The | + | The calculators use linear voltage regulators, which convert the extra voltage supplied by the batteries into waste heat. Consequently, the calculators are fairly flexible with respect to the voltages they can accept. The TI-84+/SE uses TI own voltage regulator, the TPS76901 and TPS76933. These regulators are rated to accept input voltages of up to 13.5 V and are rated to produce a sustained output current of 100 mA. They are also rated to produce up to 350 mA output current with no output voltage drop for brief periods; the device will automatically shutoff if high-current output causes its internal temperature to exceed safe limits. Because the OS specifically looks for around 5.0 V, you should not supply less than 5.0 V. Due to various issues like voltage losses in the USB cable, a USB port might actually supply slightly less than 5.0 V. Alkaline batteries supply 1.5 V for between 250 and 1200 mAh; rechargeable batteries typically supply 1.2 V, with a similar capacity range, though usually lower. Because rechargeables supply a lower voltage, they can easily fail to meet the OS's voltage expectations. |
Generally, it is perfectly acceptable to run a calculator from a generic power supply. However, a poor-quality power supply may permit excess AC noise to reach the calculator, causing stability issues. Adding a capacitor may help filter out noise. For a USB port, a capacitor may stabilize the voltage output, as changes in the calculator's load can cause transient voltage drops with a poor-quality USB power supply. | Generally, it is perfectly acceptable to run a calculator from a generic power supply. However, a poor-quality power supply may permit excess AC noise to reach the calculator, causing stability issues. Adding a capacitor may help filter out noise. For a USB port, a capacitor may stabilize the voltage output, as changes in the calculator's load can cause transient voltage drops with a poor-quality USB power supply. | ||
| + | |||
| + | = More About Booting and When RAM Clears Happen = | ||
| + | <i>I wrote this as a response to another forum post. It covers a little bit more about what exactly it means for a calculator to be "turned off." I'll post on a page about flags the information about which flag controls how the interrupt handler deals with a sudden power-off.—[[User:Dr. D'nar|Dr. D'nar]] 00:22, 6 February 2013 (UTC)</i> | ||
| + | |||
| + | The only to truly turn off a calculator is to remove all four AAAs and the backup battery. The calculator requires about 70 microamps to maintain RAM contents and to be able to sense when the ON key is pressed. The OS itself uses the same "low-battery trick" you speak of. Some really old programs may not do it correctly, but I doubt that's a problem anymore. (The correct code should be located on WikiTI.) | ||
| + | |||
| + | More technical information: During a normal power-down, writing to a port configures the ASIC to enter a special low-power mode when it sees the CPU core enter the HALT state. Hardware-wise, there is no difference between the OS doing it and a RAM program or application doing it. In both cases, pressing ON issues an interrupt that terminates the HALT state, and the ASIC exits low-power mode. The CPU then continues executing instructions from where ever it left off. | ||
| + | |||
| + | So why does removing a battery when in a RAM program cause a RAM reset, but no reset happens when the OS does it? It's a bit of a long story: Disconnecting the main AAAs will cause the ASIC and the CPU to hard-reset---except for RAM, which continues to be powered from the backup battery. When power is restored, the CPU is immediately hard-reset, and the boot code boots. It sees that the OS is valid, and transfers control to the OS after initializing some hardware. Now, when the OS turns off normally or APDs, it calculates a checksum for RAM. So, after you reinsert the AAAs, the OS sees that the RAM checksum is still valid, and that RAM should not be reset. | ||
| + | |||
| + | Cool fact: The calculator boots immediately after restoring main power. The OS (or boot code, if no OS is present) checks the state of the ON key after booting; if it isn't being pressed, it immediately does a normal power-off, as mentioned above. | ||
| + | |||
| + | Also, if you remove a battery at the homescreen with the blinking cursor, the calculator actually stays on for a split second, during which time an interrupt (HW timer 2) fires. The OS, seeing the power outage, changes the RAM checksum to a special value to signal that a RAM reset should be not performed after power is restored. This behavior is activated by a particular flag, which assembly programs should not normally use due to a memory-leak issue. (Specifically, CPU control is not returned to the running program; it's just like doing JForceCmdNoChar.) Although, I suppose a custom OS could take a few microseconds to save the CPU state. Actually, that should be a zStart feature: improved RAM-reset prevention for compatible programs. (It won't work if the interrupt handler is not called, which can be either because interrupts are disabled or the current program is using a custom interrupt.) | ||
= Power Usage Measurements = | = Power Usage Measurements = | ||
Latest revision as of 09:19, 9 March 2013
Notes About Power
After seeing more power-related discussion, I decided to write a post with pretty much all I know. It needs to be documented, so here is the post.—Dr. D'nar 21:00, 17 February 2012 (UTC)
The TI-84+/SE's maximum current draw without USB is about 30 mA, which happens during flash write/erase operations; the typical current draw is 16 mA max in other circumstances, 5–12 mA typical, and 2 mA on the homescreen with no hooks. For comparison, when a USB device is initially connected, it can draw up to 100 mA, and up to 500 mA if authorized by the computer. The USB port on the TI-84+SE is a USB On-the-Go port, and supplies a maximum of 100 mA to a connected peripheral.
The TI-83+/SE/84+/SE family of calculators test the batteries by reading the voltage with the CPU in a busy-loop (which raises the current draw; also, this loop should be in flash or else you might not see a low-battery voltage drop). The TI-83+ was originally based on 5.0 V logic, and the CPU specifically tests for voltages around this level. The newer TI-83+s and the SE/84+ series of calculators are based entirely around 3.3 V logic, but the OS still expects at least 5.0 V, even though the hardware (except for the USB port +5 V power rail) technically does not need it. (If you write your own OS, you can see that the calculator will run fine on as little as 3.5 V, and even flash write/erase operations will complete correctly.)
The calculators use linear voltage regulators, which convert the extra voltage supplied by the batteries into waste heat. Consequently, the calculators are fairly flexible with respect to the voltages they can accept. The TI-84+/SE uses TI own voltage regulator, the TPS76901 and TPS76933. These regulators are rated to accept input voltages of up to 13.5 V and are rated to produce a sustained output current of 100 mA. They are also rated to produce up to 350 mA output current with no output voltage drop for brief periods; the device will automatically shutoff if high-current output causes its internal temperature to exceed safe limits. Because the OS specifically looks for around 5.0 V, you should not supply less than 5.0 V. Due to various issues like voltage losses in the USB cable, a USB port might actually supply slightly less than 5.0 V. Alkaline batteries supply 1.5 V for between 250 and 1200 mAh; rechargeable batteries typically supply 1.2 V, with a similar capacity range, though usually lower. Because rechargeables supply a lower voltage, they can easily fail to meet the OS's voltage expectations.
Generally, it is perfectly acceptable to run a calculator from a generic power supply. However, a poor-quality power supply may permit excess AC noise to reach the calculator, causing stability issues. Adding a capacitor may help filter out noise. For a USB port, a capacitor may stabilize the voltage output, as changes in the calculator's load can cause transient voltage drops with a poor-quality USB power supply.
More About Booting and When RAM Clears Happen
I wrote this as a response to another forum post. It covers a little bit more about what exactly it means for a calculator to be "turned off." I'll post on a page about flags the information about which flag controls how the interrupt handler deals with a sudden power-off.—Dr. D'nar 00:22, 6 February 2013 (UTC)
The only to truly turn off a calculator is to remove all four AAAs and the backup battery. The calculator requires about 70 microamps to maintain RAM contents and to be able to sense when the ON key is pressed. The OS itself uses the same "low-battery trick" you speak of. Some really old programs may not do it correctly, but I doubt that's a problem anymore. (The correct code should be located on WikiTI.)
More technical information: During a normal power-down, writing to a port configures the ASIC to enter a special low-power mode when it sees the CPU core enter the HALT state. Hardware-wise, there is no difference between the OS doing it and a RAM program or application doing it. In both cases, pressing ON issues an interrupt that terminates the HALT state, and the ASIC exits low-power mode. The CPU then continues executing instructions from where ever it left off.
So why does removing a battery when in a RAM program cause a RAM reset, but no reset happens when the OS does it? It's a bit of a long story: Disconnecting the main AAAs will cause the ASIC and the CPU to hard-reset---except for RAM, which continues to be powered from the backup battery. When power is restored, the CPU is immediately hard-reset, and the boot code boots. It sees that the OS is valid, and transfers control to the OS after initializing some hardware. Now, when the OS turns off normally or APDs, it calculates a checksum for RAM. So, after you reinsert the AAAs, the OS sees that the RAM checksum is still valid, and that RAM should not be reset.
Cool fact: The calculator boots immediately after restoring main power. The OS (or boot code, if no OS is present) checks the state of the ON key after booting; if it isn't being pressed, it immediately does a normal power-off, as mentioned above.
Also, if you remove a battery at the homescreen with the blinking cursor, the calculator actually stays on for a split second, during which time an interrupt (HW timer 2) fires. The OS, seeing the power outage, changes the RAM checksum to a special value to signal that a RAM reset should be not performed after power is restored. This behavior is activated by a particular flag, which assembly programs should not normally use due to a memory-leak issue. (Specifically, CPU control is not returned to the running program; it's just like doing JForceCmdNoChar.) Although, I suppose a custom OS could take a few microseconds to save the CPU state. Actually, that should be a zStart feature: improved RAM-reset prevention for compatible programs. (It won't work if the interrupt handler is not called, which can be either because interrupts are disabled or the current program is using a custom interrupt.)
Power Usage Measurements
Somebody posted a question about power usage, so I decided to some research on the topic. Here are my results. They show that coding practices can have a significant effect on power usage. I also speculate that hooks can adversely affect battery life, too, though more research is needed.
Somebody should Wikify this into a table, and maybe add more data. Be sure to specify your supply voltage with the current measurements.—Dr. D'nar 06:17, 2 May 2011 (UTC)
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.
