USART Problem Receiving Bytes


Closed Thread
Results 1 to 5 of 5
  1. #1

    Default USART Problem Receiving Bytes

    Code:
    main:
        if RCIF = 1 then                            ' If RCIF=1 there's a new character in RCREG
            BytesIn[ByteCnt] = RCREG                ' Yes. Then store it in array
            if BytesIn[ByteCnt] = eom then OutMsg
            ByteCnt = ByteCnt + 1                   ' Increment array index pointer 
        endif
        goto Main
    This code works great but how can I send the value 23? If I try it assumes each character is a byte when they are not.

  2. #2
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

    not sure of me but what about
    Code:
            HSERIN [str BytesIn\ByteInArraySize\eom]
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  3. #3


    Did you find this post helpful? Yes | No

    Default

    I think part of my problem lies in the fact that I'm using the Serial Communicator in MCSP. I think anything you enter in the transmit window is by default send as ascii. However if this in in fact the case then I have no way to send 23 since the ascii representation of 23 is "end of transmission block".

  4. #4
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

    This may help

    Quote Originally Posted by Serial Communicator MCS Help file
    Parse Control Characters

    When enabled, the parse control characters option enables you to send control characters in your message, using either a decimal or hexadecimal notation. For example, if you want to send hello world followed by a carriage return and line feed character, you would use hello world#13#10 for decimal, or hello world$D$A for hex. Only numbers in the range 0 to 255 will be converted. For example, sending the message letter #9712345 will be interpreted as letter a12345.

    If the sequence of characters does not form a legal number, the sequence is interpreted as normal characters. For example, hello world#here I am. If you don't want characters to be interpreted as a control sequence, but rather send it as normal characters, then all you need to do is use the tilda symbol (~). For example, letter ~#9712345 would be sent as letter #9712345.
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  5. #5


    Did you find this post helpful? Yes | No

    Default

    I was just going to post that. Thanks.

Similar Threads

  1. Usart problem with 18F4550
    By maus in forum Serial
    Replies: 7
    Last Post: - 3rd November 2009, 03:54
  2. byte Tx w/ USART 16f876a problem
    By GargamelDigi in forum mel PIC BASIC
    Replies: 2
    Last Post: - 15th July 2008, 05:50
  3. USART Problem , but don't know where, in pc? or in PIC?
    By precision in forum mel PIC BASIC Pro
    Replies: 0
    Last Post: - 15th July 2007, 08:12
  4. Receiving Packet Array In Usart
    By crhomberg in forum mel PIC BASIC Pro
    Replies: 29
    Last Post: - 24th April 2007, 20:41
  5. problem with USART
    By leemin in forum Serial
    Replies: 4
    Last Post: - 11th December 2006, 17:56

Members who have read this thread : 1

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts