USART problems

[Demon]

I went for a nap after my last post and not 2 minutes later, I remember this:

"If you just need to PIC to tell the PC to stop sending data, connect the PIC flow control pin to the PC CTS pin."

Robert

[Bruce]

Why not do something useful with the data received instead of wasting time in the doodle routine or writing everything received into another array?

Once you receive the terminating character, write your data to EEPROM, then wait for the next packet.

Also, you don't need all this;

ASM
LIST
INCLUDE 'M16F87X.INC' ; PM header
DEVICE PIC16F877, HS_OSC, WDT_OFF, PWRT_ON, BOD_ON, LVP_OFF, CPD_OFF, WRT_OFF, DEBUG_OFF, PROTECT_OFF
XALL
NOLIST
ENDASM

Just drop in your fuse definitions like below, and leave the rest to PBP. It does all this for you.

@ DEVICE PIC16F877, HS_OSC, WDT_OFF, PWRT_ON, BOD_ON, LVP_OFF, CPD_OFF, WRT_OFF, DEBUG_OFF, PROTECT_OFF

This routine;

WHILE RCIF
BytesBK[ByteBKN]=RCREG
ByteBKN=ByteBKN+1
WEND

Just clears whatever characters may have arrived after the terminating character was received. You want to be sure RCREG is empty & RCIF is clear before your next data packet shows up.

At some point, you're going to need some kind of synchronization with your PC program sending your data. You can't just keep slamming data into the USART without doing something with it to clear the array, and you're going to need some time to write your data to EEPROM (without interrupts enabled).

You do not want interrupts enabled when writing data to the EEPROM, so you will definitely want to implement something to let the PC know you're busy.

Example scenario:

PIC requests data from PC.
PC sends packet with terminating character.
PIC receives & stashes data in array until terminating character is received.
PIC processes data.
PC waits for signal from PIC to send next packet.
PIC says OK, let's have it.
PC sends next data packet.

Two way communications is the key.

Strip all the useless stuff out of my example. You don't need to send everything back to the PC terminal program or waste time in the doodle sub-routine. That was just an example showing how to receive streaming data, and key on the terminating character to find the end-of-packet.

The time you spend in re-writing everything into another array, pauses, etc,, could be used for processing your inbound data, and let you setup & wait for the next packet.

Note: Watch for stuff like this;

On Interrupt Goto Main
Doodle:
FOR X = 0 TO 250 : PAUSEUS 20 : NEXT X
FOR X = 0 TO 250 : PAUSEUS 20 : NEXT X
RETURN
INTCON=$80

Program flow will never reach INTCON=$80 because it RETURNs before landing on it.

[Demon]

Hi Bruce,

"If you just need to PIC to tell the PC to stop sending data, connect the PIC flow control pin to the PC CTS pin."

I tried that, didn't work.

"Once you receive the terminating character, write your data to EEPROM, then wait for the next packet."

I tried that too, writing to EEPROM takes too long. The balance of data goes to hyperspace.

"Just clears whatever characters may have arrived after the terminating character was received. You want to be sure RCREG is empty & RCIF is clear before your next data packet shows up."

I can't exactly do that. Those characters sitting in the 2nd byte of RCREG and in RSR are the start of the next record.

"You do not want interrupts enabled when writing data to the EEPROM, so you will definitely want to implement something to let the PC know you're busy."

Yup, I only have interupts enabled in a small loop where I'm waiting for input. Besides CTS, which I can't get to work, is there another means of telling the PC to stop sending? It looks to me like the PC only listens to CTS at the end of his packet, not in the middle.

"At some point, you're going to need some kind of synchronization with your PC program sending your data. You can't just keep slamming data into the USART without doing something with it to clear the array, and you're going to need some time to write your data to EEPROM (without interrupts enabled)."

Do you have any idea how to do that? I've been going through pages 101 and 102 of the PIC 16F877 - USART ASYNCHRONOUS RECEIVER, and tried a ton of combinations using the flags they mention. Nothing works as expected.

I can read my entire file without any problems, I just don't have time to process the records. I don't even have time to write to EEPROM without doing any record formatting whatsoever. I just set the location to 1 and write a record with zeroes.

I have to momentarily interrupt the transfer, but I can't figure out how. Mister E has been giving this a try on his end and as far as I know, he's still stumped.

Robert

[Demon]

I think I figured it out.

I lowered the BAUD rate down until I got to 2400 and things seem ok at first glance. Since the PC didn't want to wait or wasn't receiving the CTS flag fast enough, I guessed that lowering the transfer speed would give it more time to react.

I have to go line by line to make sure no garbage crept through isolated areas, but the records line up and look good.

Robert

[mister_e]

to use CTS, you must ensure your terminal software handle it. If you're using MicroCode studio... it does'nt. Only RealTerm, or others with proper FlowControl setting CTS/RTS or DSR/DTR will stop when you clear CTS... in the worst case... $#%#$!#%$##*#$* hyperterm can stop too... if you're able to make it work... $%$### hyperterm ...

BTW, at this poit, it looks like any of those terminal program i use, handle poor the flow control. I can stop, receive echo back a character of 4Mb files without any delay between receive, but if i place 5-10 or else uSec or mSec delay between each CTS i'm screw up. it's skip character, or i get garbage...

still looks like the program stop serial out in the middle of a character or else.

i figure i'll have to make my own software... again. we can't never trust somebody on this earth... still a pain to have a 100% workable program... Terminal 2.xyz is a big piece of &^&^%@@$%... sorry for the person who refer this program...

As Bruce said, 2 way comm is the way... i agree. Probably better than CTS/RTS bulls.h.i.t... wich is probably just good enough to start transfer and stop at the end... or

1. i'm missing something trivial on that.
2. my terminal program is not good enough.. but for sure better than Hyperterm

[Demon]

Yup,


I couldn't get RealTerm to work properly either, I get garbage chatacters echoed back, and nothing goes to the PIC. HypeTerminal (R intentionally left out) is worse, I don't get any feedback at all.

I've been using the serial window from Studio Plus and it looks like the best solution for me. I copy my datafile from NotePad, paste in the SEND window, CLICK, and away it goes. I lose out on some of the echo at the bottom of the file, but I don't really care. I also display on the LCD and the last records seem to be there.

So now I'm going to write a program to read back from EEPROM. It's a link list database, so I have to write the code to follow through all the pointers and display the data back on the PC; using HSEROUT should not be a problem at this point.

It's not a perfect solution, 2400 BAUD ain't something to brag about, but it seems to work. Since this download will not be used often, that suits me fine. As long as it works reliably, I'm happy.

Robert

[Bruce]

Take a look at the source code for one of the free boot-loader programs out there. You'll see how the PIC firmware & PC loader software work together (with two-way communications) to transfer large files from PC to PIC.

[mister_e]

yup, that's for sure Bruce, this is why i plan to do my own terminal program for some 'specific' purpose.

Send a packet to PIC, PIC send 'ok' (or whatever else), once PC receive it, send next packet, and so on. That imply to build our own program instead of using CTS/RTS DTR/DSR with already made terminal program. AND we save i/o for handshaking.