-   OpenGauge / MPGuino FE computer (
-   -   MPGuino CPU > 100% (

arlo 07-16-2009 06:20 PM

MPGuino CPU > 100%
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?

NachtRitter 08-12-2010 09:14 PM

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 08-13-2010 11:35 AM

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 08-13-2010 02:28 PM

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 :confused:

nickdigger 08-15-2010 10:09 PM

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 08-16-2010 10:27 AM

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 08-17-2010 01:59 AM

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 08-17-2010 03:10 PM

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.

All times are GMT -4. The time now is 10:21 PM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Content Relevant URLs by vBSEO 3.5.2
All content copyright