Re: NI Power Meter Results
Zach Pfeffer writes: > Just wanted to share this with everyone. > > I've attached the "output" folder that the NI instrument creates for > each test session. In the results file you'll see a text doc called > results.txt that lists the comma delimited parameters that get > measured followed by the measurements themselves: > > Current Cycle Average,Current Cycle RMS,Current Mean (DC),Current > Negative Peak,Current Peak to Peak,Current Positive Peak,Current > RMS,Volt Cycle Average,Volt Cycle RMS,Volt Mean (DC),Volt Negative > Peak,Volt Peak to Peak,Volt Positive Peak,Volt RMS > > See: > > https://docs.google.com/a/linaro.org/file/d/0B3pUtxWjZbP9bFhqNGZfYzNSMWs/edit That actually looks fairly similar to what you get out of streamline with the energy probe. Not too surprising I guess. > Included in each record is a Record Number that indexes into the > "report directory." Each directory is marked with an index and under > that directory is the graph associated with the data for example: > > https://docs.google.com/a/linaro.org/file/d/0B3pUtxWjZbP9VnVQS3M4WWx1OVk/edit > > In addition, controlling the instrument is super easy. You connect to > the box over TCP/IP the you can send 5 single character commands in > any order: 1,0,s,e,r > > 1 turns the power on > 0 turns it off > s starts a measurement > e ends a measurement > r records > > r is destructive, so if you send an r it erase the previous data > record. The data record does survive instrument restarts (as opposed > to having an implicit r at the start of the measurement. I'm not sure I entirely understand. What's the difference between "r" and "s", aside from the fact that r erases previous data? Is there any reason to power the device down between tests in the usual course of things? > At any point the existing data set can simply be uploaded. This is just putting things into my language rather than yours I guess, but is it correct to stay that your VI puts the output in a known location, so other processes on the box can access it? I'm imagining something like the following course of events during a test run (please forgive a certain amount of hand-waving): * The LAVA host sends '1' if necessary to the VI and then 'r' * for each test case: * The target sends 's' to the VI * The target runs the test case * The target send 'e' to the VI * The LAVA host grabs the results from the VI and matches the power data against the test results * The host (maybe?) sends '0' to the VI. * The results are uploaded to the dashboard and displayed in some useful way > One minor point. This instrument produces a lot of data, instead of > moving all this data around, the instrument can be configured to do > all the measurement, making the analyzed data set easier to understand > and faster to upload. Yeah, I think that we'd like to just upload something like the readings.txt file for now? Or possibly something even more derived than that to start with... just the average power draw over a period would be a good start! > Comments and questions welcome. > > See it in action at: > https://plus.google.com/u/0/104422661029399872488/posts/NU4pZ36L13U > Cheers, mwh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: NI Power Meter Results
I should have watched the video before replying! Sorry about that. I think it answered all my questions. A few more comments below. Michael Hudson-Doyle writes: > Zach Pfeffer writes: > >> Just wanted to share this with everyone. >> >> I've attached the "output" folder that the NI instrument creates for >> each test session. In the results file you'll see a text doc called >> results.txt that lists the comma delimited parameters that get >> measured followed by the measurements themselves: >> >> Current Cycle Average,Current Cycle RMS,Current Mean (DC),Current >> Negative Peak,Current Peak to Peak,Current Positive Peak,Current >> RMS,Volt Cycle Average,Volt Cycle RMS,Volt Mean (DC),Volt Negative >> Peak,Volt Peak to Peak,Volt Positive Peak,Volt RMS >> >> See: >> >> https://docs.google.com/a/linaro.org/file/d/0B3pUtxWjZbP9bFhqNGZfYzNSMWs/edit > > That actually looks fairly similar to what you get out of streamline > with the energy probe. Not too surprising I guess. Except that each line summarises a measurement, whereas with the energy probe each line summarises a sample period (i.e. 1ms). >> Included in each record is a Record Number that indexes into the >> "report directory." Each directory is marked with an index and under >> that directory is the graph associated with the data for example: >> >> https://docs.google.com/a/linaro.org/file/d/0B3pUtxWjZbP9VnVQS3M4WWx1OVk/edit >> >> In addition, controlling the instrument is super easy. You connect to >> the box over TCP/IP the you can send 5 single character commands in >> any order: 1,0,s,e,r >> >> 1 turns the power on >> 0 turns it off >> s starts a measurement >> e ends a measurement >> r records >> >> r is destructive, so if you send an r it erase the previous data >> record. The data record does survive instrument restarts (as opposed >> to having an implicit r at the start of the measurement. > > I'm not sure I entirely understand. What's the difference between "r" > and "s", aside from the fact that r erases previous data? I think 'r' should be a mnemonic for 'reset' not 'record' :-) > Is there any reason to power the device down between tests in the usual > course of things? I see here that 1/0 controls power to the device under test, not the NI hardware. I was a bit confused. I assume the VI isn't particularly connection-oriented? I mean that if you connect, send 1, disconnect, connect again and send r, the effect is the same as just connecting and sending 1 then r? We'll need to teach lava how to power control a NI-attached board then -- but that looks really easy, so I'm not at all worried about this. Is there any latency between the VI receiving the 's' byte and starting measurement? >> At any point the existing data set can simply be uploaded. > > This is just putting things into my language rather than yours I guess, > but is it correct to stay that your VI puts the output in a known > location, so other processes on the box can access it? > > I'm imagining something like the following course of events during a > test run (please forgive a certain amount of hand-waving): > > * The LAVA host sends '1' if necessary to the VI and then 'r' > * for each test case: > * The target sends 's' to the VI > * The target runs the test case > * The target send 'e' to the VI > * The LAVA host grabs the results from the VI and matches the power data > against the test results > * The host (maybe?) sends '0' to the VI. > * The results are uploaded to the dashboard and displayed in some useful > way I had this mostly right I think, apart from the stuff about 1/0, and, because of what readings.txt actually records, the "match the power data against the test results" is going to be really easy. >> One minor point. This instrument produces a lot of data, instead of >> moving all this data around, the instrument can be configured to do >> all the measurement, making the analyzed data set easier to understand >> and faster to upload. > > Yeah, I think that we'd like to just upload something like the > readings.txt file for now? Or possibly something even more derived than > that to start with... just the average power draw over a period would be > a good start! And now I see that "just the average power draw over a period" is actually what readings.txt contains :-) >> Comments and questions welcome. >> >> See it in action at: >> https://plus.google.com/u/0/104422661029399872488/posts/NU4pZ36L13U >> Cheers, mwh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: NI Power Meter Results
On 23 September 2012 19:28, Michael Hudson-Doyle wrote: > Zach Pfeffer writes: > >> Just wanted to share this with everyone. >> >> I've attached the "output" folder that the NI instrument creates for >> each test session. In the results file you'll see a text doc called >> results.txt that lists the comma delimited parameters that get >> measured followed by the measurements themselves: >> >> Current Cycle Average,Current Cycle RMS,Current Mean (DC),Current >> Negative Peak,Current Peak to Peak,Current Positive Peak,Current >> RMS,Volt Cycle Average,Volt Cycle RMS,Volt Mean (DC),Volt Negative >> Peak,Volt Peak to Peak,Volt Positive Peak,Volt RMS >> >> See: >> >> https://docs.google.com/a/linaro.org/file/d/0B3pUtxWjZbP9bFhqNGZfYzNSMWs/edit > > That actually looks fairly similar to what you get out of streamline > with the energy probe. Not too surprising I guess. > >> Included in each record is a Record Number that indexes into the >> "report directory." Each directory is marked with an index and under >> that directory is the graph associated with the data for example: >> >> https://docs.google.com/a/linaro.org/file/d/0B3pUtxWjZbP9VnVQS3M4WWx1OVk/edit >> >> In addition, controlling the instrument is super easy. You connect to >> the box over TCP/IP the you can send 5 single character commands in >> any order: 1,0,s,e,r >> >> 1 turns the power on >> 0 turns it off >> s starts a measurement >> e ends a measurement >> r records >> >> r is destructive, so if you send an r it erase the previous data >> record. The data record does survive instrument restarts (as opposed >> to having an implicit r at the start of the measurement. > > I'm not sure I entirely understand. What's the difference between "r" > and "s", aside from the fact that r erases previous data? r clears the previous run's data and gets the files ready for the next runs. s just starts the measurement, its a software trigger, e ends the measurement you can say s and e multiple times. Each time an entry gets made into the readings.txt file and a graph capture gets made. > Is there any reason to power the device down between tests in the usual > course of things? Not sure, but it may prove a useful thing to do. We have been power cycling between lava tests to improve reproducibility so i suspect power tests may need the same feature. >> At any point the existing data set can simply be uploaded. > > This is just putting things into my language rather than yours I guess, > but is it correct to stay that your VI puts the output in a known > location, so other processes on the box can access it? Actually, the idea is for LAVA to upload the data set via FTP. I'm also going to add a z command which will zip up the data set. They'll be FTP running on the box (or whatever we need) and LAVA will just transfer the files and save them with the test run. > I'm imagining something like the following course of events during a > test run (please forgive a certain amount of hand-waving): > > * The LAVA host sends '1' if necessary to the VI and then 'r' > * for each test case: > * The target sends 's' to the VI > * The target runs the test case > * The target send 'e' to the VI > * The LAVA host grabs the results from the VI and matches the power data > against the test results > * The host (maybe?) sends '0' to the VI. > * The results are uploaded to the dashboard and displayed in some useful > way Yeah, that's basically it. >> One minor point. This instrument produces a lot of data, instead of >> moving all this data around, the instrument can be configured to do >> all the measurement, making the analyzed data set easier to understand >> and faster to upload. > > Yeah, I think that we'd like to just upload something like the > readings.txt file for now? Or possibly something even more derived than > that to start with... just the average power draw over a period would be > a good start! Take a look at the readings.txt the figure of merit is the RMS Current. That's what you should display. Voltage is more or less constant, though I also present the RMS voltage. But you'll want to actually show all the numbers in there. >> Comments and questions welcome. >> >> See it in action at: >> https://plus.google.com/u/0/104422661029399872488/posts/NU4pZ36L13U >> > > Cheers, > mwh -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] mfd: Implement devicetree support for AB8500 fg
From: "Rajanikanth H.V"
This patch adds device tree support for
fuel guage driver
Signed-off-by: Rajanikanth H.V
---
Documentation/devicetree/bindings/mfd/ab8500.txt |8 +-
.../devicetree/bindings/power_supply/ab8500/fg.txt | 86
arch/arm/boot/dts/dbx5x0.dtsi | 22 +-
drivers/mfd/ab8500-core.c |1 +
drivers/power/Makefile |2 +-
drivers/power/ab8500_bmdata.c | 454
drivers/power/ab8500_fg.c | 169 +++-
include/linux/mfd/abx500.h |7 +-
include/linux/mfd/abx500/ab8500-bm.h |7 +
9 files changed, 731 insertions(+), 25 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
create mode 100644 drivers/power/ab8500_bmdata.c
diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt
b/Documentation/devicetree/bindings/mfd/ab8500.txt
index ce83c8d..762dc11 100644
--- a/Documentation/devicetree/bindings/mfd/ab8500.txt
+++ b/Documentation/devicetree/bindings/mfd/ab8500.txt
@@ -24,7 +24,13 @@ ab8500-bm: :
: Battery Manager
ab8500-btemp : : : Battery
Temperature
ab8500-charger : : : Battery
Charger
ab8500-codec : : : Audio Codec
-ab8500-fg: : : Fuel Gauge
+ab8500-fg: : vddadc : Fuel Gauge
+: NCONV_ACCU : : Accumulate N
Sample Conversion
+: BATT_OVV : : Battery Over
Voltage
+: LOW_BAT_F: : LOW threshold
battery voltage
+: CC_INT_CALIB : : Counter
Counter Internal Calibration
+: CCEOC: : Coulomb
Counter End of Conversion
+: : :
ab8500-gpadc : HW_CONV_END : vddadc : Analogue to
Digital Converter
SW_CONV_END : :
ab8500-gpio : : : GPIO
Controller
diff --git a/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
b/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
new file mode 100644
index 000..c576558
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
@@ -0,0 +1,86 @@
+=== AB8500 Fuel Gauge Driver ===
+
+AB8500 is a mixed signal multimedia and power management
+device comprising: power and energy-management-module,
+wall-charger, usb-charger, audio codec, general purpose adc,
+tvout, clock management and sim card interface.
+
+Fuel-guage support is part of energy-management-module, the other
+components of this module are:
+main-charger, usb-combo-charger and Battery temperature monitoring.
+
+The properties below describes the node for fuel guage driver.
+
+Required Properties:
+- compatible = "stericsson,ab8500-fg"
+- interface-name:
+ Name of the controller/driver which is part of energy-management-module
+- supplied-to:
+ This property shall have dependent nodes which represent other
+ energy-management-module.
+ This is a logical binding w.r.t power supply events
+ across energy-management-module drivers where-in, the
+ runtime battery properties are shared along with uevent
+ notification.
+ ref: di->fg.external_power_changed =
+ ab8500_fg_external_power_changed;
+ ab8500_fg.c
+
+ Need for this property:
+ energy-management-module driver updates power-supply properties
+ which are subset of events listed in 'enum
power_supply_property',
+ ref: power_supply.h file
+ Event handler invokes power supply change notifier
+ which in-turn invokes registered power supply class call-back
+ based on the 'supplied-to' string.
+ ref:
+ power_supply_changed_work(..)
./drivers/power/power_supply_core.c
+ di->fg_psy.external_power_changed
+
+ example:
+ ab8500-fg {
+ /* Other enery management module */
+ supplied-to = <&ab8500_chargalg &ab8500_usb>;
+ };
+
+ ab8500_battery_info: ab8500_bat_type {
+ battery-type = <2>;
+ thermistor-on-batctrl = <1>;
+ };
+
+Other dependent node for fuel-gauge is:
+ ab8500_battery_info: ab8500_bat_type {
+ };
+ This node will provide information on 'thermistor interface' and
+ 'battery technology type' used.
+
+Properties of this node are:
+thermistor-on-batctrl:
+
