PG PRO
Change PG timing
I've noticed from reading through the PG Pro manual that _OtherNullEvent gets passed every tickcount or 1/60 of a second. It's setup in FN pGinitRuntime. If I understand the manual correctly 1/60 of a second is the smallest unit I can use for this.
I have a function that needs to be called repeatedly a lot quicker than this.
My question would be is there a way I can force PG Pro call my function quicker, say at least every 300 / 400 us or can anyone explain to me how I would go about calling my function at an Interrput Level if this would make it be called quicker then every 1/60 second.
Sean
This answer is not PG:Pro specific... I haven't used PG yet so I'm not sure where in a PG program to insert this, but it works in "vanilla" FB.
In your event loop, you'll have something that looks like;
DO
HANDLEEVENTS
UNTIL gTheEndOfTime%
Change that to read:
DO
HANDLEEVENTS
FN myFnToCallAsFastAsPossible
UNTIL gTheEndOfTime%
This will be machine-specific as to how _fast_ your routine gets called, but it'll be as fast as it can, as long as there aren't any events. Every _OtherNullEvent will zip out to your event handler and back, and during that time you _won't_ call the function. The opposite of what you've got now.
Bill
What about calling your function several times during each null event.
STAZ ~)~
I use PG and the _otherNullEvent case to access a serial port device to monitor sensors and do so faster than the 1/60th of second limit in PG. But I did not change PG's timing.
I execute quite a bit of code on each null event. Nothing says that you can only do one thing per null event. In your case, you could do 40 tasks each taking 400 <mu>sec and still be done before the next 1/60th of a second.
The trick is not to try to do too much. I check to see what kind of processor the users' Mac has, and alter the amount of tasks that are done each null event so that I don't slow down response time. PG handles all the user activity - windows (opening, closing, moving), buttons, menu's etc. I want my program to be responsive to those types of user requests, so I keep my null event tasks shorter than 1/60th of a second. But why not use all the time you have? If the user is doing nothing, then you get lots of null events, and your code executes continuously.
Keith Ronnholm