54 lines
5.5 KiB
Plaintext
54 lines
5.5 KiB
Plaintext
Communication flow description:
|
||
|
||
|
||
1.
|
||
Slave communication state is completely idle and rx gpio pin has exti awaiting for bitbang.
|
||
|
||
2.
|
||
When the Rx pin goes low (gpio exti), it shall start sampling at 5 bauds.
|
||
When the byte is received, it is verified that it equals 0xf1. If verification is passed, the huart should be initialized and the 9600 baud communication halted for a delay. If the verification fails, it returns to idle/awaiting bitbang.
|
||
|
||
3.
|
||
When the 9600 baud is enabled a handshake sequence will take place. The slave sends a sync byte, waits 10.5ms, then the keyword lsb, waits 10.5ms, and the keyword msb. After the keyword msb has been sent, it should schedule another handshake sequence to start after 43 ms. The handshake should be repeated for a maximum of 5 times before failing and the communication returning to idle.
|
||
After each time the three bytes of the handshake have been sent (sync lsb and msb), the master will have an opportunity to send an acknowledgement byte to end the handshake sequence. For advancing to the next state, the acked byte’s value should be equal to ~keyword msb.
|
||
|
||
4.
|
||
After the valid handshake has been completed, the slave should identify itself.
|
||
The identification will be a combined ascii string of data with lengths up to 64 bytes, sent in chunks in n packets.
|
||
These packets will respect the general packet structure and characteristics, described in the packets section.
|
||
The packets’ title will be 0xF6 which corresponds to CMD_AsciiData.
|
||
After each packet containing a chunk is sent, a CMD_Ack packet is expected, and when it is received, the next packet is sent. This repeats until all the data is sent. When all the data is sent and the last ACK packet is received, a final ack packet is sent and the next state is achieved.
|
||
|
||
5.
|
||
After all the initiation sequence is correctly done, the slave will be in a ready state, and the session will be alive until it reaches its deadline. The session deadline is kicked for 1000ms every time a valid packet is received.
|
||
|
||
In this state the master will be sending different types of packets that the slave should receive and answer accordingly.
|
||
|
||
If there are non valid packets received (unknown title or denied action), a NAK packet should be returned.
|
||
|
||
|
||
Packet based Protocol description:
|
||
Each packet is transmitted in the form:
|
||
[LENGTH] [COUNTER] [COMMAND] [DATA_0 ... DATA_N] [0x03]
|
||
|
||
The LENGTH byte defines the size of the logical packet excluding the end byte 0x03, and is calculated as the number of payload bytes plus two additional bytes for COUNTER and COMMAND. The COUNTER is an incrementing sequence byte used to keep synchronization between slave and master. The COMMAND defines the requested service or response type, and the DATA field is variable length depending on the service. The byte 0x03 is always used as packet terminator.
|
||
|
||
It may not need clarification, but a packet can be sent from either master or slave.
|
||
|
||
A key aspect of the protocol is the byte-by-byte acknowledge mechanism. Every byte transmitted by one side must be immediately acknowledged by the other side with its bitwise complement. In other words, for any received byte B, the acknowledge byte is ~B. For example, if the slave sends 0x10, the master responds with 0xEF. This acknowledge is required for LENGTH, COUNTER, COMMAND bytes and every data byte, except the important packet terminator byte.
|
||
|
||
Once a complete packet has been received and all bytes (except the packet terminator one) have been individually acknowledged, the receiving side processes the command and sends a packet-level response. This response is distinct from the per-byte complements and represents the application-level protocol behavior. The response packet itself follows exactly the same framing and byte acknowledge rules as the original request.
|
||
|
||
|
||
Implemented packets are:
|
||
CMD_ReadIdent -> Triggers a repeat of the ascii packets identification sequence.
|
||
CMD_WritesRam -> Returns variable values that are mapped to valid address requests. If valid returns ACK, else fails with NAK.
|
||
CMD_FaultCodesRead -> Triggers a chunk sending sequence of a dtc built stream awaiting ack packets between each packet containing a chunk and sends a final ack packet. It’s similar to the identification chunk sending.
|
||
CMD_LoginEeprom -> Compares login payload and if valid, unlocks implemented zones with a flag. If valid returns PACKET_CMD_EepromLoginResponse and awaits ACK, else fails with NAK.
|
||
CMD_WriteEeprom -> Checks requested write address and length is valid and unlocked. If valid returns CMD_WriteEepromResponse and awaits ACK, else fails with NAK.
|
||
CMD_ReadRom -> Checks requested read address and length is valid. If valid returns CMD_ReadRomResponse with the corresponding data as payload and awaits ack.
|
||
CMD_End -> Sends ack packet and terminates the session, returning to idle.
|
||
|
||
Special consideration:
|
||
As the byte by byte protocol is implemented in an embedded solution with a kline transceiver with the simpler huart setup, each transmitted byte is echoed through the rx and received instantly. This echo is the same value as the last sent byte and is received instantly upon transmission, and should not be confused with the acknowledged byte sent by the master, and should be discarded correctly. A simple comparison between the last transmitted byte and the currently received one is not enough as there are packets that start with length 0x03, and the echo detection would suppress this byte when comparing it when the last transmitted one (0x03 packet terminator). A better driver implementation strategy is expected.
|