Will Honea wrote in a message to David Etheredge:

 WH> PMJI, but this thread grabbed my attention since I'm doing
 WH> about the same thing.  I may just be lucky, but the radio
 WH> modems I'm working with all implement a CTS reply to the RTS
 WH> assertion.  That handshake implies carrier stable so that I
 WH> can immediately begin stuffing the data.  The biggest
 WH> problem I have right now is to cleanly detect when all the
 WH> data has been transmitted in order to turn the line around
 WH> and receive.  This has gotten especially troublesome as I
 WH> may be servicing up to 4 9600-14.4k baud channels at once
 WH> and can't afford to poll for transmitter empty on the UARTs.
 WH>  Any good ideas on how to set this up?  It wouldn't be a
 WH> problem if I could assume 16550's on all channels but I have
 WH> to allow for 16450's and 8250's and they don't interrupt on
 WH> shift register empty.  So far, I'm resorting to blocking on
 WH> a timer after loading the last data byte then turning the
 WH> line on timer expiration but there's gotta be a better way. 

The principal constraint that I see is the maximum time allowed between the
end of actually transmitting data and when you must switch from transmit to
receive.  Blocking on a timer actually sounds like a very good approach,
provided that you check to see that TSRE is actually asserted at timer
expiration.

I am not clear if you are working at application level or device driver
level. If you are working at application level, you have 32 ms granularity
anyway, so your timing constraints will have to be quite relaxed.

A nice approach at device driver level might be to encapsulate the
interrupt handler for each channel such that a unit control block is
maintained.  The unit control block could include enough information to
determine whether the unit needs to be turned around, using an algorithm
something like this: if the main code has set the flag that said it is done
sending data, and if THRE is asserted, then set a flag that says this unit
needs to be unkeyed.  Then you could have an asynchronous daemon
implemented as a timer handler that runs through all of the unit control
blocks and, for each unit which is flagged to be unkeyed, checks to see if
TSRE is asserted.  This also has a rather significant benefit in that you
get a free watchdog system as a by-product.

You might even be able to simplify the logic from what I describe.  For
example, if you are guaranteeing that the UART will never be allowed to
enter an idle state while transmitting, then you could code the
asynchronous timer daemon such that it checks to see if both THRE and TSRE
are asserted, which would imply that it is safe to unkey; the only
exception would be right after the unit is keyed but before data has
started to be sent.

 WH> I played with a new line of modems last week that solve a
 WH> lot of problems.  They have internal buffers and do all
 WH> their own collision detection/avoidance, carrier control,
 WH> etc.

What are you using now?  What are you looking at using?

 WH> PLC's, you say?  I gotta dup this radio modem stuff on RTU's
 WH> using 6303 micro's (6800+ chips), so it's assembler on one
 WH> end, C++ on the other.  No wonder engineers go bald - we
 WH> tear it out as fast as it grows back.

One common trick with this sort of thing is to have modems that echo back
your transmitted data.  Since you know you are on a half-duplex link, you
just wait for the data to be received back and this guarantees that it has
been transmitted already.
 
-- Mike


---