high CPU usage with Unified Firmware on Raspberry Pi

[kms]

I’ve installed the new unified firmware 2.1.3 on my
Raspberry Pi model B + OpenSprinker Pi and it works great.
I’m happy, and so are my plants.

However as soon as the OpenSprinkler process is started after boot time,
it consumes all available CPU. This means the CPU runs hotter,
and the web GUI runs much slower than it should.

Tracing the process shows it is in a tight loop inside main.cpp:do_loop(),
continually talking to the GPIO pins, and querying/setting the time.
This behaviour is constant – it does not matter if the system is
idle, or if it is actively watering.

Is this high CPU usage a bug, or intentional?

Kim.

[Ray]

That’s a very good point, I haven’t thought about it — for the initial implementation I focused on getting the firmware compatible with OS, but I haven’t thought about making it more efficient for RPi. Right now the inner loop uses nonblocking socket, and repeatedly checks schedule data and so on. Although the GPIO pins are only read/write once every second, the busy poll of the loop is probably consuming the entire CPU. One solution is to add a short sleep at the end of the loop to give the CPU some spare time. A more ideal solution is probably to make the algorithm event driven or interrupt driven. I will do a few tests this weekend, in the meantime, feel free to experiment with it and post your findings. Thanks.

[kms]

> One solution is to add a short sleep at the end of the loop to give the CPU some spare time.

Yes, I thought about this but, not understanding the code, was reluctant to change things in
case I accidentally started turning the solenoids on and off every 10 milliseconds or something.

So, a quick test of adding a usleep(10000) to the end of the loop (ie, 10ms delay) has reduced the CPU usage to
about 2% when idle, and the system still works, and the solenoids havent exploded 😉

Thanks.

Kim.

[Ray]

Adding a short sleep has very little impact on the accuracy of running times — because the running times are all controlled by timer values (each station is given a start time and stop time, both of which are system times), the delay will not add up to affect the running time.

[Author]

Posts