No announcement yet.

Serial Communication uLCD-32PT

  • Filter
  • Time
  • Show
Clear All
new posts

  • Serial Communication uLCD-32PT

    Few basic questions on the serial RS 232 port:
    What is the best way to receive a few integer values through serial RS 232 port ? How do i receive/deserialize the bytes if i send an integer array from a host microcontroller to the display module?

    Also, is there an interrupt or a flag being set when RS 232 receives a byte or should i keep polling for bytes? Is there a simpler way to deserialize the buffer values from Com_Init buffer ?? Could someone explain the concept of serial communication buffering on the background using Com_Init routine.


  • #2

    What are you trying to send? Do you have control of what you send?

    I always send with a header character and then check if there is the correct com_count for the data I'm sending

    Can post some code if needed but get back with answers first as there may be a better way

    Have you looked at the samples

    Don't forget if you send a '1' you need to subtract 48 to make it a 1


    • #3

      Thanks for the response.
      I'm trying to send 4 16-bit integer values in a sec timer. Ill have control over the input data. What is the best way to send an integer say 1022 ?
      Since every variable is of 16-bit length in picaso, if i need to send 4 integer values, the com_count with a header character would be 9 ?
      I sent 1 and printed the number in decimal, so i got 1.

      I checked a few samples on buffered rx about the sync, com_init and com_count.
      While using the background buffering service, is it not necessary to use the serin() function everytime to receive a byte ?
      where does the serin() function gets the bytes from in the above example ? - from the buffer defined as combuf ?
      Is there a better way to split those 9 bytes that i send through the buffer defined in com_init ?
      Any code examples would be helpful.



      • #4

        If you are using the bufferred coms service serin() reads from the buffer if there's something in it, otherwise it returns the comms status 'as usual'.

        So if you were sending 3 byte commands you could process serial commands in the main touch loop with something like this

        if (com_Count() >= 3)
            cmd := serin() ;
            if (cmd == 'I')
                i := serin() << 8 | serin() ; // depending on endianness of sent integer
                // process new i value
                serout(ACK) ; // valid value, send ACK
            else if (cmd == 'J')
                j := serin() << 8 | serin() ;
                // process new 'J' value
                serout(ACK) ; // valid value, send ACK
                serout(NAK) ; // invalid value, send NAK
        The purpose of sending ACKs and NAKs is so the main controller can see if there has, somehow, been an error in communications and needs to take some action to get the two back in sync.


        • #5

          I sent an integer from the host controller and when i read the buffer combuf[0], i was able to get the exact 16 bit integer that i sent.

          What i do not understand is, i am sending 4 integers from the host controller but for some reason, the display serial module indicates the received byte count as 28. Still i was able to retrieve the sent integer values in combuf[0] to combuf[3]. Any reason why the byte count (buffsize) shows that way ?


          • #6

            Must be because that's what you are sending

            Your controlling computer may be trying to be too smart for it's own good.

            Print everything received as hex and then try to equate it to what you thought you sent


            • #7

              Ok from looking at the provided code, it looks like there is no interrupt generated when the UART1 receives incoming bytes. Is that correct?


              • #8

                No, the interrupt works behing the scenes to buffer the received data.

                You just check com_Count()


                • #9

                  Ok thanks.

                  Just one more thing: Can the buffer be bigger than 128 words (256 bytes) ?


                  • #10

                    Sure can.