Remote Programmable Unit serial Bus

The RPU_BUS has four twisted pairs in a CAT5 cable that includes RS-422 pairs TX and RX, an RS-485 pair  
DTR, and a pair used for ground

Image is the link to Forum.
RPU bus Idealized Philosophy

Shields for communication, they connect serial from a host computer to several embedded controllers over RS-422. An out of band RS-485 channel is used for management which allows switching from multi-drop to point-to-point. Note that in point-to-point bootloading between avrdude and optiboot (or xboot) has been working.
Programmable application boards have microcontrollers that are programmed with an open source toolchain (GCC). They have DIN Rail mounting options and pluggable terminal options. The idea is to have a host (e.g. Raspberry Pi) connect to one of the controller boards and use that to provide the toolchain for compile and firmware upload without having to expose a firmware update port to a network. It minimizes the network footprint (e.g. only SSH is needed).
Current loop sensors: 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 is a pulse extender for when a switch is closed. The output from these transmitters are sent over a 100 Ohm twisted pair (transmission line). Input capture hardware (ICP) is recommended to measure the pulse timing.
Driver boards. CL8 is used to select a sensor loop, K3 is used to latch solenoids, ICSP does SPI level shifting and has IOFF.
I offer my boards through Tindie I sell on Tindie Note: for my reference, Tindie's customer service is hello at tindie dot com.
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. For half duplex (e.g. RS485) the transceivers need to be controlled by the serial software, which needs to understand how a push to talk system works. Personally, I have no desire to make avrdude understand how to operate a push to talk system, fortunately when the RS-422 with automatic enable is placed into a point-to-point mode then avrdude can upload firmware without any changes. Once the RS-422 is back in a multidrop mode then the application firmware needs to know it should only talk when addressed or data will be scrambled. The host transmits a command to the microcontrollers from its general purpose serial UART. All the microcontrollers see the command and react accordingly. Provision is needed on the controller firmware to prevent multiple answers (collision). Image is the link to Forum. MultiDrop Philosophy Characters are sent out of the UART's in the normal fashion. LOW bits of the character output will cause the UART TX line to pull low from its resting HIGH state. The LOW will enable the transceiver driver and drive -3V on the multi-drop pair which is then seen by all the enabled differential receivers. In the resting HIGH state, the transceiver driver is off and the differential pair has 0V. Each end of the pair has a 100 Ohm resistor to prevent the signal power from reflecting back since the pair is a transmission line (the resistor needs to match its characteristic impedance). There are two transceiver chips that I know of which should work for this setup the ISL3172 and the MAX3085. These transceivers have built-in fail-safe biasing, that is they see everything on the pair that is higher than -50mV as a HIGH. Between -50mV and -200mV is undefined and bellow -200mV is a LOW. These devices will all see 0V on the pair as a HIGH. Is it worth it? I can tell you that the software is easier to write since I don't have to tell the transceiver anything (e.g. no push-to-talk). Also the default UART TX level (HIGH) turns off the transceiver, so I only use the battery when I am sending data. Additionally my fear of cross-conduction caused by having bad software that sets a few transceivers HIGH and then one set LOW is not an issue.

Copyright (C) 2017 Ronald S Sutherland