Announcement

Collapse
No announcement yet.

ON TIMER - EVENT ON/OFF

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Ian Cairns
    replied
    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.
    Code:
    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]

    Leave a comment:


  • Tom Hanlin
    replied
    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

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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.


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

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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.



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

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Guest's Avatar
    Guest replied

    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




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

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Mel Bishop
    replied
    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.



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

    Leave a comment:


  • Guest's Avatar
    Guest started a topic ON TIMER - EVENT ON/OFF

    ON TIMER - EVENT ON/OFF



    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.



    ------------------
Working...
X