#SpringCore Direct over Serial

#Overview

SpringCore Direct is a versatile protocol that allows the host to control the SpringCore device independently of its operating mode and independently of its communication interface (USB, BLE, Serial, …).

This chapter details the implementation of SpringCore Direct over the Serial interface, i.e. through a short RX/TX link at TTL/CMOS level, or through a standard RS-232 or RS-422 link using the approriate line driver. RS-485, that is half-duplex only, may be supported provided a few precautions are taken in the host application, yet the link remains point-to-point since the protocol does not provide any addressing scheme.

The higher level protocol is documented in its own chapter: Direct Protocol.

Controlling the device’s user interface (and many other features) is detailed in Direct Protocol : Control Class and operating the device in Smart Reader Mode in Smart Reader Operation : Protocol and API.

#Bitrate and communication parameters

The Serial implementation of the SpringCore Direct protocol uses the global bitrate and communication parameters assigned to the SpringCore’s UART.

On startup, default bitrate is 38400bps and default communication parameters are 8 data bits, 1 stop bit, no parity, no flow control. These settings may be changed at runtime using the SET_SERIAL_PARAMETERS instruction. Default settings may also be overwritten in configuration.

#Multiplexing with other protocols

All frames in the Serial implementation of the SpringCore Direct protocol start with 16 (hex) / 22 (dec), which is the ASCII SYN (Synchronous Idle) character.

Since the Serial implementation of the CCID protocol uses CD (hex) as start character, and the $SCRDR protocol uses 24 (hex) i.e. the $ (dollar sign) as start character. Therefore, it is easy to discriminate among the 3 protocols, so the SpringCore Direct protocol may be activated and used in parallel with one of the two others.

#Direct protocol over Serial

Every message starts with a constant START mark (SYN character), followed by a PCB (Protocol Control Byte), then the CLAss, the LENgth and the payload. The length is expressed on 2 bytes only. A 1-byte LRC terminates the message.

Byte	Name	Description
0	START mark	Constant ASCII SYN character (16 in hex)
1	PCB	Protocol Control Byte - see section “PCB” below
2	CLAss	Class of command or response
3-4	LENgth	Length of payload minus 1 (0000 = 1 to FFFF = 65536), MSB-first
5-N	Payload	Up to 64kB
N+1	LRC	XOR of bytes 1-N (all the preceding bytes, expect the START byte)

#PCB

Bit	Name	Description
7	Way	0: host to device 1: device to host
6	Channel	0 for bulk (command/response scheme) 1 for interrupt (event scheme)
5	Secure	must be 0 for plain communication
4	Header type	must be 0 (long header not supported on Serial link)
3-0	Sequence	Sequence number. Incremented by the host (modulo 16) and echoed by the device.

As a summary, allowed PCB values on a Serial link are

• 0x: host to device, command (same as BulkOut on USB)
• 8x: device to host, response (same as BulkIn on USB)
• Cx: device to host, event (same as InterruptIn on USB)

A PCB with a high-order nibble not in { 0, 8 , C } is definitively a protocol error.

#Rules for command/responses

#Half-duplex communication

All messages work as command/response pairs:

• the host sends a command (PCB=0x),
• the device processes the command and sends its response (PCB=8x).

The host SHALL NOT send a new command before it has received a response to the previous one, or a timeout has occurred (timeouts are defined in next section).

The device DOES NOT send a response without having received a valid command.

#Timeout

The timeout from end of command to beginning of response is fixed to 1000ms.

If the device is not able to terminate the execution of the command within 1000ms, it DOES send a response using the PROTOCOL Class and the TIME_EXTENSION_REQUEST Status.

The host SHALL then send a TIME_EXTENSION_ACK instruction or a CANCEL instruction.

The device DOES NOT send another response before having received either instruction.

#Rules for the events

#Enabling events

The device DOES NOT send events on the Serial line until events have been enabled in the SET_SERIAL_PARAMETERS instruction (this instruction also allows to change the bitrate of the communication).

In the parameters to the instruction, the host precise how the events are implemented. There are 2 modes: spontaneous transmission or using the /WAKEUP line and the HOST_EVENT_POLL instruction.

#Spontaneous transmission

If spontaneous transmission is selected, the device MAY send an event message anytime.

Since the Serial line is supposed to be full-duplex, this may take place indifferently:

• outside of any command/response pair,
• while the command is being received,
• while the command is being processed, i.e. between the end of the command and the beginning of the response.

The host SHALL be ready to handle event messages whenever they arrive, even if such event message immediately precedes or follows a response message.

#Using the /WAKEUP line

Using the /WAKEUP line makes it possible to operate over an half-duplex only Serial line (such as RS-485).

In this case, the device DOES NOT send any event message spontaneously. Instead, when an event is raised, the device DOES assert its /WAKEUP line.

The host SHALL then send the HOST_EVENT_POLL instruction to the device. The device’s response is the event message. The device DOES de-assert the /WAKEUP line when the event message has been transmitted.

By using this method, the host is sure to receive only one message at once.