Announcement

Collapse
No announcement yet.

Comport problems

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

  • Comport problems

    I'm a bit puzzled by strange behaviour of a simple test program I wrote for somebody.
    It receives data from a comport and processes that.

    I never had problems with serial ports, but this program sometimes 'mangles' the data or adds an extra character to it.
    This skeleton program shows the received hex values. (shown on 250mS timeout after last character received)

    Probably something simple I've overseen, but for now I'm stumped.
    If I use a terminal program like HTerm it works flawless, so connection and sent data is OK.
    Lower baudrate doesn't make it better either...

    Code:
    #COMPILE EXE
    #DIM ALL
    #INCLUDE "WIN32API.INC"
    
    Global hDlg, Baudrate, hCom, hTimer As Long, ComPort, sCom As String
    $DEFCOMPORT     = "COM3"
    %DEFBAUDRATE    = 115200
    %DEFRXBUFFSIZE  = 20000
    %PIXELSIZE      = 4
    %LBL1           = 1001
    
    ' ========================================================================================
    ' Main
    ' ========================================================================================
    FUNCTION PBMAIN
      local lCnt, lCnt2, lRet As Long
      Dialog New %HWND_Desktop, "Serial data test",,, 600,60, _
                 %DS_ModalFrame Or %WS_Caption Or %WS_Sysmenu To hDlg
      Control Add Label, hDlg, %LBL1, "",  25, 25, 550 , 14, %WS_BORDER
      Dialog Show Modal hDlg, Call MainDialogCB To lRet
    END FUNCTION
    
    ' ========================================================================================
    ' Callback function
    ' ========================================================================================
    Callback Function MainDialogCB()
      Local lCnt, lCnt2, lRet As Long, lsStr As String
      Static RxCnt As Long
      '---------------------------------------------------------------------------------------
      Select Case CbMsg
        Case %WM_InitDialog
          SetTimer hDlg, &hFEED, 250, Byval 0
          Dialog Get Text hDlg To lsStr
          If OpenComPort()Then
            lsStr = lsStr & " - Port: " & Comport & " , " & "Baudrate: " & Format$(Baudrate)
          Else
            lsStr = lsStr & " - Unable to open Comport: " & Comport
          End If  
          Dialog Set Text hdlg, lsStr
        Case %WM_TIMER
          lRet = Comm(#hCom, RxQue )
          If (lRet = RxCnt) Then
            If (lRet > 0) Then
              Comm Recv #hCom, lRet, sCom
              lsStr = "Received " + Format$(Len(sCom)) + " characters:"
              For lCnt = 1 To Len(sCom)
                lsStr = lsStr + " " + Hex$(Asc(sCom,lCnt),2)
              Next  
              Control Set Text hDlg, %LBL1, lsStr
              RxCnt = 0
            End If  
          Else
            RxCnt = lRet  
          End If  
        Case %WM_DESTROY
          KillTimer hDlg, &hFEED
          If hCom Then Close #hCom
      End Select  
    End Function
    
    ' ========================================================================================
    ' Open comport
    ' ========================================================================================
    Function OpenComPort() As Long
      Local lCnt As Long, lStr As String
      '---------------------------------------------------------------------------------------
      Baudrate = %DEFBAUDRATE  :  Comport  = $DEFCOMPORT
    
      If ParseCount(Command$," ") And Command$ <> "" Then
        For lCnt = 1 To ParseCount(Command$, " ")
          lStr = Ucase$(Parse$(Command$, " ", lCnt))
          If Instr(lStr, "PORT") Then Comport  = Trim$(Remain$(lStr,"="))
          If Instr(lStr, "BAUD") Then Baudrate = Val(Remain$(lStr,"="))
        Next  
      End If  
      hCom = Freefile
      Comm Open Comport As #hCom Chr=Ansi       : If Err Then Exit Function
      Comm Set #hCom, Baud=Baudrate             : If Err Then Exit Function
      Comm Set #hCom, RXBUFFER=%DEFRXBUFFSIZE   : If Err Then Exit Function
      Comm Set #hCom, Break=%False              : If Err Then Exit Function
      Comm Set #hCom, Stop=0                    : If Err Then Exit Function
      Comm Reset #hCom, Flow                    : If Err Then Exit Function
      Function = 1
    End Function
    Regards,
    Peter

  • #2
    Could the transmitter be sending UTF-8? An occasional character above 127 would become two characters of above 127 received as a normal (8 bit) text string.

    Cheers,
    Dale

    Comment


    • #3
      Originally posted by Dale Yarker View Post
      Could the transmitter be sending UTF-8? An occasional character above 127 would become two characters of above 127 received as a normal (8 bit) text string.

      Cheers,
      Good guess. Are the '"extra" Hex characters &HC2 and/or &HC3 ?

      Comment


      • #4
        It is often 0x7F...
        I'm still looking into it, because it doesn't happen always. After HTerm has run my program also runs flawlesly, but not always.
        (could it be HTerm sets some com port parameter that I have overseen in my program?)
        Regards,
        Peter

        Comment


        • #5
          Maybe the Byte size,
          I didn't see you setting it in you code above.
          Code:
          COMM SET #hComm, BYTE     = 8      ' 8 bits

          Comment


          • #6
            0x7F is DELETE.

            Also has bit 7 as "0", so not UTF-8 problems.

            My USB serial port didn't "follow" me out of Afghanistan so I can't test settings. Guess I'm done here.

            Cheers,
            Dale

            Comment


            • #7
              Your test app may need to use the SetCommTimeOuts API to configure the port?
              Rgds, Dave

              Comment


              • #8
                AT 115200 baud , each byte takes approx 86 uS. So nearly 2900 bytes arrive every 250mS, depending on volume of data sent by sender. Because you are writing into control inside Timer Handler, Timer routine may not be executing every 250mS, so there may be overrun errors. Take out all screen handling functions out of interrupt handlers. It should work with that.

                Comment


                • #9
                  Deleted.

                  Comment


                  • #10
                    from post 1
                    Lower baudrate doesn't make it better either...
                    from post 6
                    Guess I'm done here.
                    On the other hand ...

                    Cheers,
                    Dale

                    Comment


                    • #11
                      What's on the other end of the line?
                      Can you configure it?

                      Comment


                      • #12
                        I'm using 2 computers.
                        The sender on PC1 uses HTerm to send a string of 9000 bytes of "U" character (pattern 01010101)
                        PB program on PC2 receives the string, but with strange characters added (and more as 9000 bytes).

                        If I use HTerm on PC2 it always functions correct: it receives 9000 x "U" always.
                        If I then end HTerm on PC2 and start the PB program again, it also works flawlessly (?)
                        Apparently the HTerm program does some settings to the serial port that my PB program doesn't...

                        I'm using two genuine legacy serial ports (no USB converters)
                        Regards,
                        Peter

                        Comment


                        • #13
                          Found it!

                          It was the Comm Set #hCom, byte=8 as Rod mentioned earlier...
                          (Still I can't understand why most characters are received OK without setting byte=8, and a few are not?...)
                          Regards,
                          Peter

                          Comment


                          • #14
                            Originally posted by Peter Lameijn View Post
                            Found it!

                            It was the Comm Set #hCom, byte=8 as Rod mentioned earlier...
                            (Still I can't understand why most characters are received OK without setting byte=8, and a few are not?...)
                            Hard to say without more info on sending side settings and what you are being sent, but if you send 8bits and receive at 7bits most ASCII characters (the first 127) will be transmitted OK, the other half will drop the 8th bit.

                            Comment


                            • #15
                              As said I send a string of 9000 x "U" (01010101 pattern), so all characters are the same...
                              Regards,
                              Peter

                              Comment


                              • #16
                                and good catch in post 5!
                                Dale

                                Comment

                                Working...
                                X