Author Topic: Idling the CPU  (Read 9402 times)

0 Members and 1 Guest are viewing this topic.

Offline Goplat

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 289
  • Rating: +82/-0
    • View Profile
Idling the CPU
« on: March 14, 2011, 06:27:45 pm »
I noticed a thread on TI-Bank where someone said his TI-Nspire CAS drained a set of batteries by 50% in one day while testing out some programs... Power consumption is a very annoying thing in that you can't ignore it even though it's practically impossible to measure it effectively :(

I suspect that it's mainly the Nspire's 90MHz CPU that can be a power hog, so it's important to make sure we idle it properly when nothing is happening. The way to do this is with the wait-for-interrupt instruction (mcr p15, 0, SBZ, c7, c0, 4), which is executed by the idle() function in libndls. However, this instruction is only useful if the interrupt that wakes the CPU up is acknowledged. Otherwise, next time around, the interrupt controller is already asserting to the CPU that an interrupt is pending, so the instruction just returns immediately.

Presently, Ndless programs run with the CPSR I bit set on the CPU, so the OS's IRQ handler is not run, and IRQs never get acknowledged unless a program does so explicitly. I think libndls should have a delay routine that keeps the CPU idle by acknowledging timer interrupts as they come, something like this:

Code: [Select]
// Idle for n/100 seconds
void delay(int n) {
int irq_mask = *(volatile int *)0xDC000008;
*(volatile int *)0xDC00000C = ~(1 << 19); // Disable all IRQs except timer
for (; n; n--) {
asm ("mcr p15, 0, %0, c7, c0, 4" : : "r" (0)); // Wait for an interrupt to occur
*(volatile int *)0x900A0020 = 1; // Acknowledge timer interrupt at source
*(volatile int *)0xDC000028; // Make interrupt controller stop asserting nIRQ if there aren't any active IRQs left
}
*(volatile int *)0xDC000008 = irq_mask; // Re-enable disabled IRQs
return 0;
}
Numquam te deseram; numquam te deficiam; numquam circa curram et te desolabo
Numquam te plorare faciam; numquam valedicam; numquam mendacium dicam et te vulnerabo

Offline fb39ca4

  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1749
  • Rating: +60/-3
    • View Profile
Re: Idling the CPU
« Reply #1 on: March 14, 2011, 09:50:50 pm »
A function to over/underclock the CPU would also be nice, a game like block dude or ferris doesnt need 90 MHz. Even though it is simple enough already, having a function means more people are likely to use it.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Idling the CPU
« Reply #2 on: March 14, 2011, 09:58:27 pm »
For me batteries lasts about 2 hours O.O , but they were cheap batteries I bought in set of 12 for $1.49. It would be nice to be able to save power somehow, like during less intensive parts of games such as a RPG menu or any game that doesn't require smooth scrolling.
« Last Edit: March 14, 2011, 09:58:43 pm by DJ_O »

Offline fb39ca4

  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1749
  • Rating: +60/-3
    • View Profile
Re: Idling the CPU
« Reply #3 on: March 14, 2011, 11:39:27 pm »
Exactly. If a program that uses timers to keep a constant frame rate were to calculate how much time is being taken to make each frame, it could adjust the CPU frequency accordingly, kind of like how speedstep works on computers. The only problem I could think of is it may not be good for the hardware to keep on switching frequencies.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Idling the CPU
« Reply #4 on: March 14, 2011, 11:52:11 pm »
Yeah that's one worry I have. I wonder if there are previous cases of dying hardware for any other kind of device due to constant frequency changes?

Offline Jonius7

  • python! Lua!
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1918
  • Rating: +82/-18
  • Still bringing new dimensions to the TI-nspire...
    • View Profile
    • TI Stadium
Re: Idling the CPU
« Reply #5 on: March 15, 2011, 06:45:55 am »
ndless uses a lot of battery life, especially when playing games on it. it had dropped to 25% on my nspire in a week

post 444 unlucky number....
« Last Edit: March 15, 2011, 06:46:38 am by jhgenius01 »
Programmed some CASIO Basic in the past
DJ Omnimaga Music Discographist ;)
DJ Omnimaga Discography
My Own Music!
My Released Projects (Updated 2015/05/08)
TI-nspire BASIC
TI-nspire Hold 'em
Health Bar
Scissors Paper Rock
TI-nspire Lua
Numstrat
TI-nspire Hold 'em Lua
Transport Chooser
Secret Project (at v0.08.2 - 2015/05/08)
Spoiler For Extra To-Be-Sorted Clutter:

Spoiler For Relegated Projects:
TI-nspire BASIC
Battle of 16s (stalled) | sTIck RPG (stalled) | Monopoly (stalled) | Cosmic Legions (stalled)
Axe Parser
Doodle God (stalled while I go and learn some Axe)

Offline calc84maniac

  • eZ80 Guru
  • Coder Of Tomorrow
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2912
  • Rating: +471/-17
    • View Profile
    • TI-Boy CE
Re: Idling the CPU
« Reply #6 on: March 15, 2011, 09:52:50 am »
I think ARM is supposed to handle frequency changes well. I do know that the OS frequently clocks the processor down while idle, then clocks it back up when it needs to do something.
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman

Offline NeoCrisis

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 217
  • Rating: +14/-2
  • tihacker59
    • View Profile
Re: Idling the CPU
« Reply #7 on: March 15, 2011, 09:58:26 am »
that's funny, because mine did this too!! I thought it was the battery-level component which was buggy :o but my batteries are Duracell, and they must last more than 2 months :o when i started testing games and progs such as nTris, gbc4nspire, and the whole bunch of nice projects, it went slower, and slower, and slower, so I could difficultly move the character of Pokémon... Even when CPU runs at the official 2.0 CPU (it's with 2.1 currently)
« Last Edit: March 15, 2011, 09:59:11 am by rayquaza59 »



TI-Planet moderator

Offline Goplat

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 289
  • Rating: +82/-0
    • View Profile
Re: Idling the CPU
« Reply #8 on: March 15, 2011, 11:30:28 am »
I think ARM is supposed to handle frequency changes well. I do know that the OS frequently clocks the processor down while idle, then clocks it back up when it needs to do something.
It only changes the processor speed, though, keeping the bus speed constant.

OS 1.1-2.01: 145002 when active (CPU=90MHz AHB=15MHz), 14000c when idle (CPU=15MHz AHB=15MHz)
OS 2.1: 0a1002 when active (CPU=120MHz AHB=60MHz), 0a0004 when idle (CPU=60MHz AHB=60MHz)
Numquam te deseram; numquam te deficiam; numquam circa curram et te desolabo
Numquam te plorare faciam; numquam valedicam; numquam mendacium dicam et te vulnerabo

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Idling the CPU
« Reply #9 on: March 15, 2011, 03:18:58 pm »
The change from 90 to 120 was an excuse to them failing at optimizing 2.1 enough to run at the same speed as the old OS at 90 MHz?

Offline ExtendeD

  • Project Author
  • LV8 Addict (Next: 1000)
  • *
  • Posts: 825
  • Rating: +167/-2
    • View Profile
Re: Idling the CPU
« Reply #10 on: March 19, 2011, 04:09:42 am »
Sorry for this issue :(
I have updated idle() with Goplat's code. sleep() still uses idle() and is unchanged.
Programs needs to be rebuild to use the updated version.
Ndless.me with the finest TI-Nspire programs