Making my own UART flow control for PIC18F2480

[aiq25]

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.

[dannyf]

I think I need some kind of flow control.

Don'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.

[SL4P]

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 problem before you try to solve it!

[aiq25]

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.

[SL4P]

having not used LV, my first thoughts are : that the 'receiver' is not fast enough to handle the incoming data stream, which may not be solved with FC if there is no RX buffering.... OR the sender is not respecting the listener's processing overhead.
 (With FC! The sender will take at least one 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)

[suicidaleggroll]

I highly doubt your desktop computer running lab view is too slow to keep up with a UART stream from a PIC...

[embeddedbob]

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-monitor

Get you PIC comms working 100% first. You can use Realterm http://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.

[aiq25]

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!!

[dannyf]

I think in my LV code I didn't set the correct buffer size

How would implementing flow control on the PIC solve that problem exactly?

[aiq25]

I think in my LV code I didn't set the correct buffer size

How would implementing flow control on the PIC solve that problem exactly?

My 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.