Searching \ for '[PIC]:USART receiving data' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/microchip/ios.htm?key=usart
Search entire site for: 'USART receiving data'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:USART receiving data'
2002\02\25@124444 by Mike Blakey

flavicon
face
I'm doing a little project using an f876 storing and retrieving data (a lookup
table) into the EEDATA memory. The routine works fine, except for receiving data
from the PC. I send the data using VB6 MSComm1 but I get an overrun error after
about 4 bytes. even if I change the speed from 19200 down to 9600, exactly the same
thing happens. I have not got any hardware handshaking, so I am assuming that I
will have to handshake by sending back an acknowledgement byte before sending the
next byte down to the PIC. Am I missing something or is this the right way? Thanks.



********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

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


2002\02\25@125249 by Spehro Pefhany

picon face
At 05:42 PM 2/25/02 +0000, you wrote:
>I'm doing a little project using an f876 storing and retrieving data (a lookup
>table) into the EEDATA memory. The routine works fine, except for
>receiving data
>from the PC. I send the data using VB6 MSComm1 but I get an overrun error
>after
>about 4 bytes. even if I change the speed from 19200 down to 9600, exactly
>the same
>thing happens. I have not got any hardware handshaking, so I am assuming
>that I
>will have to handshake by sending back an acknowledgement byte before
>sending the
>next byte down to the PIC. Am I missing something or is this the right
>way? Thanks.

I think you should buffer the data into RAM and write it later.
Xon/Xoff handshaking can allow a *lot* of bytes to be sent before it
stops sending, or so is my experience.

You could also reduce the speed to allow the longest possible write time
to be accommodated (10ms per byte or whatever you find is safe).

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam@spam@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
9/11 United we Stand

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


2002\02\25@125450 by Peter Onion

flavicon
face
On 25-Feb-02 Mike Blakey wrote:
> I'm doing a little project using an f876 storing and retrieving data (a
> lookup
> table) into the EEDATA memory. The routine works fine, except for receiving
> data
> from the PC. I send the data using VB6 MSComm1 but I get an overrun error
> after
> about 4 bytes. even if I change the speed from 19200 down to 9600, exactly
> the same
> thing happens. I have not got any hardware handshaking, so I am assuming that
> I
> will have to handshake by sending back an acknowledgement byte before sending
> the
> next byte down to the PIC. Am I missing something or is this the right way?
> Thanks.

You havn't given us much to go on Mike....

Is your code getting any characters from the USART ?
Have you got the correct number (zero) of parity bits ?
PIC USART does NOT do parity by itself,  you need to enable the ninth data bit
and work out the parity for yourself.

Maybe you could post the USART code you are using .

Peter

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


2002\02\25@130331 by Martin Peach

