Hello Andy,
"As far as I can tell from what you've mentioned, the uC's are sending interrupts asynchronously to the CPU (S635MP Via MoBo), and the graphics are not able to keep up with the incoming data."
Ah .. not exactly. I am having trouble keeping the graphics from flickering on the tach. Running less that 1% CPU. Case of getting the graphics to function the way I want :)
"It seems to me that if you were to buffer the incoming data in memory and average the incoming data for each uC every 16 milliseconds via a polling routine, you would have a flicker free 60Hz display. As it stands now you could have each of the uC's generating an interrupt every .01 milliseconds (or perhaps even every uSec). There isn't an off the shelf monitor/video card combo in the world that can keep up with that type of blistering pace (though if you used oscilliscopes for each channel you might - verrry expensive). So back to averaging out the incoming data at 16 millisecs intervals, you could use Blitz banks, which are chunks of managed memory that you can use any way you like, and is very fast, as the buffer for the incoming data stream."
To poll or not to poll, that is the question :)
Reference the timing: The uC's 'resolution' for the PW time period is .01ms .. the PC hasn't a clue about this. PC would 'send' a value to a uC stating how many .01ms iterations were required .. 255 * .01 = 2.55ms total PWM time period etc. All a UC thing.
12K RPM = 100 Rcv/Xmit 'events' per second per cylinder = .01 seconds. The .01ms is uC specific. A 12 Cyl at 12K would have 6 events per 360 degree revolution = 600 total 'events' per second per rev = 1.33 Million instructions 'between' events at 800MHz. Considering I had been dealing solely with 16MHz uC's .. that is a lifetime :)
Assuming a fixed display freq of 60Hz and the system providing 600Hz freq of "information" I see it as reading the 'latest' information in some cases and averaging in others. At 1K RPM I'm only getting 50Hz of info.
Take care,
And why I lean toward multiple instances. Need a function? Add an instance (or mod an existing one). Then mess with main as to when to display the display the data.
Better still, if you can use a rolling average for the each of the incoming data streams, you should get a display that is exactly what you have described with a silky smooth flicker free 60Hz and still be very accurate. Even at only 60Hz display updates, the gauges will *appear* to be functioning in real time to the average person.
"As far as I can tell from what you've mentioned, the uC's are sending interrupts asynchronously to the CPU (S635MP Via MoBo), and the graphics are not able to keep up with the incoming data."
Ah .. not exactly. I am having trouble keeping the graphics from flickering on the tach. Running less that 1% CPU. Case of getting the graphics to function the way I want :)
"It seems to me that if you were to buffer the incoming data in memory and average the incoming data for each uC every 16 milliseconds via a polling routine, you would have a flicker free 60Hz display. As it stands now you could have each of the uC's generating an interrupt every .01 milliseconds (or perhaps even every uSec). There isn't an off the shelf monitor/video card combo in the world that can keep up with that type of blistering pace (though if you used oscilliscopes for each channel you might - verrry expensive). So back to averaging out the incoming data at 16 millisecs intervals, you could use Blitz banks, which are chunks of managed memory that you can use any way you like, and is very fast, as the buffer for the incoming data stream."
To poll or not to poll, that is the question :)
Reference the timing: The uC's 'resolution' for the PW time period is .01ms .. the PC hasn't a clue about this. PC would 'send' a value to a uC stating how many .01ms iterations were required .. 255 * .01 = 2.55ms total PWM time period etc. All a UC thing.
12K RPM = 100 Rcv/Xmit 'events' per second per cylinder = .01 seconds. The .01ms is uC specific. A 12 Cyl at 12K would have 6 events per 360 degree revolution = 600 total 'events' per second per rev = 1.33 Million instructions 'between' events at 800MHz. Considering I had been dealing solely with 16MHz uC's .. that is a lifetime :)
Assuming a fixed display freq of 60Hz and the system providing 600Hz freq of "information" I see it as reading the 'latest' information in some cases and averaging in others. At 1K RPM I'm only getting 50Hz of info.
Take care,
And why I lean toward multiple instances. Need a function? Add an instance (or mod an existing one). Then mess with main as to when to display the display the data.
Better still, if you can use a rolling average for the each of the incoming data streams, you should get a display that is exactly what you have described with a silky smooth flicker free 60Hz and still be very accurate. Even at only 60Hz display updates, the gauges will *appear* to be functioning in real time to the average person.