Crist=F3v=E3o Dalla Costa
> Handshaking is a good way to start the protocol from a know point. If
> available for free such as in a serial cable to a PC it eases development
> since you have a way, from the PC, to tell the PIC to start over (or
> vice-versa).

The reason handshaking exists, is to protect the buffer of the receiving =

device from overflowing. In a great majority of cases, especially using a =

modern PC and a PIC with a hardware USART, handshaking is not necessary.

> Sure everything that's done with handshaking can also be done
> without, but if it's more difficult and the lines are already there...

I'm talking about not using *any* handshaking, hardware or software. Which, =

by definition, is less complicated.

> For example if the PIC resets for whatever reason the handshake is still
> there telling it to send data to the PC after it initializes, and no time =

> is
> lost. Try doing that without handshake, how do you save state between
> resets? If however you let the PIC send data regardless you'll have to
> switch it off manually before starting the PC program as Windows won't let
> you open the port when it's active receiving data (even if no other =

> program
> is using it).

I have no idea what you are talking about. When the PIC resets, your =

transmit buffer is cleared. Even if it didn't, the PIC may have reset in th=
e =

middle of transmitting a byte, and you don't know which byte you were =

transmitting. Unless you're transmitting the same byte over and over, I =

don't understand how handshaking help, even with the situation you =

described.

>> Why are you using interrupts for transmit?
>
> Why not? It's better than polling.

Interrupts have latencies, and waste processor cycles. In most cases, =

polling would be faster than interrupts, and definitely a lot more =

straightforward.

Vitaliy

-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist