Protocol RS-232

This implementation is fit for UART and USB Virtual COM Port based connections from the host to the Propeller. Developers are urged to read through and understand Protocol Proper, even if they only intend to implement Protocol RS-232, since full understanding of the intent can not be gained otherwise.

Protocol RS-232 takes the nature of Protocol Proper and carefully translates it to fit the constraints of the RS-232 protocol. The resulting signals are, from the Propeller’s perspective, indistinguishable from that of Protocol Proper except in terms of timing. The same exact General Principles apply here as well.

Except for cases where special techniques are applied to overcome behaviors of typical host systems, it can be said that Protocol RS-232 is simply a translation wrapper around Protocol Proper.

Metrics

  • Baud Rate - 38,400 to 230,400 bps (115,200 recommended).
  • Data Bits - 8
  • Parity - None
  • Stop Bits - 1
  • Flow Control - Off
  • Delay Between Bytes - ≤ 90 ms

Protocol RS-232 Algorithm

The following describes the steps for Protocol RS-232 from the perspective of the host. The images afterwards contain additional vital information using actual annotated examples.

When implementing this protocol from scratch, try attempting only an identification operation (the first half of the algorithm) then the final steps (in the second half) will generally be easier to implement.

  • Reset the Propeller [Image RS1, Image RS2]
    • Set DTR/RTS (which drives Propeller RESn low) > 10 μs, then clear DTR/RTS
  • Wait for Post-Reset Delay [Image RS1, Image RS2]
    • 90 to 100 ms recommended
  • Transmit Calibration Pulses [Image RS3]
    • 2-bits encoded in 1 byte ($F9; %11111001)
  • Transmit Handshake Pattern [Image RS4]
  • Receive Connection Response [Image RS5]
    • 250 iterations of: transmit 2-bit Calibration Pulse as 1 byte ($F9), receive 1-bit Connection Response Bit as byte ($FE or $FF); see Appendix A
    • If Propeller does not respond to any Calibration Pulse, or Connection Response bit is invalid, abort communication; connection error
  • Receive Version [Image RS6]
    • 8 iterations of: transmit 2-bit Calibration Pulse as 1 byte ($F9), receive 1-bit Version Pulse as byte ($FE or $FF)
    • If Propeller does not respond to any Calibration Pulse, or if Version is bad, transmit Shutdown Command, abort communication; version error
    • Valid Propeller Version = 1 (8-bit value, received LSB-first)
  • Transmit Command [Image RS7]
    • 32-bits as multiple bytes; often Shutdown (ID), LoadRun (RAM) or ProgramRun (EEPROM); see Table G1
    • If transmitted Command is Shutdown (aka Identify), success; terminate communication
  • Transmit Size of Application in longs []
    • 32-bits as multiple bytes; value should come from word 9:8 of the application image, shifted right by 2 bits
  • Transmit Application Image []
    • Stream of bits encoded into multiple bytes
  • Wait for Acknowledge (RAM Checksum) []
    • Up to 250 ms of: transmit 2-bit Calibration Pulse as 1 byte ($F9), check for Ack ($FE) or Nak ($FF)
    • If no response before timeout or Negative Acknowledge (Nak) received, abort communication; transmission error or RAM verify error, respectively
  • If Command is LoadRun []
    • Success; terminate communication
  • Else, Command is ProgramShutdown or ProgramRun []
    • Wait for EEPROM Program []
      • Up to 5 s of: transmit 2-bit Calibration Pulse as 1 byte ($F9), check for Ack ($FE) or Nak ($FF)
      • If no response before timeout or Negative Acknowledge (Nak) received, abort communication; EEPROM program error
    • Wait for EEPROM Verify []
      • Up to 2 s of: transmit 2-bit Calibration Pulse as 1 byte ($F9), check for Ack ($FE) or Nak ($FF))
      • If no response before timeout or Negative Acknowledge (Nak) received, abort communication; EEPROM verify error
    • Success; terminate communication

The following images are actual logic analyzer captures of Protocol RS-232. The example system consists of a “host” computer whose USB-based serial converter device is connected to a Propeller. The host’s RS-232 baud rate is set to 115.2 k. The signals are illustrated from the host’s perspective but were captured from the Propeller side of the connection.

