Power Consumption - some Measurements - page 3 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 [3] 4   Go Down

Power Consumption - some Measurements

  • 33 Replies
  • 15106 Views
*

Offline RaduP

  • *****
  • 908
Re: Power Consumption - some Measurements
« Reply #20 on: 08 / November / 2009, 05:07:22 »
Advertisements
Fudgey, if you still have access to your power supply and your camera, can you maybe try this code in boot.c?
Note that the LED address 0xc0220130 needs to be changed, but I think the CLOCKs address is the same.
The LED should bring about every 3 seconds, so that means 1mhz.
And if you have other ideas, please share.

Code: [Select]
void delay(int n)
{
int i;

for(i=0;i<n;i++)
asm volatile (
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    "nop\n"
    );
}

void __attribute__((naked,noinline)) boot() {

int i=0;
*(int *)(0xC0400044)=5;
delay(100);
*(int *)(0xC0400048)=5;
delay(100);
*(int *)(0xC040004c)=5;
delay(100);

while(1)
{
*((volatile int *) 0xc0220130) = 0x46;
delay(100);


*((volatile int *) 0xc0220130) = 0x44; // Turn off LED
delay(100000);
}
//rest of the boot code.
Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Power Consumption - some Measurements
« Reply #21 on: 08 / November / 2009, 06:25:35 »
Quote from: RaduP on 08 / November / 2009, 05:07:22
Fudgey, if you still have access to your power supply and your camera, can you maybe try this code in boot.c?
Note that the LED address 0xc0220130 needs to be changed, but I think the CLOCKs address is the same.
The LED should bring about every 3 seconds, so that means 1mhz.

I can't do input current measurements until tomorrow, but I already tried the code. Using addr 0xc02200c4 blue led blink period is approx 2 seconds (around 31 blinks per minute). It works from both PS.FIR and DISKBOOT.BIN boots, it'll be interesting to see whether there's a difference in power consumption between those two methods.

I still use gcc3.
Logged
*

Offline RaduP

  • *****
  • 908
Re: Power Consumption - some Measurements
« Reply #22 on: 08 / November / 2009, 12:53:57 »
Hmm, 2 seconds?
That's interesting, I wonder why your camera can't set the clock as low as mine.
And yes, would be interesting to see if the firmware or bootdisk method draw more current, then maybe we can get a hint on what else eats the power.
Logged
*

Offline RaduP

  • *****
  • 908
Re: Power Consumption - some Measurements
« Reply #23 on: 08 / November / 2009, 13:24:35 »
One more thing. I am curious if NOP is energy efficient or not.
So can you also try this? Call it once right after you set the clocks. It will freeze the camera, because the interrupts are disabled (I think), but I am curious how the power consumption changes, if it is any different than just running nops.

void wait_for_intrerrupt()
{
   asm volatile (
      "MCR p15, 0, R0, c7, c0, 4"
      );
}

Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Power Consumption - some Measurements
« Reply #24 on: 08 / November / 2009, 15:01:49 »
Quote from: RaduP on 08 / November / 2009, 13:24:35
One more thing. I am curious if NOP is energy efficient or not.
So can you also try this? Call it once right after you set the clocks. It will freeze the camera, because the interrupts are disabled (I think), but I am curious how the power consumption changes, if it is any different than just running nops.

Yep, it freezes. I'll measure that one too.
Logged
*

Offline RaduP

  • *****
  • 908
Re: Power Consumption - some Measurements
« Reply #25 on: 08 / November / 2009, 22:56:12 »
Ok, something interesting..
I was assuming that when I am using the wait for interrupt instruction in the boot code the camera freezes because the interrupts are not enabled in the CPSR.
However, after reading the arm docs, it seems that the CPU will wake up even if they interrupt flags are disabled. So since it never wakes up, I guess the CPU doesn't get an external interrupt at all (I was hoping that pressing the buttons might do it, but it doesn't).
So probably there is some MMIO address that enables an external oscillator that generates the interrupts or something..
Logged
*

Offline reyalp

  • ******
  • 13938
Re: Power Consumption - some Measurements
« Reply #26 on: 08 / November / 2009, 23:53:11 »
Quote from: RaduP on 08 / November / 2009, 22:56:12
So since it never wakes up, I guess the CPU doesn't get an external interrupt at all (I was hoping that pressing the buttons might do it, but it doesn't).
Correct, the buttons are polled, they don't need to generate interrupts. See physw task.

You can find the canon interrupt handling code quite easily, the interrupt handlers are copied to instruction TCM (4k starting at address 0) very early in the boot process. See ARM Architecture Reference Manual chapter 7 for information about TCMs

Note that when the camera first starts, the interrupt vector is set to the high vectors at 0xFFFF0000, not zero.  See ARM Architecture Reference Manual A2.6.11 High vectors

These items are also both discussed in ARM946E-S Technical Reference Manual
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 908
Re: Power Consumption - some Measurements
« Reply #27 on: 09 / November / 2009, 00:38:09 »
Well, I might be wrong, but I don't think I need to worry about how the interrupts are handled and stuff.
Based on what I've read, based on a slightly different CPU, you can have the interrupts disabled but they would still wake up the CPU: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0311d/I1014521.html

Quote
Asserting nIRQ or nFIQ wakes the processor from wait-for-interrupt state even if the I or F interrupt disable bit is set in the CPSR. If interrupts are enabled, the ARM968E-S processor is guaranteed to take the interrupt before executing the next instruction after the wait-for-interrupt instruction.

So I am thinking that the IRQ generator is some low frequency clock or something, that generates an interrupt every so many MS. And I think that circuit is enabled after a certain point in the boot process (which I am trying to determine).
Logged
*

Offline reyalp

  • ******
  • 13938
Re: Power Consumption - some Measurements
« Reply #28 on: 09 / November / 2009, 00:52:58 »
Quote from: RaduP on 09 / November / 2009, 00:38:09
Well, I might be wrong, but I don't think I need to worry about how the interrupts are handled and stuff.
I was suggesting that looking at the code that handles interrupts would give you a hint as to which things trigger them.
Quote
based on a slightly different CPU, you can have the interrupts disabled but they would still wake up the CPU: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0311d/I1014521.html
Although it doesn't matter in this case, I can't imagine why you would choose refer to the docs for the wrong CPU when the correct ones are readily available the very same site ?
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 908
Re: Power Consumption - some Measurements
« Reply #29 on: 09 / November / 2009, 01:21:44 »
Quote from: reyalp on 09 / November / 2009, 00:52:58
I was suggesting that looking at the code that handles interrupts would give you a hint as to which things trigger them.
I first took a cursory look at the boot process, but it branches too much so I couldn't find anything yet. And it is quite possible that the interrupts handling way before the actual hardware is started.
The way I am doing it is call my function that waits for interrupts and blinks the LED at various points in the boot process, then narrow it down to where it actually works. So far, I found a generic routine where this is done, but it's quite big and branches more, so I need to hijack more functions until I find the exact place. I don't even know what exactly I am looking for, although I suspect that some MMIO location is involved.

Quote
Although it doesn't matter in this case, I can't imagine why you would choose refer to the docs for the wrong CPU when the correct ones are readily available the very same site ?

I found the link based on some discussion forums, and just assumed that the basic concept is the same on all ARMs from the same architecture.
Logged
Pages: 1 2 [3] 4   Go Up
« previous next »
 

Related Topics