Reggie,

>> While the pic may be able to send at this speed, it
>> would be hard for it to receive at the same speed.
>SNIP
>
>I have not yet implemented the code on any device yet,
>but it will be useful for high speed PIC to PC data
>transfer.


For really, really fast xfer, use all eight bits of a port,
( the other seven bits of the port will be unusable as outputs )
Hook the pc to the bit at the end of the port.
the bit being used must be cleared from previous operation.
then the pic program,
    set the output bit.      start bit
    put the data byte on the port   first bit of data
    shift the bits of the port       second bit of data
     shift      third bit
    shift   forth bit
    shift    fifth bit
    shift    sixth bit
    shift     seventh bit
    shift     last data bit
    clear bit    stop bit

    total is 10 cycles.

The pc has the data line setup as a interupt as well as "data
in".
when the pic puts the start bit on the line, the pc takes an
interupt
and mindlessly starts reading the bit (in byte format) and
storring
it in a array. After a certain number of loops, the pc interupt
routine
stops collecting the state of the data input and starts looking
at
the beginning of the array to determine what the data bits were.
It then stores the data byte and returns from interupt.

The thing is that the pc just grabs the data and stuffs it in an
array
as fast as it can and does not look at what it read.  After it is
all
over, ( determined by how many bytes were stuffed, time)
then the pc goes back and tries to determine what came over
the line.

A word of warning, the pc may take another type of interupt
durining the "grab and stuff" time.  This would mess up was was
stored in the array.  A way around this may be to take the
total count of grab and stuff cycles from the leading edge
of the start bit to the leading edge of the stop bit.  This time
should be fairly constant unless another interupt occured.  In
which case the data would be considered bad and thrown
out.

This could be done with one bit of a parallel port and would only
require changing the interupt vector for that port.  A serial
port
could also be used if the proper bit of the uart was used so
that the uart would generate an interupt when it received the
start bit.  Note that the data doesn't go through the uart, it
just sets one of the status bits and the status byte of the uart
is what is grabbed and stuffed into the array.

Should I start looking for professional help?

Bill C.   bill@cornutt.com

Looking this over, I see a flaw with determining the time of the
entire
transmittion.  The leading edge of the stop bit could only be
determined
if the last bit was a one.  If the data was zero, then there
would only
be the start bit that could be determined.

The solution would be to use a second start bit at the end of the
data
bits and before the stop bit.


>This routine can also be useful if you are running on
>LP mode and you need to send data a little bit faster.
>
>> 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.
>SNIP
>
>Yes, you are right it should be used with a common
>crystal rate to be compatible with standard baud rates.
>
>Reggie
>