Identification Sequence

The first set of images demonstrates the identification process (Reset through Command) which covers the first half of the Propeller RS-232 Algorithm.

Image RS1 - Full Identification Sequence

Full ID RS-232.gif

This image shows a full identification sequence with Protocol RS-232. Signals rest high. Note the approximate 90 ms post-reset delay (after DTR/RTS’s low pulse) before host transmission begins (Host Tx). The following are zoomed-in views of this image.

Image RS2 - Reset Pulse

Reset Pulse RS-232 (zoom).gif

The host-driven Reset Pulse on DTR/RTS (when connected to the Propeller’s RESn pin) causes the Propeller to stop any activity and perform a boot sequence. The Reset Pulse is shown here followed by an approximate 90 ms delay before Host Tx communication begins.

Image RS3 - Calibration Pulses

Calibration Pulse RS-232 (zoom).gif

Approximately 90 ms after the rising edge of the Reset Pulse (DTR/RTS), Host Tx communication begins with Calibration Pulses. This is the host’s way of saying, “This is how I talk.” The same 2-bit calibration sequence described by Protocol Proper is actually communicated by Protocol RS-232 as a serial byte value of $F9 (%11111001), at 115.2 kbaud in this case. Note that the effective signal looks very similar to Protocol Proper’s Calibration Pulses and, with the General Principles in mind, translates to exactly the same data; a binary 1 and a binary 0 communicated as a low pulse (of width t), a spacer (high), and a second low pulse (of width 2t) followed by a spacer (high). Also note that the serial start bit itself (a low pulse signaling the beginning of a serial byte) is always a data bit as interpreted by Protocol Proper. Similarly, the stop bit itself (a high pulse marking the end of a serial byte) is always a spacer as interpreted by Protocol Proper.

Image RS4 - Handshake Pattern

Handshake RS-232 (zoom).gif

The Handshake pattern (the host-transmitted pattern of 250 bits) immediately follows the Calibration Pulses. This is the host’s way of saying, “I’m a qualified Propeller host trying to speak to a Propeller.” As with the Calibration Pulses, the 250-bit pattern matches that of Protocol Proper (looking at low pulses only). In this example of Protocol RS-232, binary 0 is expressed with serial byte value $FE (%11111110) and a binary 1 as serial byte value $FF (%11111111). Remember, the start bit of each serial byte is a data bit as interpreted by Protocol Proper. This serial stream translates to the same data as, and looks similar to, Protocol Proper’s Handshake. The contents of the Handshake pattern is described in Appendix A.

Image RS5 - Connection Response

Connection Response RS-232 (zoom).gif

The Connection Response (a Propeller-transmitted pattern of 250 bits) occurs right after the Handshake. It is the Propeller’s way of saying, “I’m a Propeller that hears and acknowledges the qualifications of the host.” After the last bit of the Handshake, the Propeller transmits one bit of the Connection Response for each Calibration Pulse pair it receives from the host. The host transmits 250 Calibration Pulse pairs (as serial bytes $F9) in order to receive all Connection Response bits; 1 bit per response byte. The host usually has a UART receive buffer that automatically fills with the Propeller’s responses; full bytes of $FE (meaning bit value 0) and $FF (meaning bit value 1). NOTE: The Propeller doesn’t set its Tx line (connected to Host Rx) to output until after the last correct Handshake bit is received. Some circuitry mistakenly treats this initially-floating signal as actual bytes received– this necessitates careful flushing of the host’s receive buffer to properly parse the Connection Response. The contents of this Connection Response pattern is described in Appendix A.

Image RS6 - Version

Version RS-232 (zoom).gif

The Version is an 8-bit value transmitted by the Propeller immediately after the Connection Response; 1 bit per byte (LSB-first) for every Calibration Pulse pair (byte) the host transmits. The host should parse the LSBs of the 8 response bytes into a single 8-bit value to validate the Version response.

Image RS7 - Command (Shutdown)

Shutdown RS-232 (zoom).gif

After Version is received, the host transmits the Command (the intent of the communication); in this case, Shutdown, aka Identify. The Command is a 32-bit value (LSB-first) encoded into multiple bytes (11 in this case). If the Command were other than Shutdown, communication would continue as shown in the images below.