Searching \ for '[PIC]:[EE]: PC uart too fast for PIC - handshaking' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: '[EE]: PC uart too fast for PIC - handshaking'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:[EE]: PC uart too fast for PIC - handshaking'
2002\04\16@134656 by John Walshe

flavicon
face
I'm using an '876 with the onboard UART talking to an RF IC and a software
UART(swuart) talking to the PC. On the PC I cobbled together a Visual C(++)
application which sends commands to the PIC. However the PC talks too fast
for the PIC to both grab the command data and do something with it. Although
the shortest command is only four bytes long they come so fast on the tail
of each other that the swuart misses part of the second byte and I get a
garbled command.

I have tried CTS/RTS and DSR/DTR handshaking with the respective control
signal being deasserted when the startbit of the first byte is detected but
still all the bytes (4 of them) come down from the PC - I guess the PC uart
will always empty its buffer. I was hoping to gain byte by byte control. Is
this possible?

If I could I would insert a delay between sending the bytes but I'm afraid I
haven't found a DelayMs() type function for windows yet!. Any one got any
pointers here (forgive the pun).

I swapped the uarts for the time being in order to progress with the project
but I really would like to know why the handshaking did not work. Has anyone
got experiences in this area that they would like to share?

Slan
John

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2002\04\16@144408 by Bob Barr

flavicon
face
On Tue, 16 Apr 2002 18:38:51 +0100, John Walshe wrote:

>I'm using an '876 with the onboard UART talking to an RF IC and a software
>UART(swuart) talking to the PC. On the PC I cobbled together a Visual C(++)
>application which sends commands to the PIC. However the PC talks too fast
>for the PIC to both grab the command data and do something with it. Although
>the shortest command is only four bytes long they come so fast on the tail
>of each other that the swuart misses part of the second byte and I get a
>garbled command.
>

What's your baud rate and how much are you trying to do between bytes?

Unless your 876 is running real slow or your PC is talking real fast,
the stop bit time should give you quite a bit (pun intended) of time
between characters. At 9600 baud, you'll have at least 104uS (1 bit
time) before you have to start looking for the next byte's start bit.

