Remote Programmable Unit Bus

The RPU_BUS has four twisted pair that include a TX pair, a RX pair (TX/RX are RS-422), 
DTR pair (RS-485), and a ground pair in CAT5 cable. 

Image is the link to Forum.
RPU bus Idealized Philosophy

Shields with RS-422 full duplex communication (RX and TX) and a RS-485 half duplex out of band management channel. Solar powered programmable controller node, these boards have microcontrollers that are programable with an open source toolchain and a built-in solar charge controller. Pluggable terminals are provided for the application interface. Mezzanine headers are compatible with the shields. The boards are DIN Rail mounted. HT, MT, and LT are Capacitive sensors with Thermistors that make a timing pulse with a duty ratio that measures the thermistor and a width that measures the capacitor. OneShot acts as an analog pulse extender when a switch is closed. The output from these transmitters is sent over a CAT5 twisted pair (transmission line) as a current loop. Input capture hardware (ICP) is recommended to measure the pulse timing. CL8 is used to select a sensor loop to power, K3 is used to latch solenoids, ICSP does level translate and has IOFF.
A Host computer (e.g. a desktop with RPUftdi or a Pi Zero with RPUpi) connects to the transceivers which drive the differential pairs. The RX and TX lines from the microcontroller board(s) are also connected to the transceivers. The transceiver connection acts as a crossover (e.g. host TX to MCU RX, and host RX to MCU TX), although the pair names match the MCU side (that is the side I was looking at when I named them). Because the transceiver driver-enable is taken from the transmitted signal it is automatically activated. Most general purpose RS232 serial software (e.g. PySerial, picocom, avrdude...) can be used with this setup because the transceiver control is not needed. Half duplex RS485 transceivers need to be controlled by the UART core software, as well as understanding how a push to talk system works. Personally, I have no desire to make avrdude respect a push to talk system, but the RS-422 does need to change into a point to point mode when uploading firmware, and since RS-422 is multi-drop the application firmware needs to known that only one device can talk without scrambling the data. The host transmits a command to the microcontrollers as though sent on a general purpose RS232 serial bus. The microcontrollers see the command and react accordingly. A single host transmit is seen by multiple bare metal nodes so some provision is needed on the bare metal side to prevent multiple answers (collision). Image is the link to Forum. MultiDrop Philosophy Writing software for the bus is easy. When a character is sent out of a UART it will pull down the TX line that it is connected to, this will then turn on the differential transceiver that drives the multi-drop pair and copies the signal to all the connected differential receivers. The bus manager should probably allow one host to control the bus at a time. Common RS-232 software libraries should be fine to control the bus from the host side. On the bare metal side, the multiple devices can collide when replying but otherwise common RS-232 libraries should also work. My example software handles collision by using two characters for the address (e.g. "/0", "/1", "/2"...) sent after a newline. The first character ('/') is used to stop the output from all devices, that is they delay the echo of the first character. The second character is used as the address and starts the echo, at which time the first character is sent and then the second. The UART core I used for these examples is for a general purpose RS-232 serial UART and has a stdio-compatible stream interface. During UART initialization the UART stream is assigned to stdout and stdin which allows using printf() as one would with a C program on Linux.

Copyright (C) 2016 Ronald S Sutherland