All serial ports that I am aware of have two registers on the transmitter
side; transmit data register and a transmit shift register. The usual data
path is for the program to store the next byte to be transmitted into the
transmit data register. If it is the first byte in a frame (meaning that
the transmit shift register is empty), that byte will be immediately
transfered into the transmit shift register, the transmitter will be started
to shift the data out onto the Tx data line and a transmit data register
empty interrupt (TDRE) will be posted to inform the program that the
transmit data register is empty and ready to receive the next byte of the
frame.
Upon receipt of a TDRE interrupt, the program should either a) store the
next byte of the frame in the transmit data register, or b) if the last byte
of the frame has already been sent then the program should disable the
transmit data register empty interrupt and then wait for a transmit complete
(TC) interrupt.
When the transmitter shifts out the list bit of any data byte, it examines
the transmit data register to see if another data byte is waiting in the
transmit data register to be sent. If there is a byte waiting it is
immediately transferred to the transmit shift register, the transmitter is
re-started, and the next TDRE interrupt is posted.
The process continues untill the last bit of the last byte is shifted out of
the transmit serial register. When that happens both the transmit data
register and the transmit shift register are empty (the complete frame has
been sent out the Tx data port), and the tranmitter posts a transmit
complete (TC) interrupt.
In a half duplex implementation, you should wait for the TC interrupt before
turning the link around, else you risk losing part of the last byte of any
given frame. To turn the link around you should disable the transmitter,
enable the receiver, and then toggle the Rx Enable and Tx Enable bits on the
drivers.
There is some risk in tying the two driver enable bits together. Depending
on the propagation delays of the two enables, you may wind up with both
directions enabled at the same time, thus introducing bus transients and
some risk of a latch up conditions.
Note - The above is a simplified summary of the function of the SCI port on
the MC68332 but will be applicable to all compatible SCI ports in the
MC683xx family devices. Further detail is provided in the applicable
sections of your device's user manual. Look for a section titled something
like "Transmitter Operation".
Good Luck, Bob Smith
--- Avoid computer viruses, Practice safe hex ---
-- Specializing in small, cost effective
embedded control systems --
Robert L. (Bob) Smith
Smith Machine Works, Inc.
9900 Lumlay Road
Richmond, VA 23236 804/745-1065
bobsmith5@...
----- Original Message -----Show quoted textHide quoted text
From: "jgodiska2002" <jgodiska@...>
To: <68300@yahoogroups.com>
Sent: Friday, June 07, 2002 10:38 AM
Subject: [68300] 68376: RS485 half duplex setup
> Hello List,
>
> I need some advise on setting up a half-duplex RS485 channel using
> both the QSM's Serial Communication Interface and also the TPU's UART
> function. I have two serial ports on my circuit board, and I have
> already set up hardware for both. My driver chips have both Drive
> Enable and Receive Enable pins, which I have tied together. I am
> using PC6 to control the DE/RE line for the QSM's SCI port and PC5 to
> control the one for the TPU port.
>
> My question is this: Is there a status bit or some flagging
> mechanism I can use to say that when the 68376 is done transmitting a
> message, I can now safely change the state of the DE/RE bit and
> prepare to receive data? I have a concern about when a flag would be
> set compared to when the last bit in the data is shifted onto the bus.
>
> I am hoping to avoid having to use any kind of delay timer to switch
> from TX->RX or RX->TX.
>
> Thanks,
> Jim
>
>
>
> ---------------------------------------------------
> To unsubscribe from this group, send an email to:
> 68300-unsubscribe@yahoogroups.com
>
> To learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>