I am using a SCC port of a MPC8xx / MPC82xx as UART;
for the Linux UART driver I have configured support for hardware handshake.
Then I used a null-modem cable to connect the port to the serial port of my PC.
But this does not work. What am I doing wrong?
Answer:
There is absolutely no way to connect a MPC8xx / MPC82xx SCC port
to any DTE and use RS-232 standard hardware flow control.
Explanation:
The serial interface of the SCC ports in MPC8xx / MPC82xx
processors is designed as a DTE circuitry
and the RS-232 standard hardware flow control can not be used in the DTE to DTE
connection with the null-modem cable (with crossed RTS/CTS signals).
The RS-232 standard specifies a DTE to DCE connection and
its hardware handshaking is designed for this specific task.
The hardware flow control signals in the PC (and similar equipment)
are implemented as software readable/writable bits in a control
register and therefore may be arbitrary treated. Unlike that,
in the 8xx/82xx the handshake protocol is handled by the CPM microcode.
The meaning of the signals is fixed for the RS-232 standard with
no way for user to change it.
In widely spread DTE-to-DTE connections over the so called 'null-modem'
cable with the hardware flow control lines the meaning of
the handshake signals is changed with respect to the RS-232 standard.
Therefore this approach may not be used with the 8xx/82xx.
Question:
I succeeded in activating hardware handshake on the transmit side
of the SCC using the CTS signal. However I have problems in the receive
direction.
Answer:
This is caused by the semantics of the RTS signal as implemented on
the SCC controllers: the CPM will assert this signal when it wants to
send out data. This means you cannot use RTS to enable the transmitter
on the other side, because it will be enabled only when the SCC is
sending data itself.
Conclusions:
If you want to use 8xx/82xx based equipment in combination
with RS-232 hardware control protocol, you must have a DCE device (modem,
plotter, printer, etc) on the other end.
Hardware flow control on a SCC works only in transmit direction; when
receiving data the driver has to be fast enough to prevent data overrun
conditions (normally this is no problem though).