Easy GUI SPI Protocol

Easy GUI uses an ASCII communication protocol between the Easy GUI LCD Module (client) and your embedded device (server). The server must be an external device capable of SPI communications. Client messages are initiated either by timer events or by user input from the touch panel. Client messages are derived from compiled Amulet widgets stored in the data flash on the Easy GUI Controller Board. (See Widgets Document for more information.)
See Appendix C for a sample implementation of the server side.


SPI Header Pinouts (5.7" board only)

The SPI lines on the 5.7" board have been brought out from the Amulet Browser chip to the J6 header. The pin-out for the header is as follows:

If you wish to access the SPI lines directly from the Amulet Browser Chip, the pin-out for the chip is as follows:


Amulet Protocol

The communications protocol is half-duplex, with the Easy GUI client acting as master. The Amulet GUI can send five different types of messages, which are the same five types seen in the Amulet UART protocol:

If the message is valid, the server should either return the requested data (if a "Get" request) or simply echo back the request (if a "Set" or "Invoke" request).

Table 1 defines the five types of messages that can be sent between the client and the server. The valid range of variables and Remote Procedure Calls is 0-0xFF. The valid range for variable values returned from the external server (in response to the "Get" variable request) is also 0-0xFF. Since this is an ASCII protocol, it takes two bytes to send one-byte variables and RPCs. For example, the variable 0x1A would be transmitted as 0x31, 0x41, where 0x31 is the ASCII representation of the high nibble"1" and 0x41 is the ASCII representation of the low nibble "A".

 
 

Table 1. Flow charts for each of the 5 message types

Synchronization--As master, the client initiates all communications by sending a message to the server. Before sending any bytes, the master will pull the Slave Select line 2(SS2) to ground. SS2 should be attached to the server's SPI Slave Select pin. All valid messages from the client to the server start with one of four command bytes: [0x11], [0x12],[0x13],[0x14] or [0x15] -- these are considered the Client Start Of Message (CSOM) characters. NOTE: These four CSOM bytes ALWAYS signify the start of a message and they are not allowed in the body of any message. The only valid characters in the body of a message are: ASCII 0-9 (0x31-0x39), and A-F (0x41-0x46), except in the body of the "Get string" response, where all ASCII characters from ' ' -' ~' (0x20-0x7e) are valid. If the server receives any character other than those specified, the message should be considered errant, and the server should start over hunting for a new CSOM character.

All server responses must start with the counterpart of the CSOM character that began the message that is being responded to. The valid Server Start Of Message (SSOM) bytes are: [0x21], [0x22], [0x23],[0x24] or [0x25]. The body of the response message starts with a byte for byte echo of the command message. The echo is then followed by any optional response data (in ASCII format).

The master initiates the transfer by sending the CSOM out [the MOSI line] and the slave sends 0xFE [on the MISO line]. The GUI must receive the 0xFE in order for the communication to continue. After processing the CSOM byte (and loading the SPI data register with the SSOM), the slave must pull the GUI's interrupt line to ground to signify that it is ready to receive another byte. The GUI's interrupt line (IRQ) must be pulled to ground for at least 5 T states of the GUI controller. At 16 MHz the minimum grounding time would be 312ns. The IRQ line should be released before the GUI finishes sending the next SPI byte. 

Upon reception of the interrupt, the GUI will send out the next byte in the message as the slave simultaneously sends the value that was loaded into the data register after the last transfer, in this case the SSOM. The communication process continues in this format and will eventually come to a point where the master does not need to send any more "message body" bytes relevant to the current message, but the slave still needs to send bytes to the master to complete the message on its side; for instance, the byte value on a "Get" byte message. In order to accommodate the slave's need for more transfers and since the master initiates the transfer, the master will send out dummy bytes (0xFE) until the slave stops sending interrupts to the master. Following the final byte of the message, the slave should not send an interrupt to the master. That interrupt is meant to signify that the slave is ready for the next byte in the message and since the message is complete, there is no need for the interrupt. Once the message is complete, if there are any new messages that are queued up on the master side, the master will immediately start transmitting the next message. Flow charts of each message type can be viewed in the tables above.

As noted earlier, after receiving a byte of a valid message from the client, the server then has 200ms to respond to the message before the client times out. After 200ms, if there is no response, the client will consider the message dropped, move to the next message in the buffer, and then transmit any new messages. The client will NOT repeat a message after a TIME OUT. Remember, this could lead to erratic behavior.


Flow Diagram Example

The flow diagram of Table 2 depicts a sample communications session between an Easy GUI client and an external server that supports one byte variable and one string variable. Although this fictional server only supports byte variable 01 and string variable 01, Easy GUI supports up to 256 different byte variables, 256 different string variables, 256 different word variables and 256 different RPC's. The valid range for all the variables and the RPC's is 00-0xFF.

In this example, the server variables have the following values:
Byte variable 01 = 0x38
String variable 01 = "Abc"

We see in Table 2 the transfer cycle for a GetByte request as well as a GetString request. Remember during the course of the data transfers from the client to the server and the server to the client, data is transmitted and received simultaneously on both sides (i.e. in byte 4 of the GetByte command, on the client side, a 0xFE is sent out to the server while a 0x31 is received from the server). The interrupt field in the chart indicates whether or not the server needs to send an interrupt to the client, signaling that it is ready to transfer/receive again.

 


Table 2. Data flow diagram depicting several messages transmitted between the client and a fictitious server.



Amulet HTMLCompiler,
Copyright © 2000-2004 by
Amulet Technologies, LLC

Back to Welcome - Contact Amulet - Amulet Home