Firmware portfolio
RS-485 Switching mainboard
6 Channel mainboard, can be daisy chained to allow for 24 channels.
Main Goal: Simplify and ultimately avoid device address configuration on each device.
Since the target users of the system was not expected to be technically experienced in data communication.
And everyone that has been working with RS-485 handling multiple devices on this half-duplex communication medium, knows the risk of having multiple devices having the same address. It can be quite cumbersome to debug and locate a device with a wrong address. You might have multiple devices responding on the same address, resulting in buggy communication. But which device has its address set wrong ??
My take on this problem was to completely remove the need for system-users to assign addresses to each device. I decided to divide the address space (byte size) into chunks of 10 addresses allowing for 24 channels with 10 addresses on each channel (using 240 addresses), giving channels layout like 10-19, 20-29, 30-39 etc.
Next the decision was made to re-map each channel into address 10-19, so that each channel has the same local address space. Then we can simply have back-planes with hard-coded address inputs for each device-slot. Those back-planes could then have 1-10 slots, all depending on the requirement for the specific channel. No technical knowledge required, simply connect your device into an empty slot, and it automatically gets its own unique address, based on the current channel and the device position in the back-plane.
The firmware for the Switching mainboard handles the re-mapping of the addresses from etc. 45 to channel 4 & address 5 and back from the channel device address 5 to global address 45.
Next the firmware was also optimized for speed. The problem with relaying half-duplex messages, is that the speed decreases by 2 if we has to completely receive and validate a telegram before we can relay it. The proprietary protocol had a destination address and a source address, located in the 3 first bytes of the telegram. The firmware then uses this to start the mapping and relaying into channels when those 3 bytes was received, this greatly improved transmission speed.
Since the proprietary protocol included CRC checking and since we has re-mapped its destination address the CRC would no longer match, so the firmware is recalculating the re-mapped telegram CRC during relaying. In case of reception of a faulty telegram the firmware generates a faulty CRC at the end, so the error handling still works.
