Reggie,

While the pic may be able to send at this speed, it
would be hard for it to receive at the same speed.

If you are using a device other than a pic to receive
at this speed then it may work.

If you are going to do this, I would suggest that you
use a crystal of such a frequency that you get a common
serial rate.  This would enable the receiver to use
one of its internal baud rates.

Now comes a explaination that you may well allready
know, but I will give it anyway.

There are two types of serial communications
that I know of.  Bisycronus, where there the data
is sent as well as a clock.  The 'bi' part may stand
for two as in biplane, two sets of wings.  Or it may
be that it stands for 'bit'.  The clock is used to
keep the receiver in sync with the sender.  The clock
may be on a seperate line (chanel) or may be in
with the data some way on the same line.  Each time
the receiver sees a clock pulse, it looks at the
data to see if a one or a zero is being sent.

The other is asyncrous.  The 'a' part stands for
'not'.  It may be a latin thing?  As an example,
atypical means not typical.  This type has no sync
signal between them, just data.  There is an attempt
made to keep the receiver in sync with the sender.

The first sync is the leading edge of the 'start bit'.
The receiver sees this edge and checks that the line
remains in that state for a certian length of time.
If it is still 'on' at the end of the time, then it
is truly a 'start bit'.

The next 8 bits may be the same level as the 'start
bit', and in that case, the receiver would have no
way to tell for certain what data bit was being sent,
except by its own internal timming.  So the receiver
has a clock running at 16 times the baud rate.  And
So the data bits take 16 clock cycles each.  At the
eight internal clock pulse for each data bit, the
data is sampled and the bit stored.

This means that the transmit clock can be a little
different than the receive clock and the data will
still be read.  There can be at most, 1/2 of the
baud rate timming difference total for the byte.
To show this, if the two clocks are different by 5%,
then after nine bits are received, the receiver and
sender may be out of sync by 45% of one bit time.
And this 45% is just barlely less that 1/2 the baud
rate (time for one bit).

When I said that there was no sync in asyncronus, I
was lying.  The bytes do contain a sync scheme.
This is the start bit/ stop bit combination.
When the receiver thinks that it is receiving
the stop bit, then it starts looking for the
next transistion and will use this edge as the
start of the next start bit.  So it syncs with
the leading edge of the start bit.

The case where the start bit and the eight
data bits are the same is an extreme example,
but as it is a valid byte, it must be planned for.

End.

Bill C.   bill@cornutt.com



>Hi all,
>
>While reading the piclist on the topic about rs233,
>an idea came to me for sending fast asynchronous data.
>A similar routine may have been discovered and posted
>before. But just in case, I will share this to all.
>This routine is not yet tested and may contain bugs.
>
---- code clipped ----

>This gives only 2 cycle per bit which is quite fast.
>On a 4MHz pic, it can send max. 500KBps.
>
>Reggie
>