|
2010-07-28
, 01:13
|
Posts: 726 |
Thanked: 345 times |
Joined on Apr 2010
@ Sweden
|
#2
|
|
2010-07-28
, 01:23
|
Posts: 8 |
Thanked: 1 time |
Joined on Jun 2008
|
#3
|
|
2010-07-28
, 10:28
|
Posts: 1,258 |
Thanked: 672 times |
Joined on Mar 2009
|
#4
|
|
2010-07-28
, 13:00
|
Posts: 726 |
Thanked: 345 times |
Joined on Apr 2010
@ Sweden
|
#5
|
Cheers for your reply. Yea i'll be wanting real time updates, but my main concern is avoiding infinite loops or big loops as much as possible.
The problem i think about using usleep is that it'll halt execution for a period of time, but i will require the function to re-execute after a period of time. I can achieve what i want with loops, but as we all know it's nasty to do so.
while(1) { get_and_send_sample(); usleep(DELAY); }
|
2010-07-28
, 13:04
|
Posts: 726 |
Thanked: 345 times |
Joined on Apr 2010
@ Sweden
|
#6
|
Actually the CPU doesn't tick at all if there are no timers about to expire.
When the time to the next timer firing gets large enough, the CPU clocks and voltage are switched off, completely halting the CPU and dropping power consumption of CPU to near-zero. The RAM is kept alive, and the CPU eventually gets woken up by an external timer or external IRQ, to process whatever app requested to be woken up..
So yes, if you have a timer that fires every 100ms, there will be a significant impact on standby battery life. XChat used to have a periodical 1-second timer (IIRC), and when the maintainer managed to get rid of it, battery life improved significantly for me :-)
|
2010-07-28
, 18:58
|
Posts: 1,258 |
Thanked: 672 times |
Joined on Mar 2009
|
#7
|
This makes no sense. With 150+ processes running on your device, you will have some process running in the CPU at almost all time.
The kernel doesn't stop, hence the CPU can't halt. Device drivers rely on the continuous flow of timing ticks in the kernel.
The tickless kernel feature (CONFIG_NO_HZ) enables 'on-demand' timer interrupts: if there is no timer to be expired for say 1.5 seconds when the system goes idle, then the system will stay totally idle for 1.5 seconds. This should bring cooler CPUs and power savings: on our (x86) testboxes we have measured the effective IRQ rate to go from HZ to 1-2 timer interrupts per second.
C# | Ratio | Avg/dura | Frequency | Ratio --------+--------+----------+-----------+--------+ C0 | 10.0% | | 600 MHz | 9.5% | C1 | 0.2% | 0.3ms | 550 MHz | 0.0% | C2 | 12.1% | 2.5ms | 500 MHz | 11.7% | C3 | 26.6% | 101.2ms | 250 MHz | 78.8% | C4 | 51.0% | 528.4ms |
Power domain activity breakdown Domain | % of time spent in states --------+---------+---------+---------+---------+---------- usbhost |OFF: 100%|RET: 0%|INA: 0%| ON: 0%| now:(OFF) sgx |OFF: 96%|RET: 0%|INA: 0%| ON: 3%| now:(OFF) per |OFF: 75%|RET: 13%|INA: 0%| ON: 10%| now:(ON) dss |OFF: 92%|RET: 0%|INA: 0%| ON: 7%| now:(ON) cam |OFF: 100%|RET: 0%|INA: 0%| ON: 0%| now:(OFF) core |OFF: 50%|RET: 24%|INA: 3%| ON: 21%| now:(ON) neon |OFF: 50%|RET: 26%|INA: 11%| ON: 10%| now:(ON) mpu |OFF: 50%|RET: 26%|INA: 11%| ON: 10%| now:(ON) iva2 |OFF: 100%|RET: 0%|INA: 0%| ON: 0%| now:(OFF)
The Following 3 Users Say Thank You to shadowjk For This Useful Post: | ||
|
2010-07-28
, 19:05
|
Posts: 219 |
Thanked: 94 times |
Joined on Nov 2009
@ Helsinki, Finland
|
#8
|
|
2010-07-28
, 19:16
|
Posts: 8 |
Thanked: 1 time |
Joined on Jun 2008
|
#9
|
|
2010-07-28
, 19:22
|
Posts: 726 |
Thanked: 345 times |
Joined on Apr 2010
@ Sweden
|
#10
|
Also at the same time I'm thinking even if it would start to drain the battery to begin with, as using timers only use processor tick's, so my code will only execute when the processing ticks rollover.