FB II Compiler

PG PRO

Debugging

Memory

System

Mathematics

Resources

Disk I/O

Windows

Controls

Menus

Mouse

Keyboard

Text

Fonts

Drawing

Sound

Clipboard

Printing

Communication

ASM

Made with FB

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