Fire Pong/Interfaces/Puffer Control: Difference between revisions

From Nottinghack Wiki
Jump to navigation Jump to search
Mousetad (talk | contribs)
No edit summary
Mousetad (talk | contribs)
No edit summary
Line 9: Line 9:
* Serial bus params TBD, but probably slowish with error correction if possible because interference from sparkers:
* Serial bus params TBD, but probably slowish with error correction if possible because interference from sparkers:
** RS232 because Mouse has a bunch of MAX3232 converters
** RS232 because Mouse has a bunch of MAX3232 converters
** parity & ECC
** parity if possible
* Only control box writes to bus
* Only control box writes to bus
* Puffer events are sent in real time
* Only well-formed event packets are processed by puffers to prevent accidental firings due to corrupted packets
** Addressed by puffer ID
** Packet starts with two-byte "magic"
** With duration argument
** Packet ends with one-byte CRC8 of the rest of the packet (excluding magic)
** Multiple IDs in a single request?
* Events are processed immediately by clients
* Client addresses are 2**n values - there may be 32 clients on the bus at a time
* Multiple clients can be addressed in a single packet


=== IDs ===
=== IDs ===

Revision as of 10:54, 20 June 2016

Purpose

This interface defines how the main game control unit signals other parts of the system to set off the various puffers in the system.


Requirements

  • All puffers on a serial bus, each with ID mask (see below)
  • Serial bus params TBD, but probably slowish with error correction if possible because interference from sparkers:
    • RS232 because Mouse has a bunch of MAX3232 converters
    • parity if possible
  • Only control box writes to bus
  • Only well-formed event packets are processed by puffers to prevent accidental firings due to corrupted packets
    • Packet starts with two-byte "magic"
    • Packet ends with one-byte CRC8 of the rest of the packet (excluding magic)
  • Events are processed immediately by clients
  • Client addresses are 2**n values - there may be 32 clients on the bus at a time
  • Multiple clients can be addressed in a single packet

IDs

  • Each puffer has an ID mask, which is:
    • a 32-bit unsigned integer (uint32_t from stdint.h)
    • little endian
    • mask with a single bit set, i.e. 0x00000001, 0x00000002, 0x00000004, 0x00000008, ..., 0x80000000
  • Requests include an ID set, which is:
    • a 32-bit unsigned integer (uint32_t from stdint.h)
    • little endian
    • mask with one or more bits set e.g. 0x00003001, corresponding to ID masks 0x00000001, 0x00001000, and 0x00002000,

Event Types

  • Enumerated event type:
    • 0: STOP (requires manual reset)
    • 1: Spark/ignite only
    • 2: Puff sequence
    • other: undefined (do nothing)
  • 8-bit unsigned integer (uint8_t from stdint.h)
  • little endian

Durations

  • A time in milliseconds for a puffer solenoid valve to be open for
  • Typically 100 or 150 for small puffers
  • Between 100 and 2000ms for large puffers (?)
  • 16-bit unsigned integer (uint16_t from stdint.h)
  • little endian

Checksum

Because of the sparkers, we're operating in a noisy environment, so we need error detection so that we don't end up running too many sparkers at once (and causing too much current draw).

  • A checksum value is a 8-bit unsigned integer which is set the the CRC8 checksum of the other seven bytes of data in order, as calculated by the CRC polynomial X^8 + X^5 + X^4 + X^0.
  • Implementation from here

Events

  • Events are sent in real time and processed immediately by all puffer controllers on the bus
  • An event consists of an ID set, and Event Type, a Duration and a check byte
  • No acknowledgement is required - this is a broadcast only protocol

Example C code

   #include <stdint.h>
   
   typedef struct PufferEvent {
       uint32_t id_set;
       uint8_t  type;
       uint16_t duration;
       uint8_t checksum;
   } t_PufferEvent;