• AVR Freaks

Hot!UART RTS/CTS PIC18F27k42

Author
aleksey1112
New Member
  • Total Posts : 14
  • Reward points : 0
  • Joined: 2019/01/20 07:27:49
  • Location: 0
  • Status: offline
2019/06/24 10:10:30 (permalink)
0

UART RTS/CTS PIC18F27k42

Hello, I ask for help. I am writing a program in which it is necessary to receive data on UART, the data is sent in a large stream and there is a need for stopping the transmission. I looked through the code obtained from the MCC configurator did not understand how to control the RTS and CTS legs.
#1

14 Replies Related Threads

    mbrowning
    USNA79
    • Total Posts : 1535
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: offline
    Re: UART RTS/CTS PIC18F27k42 2019/06/24 13:26:21 (permalink)
    +1 (1)
    Sorry to repeat what you might already know but you didn't give many details. I have used K42 UART many times but I never need flow control and never use MCC except for playing around, so take the following as only academic and only partly tested.
     
    In the MCC register tab of the UART, set U1CON2 FLO to Hardware flow control.
    Now as well as TX and RX, you need to select pins for CTS and RTS. Don't select a pin for TXDE unless you need transceiver control.
    The PIC UART will set RTS low when it's input FIFO is empty (see datasheet section 31.12).
    The PIC UART TX will stop transmitting when CTS input is high.
    The connections depend on what you are connecting to. Generally (DTE to DTE) connect RTS to CTS. If its a modem, RTS to RTS, CTS to CTS.
     

    Go Navy! Beat Army!
    #2
    ric
    Super Member
    • Total Posts : 23859
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: UART RTS/CTS PIC18F27k42 2019/06/24 13:30:50 (permalink)
    +1 (1)
    Personally, I'd ditch the hardware flow control and use one of the file transfer protocols that have been around for decades.
    (XMODEM is the granddaddy of them all, but I'm sure there's better ones around now)
    That gives you software flow control AND error checking.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #3
    aleksey1112
    New Member
    • Total Posts : 14
    • Reward points : 0
    • Joined: 2019/01/20 07:27:49
    • Location: 0
    • Status: offline
    Re: UART RTS/CTS PIC18F27k42 2019/06/25 10:39:49 (permalink)
    0
    That is, in manual mode, I myself can at any time change the state of the RTS and CTS legs.
    #4
    NorthGuy
    Super Member
    • Total Posts : 5672
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: offline
    Re: UART RTS/CTS PIC18F27k42 2019/06/25 10:53:58 (permalink)
    +1 (1)
    aleksey1112
    That is, in manual mode, I myself can at any time change the state of the RTS and CTS legs.



    You would normally control the state of RTS to pause the sender when your buffers are almost full. But you would not control CTS - CTS would be controlled by the receiver to let you know when you're sending too fast.
     
    In practical terms, decreasing baud rate to manageable levels works just as well as RTS/CTS and is much easier to implement.
    #5
    aleksey1112
    New Member
    • Total Posts : 14
    • Reward points : 0
    • Joined: 2019/01/20 07:27:49
    • Location: 0
    • Status: offline
    Re: UART RTS/CTS PIC18F27k42 2019/06/25 11:44:43 (permalink)
    0
    In general, the task is this, I receive data on wifi (esp8266), from the JINX program (it controls the ws2812 matrix), and so there is a constant data flow, which causes a frame shift. So it turns out flow control is the easiest option.
    #6
    NorthGuy
    Super Member
    • Total Posts : 5672
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: offline
    Re: UART RTS/CTS PIC18F27k42 2019/06/25 16:40:57 (permalink)
    +1 (1)
    aleksey1112
    In general, the task is this, I receive data on wifi (esp8266), from the JINX program (it controls the ws2812 matrix), and so there is a constant data flow, which causes a frame shift. So it turns out flow control is the easiest option.



    Flow control won't help with the constant flow. Flow control is useful when you have periods of higher activity and want to offload the traffic until the time when activity is low.
     
    If the flow is constant then the the flow is either slower than you can handle (and thus there's no need for flow control), or it is faster than you can handle (and thus the flow control will not help because you lose some of the traffic anyway).
    #7
    ric
    Super Member
    • Total Posts : 23859
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: UART RTS/CTS PIC18F27k42 2019/06/25 17:02:12 (permalink)
    +1 (1)
    I'm going to take a guess here, that the OP is trying to make a bootloader, and wants to stop receiving while programming each block to FLASH.
    The viability of this depends upon the capability of the sender (ESP8266) to wait for extended periods when flow is halted, without losing any data.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #8
    NorthGuy
    Super Member
    • Total Posts : 5672
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: offline
    Re: UART RTS/CTS PIC18F27k42 2019/06/25 19:48:51 (permalink)
    +1 (1)
    ric
    I'm going to take a guess here, that the OP is trying to make a bootloader, and wants to stop receiving while programming each block to FLASH.
    The viability of this depends upon the capability of the sender (ESP8266) to wait for extended periods when flow is halted, without losing any data.



    In such case, I would use SPI (with PIC being a master). This would let the PIC dictate the pace as needed.
     
    Another idea is to insert gaps between packets sent by ESP8266, so that the packets would arrive exactly when needed. Bootloader writes are very predictable.
     
    #9
    Jerry Messina
    Super Member
    • Total Posts : 437
    • Reward points : 0
    • Joined: 2003/11/07 12:35:12
    • Status: offline
    Re: UART RTS/CTS PIC18F27k42 2019/06/26 03:04:48 (permalink)
    0
    ...or it is faster than you can handle (and thus the flow control will not help because you lose some of the traffic anyway)
    I guess I'm not following what you're saying there. Isn't that the whole point of hardware RTS/CTS handshaking? How do you lose traffic if the sender waits for its CTS input?
     
    #10
    ric
    Super Member
    • Total Posts : 23859
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: UART RTS/CTS PIC18F27k42 2019/06/26 03:07:09 (permalink)
    +1 (1)
    Jerry Messina
    ...
    Isn't that the whole point of hardware RTS/CTS handshaking? How do you lose traffic if the sender waits for its CTS input?

    Which is the point I was making in post#8.
    Where is the ESP8266 getting the data from?
    If it's coming from somewhere else, can the ESP8266 buffer it up when the PIC drops CTS?

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #11
    aleksey1112
    New Member
    • Total Posts : 14
    • Reward points : 0
    • Joined: 2019/01/20 07:27:49
    • Location: 0
    • Status: offline
    Re: UART RTS/CTS PIC18F27k42 2019/06/26 06:24:41 (permalink)
    0
    SPI seems to me in this case is not quite the right decision, as it is not quite understood the work of esp8266 and while I control it with the help of AT commands. The JINX Soma program (http://www.live-leds.de/) must support the suspension of data transfer. In general, while waiting for the module esp8266 with all the legs uart.
    #12
    NorthGuy
    Super Member
    • Total Posts : 5672
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: offline
    Re: UART RTS/CTS PIC18F27k42 2019/06/26 10:42:46 (permalink)
    +1 (1)
    Jerry Messina
    ...or it is faster than you can handle (and thus the flow control will not help because you lose some of the traffic anyway)
    I guess I'm not following what you're saying there. Isn't that the whole point of hardware RTS/CTS handshaking? How do you lose traffic if the sender waits for its CTS input?



    If it's a constant flow, say at 9600 (roughly 1k characters/sec), and you can process only 500 characters/sec, you will lose some traffic no matter what you do.
     
    If you pause traffic with RTS, it won't be a constant flow any more. You will still process only 500 characters/sec, the same as if you would switch to 4800 baud without RTS.
    #13
    NKurzman
    A Guy on the Net
    • Total Posts : 17846
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: UART RTS/CTS PIC18F27k42 2019/06/26 12:16:54 (permalink)
    +1 (1)
    ric
     
    Which is the point I was making in post#8.
    Where is the ESP8266 getting the data from?
    If it's coming from somewhere else, can the ESP8266 buffer it up when the PIC drops CTS?



    I think (but do not know) the the TCP/IP would make this work since the ESP8266 would not accept the Packet, so the Sender could not send the Next one.  UDP would just loose the Packets.
    #14
    Jerry Messina
    Super Member
    • Total Posts : 437
    • Reward points : 0
    • Joined: 2003/11/07 12:35:12
    • Status: offline
    Re: UART RTS/CTS PIC18F27k42 2019/06/26 12:36:55 (permalink)
    0
    NorthGuy
    If it's a constant flow, say at 9600 (roughly 1k characters/sec), and you can process only 500 characters/sec, you will lose some traffic no matter what you do.

    I see what you're saying. For some reason the "constant flow" part didn't sink in.
     
    I reread your post #7 and it makes complete sense. Thanks.
    #15
    Jump to:
    © 2019 APG vNext Commercial Version 4.5