Protocol 7.00 communication flows¶
Protocol 7.00 involves an active side and a passive side. At the beginning of the communication, the passive side is usually the calculator, and the active side is the client, e.g. a PC or another calculator.
When a flow isn’t currently in progress, the active side is allowed to send a command to the passive side. This command may start a flow where a “role swap” occurs, i.e. the active side becomes the passive side, and vice versa. At the end of said flow, the role are usually swapped again, so that the original active side becomes the active side again.
When required, the role swap is always initiated by the active side.
The communication schema is the following:
The different blocks are described in the following sections.
Note
If any packet is received with an invalid checksum, a specific flow takes place for the sender to be able to understand the situation and resend said packet.
This sub-flow is considered part of the “sending a packet” flow, and must be treated within this logic.
See Reporting invalid checksums for more information.
Note
In between any of the packet sending steps, if the side expected to send a packet takes too long to do so, a sub flow takes place to check if the other side is still present.
See Checking up on the link for more information.
Reporting invalid checksums¶
In case a packet has an invalid checksum, it may mean that the packet has been corrupted by the medium lying under the link. In such cases, a specific flow takes place so that the sender of the packet can resend the packet.
An example flow where the active side sends the corrupted packet is the following:
An example flow where the passive side sends the corrupted packet is the following:
Initiating the link¶
When opening a link to a calculator that hasn’t received any packets yet, the PC must initialize the link using this flow, which is the following:
The initial check packet is a check packet of subtype 00; see
0x05 – Check packet for more information.
Terminating the link¶
When closing a link to a calculator that we don’t plan on sending packets anymore, we are expected to terminate the link using the following flow:
See 0x18 – Terminate packet for more information on the terminate packet.
Checking up on the link¶
In order to detect a “deaf” passive side, the active side must run the following flow if inactive for more than 6 minutes:
The regular check is a check packet with the 01 subtype; see
0x05 – Check packet for more information.
If this flow is not run and the connection is active for more than 6 minutes, the passive side terminates the connection.
Confirming or rejecting overwrite¶
Some commands, such as 45 “Transfer file” (storage), may require overwrite confirmation in case the file already exists on the calculator. In such cases, the flow is the following:
The packets used in this sequence are the following:
The overwrite confirmation request is represented as a NAK packet with the
02subtype; see 0x15 – Negative acknowledgement (NAK) packet.The overwrite confirmation is represented as an ACK packet with the
01subtype; see 0x06 – Acknowledgement (ACK) packet.The overwrite denial is represented as a NAK packet with the
03subtype; see 0x15 – Negative acknowledgement (NAK) packet.Both the overwrite confirmation acknowledgement and overwrite denial acknowledgement are represented as an ACK packet with the
00subtype; see 0x06 – Acknowledgement (ACK) packet.
Transferring data¶
Say that an active and a passive side have agreed on a data exchange through commands, and have already swapped if necessary. In order to transfer data, the flow is the following:
Data packets are described in 0x02 – Data packet.
Note
Note that the number of data packets must be known in advance, since all data packets contain both the sequence number and the total sequence count, e.g. “packet 51/128”.
In order to know the number of packets an original buffer can take, due to escaping concerns, it is highly recommended to consider that all packets contain up to 256 bytes, except the last one that may contain less. For example:
500 bytes will be represented as 2 data packets (one of 256 bytes, one of 244 bytes).
512 bytes will be represented as 2 data packets (both of 256 bytes).
1055 bytes will be represented as 5 data packets (four of 256 bytes, one of 31 bytes).
Packet shifting¶
Packet shifting is a technique discovered in 2017 that makes data transfers faster. It consists in sending the next data packet before the acknowledgement for the previous one is received.
The flow becomes the following:
Warning
This technique comes with its risks, especially the fact that it renders the link non-recoverable in case of bad packet checksum while it is in effect, since the packet correction flow assumes that no “normal” packet is sent after the problematic packet (while we have already sent the packet that comes after in the sequence).
In order to mitigate such risks while still employing the technique, Cahute disables packet shifting on serial links, i.e. only enables it on USB and UMS (SCSI) links.
Requesting data transfer(s)¶
When requesting a file or some data generally from the calculator, the usual flow is the following:
This applies to several use cases, but an example one is the PC requesting a file from the calculator’s flash memory. The transfer request command for such a case is 24 “Request file transfer” (main memory), and the transfer command emitted by the calculator after the roleswap is 25 “Transfer file” (main memory).
Note
The transfer request can lead to multiple commands from the calculator, e.g. with commands such as 29 “Request transfer of all files” (main memory) that will spawn one command and associated data transmission by file in the main memory.
Requesting device information¶
While in the “requesting transfer” rationale, the flow to get the device information using command 01 “Get device information” is different from the usual solution applied for this case:
Note
This is likely to avoid a more complex flow with a roleswap, as described in Requesting data transfer(s), or because the aforementioned flow did not exist when this command was conceived.
Updating serial parameters¶
If the link is established on a serial medium, it is possible to negotiate different serial parameters with the calculator dynamically using 02 “Set link settings”, using the following flow:
The only elements that can be updated are the serial speed in bauds, the parity, and the number of stop bits (1 or 2).
The serial speeds are limited to the following speeds (or baud rates): 300, 600, 1200, 2400, 4800, 9600 (by default), 19200, 38400, 57600 and 115200 bauds.
Warning
Depending on the quality of the serial cable (or USB to serial cable / converter), higher speeds may cause more corruption to occur, causing a lot of resends and hence, being less efficient than lower baud rates.