Announcement

Collapse
No announcement yet.

Serial port break detection / ignoring

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

  • Jim Martin
    replied
    Well, I knew I was doing something wrong.

    Thanks for the help.

    Jim

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

    Leave a comment:


  • Mel Bishop
    replied
    Originally posted by Paul D. Elliott:
    ...may be wrong...
    You're not wrong.



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

    Leave a comment:


  • Paul D. Elliott
    replied
    Just a guess but move the On Error line above the Input$ line.
    And it probably only needs to be done once, not within a loop.
    unless you're resetting with an On Error GoTo 0. but this last
    may be wrong as it's been a while since I've done error handling
    in DOS.


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

    Leave a comment:


  • Jim Martin
    replied
    Okay, what am I doing wrong?

    The original problem was that a break would cause an Error 57 at the following line:

    [CODE]

    XCommand$ = Input$(1,#99)

    [CODE]

    So I modified it as follows:

    [CODE]

    XCommand$ = Input$(1,#99)

    On Error Resume Next

    If (Err <> 57) then

    NewCommand$ = NewCommand$ + XCommand$

    else

    incr BreakCount%
    locate 1,1
    print BreakCount%

    End if

    [CODE]

    BreakCount% is declared as SHARED at the beginning of the program.

    As I understand it, a valid character should be handled correctly, while an error should update the error count at the top left of the page. Instead, I sometimes get a program failure with Error 57 ans the message.

    Or am I missing something?

    Jim



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

    Leave a comment:


  • Aldo Cavini
    replied
    Jim,

    I never used BREAKs on a COMM under BASIC, but I do know what it does mean. A break results as a start bit, the data bits, may be the parity bit, and an INVALID stop bit. This stop bit results in an error 57, and is related to the "break" character. You should setup an error trap and receive single chars one by one. If you get that errorr 57 and the char is a NUL, it was a break.

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

    Leave a comment:


  • Jim Martin
    replied
    Mel -

    As an example: from http://wandel.ca/homepage/dswitch/switchdocs.html

    "An RS-232 "break" signal is used to obtain the processor's attention. This signal consists of the RS-232 line being continually high (+12V, logical zero) for a period exceeding a normal character time."

    In other words, you get a start bit, 8 data bits, and then no stop bit. That's why the serial port flags it as bad formatting.

    The command/response protocol is a custom structure, taking advantage of the fact that the server only asks me for data, and all I do is respond to such requests. Requests are simple character strings with a delimiter. Responses are similar.

    I guess an error trap is the way to go.

    Jim

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

    Leave a comment:


  • Mel Bishop
    replied
    Originally posted by Jim Martin:
    ...(logic 0 for longer than a word)...
    I'm not sure what this means. Can you expand on it?

    What kind of flow control are you using (Xoff/Xon)?

    If nothing else works, try using ON ERROR to trap it.



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

    Leave a comment:


  • Jim Martin
    started a topic Serial port break detection / ignoring

    Serial port break detection / ignoring

    Howdy, all -

    I'm using a serial port to communicate telemetry data to a server, and the server sends a "break" (logic 0 for longer than a word) at various intervals. Of course, PB detects this as a formatting error and terminates the program with an error 57.

    I've looked through the manual and can't find mention of a way to disable the function.

    Does anyone have any suggestion?

    Thanks,

    Jim

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