Description
The PN532 reader supports serial, so it would be useful to support RS485 for longer distances. This issue is intended to collect some thoughts.
RS485 needs special transceivers that translate from TTL serial to RS485 and back. RS485 uses a differential signal over a twisted wire pair for a single direction. Easiest would be to have two transceivers at each end (TX and RX) and use two wire pairs for full duplex operation. More economical is to use a single wire pair for both TX and RX for half-duplex operation. Typically, a RS485 transceiver has a "driver enable" (DE) pin to put it into TX mode, so for proper operation transceivers should be in RX mode normally and switch to TX only when sending, and some care must be taken that only one is in TX mode at a time. This is typically done by making a single master in charge and having the slave only speak when spoken to, which seems would be possible using the PN532 protocol.
On the Beaglebone side, the DE pin can be driven directly by the beaglebone. The linux kernel even supports using the RTS handshaking pin for a serial port as a DE pin, meaning it is controlled by the hardware or low-level drivers directly, so the timing is very exact (i.e. DE switches on and off closely around the actual transmission). See https://www.kernel.org/doc/html/latest/driver-api/serial/serial-rs485.html These serial pins (RX/TX/RTS) are assigned to specific pins, see http://beaglebone.cameon.net/home/serial-ports-uart for a table (the rest of that page is outdated, though).
The PN532 does not support driving a DE pin unfortunately, so this would need some additional electronics to implement a DE-autodetection. In practice, this means DE would be asserted whenever the TX signal goes low, and then a timer (RC or 555) is used to keep it low for a little over 8 bit times after the last transmision. This means that the beaglebone must wait for some fixed time after receiving a message before sending a new message, but this should be easy to implement in software.
One challenge is that the PN532 will not wait for a while before replying, so that means the DE on the BBB-side should be disabled very quickly after the end of the transmission (user manual says an ACK follows within 15ms max response time, but does not seem to specify a minimum response time). If the BBB is still in TX mode when the reply starts, it will miss the start bit of the reply and the stream gets out of sync, which probably messes up the entire message (there is a 0x00 preamble byte that could be acceptable to drop, but if you miss the start bit, the next stop bit will look like a start bit and the entire message becomes garbled, hopefully resyncing again in the pause after the message...).