C:Amie's StopWatch 1.0.3

UsedHandhelds came to me with some queries last week, one regarding getting more man-power friendly battery testing.

What I have always done historically is run a little stop watch app on the H/PC from 100% until the device auto suspends at the critical low battery alert.

Assuming that you are not too many days in between check-up or that you have a coin cell battery, you can AC the device, resume it and see where the timer on the stop watch is. Simple!

Do you know, I couldn't find a usable SA1100/XScale stop watch application anywhere to send along to UHH. Of the PPC ones that areout there, all of the ones that I looked at use the real time clock to manage the timer. The problem with that is when the device resumes from suspend, the timer recalculates based upon the real-world RTC chip time - factoring in all of the time that the device has been off for.

So I decided to write one up quickly, and here were are with C:Amie's StopWatch. It does it all without using the RTC, so if you are battery testing as I designed it for, when you resume the device on AC it will display the discharge time of the battery (it will continue ticking though).

It is a VB RTL application, consequently for .net users I have created cab redists of the required run-times (rather than the static versions on http://www.hpcfactor.com/developer/ ). They are available through H/PC:Update - not via my site.

More & Download: C:Amie (not) com

neat stuff! especially as i want to measure the battery life of some devices ...one day... so i went and tried it

but, as it is VB i wanted to test if it works at all, i have ambivalent feelings towards VB as a programming language

it turns out, it measures only about 1:56 or 1:57 in 2:00 mins:sec (tried on hpc2000), that would be a bit of a bias there. could that be fixed? of course it is probably only about 90 seconds in 2 hours, if the device is idle. so that's fine really..
under load, the delay seems to amount up to 6 seconds in 1 min, that would be 12 mins in 2 hours.
so i'd say measuring the battery time when idle this would be fine, but i think the difference is a bit too much for when measuring it under load.

as a result i started distrusting any battery application so as a comparison, i tried resinfo, that did not seem to have a delay in the 2 mins i was measuring it when device was idle. when under load, it was 0.5-1 sec delay in every min.
trick is maybe (other than it is not VB) that it doesn't try to read the time in every sec only in every 5 secs, that makes it more efficient probably.

anyway i will blame this on VB's inefficiency as a language. as an example just think of how VB does not call API's directly (resulting in much slower execution) and i assume this timing stuff needs to use functions from the OS.
btw, i don't think it is a problem to use RTC, if you don't use it in a way that calculates suspend time too, resinfo does both for you actually, it can calculate suspend time and can also calculate just the time during which the device was on.

You should always distrust benchmarking utilities as there is always a drift between a processor's temporal computational abilities and real-time, particuarly under load becuase the accuracy of RTC deminishes with fluctuations on the system bus's.

The entire point of the application was to avoid polling the RTC, so consequently the drift is entirely down to the processor under operating pressure with no safeguard checking against the RTC. There is no "trick" as the app does not read the time it counts updates from a systimer and then updates the display; updating the display every 5 seconds would be inconvenient.

The use of the high level language adds significant amounts of conversion and comprehension activity in the processor, therefore the number of instructions that it has to process is far higher.

In order to use the RTC to do it the application needs to be aware of suspend / resume state, the arm stop watch applications that are out there have no awareness of this and I needed a solution in about 20 minutes.

ok, this is the same i was saying so we agree, but also i was saying that under load the app is not reliable enough at least not for my needs.

what is the problem with resinfo? the fact it updates only in every 5 sec? other than that it seems to do the same as this stopwatch but more reliably especially when under load.

I just wanted to make an Arm stop watch application that people could use generally if they wanted to, I am not attempting out out commericalise Wolfgang, I just wanted to play with the IDE cmonex.

hehe i didn't think you would want to do that to him

BTW, i just had fun with OS timer register on xscale (900c), i find that i can reset it and at the same time resinfo's timer (along with gsbattmon etc) jumps ~19 mins while your stopwatch doesn't jump in time (i.e. stays correct). so, apparently RTC is only used for the suspend time calculation for resinfo and EVB timer control uses something else, i wonder what it is.

p.s.: on some 900c's you can get random OS timer resets and that will make the backlight turn off (if backlight timeout is set up.. by default it is) and all battery meters jump i don't know if it is a BSP fault or hardware.

Edited by cmonex 2008-01-12 9:33 PM

Humm, the systimer implementation on mine is not used to keep tabs on anything greater than 1000 milli-second periods of time, so the most you could ever force mine to jump by manipulating that register would be 1 second.

Random time resets, humm, have you observed it happening in a viewer? Perhaps something is signaling an interrupt with a higher priority than that of interrupt 0 - and winning.

yeah i noticed your app doesn't use the OS timer in this way. advantage on the 900c.

what did you call "viewer"?

it happens randomly, once in a couple of hours sometimes, sometimes not, maybe device dependant, i'll test this one day..

as for interrupts, CE interrupt system doesn't work like that especially on ARM. so still wondering what causes it..

C:Amie: trying to download your timer for my J728, but no luck finding it so far. Went to the S/W repository, no luck. Went to the HPC link you show and get bogged down in the maze. And sure enough, not on your site. Can you help? Thanks.

Edited by Hal 2008-02-05 11:59 AM

Download links are on the bottom of the page linked by "More & Download."

Geek: I tried that and the only "hot" downloads I found are:

Download: C:Amie's StopWatch 1.0.3 (VB Application only) (5 KB)

Download: C:Amie's StopWatch 1.0.3 alpha (.net Compact Framework 2.0 Application) (8 KB)

The VB application wants me to register and wants a key. The .net Compact Framework download gives a message saying missing components on my J728. Interesting that it runs on my XP laptop.

Now what?

To run C:Amie's stopwatch on their Jornada 7xx, here is the short version of what to do:

-click on: C:Amie (not) com above

-from the C:Amie site pick Download: C:Amie's StopWatch 1.0.3 (VB Application only) (5 KB)

-copy the file to your Jornada CF and run it



Edited by Hal 2008-02-05 11:47 PM

i never had any trouble in the first place, but only because i used IE... i used opera now out of curiousity and that led me elsewhere on the C:Amie site when clicking on the download link in the first post here.
did not try firefox

I didn't have any problem downloading it in Firefox.

I do not know how you managed to get a registration and key prompt from an application that doesn't have either. Suffice it to say, I have no idea what you did.