Searching \ for 'serial receive with parity' 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/io/serials.htm?key=serial
Search entire site for: 'serial receive with parity'.

Truncated match.
PICList Thread
'serial receive with parity'
1999\12\18@103007 by Hamish Moffatt

flavicon
face
I am searching for an RS-232 serial receive routine
which supports parity. The received data occurs in
short bursts at regular intervals, so some sort
of buffer is probably required also. The code in
MicroChip AN555 receives some characters OK but
loses over 50% of them for me. The data rate is
9600, and the clock rate is 10MHz (PIC16F84).

Myke's code at http://www.rentron.com does not support
parity, nor do some of the others I've seen on the
net. I did not have any luck extending them.


Thanks for your assistance,
Hamish

1999\12\18@170940 by paulb

flavicon
face
Hamish Moffatt wrote:

> I am searching for an RS-232 serial receive routine which supports
> parity.  The received data occurs in short bursts at regular
> intervals, so some sort of buffer is probably required also.

 The curly question regarding parity is:  What are you going to *do*
with the parity?  Parity is very rarely used nowadays for this simple
reason - if parity says a given character is corrupt, it is rarely
useful to deal with this on a per-character basis.

 A checksum of a burst or "packet" (including synchronising information
which denotes which character means what) OTOH allows a request to re-
send the whole packet and this is what is most often done.

 Or are you stuck with an odd-ball sender which sends parity and just
have to cater for it?
--
 Cheers,
       Paul B.

1999\12\18@184504 by Hamish Moffatt

flavicon
face
On Sun, Dec 19, 1999 at 09:08:45AM +1100, Paul B. Webster VK2BZC wrote:
> Hamish Moffatt wrote:
> > I am searching for an RS-232 serial receive routine which supports
> > parity.  The received data occurs in short bursts at regular
> > intervals, so some sort of buffer is probably required also.

[...]

>   Or are you stuck with an odd-ball sender which sends parity and just
> have to cater for it?

I should have specified in my original message. I don't mind if the
parity bit is actually tested or not -- I'm happy for it to be simply
discarded. The sender sends checksums of the data packets anyway.


thanks,
Hamish (VK3SB)

1999\12\19@023528 by paulb

flavicon
face
Hamish Moffatt wrote:

> I should have specified in my original message. I don't mind if the
> parity bit is actually tested or not -- I'm happy for it to be simply
> discarded.

 That should be easy then.  Point me to a piece of (almost-) working
code which doesn't allow for parity, and I'll try and bodge you a
Victorian special version that does!  It's just an extra implementation
of the stop-bit routine.
--
 Cheers,
       Paul B.

1999\12\19@040330 by Jose Souto

flavicon
face
part 0 683 bytes
Hamish Moffatt wrote:

> I am searching for an RS-232 serial receive routine
> which supports parity. The received data occurs in
> short bursts at regular intervals, so some sort
> of buffer is probably required also. The code in
> MicroChip AN555 receives some characters OK but
> loses over 50% of them for me. The data rate is
> 9600, and the clock rate is 10MHz (PIC16F84).
>
> Myke's code at http://www.rentron.com does not support
> parity, nor do some of the others I've seen on the
> net. I did not have any luck extending them.
>
> Thanks for your assistance,
> Hamish

Attachment converted: wonderland:serial9.zip (pZIP/pZIP) (00012300)

1999\12\19@200314 by Jose Souto

flavicon
face
part 0 705 bytes
MC & HNY
JSouto

Hamish Moffatt wrote:

{Quote hidden}

Attachment converted: wonderland:serial9a.zip (pZIP/pZIP) (000124A0)

1999\12\19@215747 by Hamish Moffatt

flavicon
face
Unfortunately I don't think a polled, non-buffered routine
is going to work. Data arrives in large bursts at 1 second
intervals. I would prefer that an interrupt was used
and the result placed in a buffer for me to use when I am
ready.

Hamish

On Sun, Dec 19, 1999 at 05:23:57AM -0200, Jose Souto wrote:
{Quote hidden}

--
Hamish Moffatt       Mobile: +61 412 011 176     spam_OUThamishTakeThisOuTspamrising.com.au
Rising Software Australia Pty. Ltd.    http://www.risingsoftware.com/
Phone: +61 3 9894 4788    Fax: +61 3 9894 3362    USA: 1 888 667 7839

1999\12\19@230228 by paulb

flavicon
face
Hamish Moffatt wrote:

> Unfortunately I don't think a polled, non-buffered routine is going to
> work.  Data arrives in large bursts at 1 second intervals.  I would
> prefer that an interrupt was used and the result placed in a buffer
> for me to use when I am ready.

 Then you don't want a 16F84.  Try a 16F87x.
--
 Cheers,
       Paul B.

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