If your software UART is sampling at the mid-point of the serial bits
as it should be, you'll have 156uS or so (1 and 1/2 bit times) of
'dead time' to work with. The 16F876 can do a lot in that much time.
(At 20MHz, that's almost 800 instruction cycles.)

>I have tried CTS/RTS and DSR/DTR handshaking with the respective control
>signal being deasserted when the startbit of the first byte is detected but
>still all the bytes (4 of them) come down from the PC - I guess the PC uart
>will always empty its buffer. I was hoping to gain byte by byte control. Is
>this possible?
>

Are you sure that you have the PC's comm port configured to use the
hardware handshaking? If I'm not mistaken, CTS/RTS is most commonly
used for the hardware handshake but the comm port is typically set by
default to ignore it.

>If I could I would insert a delay between sending the bytes but I'm afraid I
>haven't found a DelayMs() type function for windows yet!. Any one got any
>pointers here (forgive the pun).
>

That certainly shouldn't be necessary. You could send the bytes to the
PC's uart one at a time from your C program. You could lower the baud
rate to give yourself more stop-bit time or perhaps configure the PC's
uart to use 2 stop bits on each byte.


Regards, Bob

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu


2002\04\16@150449 by Olin Lathrop

face picon face
> I'm using an '876 with the onboard UART talking to an RF IC and a software
> UART(swuart) talking to the PC. On the PC I cobbled together a Visual
C(++)
> application which sends commands to the PIC. However the PC talks too fast
> for the PIC to both grab the command data and do something with it.
Although
> the shortest command is only four bytes long they come so fast on the tail
> of each other that the swuart misses part of the second byte and I get a
> garbled command.

I usually deal with this by having the PIC send a ACK no less often than the
biggest chunk it can receive at once (1 byte in your case).  The host is not
allowed to send the next chunk until the ACK is received.

Host flow control is not the answer unless your chunks are really big.  PCs
tend to implement XOFF in software, so the UART's buffer is still sent after
an XOFF is received.  I don't know how RTS is handled, but it may be the
same.  In any case, don't expect a PC to stop sending instantaneously when
you ask it to.  You will need at least a 16 byte buffer for that an possibly
more.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2002\04\16@152537 by Barry Gershenfeld

picon face
If your commands are only 4 bytes you might consider collecting
all four characters at once before actually looking at any
of them.

Since you want to waste time, going to a slower baud rate will
accomplish the same thing.   Even if it's not your favourite
solution it may help to prove to yourself that there's nothing
wrong with your software UART implementation.

It's almost never a good idea to try to implement time delays
with PC-based serial ports.  There is just too much virtualization
between the program and the actual hardware.  Recent implementations
of Windows have been observed to collect all the carefully
delayed characters and then blast them out in one shot.

Barry

>...the PC talks too fast
>for the PIC to both grab the command data and do something with it. Although
>the shortest command is only four bytes long they come so fast on the tail
>of each other that the swuart misses part of the second byte and I get a
>garbled command....
>Slan
>John

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu


2002\04\16@162828 by Bob Ammerman

picon face
----- Original Message -----
From: "John Walshe" <EraseMEJohn.Walshespam_OUTspamTakeThisOuTINPACTMICRO.COM>
To: <PICLISTspamspam_OUTMITVMA.MIT.EDU>
Sent: Tuesday, April 16, 2002 1:38 PM
Subject: [PIC]:[EE]: PC uart too fast for PIC - handshaking?


> I'm using an '876 with the onboard UART talking to an RF IC and a software
> UART(swuart) talking to the PC. On the PC I cobbled together a Visual
C(++)
> application which sends commands to the PIC. However the PC talks too fast
> for the PIC to both grab the command data and do something with it.
Although
> the shortest command is only four bytes long they come so fast on the tail
> of each other that the swuart misses part of the second byte and I get a
> garbled command.
>
> I have tried CTS/RTS and DSR/DTR handshaking with the respective control
> signal being deasserted when the startbit of the first byte is detected
but
> still all the bytes (4 of them) come down from the PC - I guess the PC
uart
> will always empty its buffer. I was hoping to gain byte by byte control.
Is
> this possible?

Yes, the UART will empty its buffer before paying attention to flow control

> If I could I would insert a delay between sending the bytes but I'm afraid
I
> haven't found a DelayMs() type function for windows yet!. Any one got any
> pointers here (forgive the pun).

Sleep( # of milliseocnds )

> I swapped the uarts for the time being in order to progress with the
project
> but I really would like to know why the handshaking did not work. Has
anyone
> got experiences in this area that they would like to share?

You should be able to store the 4 bytes in a buffer in the PIC, and then
process them all after the receive has completed. If you can't then you
probably need a better software UART.

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2002\04\16@182927 by Tony Nixon

flavicon
picon face
John Walshe wrote:
>
> I'm using an '876 with the onboard UART talking to an RF IC and a software
> UART(swuart) talking to the PC. On the PC I cobbled together a Visual C(++)
> application which sends commands to the PIC. However the PC talks too fast
> for the PIC to both grab the command data and do something with it. Although
> the shortest command is only four bytes long they come so fast on the tail
> of each other that the swuart misses part of the second byte and I get a
> garbled command.

I don't think you can ever guarantee how the PC will send your data,
especially time wise.

You didn't say what baud rate you are using, but I normally use 19200
and have no problems.

I use these 2 subroutines a lot for RS232 in/out.

;
; ----------------------------
; RECEIVE CHARACTER FROM RS232
; ----------------------------
; This routine does not return until a character is received.
;
Receive btfss PIR1,RCIF         ; (5) check for received data
       goto Receive
;
       movf RCREG,W
       return
;
; ------------------------------------
; WAIT UNTIL RS232 IS FINISHED SENDING
; ------------------------------------
;
TransWt movwf TXREG
       bsf STATUS,RP0
Wt_TX   btfss TXSTA,TRMT        ; (1) transmission is complete if hi
       goto Wt_TX
;
       clrf STATUS             ; RAM Page 0
       return


If you are expecting 4 bytes from the PC then perhaps...

       movlw Buffer
       movwf FSR
Rx_Loop call Receive
       movwf INDF
       incf FSR
       movlw Buffer + d'4'
       xorwf FSR,W
       btfss STATUS,Z
       goto Rx_Loop

       call TransWt            ; sends 0 byte back to ACK

       ; do something with data

Sending that buffer back again...

       movlw Buffer
       movwf FSR
Tx_Loop movf INDF,W
       call TransWt            ; guarantees byte is sent
       incf FSR
       movlw Buffer + d'4'
       xorwf FSR,W
       btfss STATUS,Z
       goto Tx_Loop

Basically make sure that your processing speed is OK with the baud rate
and vice versa.


--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
KILLspamsalesKILLspamspambubblesoftonline.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2002\04\17@033306 by Alan B. Pearce

face picon face
>I have tried CTS/RTS and DSR/DTR handshaking with the respective control
>signal being deasserted when the startbit of the first byte is detected but
>still all the bytes (4 of them) come down from the PC - I guess the PC uart
>will always empty its buffer. I was hoping to gain byte by byte control. Is
>this possible?

This sounds like your PC has the FIFO on the uart enabled, and I believe
that one of the problems with these uarts is that the hardware handshake
does not control bytes already loaded into the uart, it relies on the PC
software checking flags in the uart and not loading any more bytes until the
flag from the control line changes state.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\17@060658 by John Walshe

flavicon
face
Hi Guys,
   Thanks for your comments. It would seem that my suspicion re the UART
emptying it's buffer were correct. Mind you I thought that the Pic @20MHz
would have had plenty of time to do the interim short bit of work but
obviously not in this case. It looks like I'll have to implement that buffer
after all. And I learned of a new command C command for windows  Sleep() (I
could do with a bit of that myself now!)
As per usual the piclist triumphs again.
Thanks again,
John

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\17@063031 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: John Walshe [SMTP:spamBeGoneJohn.WalshespamBeGonespamINPACTMICRO.COM]
> Sent: Wednesday, April 17, 2002 11:02 AM
> To:   TakeThisOuTPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU
> Subject:      Re: [PIC]:[EE]: PC uart too fast for PIC - handshaking?
>
> Hi Guys,
>     Thanks for your comments. It would seem that my suspicion re the UART
> emptying it's buffer were correct. Mind you I thought that the Pic @20MHz
> would have had plenty of time to do the interim short bit of work but
> obviously not in this case. It looks like I'll have to implement that
> buffer
> after all. And I learned of a new command C command for windows  Sleep()
> (I
> could do with a bit of that myself now!)
> As per usual the piclist triumphs again.
> Thanks again,
> John
>
What bit rate are you using out of interest?  The PIC's USART has a small
FIFO buffer so it can actually hold two bytes whilst receiving a third,
which should give you ages to process stuff at a reasonable bit rate.
(obviously you would have to pull those two out pretty quickly to stop an
overflow under that condition).

Regards

Mike

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\17@063923 by Alan B. Pearce

face picon face
>What bit rate are you using out of interest?  The PIC's USART has a small
>FIFO buffer so it can actually hold two bytes whilst receiving a third,

Not sure what PIC you are using, but the 16F876 I have the hardware UARTs
hold only one while receiving the next.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\17@072004 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: Alan B. Pearce [SMTP:RemoveMEA.B.PearcespamTakeThisOuTRL.AC.UK]
> Sent: Wednesday, April 17, 2002 11:36 AM
> To:   PICLISTEraseMEspam.....MITVMA.MIT.EDU
> Subject:      Re: [PIC]:[EE]: PC uart too fast for PIC - handshaking?
>
> >What bit rate are you using out of interest?  The PIC's USART has a small
> >FIFO buffer so it can actually hold two bytes whilst receiving a third,
>
> Not sure what PIC you are using, but the 16F876 I have the hardware UARTs
> hold only one while receiving the next.
>
>
I'm using a 16F877.  Section 10.2.2 of the datasheet (at least in my
datasheet!) explains this.

"The RCREG is a double buffered register (i.e. it is a two deep FIFO).  It
is possible for two bytes of data to be received and transfered to the RCREG
FIFO and a third byte to begin shifting to the RSR register."

Mike

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\17@082328 by Alan B. Pearce

face picon face
>I'm using a 16F877.  Section 10.2.2 of the datasheet
>(at least in my datasheet!) explains this.

Oh, Mea Culpa or some such. The picture even illustrates it as such.

I must admit not reading the section carefully as I'm using Fr. Thomas
McGahee's uart code.

As this is the case then the original poster's problem must be either very
bad indeed, or extremely fast transmissions.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\17@124814 by John Walshe

flavicon
face
Hi Alan,Mike,
   Unfortunately I'm already using the HW uart to talk to something else.
My problem here was with a s/w uart running at 9600
John

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\17@132531 by Bob Barr

flavicon
face
On Wed, 17 Apr 2002 13:42:23 +0100, John Walshe wrote:

>Hi Alan,Mike,
>    Unfortunately I'm already using the HW uart to talk to something else.
>My problem here was with a s/w uart running at 9600

John,

How much are you trying to do between bytes? At 9600 baud, you should
have about 150 uS of dead time (half of the last bit time plus the
stop bit time) between bytes. That's an awful lot of cycles at any
imaginable clock speed.

Might you perhaps be getting back to sampling for the start bit before
the last bit of the previous byte is done? Many software uart examples
just look for the start bit as a low. On a fast processor, the line
could already be low from the last bit of the previous byte. If you
get back to the start bit test within 50 uS (half a bit time), things
would really get garbled.

You should check for the line being high (i.e. in the stop bit time)
before you start looking for the start bit transition. (Please don't
ask how I know this. It's too embarassing.)


Regards, Bob

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\17@135452 by Barry Gershenfeld

picon face
>You should check for the line being high (i.e. in the stop bit time)
>before you start looking for the start bit transition. (Please don't
>ask how I know this. It's too embarassing.)
>
>
>Regards, Bob

Heh, I can vouch for that one!  I once did that in hardware!

Barry

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\17@200032 by Tony Nixon

flavicon
picon face
John Walshe wrote:
>
> Hi Alan,Mike,
>     Unfortunately I'm already using the HW uart to talk to something else.
> My problem here was with a s/w uart running at 9600
> John

The trouble with software UARTs (bit banged I assume) is that you always
have to be ready to receive a byte 'before' it gets there. If you are
too late then you miss it, or half of it and thus mess up the rest of
your data stream.

You may not afford to have interrupts enabled, because while that is
executing, the receive code may be denied the chance to recognise a
valid start bit. Same with WDT timeouts.

If you are expecting to receive more than one byte, buffer the incoming
data stream then act on it after receiving it all.

Of course, if you have an interrupt enabled (RB0INT for example) to
catch the start bit, then that may make things easier.

Perhaps backtrack a little and only test that your RX routine is
actually grabbing the bytes - echo them back maybe.


--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
EraseMEsalesspambubblesoftonline.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\17@215017 by Bob Barr

flavicon
face
On Thu, 18 Apr 2002 09:54:25 +1000, Tony Nixon wrote:


>The trouble with software UARTs (bit banged I assume) is that you always
>have to be ready to receive a byte 'before' it gets there. If you are
>too late then you miss it, or half of it and thus mess up the rest of
>your data stream.
>

The flip side of the 'too late' problem is the 'too early' problem. If
you get back to the software uart while you're still in the last half
of the last bit, the code can mis-interpret a low as the start bit. To
ensure that this hasn't happened, you need to first check for a high
and then wait for the high-to-low transition. (Most examples of
software uarts that I've seen don't do this.)


>You may not afford to have interrupts enabled, because while that is
>executing, the receive code may be denied the chance to recognise a
>valid start bit. Same with WDT timeouts.
>

Too true.


>If you are expecting to receive more than one byte, buffer the incoming
>data stream then act on it after receiving it all.
>

While I agree on this point as a good general practice, don't forget
that you do have at least 1 and 1/2 bit times (last half of the last
bit plus the stop bit) available before the next start bit can
possibly occur.


>Of course, if you have an interrupt enabled (RB0INT for example) to
>catch the start bit, then that may make things easier.
>

Amen.

>Perhaps backtrack a little and only test that your RX routine is
>actually grabbing the bytes - echo them back maybe.
>

Just be sure to buffer the characters until you get a a specific
character (carriage-return or line-feed perhaps)  and then echo the
whole string. If you're not echoing them with the hardware uart, you
won't be able to echo each character as it is received.


Regards, Bob

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\18@095254 by ISO-8859-1?Q?Ruben_J=F6nsson?=

flavicon
face
>
> If your software UART is sampling at the mid-point of the serial bits
> as it should be, you'll have 156uS or so (1 and 1/2 bit times) of
> 'dead time' to work with. The 16F876 can do a lot in that much time.
> (At 20MHz, that's almost 800 instruction cycles.)
>

I always usa a shift in register and a holding register in my
interrupt driven software uarts. When the expected bits are
shifted in by the interrupt routine it moves this to the
holding register and signal the main program that a byte is
available. This way, the main program has 10 bit times (8n1 1
stop) to grab the holding register, act on it or put it in a
buffer.

Ruben
==============================
Ruben Jvnsson
AB Liros Electronic
Box 9124, 200 39 Malmv, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
RemoveMErubenEraseMEspamEraseMEpp.sbbs.se
==============================

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\04\18@152505 by Bob Barr

flavicon
face
On Thu, 18 Apr 2002 15:53:42 +0200, Ruben Jönsson wrote:

>
>I always usa a shift in register and a holding register in my
>interrupt driven software uarts. When the expected bits are
>shifted in by the interrupt routine it moves this to the
>holding register and signal the main program that a byte is
>available. This way, the main program has 10 bit times (8n1 1
>stop) to grab the holding register, act on it or put it in a
>buffer.
>

That method will certainly give you the most time available while
you're receiving. Since the original message didn't say anything about
the exact method being used, I assumed (possibly incorrectly) that
hard-coded delay loops were being used to establish the bit timing.

John,
How does your software uart work? Interrupts? Hard-coded delays?


Regards, Bob

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...