УДК 608.3
ORDER BYTE INDEPENDENT PROTOCOL OF ONE-DIRECTION COMMUNICATION
Gataullin R. R.
Ufa State Aviation Technical University, Ufa, Russia
This article describes in detail the universal transfer protocol, which has the ability to self–
configure the data format of the exchanging devices. A description of the possible types of
transmission is presented with references to the schedules of the package structure and the transfer
listing.
Keywords: protocol, self–tuning, packet, sending, transmission
In the development of microcontroller and other programmable systems in which there are
several devices, the question arises about the choice of channel and data transfer protocol between
them. At the same time, existing protocols are sometimes cumbersome and difficult to implement.
Another important disadvantage of existing solutions is the sensitivity to the presentation of data in
different architectures. This article presents an easy–to–implement transmission protocol with high
capabilities for expansion and a mechanism for determining the representation of the transmitted
data [1].
The concept of signature is used as the basis of the protocol. A signature is an identifier of an
action (called method or function) initiated by the package. The package, in turn, consists of the
parameters that characterize the action and the set of which is unique for each signature. A packet also
has a begin sign and an end sign, which should not be known in the data stream, as well as the length
of the parameters in bytes, which serve to identify and verify the packet. The absence of end and start
markers in the data stream allows you to use the transmission channel for several purposes, including
sharing with another protocol, or the same, but with modified tokens, without the need to physically
disconnect the device from the bus or use additional signal lines to assign the destination.
Figure 1. Package structure.
1. The marker of the beginning of the packet, chosen for reasons of invariance to the order of
bytes and bits, the probability of occurrence of which in the signal is small. Invariance is
necessary for the correct detection of a packet at the beginning of a transfer, when the data
representation of the transmitting device is not yet known.
2. The signature, the first byte of which has the value 0xAB (0b1010 1011) and is required to
synchronize the presentation of data (byte and bit order) of the transmitting and receiving sides
by determining the representation of the transmitting device. It is important to note that for the
operation of this mechanism, it is necessary that, during the transfer of the signature, the real
representation of the data in the device is saved. The second byte is the signature directly and
characterizes the composition of the parameters and / or the action initiated by the packet.
3. The length of the parameter area in bytes. Required to handle cases where parameters can
contain start and end markers. Due to the known packet length, such markers can be omitted.
As with the signature, the view must be saved.
4. Parameters (if they are necessary for this signature). Parameters can be transmitted in any
68
desired format defined by the signature. The byte order for each parameter can be adjusted, if
necessary (in
this case, the agreement on the parameters of the format must also be satisfied).
5. A packet end marker that is different from the start marker and intended to increase the
probability of detecting an incorrectly transmitted length. There is no need for representation
invariance, because by the time
the end marker is transmitted, the representation of the
transmitting side is already known, so the choice of value is not limited, on the other hand the
transfer must meet the requirements of the same length and signature transfer requirements,
namely, the transfer must be performed while maintaining. In place of this marker there can be
a hash sum of the packet.
From the structure of the packet, it can be seen that its minimum size is 12 bytes which is
necessary for implementation of the mechanism for determining the presentation and detection of a
packet in the data stream. At the same time, there are no special requirements for the parameters, in
particular, there are no requirements for the presence of start and stop markers in the parameter area,
the parameters can also contain a frame or packet forming the structure of another protocol.
Due to the presence of a test byte in the signature, it is possible to detect the order of bytes
within the parameter and the bits within the byte or nibble. At the same time, in order to make a
correct determination, it is necessary to uniquely detect byte 0xAB (0b1010 1011) and its variants
with inversion of the order of bits within byte 0xD4 (0b1101 0100) and within nibble 0x5D (0b0101
1101), in other words, there is no corresponding signature numbers, such Thus, the total number of
available signatures will be equal to 253. It is also possible to implement
the definition of bit
inversion, but in this case it is necessary to identify packets with inverted start and end markers. In the
case of bit inversion detection, the number of valid signatures is reduced to 250, since three more
combinations are possible: bitwise only inverting byte 0x54 (0b0101 0100), bit order inversion within
the byte and inverting 0x2B (0b0010 1011), bit order inversion within a nibble and its invert 0xA2
(0b1010 0010).
The protocol provides data transferring either by packets, when the value of the transmitted
array is known in advance (parameters, settings, queries, state transfer), or by streaming for data
whose length is unknown or infinite (for example, ADC readings). When streaming, a packet is first
transmitted — a token that initiates a streaming mode and specifies the transfer parameters (size,
sample format, etc.), after which the streaming begins until the next packet arrives. In this case, all
samples during streaming should satisfy the pattern defined in the signature for their correct
interpretation. Tokens at the beginning and end of the packet should not occur during streaming.
Figure 2. Packet and stream transfer modes
69
