MPGuino CPU > 100%

[arlo]

Got my new kit from spiffie and got it running...
Note: There was an imperfection in the circuit board that was causing a short across one of the zener diodes. I scraped some metal away and fixed it (before powering on).

One odd thing is that the CPU Util. is at 123.27. What is this measurement and how is over 100% possible?
Thanks

[NachtRitter]

Reviving an old thread since it's regarding the same topic...

I'm seeing the same thing... Mine shows 238%... When I first installed it, it was about 63%... now it's over 100%. Everything works fine, so I can't imagine it's accurate.

I believe I've got v 0.75 loaded.

[dcb]

the %cpu timing loop gets out of whack when you use the setup screen. If you unplug it and replug it, it should clear up. I added it originally to ensure that code changes did not put the CPU over its processing budget, it should have no bearing on accuracy.

[NachtRitter]

Awesome, thanks... That's right, I remember having to change the VSS pulse count and then seeing the weird CPU % ... didn't think it affected anything, was more of a

[nickdigger]

Almost all the cpu % "load" is eaten up by all the delay periods for each LCD command. I reduced my delays from 5ms to 1ms (or whatever.. too lazy to look at the code), and my load dropped to around 10% on a 4-row LCD, 16mhz clock. I also added code to ignore cpu% if you entered Setup screens.

[dcb]

Well it isn't technically "eaten up".
The way it is organized is that display updates are run in the main loop (low priority) every 1/2 second, and sensor updates happen in interrupts (and interrupt the main loop). If we get to the bottom of the main loop, where we sit and wait for the remainder of the 1/2 second, and we don't have any time left, then we would be at %100 indicated. So all the computations to display and interrupts are taking about 1/4 second if the cpu is at %50 and the rest is idle time, sort of (interrupts still happening)

[nickdigger]

i know how it all works, and yes, the idle is being eaten up by every "delay2(5)" during every call to LcdCommandWrite and LcdDataWrite -- basically 5ms lost for every GotoXY and every char printed. Change those delays to "delay2(1)" and watch your cpu% hit single digits. I believe 1ms is within spec for the LCDs we're using, and i know it works on my 2-row and 4-row LCDs.

The computations are simple & fast; painting the screen (and data logging, if opted) is the real time consumer.

[dcb]

Thx Nick, I'll take another gander at the lcd code. It's been a while and I don't recall how it wound up at 5ms.