dennisgunia/split-flap-controller
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

updated documentation

Browse Source
This commit is contained in:
Dennis Gunia
2025-09-18 23:43:58 +02:00
parent 6e4a40b608
commit 838227b93a
1 changed files with 34 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
software/pc_client/doc/sfbus-proto.md
View File

@@ -1,39 +1,55 @@
# SplitflapBus protocol
## Terminology
* *main controller interface*: RS485 interface, connected to the mangment pc. Serves as bus master.
* *node*: Participant on bus. Can be a controller interface or an flap controller.
* *flap controller*: Microcontroller located in each flap module that processes requests and drives motor.
The SF-Bus is an RS485 based protocol. It has a singular master node and up to 32 client nodes per interface. It can address up to 65536 devices.
## Protocol implementation
The SF-Bus is an RS485 based protocol. It has a singular master node and up to 32 client *nodes* per interface. It can address up to 65536 *devices*.
The communication is always initiated by the master node. The start of a new communication is signaled by sending the start byte `0x2B` to the bus, followed by the protocol version and frame length. Each connected node now captures the entire packet. This prevents the node from falsely identifyng payload as a start byte if it contains the value `0x2B`.
The communication is always initiated by the *main controller interface*.
The start of a new communication is signaled by sending the start byte `0x2B` to the bus, followed by the protocol version (8-bit) and frame length (8-Bit). Each connected *node* now captures the entire packet, even if the adress does not match its own. This reduces the risk of the *node* falsely identifying payload data as a start byte if it contains the value `0x2B`.
Starting after the transmission of the payload length, the receiever counts the remaining packages and terminates the transmission at 0 bytes remaining.
After the transmission of the payload length, the receiver *node* counts the remaining packages and terminates the transmission at 0 bytes remaining. The data is written to a buffer for further processing.
In version 1.0 it expects the last byte to be `0x24`. If this is not the case, the transmission is marked as invalid and will not be processed further. The client will not send any response.
In version 1.0, the receiving *node* expects the last byte to be `0x24`. If this is not the case, the transmission is marked as invalid and will not be processed further. The receiving *node* will not send any response.
In version 2.0, the checksum is verified. If it does not match the payload, the transmission is marked as invalid and will not be processed further. The client will not send any response.
No stop-byte is expected.
In version 2.0, the checksum is verified. If it does not match the payload, the transmission is marked as invalid and will not be processed further. The receiving *node* will not send any response.
No stop-byte is expected. Version 2.0 also requires a timeout-check in the receiving function. This allows the bus to support hot-plugging, to cancel incomplete or invalid packages and reliably detect the start of a new package.
The communication is typically unidirectional. Lost transmissions are not detectable. The *flap controller* NEVER initiates a communication to the *main controller interface*. *node* to *master* communication only occures as a response to specific commands. This is specified in the command / payload documentation.
## Packet format (1.0)
```
+------------+-----------+--------+----------+----------------+-----------+
+---------------------------------+----------------------------------------+
| Header | Frame |
+------------+-----------+--------+----------+-----------------+-----------+
| Start-Byte | Protocol- | Frame- | Address | Payload | Stop-Byte |
| | Version | Length | | | |
| 0x2B | 0x00 | 1 byte | 2 bytes | framelegth - 3 | 0x24 |
+------------+-----------+--------+----------+----------------+-----------+
| 0x2B | 0x00 | 1 byte | 2 bytes | framelemgth - 3 | 0x24 |
+------------+-----------+--------+----------+-----------------+-----------+
The frame length includes the address and stop-byte
Therefor, the payload is framelegth - 3.
```
## Packet format (2.0)
*This i not yet implemented!!*
*This is not yet implemented!!*
```
+------------++----------+--------+----------+----------------+-----------+
+---------------------------------+----------------------------------------+
| Header | Frame |
+------------+-----------+--------+----------+-----------------+-----------+
| Start-Byte | Protocol- | Frame- | Address | Payload | Checksum |
| | Version | Length | | | |
| 0x2B | 0x00 | 1 byte | 2 bytes | framelegth - 4 | 2 bytes |
+------------+-----------+--------+----------+----------------+-----------+
The frame length includes the address and stop-byte
| 0x2B | 0x01 | 1 byte | 2 bytes | framelength - 4 | 2 bytes |
+------------+-----------+--------+----------+-----------------+-----------+
The frame length includes the 16-bit address and 16 bit checksum.
Therefor, the payload is framelegth - 4.
Checksum is based on MODBUS CRC algorithm. Check implementation in sfbus.c
```
More infromation regarding the crc algorithm: https://ctlsys.com/support/how_to_compute_the_modbus_rtu_message_crc/
## Payload format (Protocol Version 1.0 + 2.0)
The first byte of the payload is the command. This tells the controller
what to do or what data to expect next.