Announcement

Collapse
No announcement yet.

Serial port break detection / ignoring

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

  • 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

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

  • #2
    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.



    ------------------
    There are no atheists in a fox hole or the morning of a math test.
    If my flag offends you, I'll help you pack.

    Comment


    • #3
      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

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

      Comment


      • #4
        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.

        ------------------
        Rgds, Aldo

        Comment


        • #5
          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



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

          Comment


          • #6
            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.


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

            Comment


            • #7
              Originally posted by Paul D. Elliott:
              ...may be wrong...
              You're not wrong.



              ------------------
              There are no atheists in a fox hole or the morning of a math test.
              If my flag offends you, I'll help you pack.

              Comment


              • #8
                Well, I knew I was doing something wrong.

                Thanks for the help.

                Jim

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

                Comment

                Working...
                X