flavicon
face
Or you could just time the sender so that it send one byte every second.
Waiting for an acknowledge byte is not as fast as using a port pin to toggle
the data flow. In the PIC, when you receive a byte, set the DTR (or DSR or
RTS or CTS or whichever line the PC software respects, they are all
different in this regard) pin low (or high if it's inverted by the driver)
until you are ready for another one. The actual hardware handshaking does
take place in hardware so there is no way it can overflow the way software
handshakes can.
/\/\/\/*=Martin


{Original Message removed}

2002\02\25@133342 by Bob Barr

flavicon
face
On Mon, 25 Feb 2002 17:42:54 +0000, Mike Blakey wrote:

>I'm doing a little project using an f876 storing and retrieving data (a lookup
>table) into the EEDATA memory. The routine works fine, except for receiving data
>from the PC. I send the data using VB6 MSComm1 but I get an overrun error after
>about 4 bytes. even if I change the speed from 19200 down to 9600, exactly the same
>thing happens. I have not got any hardware handshaking, so I am assuming that I
>will have to handshake by sending back an acknowledgement byte before sending the
>next byte down to the PIC. Am I missing something or is this the right way? Thanks.
>

It sounds like you're trying to write the data to the EEPROM memory on
a byte-by-byte basis, is this true? If so, the PIC isn't able to get
back to the UART code in time to read the next byte before more bytes
are sent by the PC.

EEPROM writes are relatively slow. You will probably have more success
if you can buffer up the data in RAM. You can then send the data in
blocks from the PC to the PIC and write the data blocks to EEPROM
between PC transmissions.
Acknowledgement bytes and XON/XOFF handshaking are usually best done
with blocks of data rather than with each individual byte.


Regards, Bob

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


2002\02\25@134559 by Peter Onion

flavicon
face
On 25-Feb-02 Peter Onion wrote:
>
> You havn't given us much to go on Mike....
>
> Is your code getting any characters from the USART ?
> Have you got the correct number (zero) of parity bits ?
> PIC USART does NOT do parity by itself,  you need to enable the ninth data
> bit
> and work out the parity for yourself.
>
> Maybe you could post the USART code you are using .
>
> Peter


I would go with the other ideas about EEPROM writes being slow....

Peter

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


2002\02\25@145500 by Robert Rolf

picon face
PIC EEPROM writes take about 10msec. 19.2kbaud char time is 520uSec.
The only reason you got to 4 characters is the buffering in the USART
registers. You have to buffer a block of data and then write or run your line
at 600 baud (16msec/char).

Peter Onion wrote:
{Quote hidden}

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


2002\02\26@065832 by michael brown

flavicon
face
> Or you could just time the sender so that it send one byte every second.
> Waiting for an acknowledge byte is not as fast as using a port pin to
toggle
> the data flow. In the PIC, when you receive a byte, set the DTR (or DSR or
> RTS or CTS or whichever line the PC software respects, they are all
> different in this regard) pin low (or high if it's inverted by the driver)
> until you are ready for another one. The actual hardware handshaking does
> take place in hardware so there is no way it can overflow the way software
> handshakes can.
> /\/\/\/*=Martin

CTS is the pin the PC (DTE) pays attention to (input) for hardware flow
control.  CTS is generated (output) by a modem?(DCE)  RTS is generated by
the PC (output) and monitored by the DCE device (input).

BTW, hardware flow-control does NOT guarantee that no data overruns can
occur.  Hardware flow-control still depends on software to interpret the pin
indicating the FIFO is full and to set the appropriate (RTS) indicating that
no more data is desired.

michael brown

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


2002\02\26@085625 by Mike Blakey

flavicon
face
This sounds good, thanks for the advice I'll give it a go!






KILLspambbarrKILLspamspamCALIFORNIA.COM on 25/02/2002 18:32:43
Please respond to RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDUTakeThisOuTspamINTERNETTakeThisOuTspamwtgw

To:     spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDUspamBeGonespamINTERNETspamBeGonespamwtgw
cc:
Paper Mail:
Subject:        Re: [PIC]:USART receiving data

                  *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet.
    Keep this in mind if you answer this message.


On Mon, 25 Feb 2002 17:42:54 +0000, Mike Blakey wrote:

>I'm doing a little project using an f876 storing and retrieving data (a lookup
>table) into the EEDATA memory. The routine works fine, except for receiving data
>from the PC. I send the data using VB6 MSComm1 but I get an overrun error after
>about 4 bytes. even if I change the speed from 19200 down to 9600, exactly the
same
>thing happens. I have not got any hardware handshaking, so I am assuming that I
>will have to handshake by sending back an acknowledgement byte before sending the
>next byte down to the PIC. Am I missing something or is this the right way? Thanks.

>

It sounds like you're trying to write the data to the EEPROM memory on
a byte-by-byte basis, is this true? If so, the PIC isn't able to get
back to the UART code in time to read the next byte before more bytes
are sent by the PC.

EEPROM writes are relatively slow. You will probably have more success
if you can buffer up the data in RAM. You can then send the data in
blocks from the PC to the PIC and write the data blocks to EEPROM
between PC transmissions.

Acknowledgement bytes and XON/XOFF handshaking are usually best done
with blocks of data rather than with each individual byte.


Regards, Bob

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








********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

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


2002\02\26@132515 by Martin Peach

flavicon
face
...
> > until you are ready for another one. The actual hardware handshaking
does
> > take place in hardware so there is no way it can overflow the way
software
> > handshakes can.
> > /\/\/\/*=Martin
>
> CTS is the pin the PC (DTE) pays attention to (input) for hardware flow
> control.  CTS is generated (output) by a modem?(DCE)  RTS is generated by
> the PC (output) and monitored by the DCE device (input).
>
> BTW, hardware flow-control does NOT guarantee that no data overruns can
> occur.  Hardware flow-control still depends on software to interpret the
pin
> indicating the FIFO is full and to set the appropriate (RTS) indicating
that
> no more data is desired.

True, but in the case where the PC is transmitting data to the PIC, the PIC
can shut off the data flow from the PC by holding the appropriate handshake
line inactive. This physically prevents the USART on the PC from
transmitting (as long as it has been initialized to use hardware handshaking
of course...).
/\/\/\/*=Martin

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


2002\02\26@134952 by Bob Ammerman

picon face
> > CTS is the pin the PC (DTE) pays attention to (input) for hardware flow
> > control.  CTS is generated (output) by a modem?(DCE)  RTS is generated
by
> > the PC (output) and monitored by the DCE device (input).
> >
> > BTW, hardware flow-control does NOT guarantee that no data overruns can
> > occur.  Hardware flow-control still depends on software to interpret the
> pin
> > indicating the FIFO is full and to set the appropriate (RTS) indicating
> that
> > no more data is desired.
>
> True, but in the case where the PC is transmitting data to the PIC, the
PIC
> can shut off the data flow from the PC by holding the appropriate
handshake
> line inactive. This physically prevents the USART on the PC from
> transmitting (as long as it has been initialized to use hardware
handshaking
> of course...).
> /\/\/\/*=Martin

But, as I posted earlier: it does not. After the interrupt caused by the
control line change occurs no additional characters will be written to the
PC's UART. However any characters still remaining in the PC's transmitter
shift register, buffer, or FIFO will still come blasting down the wire. This
could be quite a few characters with deep FIFOs.

Bob Ammerman
RAm Systems

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


2002\02\26@142136 by Martin Peach

flavicon
face
> > > CTS is the pin the PC (DTE) pays attention to (input) for hardware
flow
> > > control.  CTS is generated (output) by a modem?(DCE)  RTS is generated
> by
> > > the PC (output) and monitored by the DCE device (input).
> > >
> > > BTW, hardware flow-control does NOT guarantee that no data overruns
can
> > > occur.  Hardware flow-control still depends on software to interpret
the
> > pin
> > > indicating the FIFO is full and to set the appropriate (RTS)
indicating
{Quote hidden}

This
> could be quite a few characters with deep FIFOs.

OK, I see...then you also have to program the PC to not use the FIFO...it
does seem a bit silly to use a FIFO on the output if you need to be sure
that all the characters are accepted at the other end.

/\/\/\/*=Martin

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


2002\02\26@172012 by Bob Ammerman

picon face
> > But, as I posted earlier: it does not. After the interrupt caused by the
> > control line change occurs no additional characters will be written to
the
> > PC's UART. However any characters still remaining in the PC's
transmitter
> > shift register, buffer, or FIFO will still come blasting down the wire.
> This
> > could be quite a few characters with deep FIFOs.
>
> OK, I see...then you also have to program the PC to not use the FIFO...it
> does seem a bit silly to use a FIFO on the output if you need to be sure
> that all the characters are accepted at the other end.
>
> /\/\/\/*=Martin

Right, and telling the PC not to use the FIFO can be problematic. I am not
at all sure of the correct incantations, assuming there are such, to do this
under Windows.

I generally send a small packet of data to the PIC and then wait for a
acknowledge before sending the next packet.

It is really the only way to be sure the other end got the data

Bob Amemrman
RAm Systems

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


2002\02\26@180336 by Martin Peach

flavicon
face
> > > But, as I posted earlier: it does not. After the interrupt caused by
the
> > > control line change occurs no additional characters will be written to
> the
> > > PC's UART. However any characters still remaining in the PC's
> transmitter
> > > shift register, buffer, or FIFO will still come blasting down the
wire.
> > This
> > > could be quite a few characters with deep FIFOs.
> >
> > OK, I see...then you also have to program the PC to not use the
FIFO...it
> > does seem a bit silly to use a FIFO on the output if you need to be sure
> > that all the characters are accepted at the other end.
> >
> > /\/\/\/*=Martin
>
> Right, and telling the PC not to use the FIFO can be problematic. I am not
> at all sure of the correct incantations, assuming there are such, to do
this
> under Windows.
>
> I generally send a small packet of data to the PIC and then wait for a
> acknowledge before sending the next packet.
>
> It is really the only way to be sure the other end got the data
>

In Windows98 you can Do ControlPanel->System->DeviceMangaer->Ports and so on
to get to the advanced properties for a serial port and switch off the FIFO,
but probably a serial program can override all these settings. I seem to
remember having done that but it will take me some time to find the info on
MSDN...there is an iocontrol struct you can configure somewhere to use
specific hardware handshake lines and possible control the FIFO use.
/\/\/\/*=Martin

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


2002\02\26@190211 by Bob Ammerman

picon face
> In Windows98 you can Do ControlPanel->System->DeviceMangaer->Ports and so
on
> to get to the advanced properties for a serial port and switch off the
FIFO,
> but probably a serial program can override all these settings. I seem to
> remember having done that but it will take me some time to find the info
on
> MSDN...there is an iocontrol struct you can configure somewhere to use
> specific hardware handshake lines and possible control the FIFO use.
> /\/\/\/*=Martin

The logical place would be in the settings in the DCB passed to the WinAPI
SetCommState, but of course that is not it.

I'm not sure where to look in MSDN for IOCTLs that apply to the serial
device. I've never bumped into them.

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


2002\02\27@101143 by Martin Peach

flavicon
face
> > In Windows98 you can Do ControlPanel->System->DeviceMangaer->Ports and
so
> on
> > to get to the advanced properties for a serial port and switch off the
> FIFO,
> > but probably a serial program can override all these settings. I seem to
> > remember having done that but it will take me some time to find the info
> on
> > MSDN...there is an iocontrol struct you can configure somewhere to use
> > specific hardware handshake lines and possible control the FIFO use.
> > /\/\/\/*=Martin
>
> The logical place would be in the settings in the DCB passed to the WinAPI
> SetCommState, but of course that is not it.
>
> I'm not sure where to look in MSDN for IOCTLs that apply to the serial
> device. I've never bumped into them.

I was using ioctl when I meant dcb. Sorry, wrong OS. I see that in the DCB
there is a field:
"fOutxCtsFlow
Specifies if the CTS (clear-to-send) signal is monitored for output flow
control. If this member is TRUE and CTS is turned off, output is suspended
until CTS is sent again. "...which says nothing about its latency.

I found IOCTL_SERIAL_SET_FIFO_CONTROL in the Driver Development Kit, which
may mean it is hard to use by an application...see:
msdn.microsoft.com/library/default.asp?url=/library/en-us/serial/hh/s
erial/serref_42b6.asp

/\/\/\/*=Martin

--
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\02\27@212649 by Bob Ammerman

picon face
> I found IOCTL_SERIAL_SET_FIFO_CONTROL in the Driver Development Kit, >
which may mean it is hard to use by an application...see:
>
msdn.microsoft.com/library/default.asp?url=/library/en-us/serial/hh/s
> erial/serref_42b6.asp
>
> /\/\/\/*=Martin

This is probably in the DDK because replacement serial device drivers are
expected to implement it. It is also stated that the standard serial driver
implements it. It should be possible for applications to use it, if they can
figure out the args, which may be nothing more complicated than the image of
the FIFO control register of the UART.

Bob Ammerman
RAm Systems

--
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\02\27@222026 by Ashley Roll

flavicon
face
Hi Everyone,

There is the SetupComm() function which allows you to request buffer sizes,
although it can be ignored by the driver..

msdn.microsoft.com/library/default.asp?url=/library/en-us/hardware/co
mmun_29il.asp

I'd suggest that the original poster not try to do this, but rather sends a
single byte and waits for a response from the PIC before sending the next..
Doing this at a higher level then the PC UART will make is more likely to be
portable, but it will make it slower.

Cheers,
Ash

---
Ashley Roll
Digital Nemesis Pty Ltd
http://www.digitalnemesis.com
Mobile: +61 (0)417 705 718




> {Original Message removed}

2002\02\28@080018 by Olin Lathrop

face picon face
> I'd suggest that the original poster not try to do this, but rather sends
a
> single byte and waits for a response from the PIC before sending the
next..

Yes, I'd like to reinforce that.  I've done this sort of thing many times.
Usually I have both communications directions organized as opcodes followed
by data bytes dependent on the opcode.  I make sure that the UART input
buffer on the PIC is big enough to hold the largest command.  The host is
only allowed to send a new command after the previous one has been ACKed.
Of course there are timeout rules and such to avoid lockup.

> Doing this at a higher level then the PC UART will make is more likely to
be
> portable, but it will make it slower.

I agree.  I think it's a lot better to use just the basic RS-232 features on
the host that will be available anywhere.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, RemoveMEolinspamTakeThisOuTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\02\28@111009 by Martin Peach

flavicon
face
>
> I agree.  I think it's a lot better to use just the basic RS-232 features
on
> the host that will be available anywhere.

Basic RS-232 includes hardware handshaking. The FIFO issue can be avoided by
feeding the bytes one at a time after checking the hardware handshake flag.
This is faster than waiting for a character to come back from the target
since it uses just one asynchronous bit to toggle the data flow, but at the
cost of using one more wire.
/\/\/\/*=Martin

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


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