RS-485 is a popular communications interface in industrial applications. I expect that ADI realises this, as they offer many chips specifically designed for driving cables with this interface.
How do the designers of the ADuC7060 and ADuCM360 suggest generating the enable signal for the RS485 transmitter/driver?
The problem of generating Tx Enable for RS485 is discussed in some detail in this webpage:
There would of course be some signal already within the UART state machine that keeps track of whether the transmitter shift register is running. It seems like in the ADuC706X and ADuCM36X chips, there is no way to multiplex out this signal to a pin, which is sad. The signal can be read by the microcontroller (as the TEMT bit of the COMSTA0), but it seems there is no way to generate an interrupt on this signal which makes it fairly annoying to use, because it must be polled in order to know when to disable the RS485 Tx. Polling status registers is not a good thing to have to do because it means during this time, the micro cannot be doing other things. If COMSTA0 is not polled continuously but only periodically, or if code that services other peripherals such as the ADCs are used during this time, then due to the increased latency, the RS485 Tx may not be disabled promptly, leading to lost or corrupted data received from the other devices on the RS485 bus.
Am I missing something, or is this really quite a chore to deal with on the ADuC parts?
Some chip manufacturers (like NXP and Exar) allow the user to bring out the appropriate logic signal from the UART state machine to a pin, which makes this job trivial as no further software is required:
In any new all-layer tape-outs of existing or new products, it ought to be fairly trivial for ADI to make it possible to mux out the transmit-enable signal (that would already exist within the UART) to an output pin. I suggest that ADI really should do this. A nice extra refinement would be to make this Tx Enable signal be routed by default (during the bootloader) to an output pin so that that an RS485 interface could be used to program the flash memory. (This will also require that the bootloader protocol can operate with half-duplex.) With care, this could be done in a way that does not upset any existing applications, even ones that already use the pin that is chosen to be the new Tx Enable output. At worst, the Tx Enable pin could be tristated by the ADuC on reset (and externally pulled up/down to the RX-mode state by the application circuit) until the ADuC bootloader receives some message from the PC software initiating the download and the starts driving the Tx-enable pin appropriately. This way the changes will not cause problems for existing users who have not considered the new Tx-Enable pin to be an output. Being able to flash the firmware over RS-485 would be very useful in applications where the ADuC is encapsulated within a waterproof housing, with high-voltage isolation on the existing RS-485 interface, and no easy way to get at the bare UART pins.
A less desirable way to assist with generation of the Tx Enable signal would be to at least permit interrupts to be generated when the Tx shift register is empty, as Infineon has done:
This is not as nice as a hardware pin Tx-Enable output as it still requires an ISR and could contribute latency, but it is better than polling.
Otherwise, I think the easiest solutions (where cost is not the primary consideration) might be (a) to use a different microcontroller with a good UART to handle the RS-485, and then to achieve the analog performance tack on an external ADC from ADI or LT, or maybe (b) use the ADuC for the ADC functions but send all serial output via a second chip that acts as a RS-232 to RS-485 converter (made from a PIC or AVR that has nothing else to do except generate the Tx-Enable signal).
As an aside, there might be a market for a RS-485 driver chip for use with microcontrollers having inadequate UARTs, that can look at the data signal from the micro, and generate its own Tx Enable signal inside the driver chip. The driver chip would either have to be programmed for a certain baud rate (external resistor setting?) or it would have to do auto-baud-rate sensing.
Does anyone have any other suggestions?