Announcement

Collapse
No announcement yet.

Reading binary data from serial port

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

  • Reading binary data from serial port

    Using VB I can read all the printable characters, but
    apparently the MSComm tool is useless for binary data. I have
    an application that needs to read 10 to 20 bytes of data and
    display them as hex codes. Was hoping PB/DLL could do this but
    so far no luck. The help file has this two line example:

    Qty& = COMM(#hComm, RXQUE)
    COMM RECV #hComm, Qty&, a$

    In my programs Qty always gets only zero bytes. But I don't
    understand RXQUE... what is it? I tried to declare it as an
    integer etc. but no help. Also tried getting a byte or an
    integer in lieu of the a$ string variable. The incoming data
    for this app is at 19200 but repeated at a 10Hz rate so I could
    poll a function continuously, getting one byte each time.

    Any help is appreciated.

    Russ


    ------------------
    Russ

  • #2
    RXQUE is a keyword, not a variable name, and you are using it correctly to query the receive data buffer size, then use COMM RECV to get the actual bytes in the queue.

    The question in my mind is how have you set up the serial communication parameters? Possibly you are witnessing data loss because of a hand-shaking or missing comm parameter issue, but without seeing more of your code it is not possible to give you a precise answer.


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

    Comment


    • #3
      Oh, yes, of course I should have shown some code.

      #COMPILE DLL
      #INCLUDE "WIN32API.INC"
      GLOBAL hComm AS LONG

      SUB PORTSETTINGS EXPORT
      hcomm = FREEFILE
      COMM OPEN "COM1" AS #hComm
      COMM SET #hComm, BAUD = 19200
      COMM SET #hComm, BYTE = 8
      COMM SET #hComm, PARITY = %False
      COMM SET #hComm, STOP = 0 'One stop bit
      COMM SET #hComm, TXBUFFER = 2048
      COMM SET #hComm, RXBUFFER = 4096
      COMM SET #hComm, XINPFLOW = 1
      COMM SET #hComm, XOUTFLOW = 1
      COMM CLOSE #hComm
      END SUB

      FUNCTION RCVCHAR () EXPORT AS BYTE
      DIM x AS BYTE
      DIM y AS STRING
      hComm = FREEFILE
      COMM OPEN "COM1" AS #hComm
      'Original code had a while loop around the next statement
      Qty& = COMM(#hComm,RXQUE)

      COMM RECV #hComm,Qty&,x
      FUNCTION = x
      COMM CLOSE #hComm
      END FUNCTION

      I've tried to export it as a byte or integer etc. Found out
      Qty& is always zero by exporting it to VB. Should have known
      it was zero cause the computer locked up and had to exit VB by
      using the three finger salute (cntrl-alt-delete).

      Russ

      ------------------
      Russ

      Comment


      • #4
        Is that the exact code you are using?

        Four points to consider:
        • As it stands, you have two exported Sub/Functions. The PortSettings SUB opens the port, sets the parameters, then closes it... settings are lost when the port is closed.
        • The main function never configures up any comm settings for it's own session. Probably you'll want to take the parameter section from the SUB and paste it into the 'main' function.
        • You will probably also want to set up a loop to read the data stream, since the COMM OPEN statement will likely flush the receive buffer.
        • COMM RECV expects a string variable, not a byte variable.


        COMM RECV #hComm, qty&, A$
        FUNCTION = ASC(a$) ' return the 1st byte to the calling code

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

        Comment


        • #5
          Russ,

          I use these PB functions all day long & they work just fine. One
          of the things you must do is not only test for bytes in the
          receive buffer, but if there arn't any, don't read the port. It
          helps if you know how many you are expecting, but that's not always
          the case. Lets say you do:

          Code:
          DO
               QTY& = COMM(#hComm, RXQUE)
               IF QTY& = 0 THEN ITERATE
               COMM RECV #hComm, Qty, a$
               rcv$ = rcv$ + a$
               SLEEP 10  (or something that works for you)
          LOOP UNTIL LEN(rcv$) >= ExpectedLen
          If you don't know the expected length then things can get messy.
          If you are sending a command and waiting for a response then a
          time out using GetTickCount works well. If you are simply polling
          the port for bytes to come in then you should set up thread and pass
          the results to a global buffer string or string array to pass it
          back to the rest of your program. Without knowing more about what
          you're doing, it's a bit hard to tell what the best approach is.

          Best of luck,
          Russ Srole

          ------------------
          "There are two novels that can change a bookish fourteen-year old's life: The Lord of the Rings and Atlas Shrugged. One is a childish fantasy that often engenders a lifelong obsession with its unbelievable heroes, leading to an emotionally stunted, socially crippled adulthood, unable to deal with the real world. The other, of course, involves orcs." - John Rogers

          Comment


          • #6
            I use the Comm port funtions with no handshaking for many
            applications, and as yet have had no problems with anything.
            The recieved data is best handled with its own thread.
            If you are using binary, do'nt forget to set:

            COMM SET #hComm, NULL = %FALSE



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

            Comment


            • #7
              Russ, FYI, the mscomm control has an inputmode property.

              Comment


              • #8
                Thank you Lance and Russ for your replies. I was able to get
                a small program working good enough for a demo tomorrow! Gee
                the customer will see a Windows program in lieu of a clunky DOS
                program.

                Also thanks to John and Ron for their help.


                ------------------
                Russ

                Comment

                Working...
                X