Modifying XDIR for RS485 Transceiver Control

[NDonal]

Hi there,
I have some hardware based around the 128DB32, with an RS485 Transceiver on USART1. (PC0 => TXD, PC1 => RXD) . Unfortunately this specific hardware has the TX enable / !RX enable pins hard wired to PC2.
I believe that HWSerial handles enabling/disabling Transmission and Receiving? and I've noticed that XDIR for HWSERIAL_1 is defined as PIN_PC3.
#define PIN_HWSERIAL1_XDIR PIN_PC3
For my specific hardware I would want to remap this PC2 which coincidently is currently what USART1 XCK is currently defined as.
#define PIN_HWSERIAL1_XCK PIN_PC2
I was wondering what the best method could be for using PC2 as the XDIR pin?
Thanks for any suggestions? :)

[SpenceKonde]

The hardware is improperly designed, and connects the RS485 pin to the wrong port pin.

On the DB32, the available USART mapping options are PA0-3 (XDIR on PA3) or PA4-7 (XDIR on PA7), PC0-3 (XDIR on 3), PF0-PF3 (XDIR on PF3), and PF4/5 with no XDIR/XCK mapping. Refer to table 3.1 I/O multiplexing and considerations.

PC2 is not an option for xdir. This is not implemented in software, it is implemented in hardware. The #define is only there in order to tell the software which pin needs to be set output when they have RS485 mode enabled.

Time to cut and jump for now and fix your design. Always double check table 3.1 I/O Multiplexing before you get the boards made. I've tried it both ways and the other way just doesn't work well.

[NDonal]

Hi, thanks for the clarification,
The board's designer, was using it with a custom protocol, so from what you said I assume they must have been toggling the enable manually there somewhere. Given I don't have access to the design files to make the change, I may have to try something similar. If I don't pass an option for .begin method and then use PC2 just as a digital pin, implementing control in software. Not ideal I know, :( do you see any pitfalls doing this?
Thanks for you're response :)

[SpenceKonde]

Uhhhhh... I see one suggestion and one pitfall deep enough to twist your angle.

First, suggest to do digitalWriteFast() to write the pin high or low efficiently, since you'll have it in lots of places. If you do that before the call to write() or print() you'll still have some guard time at the start without having to explicitly delay. digitalWrite() is much slower, but that time isn't even useful guard time because the write takes effect at the end not the beginning of digital

Second, the main pitfall i see is that you also need to release it at the correct time. You would want to do this in the TXC interrupt, except - the TXC interrupt is already defined and you'd get a duplicate vector error.

So after each send you need to somehow make sure that the TXCIF bit in USARTn.STATUS is 1, or you need to call Serialn.flush() (which simply polls that bit until it's set). TXCIF is set when there is nothing left in the transmit FIFO and the shift register has been emptied). A polling loop will exit with effectively no guard time on the tail end, if your controller needs some more (it should be spec'ed, how much time between last bit and releasing the TXEN pin or whatever that device calls it), you might need a delayMicroseconds(); before the digitalWriteFast() to turn the pin off, but doing delayMicroseconds() and digitalWriteFast() gives more predictable timing that digitalWrite(), which may work without the delay or may not depending on how long that pin takes to determine that there's no PWM coming out of the pin and it doesn't need to turn anything off. But delayMicroseconds(n); digitalWriteFast(pin,LOW); when pin, and n are compile time known foldable constants, will always take exactly n microseconds plus 1 clock cycle. (if n is not compile time known, you'll be surprised hear, delayMicroseconds is potentially markedly less accurate, whereas it's basically always as close as possible if you use constant argumets)

The tricky thing is that you can't look for when the buffer is empty - even before there was a 2 byte fifo (ie on classic AVRs). (and now the DREIF is set if there is at least 1 byte free in the FIFO), so that test is twice as useless as before. And you must not clear TXCIF Ever - there will be a plague of locusts over the land blotting out the sun, and the dead will rise from their graves! The gates of hell will swing open! The legions of hell will march upon the earth to bring an end! TXCIF is how the serial class knows whether it is transmitting. We usually do not enable the TXC interrupt - we only enable it in one wire half duplex mode - in this case, it is enabled, and RXC is disabled when we send. TXC int then will empty our RX buffer and reenable RXC int and then disable the TXC interrupt (instead of clearing the int flag. The only time we clear the intflag is in Serial.write() when we need to mark that the port is transmitting. If you were to, say, clear it, the next call to Serial.flush() would hang, for example, because as long as a port has been written at least once since it was initialized (setting the written bit), it is assumed that unless the TXCIF bit is set, it is currently sending data. And while serial.flush() is stuck in an infinite loop, the undead you unleashed will find you and eat your brains. And that's never a good time, you know? So never ever clear TXCIF yourself, only woe and misery will befall you!

[SpenceKonde]

Edited in additional details of the hazard, including that you must never clear TXCIF lest you expose yourself to demonic hoards and armies of brain eating zombies.