>?unless he (she?) tells us more about his project..........

The project is for control and data aquisition system.. the same PIC will 
comunicate using USART with the PC and  SSP with several other PIC's 
handling several sensors and motors.. at the same time the PIC in question 
will have some logic of its own to run handle everything when not connected 
to the PC..the system needed to be responsive so my choice was to take 
advantage of interrupts instead of poling..

Its a new PC with a DB9 9pin  port.. communicating with the PIC at 
38400bps.. the legth of wire between the PIC and PC is 30ft long through a 
MAX232 chip..
The setup is like PC(as Master) and PIC(slave).. the PC sends a 1 command or 
querry and expects a 1 reply from the PIC.. the data sent will be short just 
sensor information..

regards...

"Vitaliy" <spam@maksimov.org> wrote in message 
news:123f01c74cb5$f3745ef0$6f02a8c0@WS11...
> William Chops Westfield wrote:
>>> The reason handshaking exists, is to protect the buffer of
>>> the receiving device from overflowing.
>>
>> Well, no.  "hardware flowcontrol" as commonly used doesn't really
>> exist according to any specification.  RTS/CTS is supposed to be
>> more about signaling the modem which direction data will be flowing,
>> so that the modem can do its half-duplex things.
>
> Can you explain what you mean? What are these "half-duplex" things?
>
>> "deep fifos" (ie more than one byte) are recent enough that they're
>> not well handled by traditional rs232 protocols.  It's very hard to
>> implement "hardware flow control" in software, for instance, because
>> the software is on the wrong side of the FIFO status.  UARTS with
>> DMA capability are even worse; they're in serious need of status
>> bits that mean "a DMA is in progress but hasn't hit a termination
>> condition yet" that usually doesn't exist.
>
> A buffer is a buffer, even if it's only one byte. :) I don't see what 
> you're
> trying to prove here.
>
>> If you want to transmit a string of data and then cause some other
>> externally visible signal to change AFTER the data has been
>> transmitted, you have to monitor your own software FIFOs, any
>> hardware FIFOs, the transmitter holding register AND the transmit
>> shift register to make sure your data is fully transmitted.
>
> The OP seems to only be concerned with the hardware USART.
>
>> This
>> is usually possible on a hardware uart; many have a "transmitter
>> empty" status bit in addition to a "space available in tx fifo"
>> bit.
>
> Yes, the TXIF and TRMT flags in the 18F PICs.
>
>> I think it's more difficult to retain the proper timing of
>> RXdata and RXsignals; I don't think I've ever seen the necessary
>> "partial character received" status bit (although I think some
>> UARTs claim to only poll the modem signals "in between" characters;
>> One potential difference between "real" uart status bits and GPIO
>> bits used as such...)
>
> What would you use the "partial character received" status bit for?
>
>> To implement a closely timed half-duplex sort of system, it might
>> make sense to handle all your signal changes in the same SW FIFO
>> and ISR as data, so that "rts_off()" ends up queuing a special
>> data sequence (00 01 ?) on the software FIFO, and nothing actually
>> happens until the TX ISR dequeues that command from the FIFO, at
>> which point it would toggle your signal.
>
> Sounds like another unnecessary, overly complicated hack. One that would 
> not
> work for binary data.
>
>> The receiver ought to be easier.  Just because you see a signal
>> that says you can stop receiving doesn't mean you have to fully
>> disable the receiver.  You can theoretically poll for the last
>> dribbles of characters a bit later (even after you start transmitting.)
>
> I am willing to bet my lunch, that the OP can do whatever it is he's 
> trying
> to do, without any handshaking lines. Of course, unless he (she?) tells us
> more about his project, you can speculate that he is talking to a
> prehistoric data terminal in a closely timed half-duplex system. :)
>
> Best regards,
>
> Vitaliy
>
> -- 
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
> 



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