Making my own UART flow control for PIC18F2480 - Page 1
Forum section: electronics / projects

author: aiq25
author_rank: Regular Contributor
timestamp: March 21, 2015, 12:25:06 am
content: Hi. I'm working on a college project where I'm sending data from a PIC18F2480 using UART. Right now I just have one way communication, so the PIC is only outputting data. I'm using a CP2102 module I got off eBay to see the output data. Using hyper terminal programs I can see the data and everything looks right...The problem is I need to have my own monitor software in LabVIEW. I can't figure out how to just create a monitor program in LV. I think I need some kind of flow control. I don't think my PIC ones with a hardware solution, so I'm looking to implement one. I have lots of free I/O pins. Is it as easy as just using one for RTS and another for CTS ( these are the pins I see on my CP2102 module) and using the micro I/O pins to read/write to them? Or am I missing something? Also, what do I need to do for flow control? I'm new to flow control, so I'm a little confused. Any help would be greatly appreciated! Thank You.

author: dannyf
author_rank: Super Contributor
timestamp: March 21, 2015, 12:49:31 am
content: QuoteDon't "think" you need it. Make sure that you do or you don't. There is no point in spending all the time implementing flow control and only to find out later that you don't need it.Do more homework upfront will save you a lot later on.

author: SL4P
author_rank: Super Contributor
timestamp: March 21, 2015, 06:56:36 am
content: Agree... what suggests that you need flow-control?Does your peripheral device implement / support floor con?what type of buffering are you using?I assume your solution is dropping characters? or are they simply jibberish?Bit rate, framing, stop-bits?Understand the problembeforeyou try to solve it!

author: aiq25
author_rank: Regular Contributor
timestamp: March 21, 2015, 07:31:42 pm
content: I guess I'm still trying to figure out if I need flow control.So the PIC is sending out 4 bytes and a 0xA, '\n' via UART. There is actually two of these messages that are sent one after another. On the PC I'm showing this using a LabVIEW program (using their VISA libraries, since I'm not familiar with C++ programming I decided to use LV). I was having issues in LV of showing the data but now I have something working and I'm able to display the 10 bytes of data on the screen.That's all I really need to do but I'm worried sometimes I might have a character or some type of communication error and LV will throw an error, that's why I wanted to implement a flow-control. But thinking about it I don't think I really need to do that. If LV does throw an error I will just show the error and move on.... Attached is my LV code.

author: SL4P
author_rank: Super Contributor
timestamp: March 21, 2015, 08:12:37 pm
content: having not used LV, my first thoughts are : that the 'receiver' is not fast enough to handle the incoming data stream, whichmaynot be solved with FC if there is no RX buffering....ORthe sender is not respecting the listener's processing overhead.(With FC! The sender will takeat leastone character period to stop sending the next one!)The latter may be helped by slowing down the transmission slightly... e.g put a tiny delay between each character - and possibly after the line terminator character (\n)

author: suicidaleggroll
author_rank: Super Contributor
timestamp: March 21, 2015, 09:56:34 pm
content: Ihighlydoubt your desktop computer running lab view is too slow to keep up with a UART stream from a PIC...

author: embeddedbob
author_rank: Contributor
timestamp: March 22, 2015, 01:38:54 pm
content: The PC UART (or adapter) will have buffers which you wownt overflow easily.The first problem is making sure youre always consuming the bytes that are being sent to the PIC. So if you store the bytes, or do any frame parsing off the line, what do you do when youve received a valid message? If your busy processing that message, is there another buffer to consume bytes? A simple double buffer may well suffice; you fill one, process the other...etc.Ive implemented manual flow control a couple of times. Its a case of making sure that the point which is most likely to fail triggers RTS (output) when there is no more capacity in the system. In my case I had high and low watermarks on an array of buffers such that it would switch on and off RTS.When the host asserts RTS and the PICs CTS triggers (GPIO interrupt), you stop TX UART interrupts which stops the PIC sending bytes. However, you need to make sure that your internals can cope and there is adequate buffering to prevent the whole system backing up.Both sides need to cope with the maximum number of bytes for latency just after an RTS hold off. You can calculate this given the line rate.I would use a serial monitor to see whats going on. A logic analyser, scope with serial debug, or PC based monitor such as:http://www.hhdsoftware.com/Downloads/serial-monitorGet you PIC comms working 100% first. You can use Realtermhttp://realterm.sourceforge.net/or similar to dump the contents of a test file at the target to make sure it doesnt fallover or loose bytes.

author: aiq25
author_rank: Regular Contributor
timestamp: March 23, 2015, 01:15:13 am
content: I'm sure it has nothing do with the hardware or PC actually. When I use a hyperterminal program (I tried a bunch of them and they all work, even tried a LV version and that one worked too) everything works, meaning I get all the messages from the PIC and nothing is missing or getting stuck. This makes me believe it's my LV code.I think in my LV code I didn't set the correct buffer size, which I think had to do with the termination character of 0xA. I have two of these in my message, so instead of setting a buffer size of 10 I set it to 4 and everything seems to be working. Also, the system is very slow (I get messages about every second from the PIC) and I put delays in the PIC, there is a delay of 10ms after each character being sent, which to me seems like a large delay compared to the baud rate of 4800 that I'm running the UART at. My end goal is to make the system a little faster, I will probably increase the baud rate to 9600 or faster, decrease the 10ms to 1 or 5 ms and maybe increase the refresh rate from 1 second to 0.5 second. We'll see how this works out. Since it's for my school project I don't think it has to be a fast system, just have to get everything to work.Thank you for the responses guys!!

author: dannyf
author_rank: Super Contributor
timestamp: March 23, 2015, 01:17:09 am
content: QuoteHow would implementing flow control on the PIC solve that problem exactly?

author: aiq25
author_rank: Regular Contributor
timestamp: March 23, 2015, 01:23:16 am
content: Quote from: dannyf on March 23, 2015, 01:17:09 amMy initial thought was by adding flow control I could get LV to ask for data but learning how about how the whole serial communication works I don't think it's necessary. Also, I was thinking that I would need flow control so I will have less error, like missing bits or something.But I don't think I need flow control actually. I'm going to go ahead with few more changes to the speed and what not and hopefully nothing goes wrong during the project presentation lol.