libcasio/docs/user/link/seven.rst

Using protocol 7

You can communicate directly with your device on a link that uses protocol seven. This protocol is not linked directly to the file formats used on storage or main memories, on the contrary to the CAS protocols.

This interface hides you some of the horrors the protocol uses, such as the escaping method, but you know… it can't hide 'em all.

Packet representation

Everything starts with the packet representation:

A protocol seven packet, as an abstract object.

That packet can have several types:

A protocol seven packet type, as an enumeration with the following values:

Ask something to the passive device, and initialize a packet flow relative to the issued command.

Send data as a flow.

Swap roles between the active and passive device (but the device which becomes active has a very specific role defined by the previously issued command and its packet flow).

Check if there's an interlocutor, and initiate the connection by the way (as the passive device is not supposed to answer to any command until it has received a check packet and responded to it).

Acknowledge, i.e. say “I have received and understood your message” and, in case of a command, “I am willing to do what you're ordering me to”.

Send a screen capture while in screenstreaming. The name “ohp” comes from the original representation of such a mode, as the “overhead projector” mode.

Acknowledge negatively, i.e. say “I have received but not understood your message” or, in case of a command, “I am not willing to do what you're ordering me to”. Such a packet usually says a little bit more about what the error is about.

Terminate the communication from the active side, to which, before it is terminated, the passive side must acknowledge.

There are several check types:

The check packet subtype represents the context in which the check packet is sent:

The check is the initial check to see if there is a device right at the beginning of the communication.

The check is a timeout check, to see if the device is still there and processing the command or if it has been disconnected. This was made for serial lines where you could not see if there was still a device on the other end or not, whether on USB you can (but this type of check packets still exists on it).

There also are several error types:

The error packet subtypes represents the errors.

The default error type (probably unused?).

There was a checksum or timeout error, this packet is used for asking a packet resend. Please don't use this packet directly, and let the library manage this for you.

The server wants a confirmation, either an ACK packet of type casio_seven_ack_ow or an error packet of type casio_seven_error_dont_overwrite.

When the passive device sends casio_seven_err_overwrite, you can choose to say no by sending an error packet of this type.

This error type is the generic error type that can mean many things: invalid or unsupported command, invalid argument, etc.

When you try to create a file and the calculator hasn't got enough memory left, it sends this error and immediately terminates the connection (without the terminate packet).

There also are several acknowledge types:

The acknowledge type can be used in various contexts:

The normal acknowledge kind, accepts the command and report a successful execution or respond to check, data, terminate or role swap packets.

When the passive device has responded to a command with casio_seven_err_overwrite, the active device sends the passive device an acknowledge packet with such a subtype to confirm the overwrite.

Respond to a discovery command with device information.

Used to acknowledge a terminate packet.

There also are several terminate types:

The terminate type is the reason why the connection was terminated:

Normal termination.

The user has terminated the connection (by pressing AC on the calculator, usually).

Terminated due to timeouts or checksums.

In response to ow_terminate.