Hi,
I want to measure power of beagle board. I have gone through
following discussions :
http://groups.google.com/group/beagleboard/browse_thread/thread/8e144759459a39bf
http://groups.google.com/group/beagleboard/msg/ecde5558347bbc0e
Can anyone help me on how to do it.
Thanks in advance
Tapas
tapascst@gmail.com
I suggest you power the board via the 5VDC power jack and connect a current meter in series with the 5V supply and read the current there.
Gerald
This is exactly what we've done to do some power testing first with
an old Rev B4 board and now (as of today) a new Rev C3 board.
Previously, using one of Kevin Hilman's power management kernels, I
saw about 0.200A with nothing hooked up and no changes to anything.
After doing an "echo 1" to various things like "sleep_while_idle",
"enable_off_mode", etc., and after (I think) making the vdd1_opp be 1
and vdd2_opp be 2, and lastly after setting the maximum cpu frequency
to 125000 (KHz), after going into suspend mode, current went down to
0.138A or so.
I wouldn't be surprised if I'm doing some things incorrectly or
inefficiently (since sub 100mW is apparently doable in an extremely
deep sleep/low power state and I'm nowhere near that). Also, not
trying to hijack a thread, just providing some input on my own power
measurement experience, since it might be useful, and I might learn
something new.
Did you disable the DVI-D framer and turn off the LEDS?
Gerald
I'm intending to use the BeagleBoard for a hand-held terminal, and need to interface it with an LCD touchscreen panel.
Can anyone here on the list weigh in as to pros/cons of hooking up a display via DVI/HDMI versus using the raw LCD output and connecting it directly to a panel? Obviously there will need to be some electronics involved to convert the signals from the BB into the format or levels required by a LCD panel, but then once a suitable interface has been made, would this be simpler or cheaper than using the DVI interface?
One panel I am interested in, due to it's high quality, wide availability and low cost is the LCD from a PSP - an example of which is here:
http://www.sparkfun.com/commerce/product_info.php?products_id=8335
Touchscreen overlay:
http://www.sparkfun.com/commerce/product_info.php?products_id=8448
Has anyone successfully got a BB talking to an LCD like this, or is everyone using DVI or S-Video for the display?
Cheers,
Kai
I would use the LCD raw interface. We have several people that have already hooked up this display and touchscreen to the Beagle and have it working using the raw LCD interface. This is the simplest way to do it. Using HDMI is much more complicated.
https://specialcomp.com/beagleboard/beagle_lcd.htmhttps://specialcomp.com/beagleboard/beagle_lcd.htm
Gerald
Hi Gerald,
Thank you very much for the quick reply. I had the belief that the raw LCD interface was the way to go, but having someone else back me up with that thought is good. Thanks also for the links, they’re just what I’ll need.
Cheers,
Kai
Glad to help.
Gerald
Did you disable the DVI-D framer and turn off the LEDS?
Gerald
Yes, I forgot to mention this. Using the gpio interface (149 and 150
for the LEDs and 170, I think, for the DVI-D frame) those were turned
off as well.
Great!
Gerald
I would use the LCD raw interface. We have several people that have already
hooked up this display and touchscreen to the Beagle and have it working
using the raw LCD interface. This is the simplest way to do it. Using HDMI
is much more complicated.https://specialcomp.com/beagleboard/beagle_lcd.htm*
https://specialcomp.com/beagleboard/beagle_lcd.htm<https://specialcomp.com/
beagleboard/beagle_lcd.htmhttps://specialcomp.com/beagleboard/beagle_lcd.htm*
Gerald
> I'm intending to use the BeagleBoard for a hand-held terminal, and need
> to interface it with an LCD touchscreen panel.
>
> Can anyone here on the list weigh in as to pros/cons of hooking up a
> display via DVI/HDMI versus using the raw LCD output and connecting it
> directly to a panel? Obviously there will need to be some electronics
> involved to convert the signals from the BB into the format or levels
> required by a LCD panel, but then once a suitable interface has been
> made, would this be simpler or cheaper than using the DVI interface?
>
> One panel I am interested in, due to it's high quality, wide availability
> and low cost is the LCD from a PSP - an example of which is here:
> http://www.sparkfun.com/commerce/product_info.php?products_id=8335
> Touchscreen overlay:
> http://www.sparkfun.com/commerce/product_info.php?products_id=8448
>
> Has anyone successfully got a BB talking to an LCD like this, or is
> everyone using DVI or S-Video for the display?
>
> Cheers,
> Kai
If you are strongly prefer that particular LCD, it will work. The raw LCD
interface makes it almost trivial to interface with that LCD. That entire
board is all glue logic. IIRC, the HDMI interface cannot work with that LCD
without extra stuff per the spec due to a mininum clock requirement. Has
anyone actually tried looking at the behavior of the QFP410 with a slow
clock.
A heads up I found from characterizing that LCD (it is all posted before) is
that this LCD's behavior in the corner cases does not behave nicely. It is
not a nice degradation. This is the reason I went with a different LCD. You
can see the new design at http://www.hy-research.com/beagle_lcd2.html
Just as a followup to the basic power measurement side of this
thread, as opposed to the LCD discussion side, after getting Kevin
Hilman's very latest PM branch, using the omap3_pm_defconfig, changing
from UART1 to UART3 (as instructed), and making the powersave governor
the default, my multimeter now reports 82mA in suspended state. A
pretty decent reduction, in my opinion. For some weird reason, doing
an "echo 149 > export" in the /sys/class/gpio directory no longer
creates a gpio149 interface. All relevant gpio stuff is enabled in
the .config, so this is kind of weird. However, the two LED's
controlled by 149 & 150 seem to be off by default. In arch/arm/mach-
omap2/board-omap3beagle.c I changed the DVI framer to off in the
omap3_beagle_init() function.
For those in the know and with the time to answer/comment, a few
questions/comments:
1) What is the point of the 'voltage_off_while_idle' control? It
doesn't actually seem to impact anything (no change in current) in
idle mode. If it is enabled and suspend mode is entered, on resume
the board is rebooted. Um, woo? Is that intentional or am I missing
something or doing something wrong?
2) Previously, I got a ton of "failed to enter target state"
messages, which I'm sure explains a lot of the higher observed current
usage, now I'm getting none of these messages. When I look at
pm_debug/count I see a lot of OFF transitions for all power domains,
including core and mpu.
3) Towards the end of the boot process, I see six
"regulator_init_complete: incomplete constraints, leaving X on" for
VDVI, VDAC, VMMC1, VUSB3V1, VUSB1V8, and VUSB1V5. Anything here to be
concerned about? Could I something leave these _off_ and save power
somehow?
4) Any idea why doing 'echo 149 > export' in the /sys/class/gpio
directory had no effect? That stuff was all enabled by the
omap3_pm_defconfig, so kind of weird there.
Thanks,
Bill Bock
In the 2.6.31 kernel (at least the one I'm using), the leds are controlled
through a led-specific driver. If you just want to turn them off, you can
mess with them through /sys/class/leds, with more info available in
$KERNEL/Documentation/leds-class.txt
Cameron.
Howdy:
A brief followup:
Control of the DVI framer can be exposed by adding gpio_export(170,
0) to the init function in board-omap3beagle.c
The 'voltage_off_while_idle' control may be a bit misnamed, although
it does exactly what it is designed to do, according to this: (http://
www.mail-archive.com/linux-omap@vger.kernel.org/msg11562.html)
As of May it might be possible that the 82mA I've seen is around
where purely software changes can lower power consumption the most,
and further reductions might require the types of hardware
modifications that Russ Dill did here: (http://groups.google.com/group/
beagleboard/browse_thread/thread/197a8ef6b46cc828) That's according
to this link (http://www.mail-archive.com/linux-omap@vger.kernel.org/
msg11442.html) and this link (http://markmail.org/message/
5snzyp74s2o7snzv)
I could easily be misinterpreting things and there may have been
drastic software improvements in the last several months. However, I
think we're going to try some of the simpler hardware mods to see what
happens.
-Bill Bock
DFT