ON TIMER - EVENT ON/OFF

[Kerry Holmberg]

I was wondering if anyone knew of any issues of using ON TIMER and
$EVENT OFF / $EVENT ON.

I have a routine that sends a string out a serial port (COM2) that
must not be interrupted by an ON TIMER that is running at .25 seconds.

The routine that sends the string is bracketed by the $EVENT OFF and
$EVENT ON as ahown below.

---------------

$EVENT OFF

SUB SENDSTRING(S$)
'code to send S$ to COM2
PRINT #2, S$
END SUB

$EVENT ON

-----------------

The sub sendstring() is interrupted (branches to the ON TIMER GOSUB
routine) midway through sending the string out the comport. (causing
big problems)

Prior to calling SENDSTRING() other procedures may have also disabled
event trapping by using the same $EVENT OFF / $EVENT ON.
After these routines turn event trapping back on a couple of small
procedures are called before calling SENDSTRING() when it gets
interrupted.

Is there some latency in the code between where event checking is
enabled and when it gets in to the routine where it is again disabled
that might cause this interruption?

I would be glad to post the exact code that causes the problem,
however it is rather large and comples and this problem has shown up
rather infrequently, and only when communicating with other devices
over the serial port. For this reason I do not think it would help.

The program is running in a DOS window on W98se.

Any thoughts or suggestions would be much appreciated, thanks in
advance.



------------------

[Mel Bishop]

Assuming you are using ON TIMER(x), you might try using
$TIMER OFF/ON instead of $EVENT OFF/ON.

In any event, when the ON TIMER event kicks in and sends your
program to the specified routine, an implicent OFF occurs and
then switches back to ON when the routine is finished. This is
to prevent recursion and filling up your stack.

Hope this helps. Cheers.



------------------

[Lance Edmonds]

Better make that TIMER ON|OFF|STOP (not $TIMER).

$EVENT ON|OFF is a compiler directive, TIMER ON|OFF is a run-time directive.

When $EVENT OFF is used, the compiler does not include event checking code in that portion of the executable (until the next $EVENT ON).

However, a timer event is another matter altogether, and this is controled by an interrupt handler, completely separate from the portion of code your are concerned with.

So, as Mel rightly points out, you should disable the timer event trapping for the duration of the critical code. However, it would not do any harm to retain the $EVENT OFF|ON wrapper for that small fragment too.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Kerry Holmberg]

Lance,

Below is a small routine that seems to show that no ON TIMER
gosubs occur when $EVENT OFF is used.

If you try it with the $EVENT OFF commented out and then
included you will see what I mean.

Anyway I will be trying the TIMER STOP | OFF as you suggested
today.

---------------------

CLS
ON TIMER(.25) GOSUB TIMEINT
TIMER ON


'$EVENT OFF
DO
PRINT "LOOPING ";TIMER
DELAY .1
LOOP UNTIL INSTAT
DM$=INKEY$
$EVENT ON

PRINT "LOOP ENDED"

END

TIMEINT:
PRINT "-------TIMED INTERRUPT-------"TIMER
RETURN




------------------

[Lance Edmonds]

what exactly is the problem you are experiencing? you mentioned a problem, which we assumed to be that the timer routine was interrupting your critical comm code.

have you considered the effects that windows may be having? have you run this code in plain dos mode and does the same problem occur?

when i was writing the i/o section of pbfax, i found that windows frequently interfered with the flow of xon/xoff control characters, which can cause all sorts of havoc as you can well imagine!

the best solution i found was to wrap the time-critical code inside a dos "critical section". this is done with an interrupt call (one for on, another for off) to keep windows "at bay" while your time-critical code runs. this technique works on win3.x/95/98. i've not tested it on nt, win2k or me.

see http://www.powerbasic.com/support/pb...read.php?t=138

------------------
lance
powerbasic support
mailto:[email protected][email protected]</a>

[Kerry Holmberg]

Lance,

Yes the problem is an ON TIMER interrupting a critical area of code.

I was attempting to use the $EVENT OFF | ON to prevent this from
happening.

The small program I included in the previous message was as simple a
way I could think of to demonstrate it.

In this simple code the DO|LOOP is the critical section.
With the $EVENT OFF not commented out the loop is never interrupted
by the ON TIMER. Where as in the actual code that I am having the
problem with, it would be infrequently interrupted. (but no where
near as often as with not using the $EVENT OFF at all)

If I understood your previous reply correctly I thought the the
$EVENT OFF would have no effect on blocking the ON TIMER, as you
had stated that ON TIMER generated an interrupt.

In any case I tried the TIMER OFF | ON around the critical code and
this looks like it is working.

It still just gets me wondering why that $EVENT OFF works the way
I thought it would 99% of the time not 100%.

Thanks for your reply.



------------------

[Lance Edmonds]

I'll recheck with R&D on whether I'm wrong about the effects of $EVENT OFF on TIMER interruptions... I'll let you know what they say.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Kerry Holmberg]

Lance,

Hear anything from R&D?
Also is there a bit or internal variable that you can test to
see if the timer is currently ON | STOPped | OFF.


------------------

[Tom Hanlin]

I'm inclined to think that $EVENT OFF will shut off ON TIMER processing
as well as any other events, but we're still waiting to hear back from
R&D on that to be sure.

It occurs to me to wonder whether something else is going on here. Your
$EVENT OFF / $EVENT ON bracketing is operating on the assumption that
the PRINT #2, S$ statement won't return until the string is sent. It
may well be that the string is just being placed in an output buffer,
in which case the PRINT will generally return before the string is
actually transmitted... just to name one possibility!

------------------
Tom Hanlin
PowerBASIC Staff

[Ian Cairns]

Sorry to butt in here, but your original code bracketing
$EVENT ON / $EVENT OFF is outside the SUB and should be
inside of it. I also assume that unshown code is doing the
OPEN call inside the SUB. I don't know if adding FLUSH #2
would work or not, but you might try. I don't use these
techniques myself.

SUB SENDSTRING(S$)
  OPEN #2, .....
'code to send S$ to COM2
  $EVENT OFF
  PRINT #2, S$
  FLUSH #2
  $EVENT ON
'...
  CLOSE #2
END SUB

Regards,

------------------
[email protected]

[Lance Edmonds]

Ok folks, R&D have come back with some information.

$EVENT OFF disables code generation that checks the "event flag". This flag is also set by TIMER messages, so the answer is yes, it definitely disables ON TIMER calls from code located between $EVENT OFF|$EVENT ON metastatements.

Also, writing data to a comm port is a "blocking" operation. That is, the PRINT# statement does not return until either the data is completely written or a run-time error occurs while writing the data.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>