GP-LOGIC

Introduction Architecture System Architecture Aplications Bus Query Cycle Master Software Architecture Firmware Architecture (PI units) Recepcion de comandos via puerto serie Detecting GPI activation Configuracion almacenada en FLASH Activacion/Deactivacion de GPOs Alarm Condition On-chip Timers and Virtual Timers Utilities Specifications Serial Communication Protocol Command General Format Setup Commands SETUP_GPIOS SETUP_MODES SET_DUR_GPO SET_DUR_GPO_DFLT Action Commands SET_ADDR SET_ALM SET_GPO_ON SET_GPO_OFF SET_RESET Query Commands GET_STATUS GET_SETUP GET_ADDR GET_VERSION GET_PROTO Alarm Codes Application Spec File Example Some Implementation details Master Software GPX-100 Series Firmware Program Structure Initialization Main Loop Virtual Timers GPP-112 Unit Installation Planing the Hardware Topology Selection and Placement of PI units The Serial Bus (RS-485) Preparation of PI units GPP-112 Preparation of the Configuration PC Preparation of the Master Linux Host Future Development Virtual GPIOs: Adding support for serial and networked protocols GP Panel Signal Relays

Content

A system providing user-programmable Logic between general purpose inputs (GPI) and outputs (GPO).

General Purpose Inputs/Outputs (GPIO) consisting of simple relay contact closures, is still of common use in Broadcast facilities. In some cases, a certain "logic" is desired between some GPIs and GPOs. The system presented here, GP-LOGIC, provides the means for doing that by allowing the user (engineer) to define that logic in terms of Boolean expressions.

Since we are not manufacturers, GP LOGIC will be provided as a kit: separate pieces that engineers need to put together and configure according to their needs. This manual provides all the information engineers need for successfully deploying and configuring a GP LOGIC system in their Broadcast facilities.

The GP LOGIC system relies on a centralized Linux host running the GP LOGIC Master Software. This computer communicates with different units by the mean of a 3 wires RS-485 bus. One of these equipment is a Parallel Interface Unit (PI) that implements the GPIO ports. Up to 14 devices can be connected to such a bus; this limit can be overcome by providing more buses fed by separate serial ports.

The Linux host computer can also be virtual if a device server equipment is used instead of computer physical serial ports. It is also possible to have two Linux hosts in a automatic fail over arrangement.

PI units can be of different sizes. Currently under development is the GPP-112 unit providing 12 GPIOs. Each port can be configured as either a GPI or a GPO. A suitable configuration is 8/4 meaning eight GPIs and 4 GPOs.

Each unit has a 4-bits address number set by jumpers in the unit hardware; this address must be unique within the same bus. Addresses 0 and 15 are reserved for special purposes.

A given GPO in any unit can be activated or deactivated based on a boolean combination of any given set of GPIs from any unit. This logic is set by the user in the Linux host as part of the system configuration in the form of "rules" written in plain text files.

GP LOGIC allows the existence of separate systems, isolated from each other in terms of GPIO logic. "Isolated" means that no GPO in one system needs to be activated based on the state of GPIs from other systems. This implies that "rules" in one system do not contain GPIs or GPOs from another system.

The configuration associated to a given system is called application. Rules and other configuration parameters recide in a plain-text file called application spec file (spec-file for short).

The Master Software creates separate processes for different applications to allow for concurrent execution. Since different applications run in separate processes, it is safe to suspend or restart an aplication (process) without impacting others. It is also possible to add new applications to the overal system without disturbing the execution of those currently installed, possibly taking care of crytical tasks.

If the application utilizes 14 units or less, a single RS-485 bus fed by a single serial bus will suffice. If more than 14 units are required, separated buses fed from separate ports can be installed, as long as no other application makes use of those buses.

The communication on the RS-485 bus is always initiated by the master (Linux host running the Master Software). In order for the master to obtain status from PI units, a round cycle of query commands needs to be issued on the bus. For each step in the cycle, the master sends the command to an (addressed) unit, then waits for the response before sending a command to the next unit.

In general, commands are not sent as they are produced. Instead, they are queued and sent at regular time intervals over the bus.

Two commands are noticeable:

   GET STATUS: Get GPI and Alarm status from addressed unit.
   GET ADDR  : Broadcast command to which each unit responses with its address.
               This command serves auto-discovering purposes.

GET ADDR is particularly interesting. Since it is a broadcast command, all units will decode it simultaneously; however, units can not be allowed to respond at once because that would cause collisions in the bus. The implemented solution is that each unit delay the response by 1 ms multiplied by its address, minus 1. Thus unit with address 1 will respond immediately, unit 2 will delay 1 ms, unit 3 will delay 2 ms and so on.

With 14 units in the bus (maximum permitted) it will take 14 ms for all units to respond. This figure imposes a lower limit to the query cycle step time. The implemented value is 20 ms. GET STATUS commands (and any other, by the matter) is sent every 20 ms. The complete cycle will take 280 ms in the worst case (14 units).

At 19200 baud, a GET STATUS command plus the response will take 3.25 ms in the worst case, so the tolerance to communication and processing delays is more than adequate.

NOTA:
-----
Otra posibilidad es hacer el query cycle "normal" de 5 ms, y solo hacerlo de 20 ms si el comando lanzado es GET ADDR. Se puede incluso renunciar a la idea de un query cycle fijo y dejar que cada comando tenga su propio "tiempo de espera" para la respuesta el cual se puede hasta calcular at run-time (en lugar de fijarlo por disenno).

The Firmware resides in the microcontroller program flash. Apart from code, it contains some constants such as the Firmware version that are exposed via query serial commands.

Some parameters can be stored in user FLASH memory via setup commands, such as the type of GPOs (LATCH or PULSE) and pulse duration.

The more demanding task for the Firmware is to decode incoming commands, take the appropriate action and generate the appropriate response back to the Master via serial bus.

    ALGUNAS CIFRAS PRELIMINARES

    La comunicacion serie en el Serial Bus (RS485) se efectua a 19200 Baud.
    Puesto que cada frame (byte) consta de 10 bits (start bit, 8-bits data,
    stop bit), resulta que la duracion del frame es aproximadamente: 0.25 ms.

    Los comandos son de longitud variable, pudiendo ser tan cortos como
    4 bytes. La longitud maxima permitida por disenno es 10 bytes. Algunos
    comandos causan respuestas cuya longitud maxima esta' tambien limitada
    por disenno a 10 bytes. Siendo asi, la maxima duracion de un comando
    y su respuesta es: 5ms.

    Puesto que el MASTER SOFTWARE esta' encuenstando el bus cliclicamente
    para conocer el estado de las unidades en ese bus, un ciclo completo
    toma, en el peor de los casos, 70ms.

    El PIC funciona con un reloj de 3.6864MHz cuyo periodo es 0.27uS.
    Como la mayoria de las instrucciones se ejecutan en un solo periodo
    de reloj, resulta que el CPU puede ejecutar aproximadamente 900 ins-
    trucciones en el tiempo que se esta' recibiendo un byte por el puerto
    serie.

    IMPLEMENTACION

    Todas las unidad estan conectadas al mismo SERIAL BUS y por tanto reciben
    por igual los comandos enviados por el HOST, esten dirigidos a esa unidad
    o no. El Firmware tiene que escuchar y traducir esos comandos antes de
    conocer si estan dirigidos o no a esa unidad; esto se determina por la
    direccion de destino contenida en el comando, la cual puede o no coincidir
    con la direccion configurada en la unidad.

    Los serial frames son recibidos en un UART. Por cada byte colectado en
    el UART, se produce una interrupcion cuyo ISR se encarga de coleccionar-
    los en un buffer de memoria.

    Mientras no se haya recibido el caracter STX (que encabeza cada
    comando), los bytes recibidos se descartan, es decir, no se guardan
    en memoria. Tan pronto como se recibe STX, se cae en un estado en
    el cual se interpreta el proximo byte como destination ADDR. Cuando este
    byte es recibido, se compara con la direccion de la unidad; si no
    coincide, la escucha se aborta cayendo en el estado inicial (espera
    de STX).

    Si ADDR coincide con la direccion de la unidad, el ISR comienza a
    colectar en memoria la secuencia de bytes recibidos, hasta leer
    ETX en cuyo caso da por terminada la lectura. Debe existir ademas
    un conteo de salvaguarda para evitar bloqueo en caso de no recibirse
    el caracter ETX, en cuyo caso se caera' en estado de alarma.

    Notese que la recololeccion de bytes en el UART es concurente con
    la ejecucion del programa y que esto es un periodo de tiempo bastante
    largo, suficiente para ejecutar unas 900 instrucciones. Es solo despues
    que el byte ha sido colectado en el UART que se llama el ISR via inte-
    rrupcion. No obstante, la ejecucion del ISR debe ser breve limitandose
    tan solo a lo dicho anteriormente.

    Una vez aceptado el comando, se llama a una rutina INTERPRETER como
    resultado de la cual puede, quizas, producirse el envio de una
    respuesta desde la unidad via puerto serie. Esta rutina INTERPRETE
    es interrumpible, de modo que se pueden ir recibiendo bytes por el
    puerto serie, tal vez no dirigidos a esta unidad, o quizas comandos
    dirigidos a ella (irlos colectando en memoria) mientras que el comando
    anterior esta' siendo decodificando por el INTERPRETER.

The Firmware monitors GPIs status as part of its main loop. If a change is detected and it is stable, it is written to a variable (GPI_STATUS) that will be used by the Interpreter Semantics later on to generate responses to GET STATUS serial commands.

    En el FLASH del microcontrolador se almacenan ciertos parametros como
    resultado de SETUP COMMANDS enviados por el MASTER SOFTWARE. Antes de
    recibir dichos comandos, esos parametros se inician con valores
    por defecto.

    Dichos parametros son:

    * Direccion de cada GPIO (GPI or GPO) --> default: all GPIs
    * Modo de cada GPO (PULSE or LATCH)   --> default: PULSE
    * Pulse duration de cada GPO configurado en modo PULSE. --> default: 250ms
    * Default PULSE duration. --> default: 250ms
    * Whether the unit has been setup via SETUP command. --> default: false

    Los GPOs se activan o deactivan individualmente como respuesta a ACTION
    COMMANDS enviados por el MASTER SOFTWARE. Una vez recibdo el comando,
    el Firmware debe producir la activacion en concordancia con al modo en
    que ese GPO esta' configurado.

    Pueden encontrarse discrepancias (errores) como, por ejemplo, intento
    de activar un GPIO configurado como GPI. En tales casos, el Firmware debe
    caer en condision de alarma.

    La "condision de alarma" es una variable de 8-bits en memoria cuyo con-
    tenido representa un ALARM CODE. Un valor cero indica que no hay condicion
    de alarma. El ALM LED en el front panel de la unidad se ilumina siempre
    que el contenido de esa variable es diferente de cero.

    Anomalias detectadas por diferentes rutinas del Firmware son reportadas
    como un "alarm code" (pertinente) escrito sobre esa variable. El Firmware
    no se detiene ni bloquea por una condision de alarma, simplemente la
    reporta de la menera que hemos explicado.

    De una condision de alarma solo se puede salir de las siguientes maneras:

        * Hardware Reset
    * Comando CLR ALARM enviado por el MASTER SOFTWARE.
        * If code is ALM_NOSETUP, a successful SETUP command clears the alarm condition.

    Estando en alarm condition, si se produce una segunda condision de alarma con
diferente codigo, el mismo es sobre-escrito, perdiendose el anterior.

Virtual Timers are implemented in code to overcome the limited supply of real timers provided by the microcontroller. Virtual Timers are triggered by real timers.

In addition to the Master Software, the Linux host is equipped with utility programs to help in the configuration process.

Some other utilities are meant to test and configure certain units alone while connected via RS-422 to a Configuration PC (Linux).

Examples of utilities are gpsim, a simulator to test spec-files in cold, and gpconfig, a tool to configure isolated units via RS-422.


  

This section specifies the protocol employed to communicate Parallel Interface units (PI) with the Master Linux host. This is made by the mean of a 3-wires RS-485 bus using the following communication parameters:

    19200-N-8

Each unit has an 4-bits address number ranging from 1 to 14 (values 0 and 15 have special meanings). This address must be unique within the same bus. Connecting more that 14 units is possible by placing them in separate buses.

The communication is made based on serial commands sent by the Linux host, some of which require a serial response from the unit back to the host.

Commands fall into the following three groups:

    * Setup commands: Establish unit configuration (stored in unit's FLASH memory).
    * Action commands: Cause immediate actions such as activating a GPO.
    * Query commands: Obtain information from the unit such as status of GPI inputs.

Communication is always initiated by the host. Updated status from all units is obtained by poling the bus in a cycle with query commands.

    All commands are encoded in ASCII. Some data represent Hex number
    also encoded in ASCII; for example the hex number 1F would be
    transmitted in two bytes: "F" then "1". If the Hex represents a bit-map,
    its least significant bit corresponds to GPIO-1.

    Multibyte words are transmitted least significant byte first.

    The general command format is as following:

        STX ADDR CMD [ ARGS ] ETX

    where
    
        STX     is the ASCII start-of-text control character.
        ADDR     is the address of the intended unit. This is given
                as a one-digit Hex number (1 byte).

        CMD     is the name of the command (1 byte).
        ARGS    is a sequence of argument bytes, if applicable.
        ETX     is the ASCII end-of-text control character.

    Action and setup commands do not cause any response from the unit back
    to the host. Query commands cause a response from the unit in the following
    format:

        STX ADDR ALM [ DATA ] ETX

    where
    
        STX     is the ASCII start-of-text control character.
        ADDR     is the address of the unit being responding.
        ALM     is the alarm code in the unit (1 byte). "0" means no alarm
                        condition.

        DATA     (if applicable) is a sequence of bytes which format and
                content varies depending of the command being responded.
                ETX      is the ASCII control character end-of-text.

Address "0" is reserved for SETUP commands. The unit Firmware will ignore setup commands
and possibly raise an alarm condition if a setup command is received while the address
configured in the unit is other than zero.

Address "F" means: broadcast. Commands sent with this address will be processed for all
units with disregard of their programmed address.

Broadcasting is restricted to the following commands, resulting in error otherwise:

    SET_ALM
    SET_RESET

Units need to be setup to establish the direction of GPIOs (GPI or GPO) and GPO modes (PULSE or LATCH). Setup commands are issued by the gpconfig program running at the Configuration PC to which the unit must be connected via serial port (RS-422), during an initial setup session prior to put the unit in service.

The unit will not accept setup commands if its address is other than zero. Consequently, all setup commands must be issued with ADDR = 0h, causing an alarm condition otherwise.

The configuration is stored in unit FLASH. If no setup command is ever received, default values are set depending of the unit model. Some units can be designed to remain in alarm condition until the CONFIG GPIOS command is received; others can be designed to auto-discover GPIO directions.

GPO modes are the following:
        
  PULSE: When fired, activate for a short period of time, then deactivate automatically.
  LATCH: Once activated or deactivated, remain in that estate until another command estate to change.

Setup commands are the following:

Establishes GPIO directions (GPI or GPO).

CMD: 'c'
DATA:    

Data is a Hex bit-map of GPIO directions (1 for GPI, 0 for GPO). The number of bytes depends on unit size; for example, it will be 4 bytes for GP-116 units because those have 16 GPIOs.

Setup GPO modes (PULSE or LATCH).

CMD: 'm'
DATA:

Data is a Hex bit-map of GPO modes (1 for PULSE, 0 for LATCH). Bit positions represent GPIO numbers, not necessarily GPOs. Bits corresponding to GPIs will be ignored by the unit's firmware.

Set activation time for given GPO in mode PULSE.

CMD:    'd'
DATA:    GPO DUR

where GPO is the GPIO number in Hex (2 bytes) and DUR is the pulse duration in Hex representing miliseconds in increments of 50 (2 bytes); for example DUR="05" means: 250ms.

If DUR is zero, default PULSE duraction time is assumed.

Overwrite firmware default activation time.

Pulse duration set by this command applies to all GPOs configured in pulse mode, overwriting the default duration established by the unit firmware.

CMD: 'D'
DATA: DUR

where DUR is the pulse duration in Hex representing miliseconds in increments of 50ms (2 bytes).

If DUR is zero, the command is ignored.

Establishes the unit address.

In some units, address is set by DIP switches or jumpers, in which case this command takes no effect. Some other units require the address to be set with this command.

CMD: 'A'
DATA: address (Hex)

Establishes an alarm condition (code) in the unit forcing the ALARM LED to illuminate.

CMD: '!'
DATA: alarm code (1 byte)

Code zero means no alarm condition, so asserting this command with argument zero effectively clears the alarm condition turning the ALM LED off. This can also be done using address Fh (broadcast) to clear all units at once.

Broadcasting an alarm code other than zero is illegal resulting in error.

Activates given GPO.

CMD: 'G'
DATA: GPO number in Hex (2 bytes)

Deactivates given GPO.

CMD: 'g'
DATA: GPO number in Hex (2 bytes)

Deactivates all GPOs in the unit and clears alarm condition.

CMD: 'r'
DATA: none

CMD: 't'
DATA: none

RESPONSE:

The unit responds with a bit-map of GPIO states (1 if active, 0 if not active). The number of bytes depends of the unit model; for example, a unit with 16 GPIOs will response with four bytes of data: each one being a Hex digit (encoded in ASCII) equivalent to 4 bits.

Bit positions in the bit-map represent GPIO numbers (either GPIs or GPOs, depending of unit configuration). The least significant bit of the first byte corresponds to GPIO-1 and so on.

Reads the current setup as stored in the FLASH.

CMD: 's'
DATA: none

RESPONSE:

The unit responds with the following sequence of bytes:

  * Unit address --> 1 bytes

  * Unit GPIOs count --> 2 bytes.

  * Bit-map of GPIOs directions (1 for input, 0 for output) --> 1 byte for every 4 bits.

  * Bit-map of GPO modes (1 for PULSE, 0 for LATCH). Bits for GPIO numbers configured as
    input are set to 0. --> 1 byte (Hex) for every 4 bits.

  * Default PULSE duration in 50ms increments --> 2 bytes.
    
  * PULSE duration in 50ms increments of each GPO configured as PULSE with no default
    duration.
    --> For each: 2 bytes GPO number, 2 bytes duration.
  

This is a broadcast command (ADDR="F"). Units respond at random intervals to avoid collision.

CMD: 'a'
DATA: none

RESPONSE:

No data is present in the response frame.
This command can be used for auto-discovered purposes.

Get Firmware version.

CMD: 'v'
DATA: none

RESPONSE:

Response from the unit contains three Hex numbers (6 bytes) representing the mayor, minor and built number respectively (2 hex digits each) of the Firmware version. First byte (least significant) is the built number.

Get protocol version supported by unit Firmware. Protocol version consists of a single decimal digit.

CMD: 'V'
DATA: none

RESPONSE:

Response from the unit contains a two digits Hex number (2 bytes) representing serial protocol version.

Alarm code is a Hex digit (1 byte) generated by the unit Firmware to characterize the alarm condition.

Alarm codes are the following:

0    ALM_NONE     No alarm condition exists
1    ALM_INIT     Firmware is initializing
2    ALM_NOSETUP  Get-status command received while unit is not setup
3    ALM_NOETX    No ETX char received before timeout (broken frame)
4    ALM_NOTAGPO  Attempt to fire or setup a GPI instead of a GPO
15   ALM_PING     Used for diagnostic purposes
  

;--- This is an example of Application Spec file ---
;
; The file is devided into sections. Each section starts with
; the section name (a keyword preceed by #)
;
#NAME MC  ; This name (MC) is referred in log files and error messages.

#MACROS
;
; Macros are used-defined symbols used for convenience in the file
;
BUS        /dev/ttyS1        ; Serial port feeding the RS485 bus
FOX1    S1_NW + S1_NW2    ; Either NW or NW2 taken in Switcher 1
FOX2    S2_NW + S2_NW2    ; Either NW or NW2 taken in Switcher 2
TALLY    TALLY_SGN | TALLY_VIP ; Virtual parallell of two GPOs

; GPIs can be referrenced ir rules by "GPI number"
; but it is more convenient to define macros for them. Same for GPOs.

; GPIs
;
S1_NW        GPI FOO 1    ; UTAH SWR GPO-11 fired when NW is taken
S1_NW2        GPI FOO 2    ; UTAH SWR GPO-12 fired when NW2 is taken
S1_PROD        GPI FOO 3    ; UTAH SWR GPO-13 fired when ST1 is taken

S2_NW        GPI FOO 4    ; UTAH SWR GPO-11 fired when NW is taken
S2_NW2        GPI FOO 5    ; UTAH SWR GPO-12 fired when NW2 is taken
S2_PROD        GPI FOO 6    ; UTAH SWR GPO-13 fired when ST1 is taken

EV1_NW        GPI FOO 7    
EV1_NW2        GPI FOO 8    
EV1_PROD    GPI FOO 9

EV2_NW        GPI FOO 10
EV2_NW2        GPI FOO 11
EV2_PROD    GPI FOO 12

ER_EV1        GPI BAR 1    ; EV1 taken in ER 4X1 RTR
ER_EV2        GPI BAR 2    ; EV2 taken    in ER 4X1 RTR

AIR_PLY1    GPI BAR 3    ; S1 taken in AIR 4X1 RTR
AIR_PLY2    GPI BAR 4    ; S2 taken in AIR 4X1 RTR
AIR_PROD    GPI BAR 5     ; PROD taken in AIR 4X1 RTR
AIR_ER        GPI BAR 6    ; ER taken in AIR 4X1 RTR

;
; GPOs
;
SPL            GPO BAR 9    ; Enable FOX Splicer
TALLY_SGN    GPO BAR 10    ; "On Air" sign
TALLY_VIP    GPO BAR 11    ; "On Air" label in VIP
VT7_CUT        GPO BAR 12    ; RLY cutting signal ER-->VT7

; Each unit takes in own section.
; Following the section name is the unit address in decimal.
;
#UNIT 2 ; RK-T28

name     FOO
config     12/0
port    BUS

#UNIT 3 ; RK-MC06

name         BAR
config         8/4
port        BUS
gpo default    latch
gpo 11         pulse
gpo 12         pulse
pulse default   250
pulse 12     1000


#RULES

FOX1 & AIR_PLY1 = SPL    
(S2_NW + S2_NW2) & AIR_PLY2 = SPL    

(EV1_NW + EV1_NW2) & ER_EV1 & AIR_ER = SPL
(EV2_NW + EV2_NW2) & ER_EV2 & AIR_ER = SPL
    
S1_PROD & AIR_PLY1 = TALLY
S2_PROD & AIR_PLY2 = TALLY
EV1_PROD & ER_EV1 & AIR_ER = TALLY
EV2_PROD & ER_EV2 & AIR_ER = TALLY

; The following rules are to avoid video/audio feed back
; from Air (ER) to production Switcher when VT7 is taken
; in the prod. switcher and production is taken somewhere
; in the ER path.

EV1_PROD & ER_EV1 = VT7_CUT
EV2_PROD & ER_EV2 = VT7_CUT

The GPX-100 Series of PI units is currently under development. Model numbers have the following format:

  GPa-1nn[-x]

where
  a    is a single capital latter indicating the equipment type
  1    names the series. It would be 2 for a 200 series.
  nn   is the number of GPIOs present in the unit.
  x    is an optional extension number.

Example:
   GPP-112

I this example, the second 'P' indicates Parallel Interface Unit.

Althogh the Firmware is different for every model, the program structure is basically the same. It comprises the following blocks:

* Initialization
* Main Loop
* Virtual Timers
* UART Interrupt Service Routines
* Command Interpreter
* Command Semantics

After disabling interrupts, the initialization routine writes the alarm code ALM_INIT in memory and illuminates the ALARM LED signaling that Firmware initialization is taking place.

The initialization routine continues to configure on-chip resources and memory variables, including UART, on-chip timers and Virtual Timers.

As mentioned earlier in this manual, GPIO configuration is stored in FLASH as results of a SETUP GPIO serial command. Also in FLASH is a "setup bit" telling whether or not that command have been ever received. If that bit is set, the initialization routine configures GPIO ports as indicated in FLASH, putting all GPOs in no-activated status; otherwise, all GPIO ports are configured as inputs.

Before ending, the initialization routines writes the alarm code ALM_NONE. If the "setup bit" is clear, it also turns the ALARM LED off; otherwise, it let it on signaling that the unit has not been setup yet.

Initialization ends by enabling interrupts before falling into the Main Loop.

The main task of the Main Loop is to monitor and debounce GPI inputs. When a valid (stable) change is detected, the status of all GPIs is saved into memory variable GPI_STATUS as a bit-map. This variable will later be used by the Command Semantics routines to generate responses to GET STATUS query commands.

The Main Loop is structured as a Finite State Machine (FSM).

Being in state 1, it reads the GPIO ports masking the GPOs to obtain a bit-map of GPIs which is compared with a temporary variable GPI_TMP. This variable had previously been initialized as zero (no active GPIs). While no change is detected, the FSM remains in state 1.

As soon as GPIs reading mismatches GPI_TMP, the FSM starts a Debounce Timer and changes to state 2 in which it will remain indefinetly.

The timeout routine of the Debounce Timer will simply set the FSM state to 3. Being in this state, the FSM will read the GPIs port again and repeat the comparison. A match means that the now debounced input is statable, so GPI_TMP is copied to GPI_STATUS, and returns to initial state 1. A mismatch means that the reading is not stable; in this case, the Debounce Timer is started again and status is changed to 2 to give it another try.

The number of tries is limited, but that is not part of the FSM; instead, a counter is checked against a literal DEBOUNCE_TRIES_MAX.

A Virtual Timer consists of these parts:

* Memory variable T[i] representing a count down.
* Literal COUNT[i] to initialize T[i].
* Time-out routine.
* Enable flag.

There are two types of Virtual Timers:

* Free-Running:
  When T reaches zero, it is loaded again with COUNT so the count down restarts automatically.

* One-Time:
  When T reaches zero, the Enable flag is cleared automatically.

All Virtual Timers are initialized during the Initialization routine by copying COUNT[i] into T[i] and setting the enable flag to zero (disabled).

The interrupt service routine TMR_ISR of the on-chip real-timer decrements at once all Virtual Timers T's of those that happen to be enabled.

TMR_ISR also checks if T[i] equals zero, in which case it reloads the timer (T[i]=COUNT[i]), then call the TimeOut[i] routine. If it is of type One-Time, it clears the Enable bit of that Virtual Timer before calling TimeOut[i] so the Virtual Timer runs only once.

The TimeOut[i] routine implements the useful work. From the client code viewpoint, that routine takes the place that otherwise would occupy the Interrupt Service Routine of a real timer.

Client code activate or deactivate Virtual Timers at will by setting or clearing their Enable flags, respectively.

In a complex scenario you will have various applications (unrelated GPIO sources) in your facility. For each application, a number of equipment provide GPOs while others receive GPIs from the former. It is also likely to have some equipment providing both GPI and GPOs but that is irrelevant to our purposes.

Equipment conforming a given application connect their GPIOs to units attached to a single BUS. In the unlikely case that more than 14 units would be required for a particular application, more buses can be assigned to it. What you can not do is to mix units from different applications in the same bus.

The first step in designing your system would be to define the hardware topology.

Units must be close to equipment they connect to, because this simplifies wiring. You must allocate units with suitable configurations near those equipment. For example, if your are implementing a Production Tally System, a unit with just GPOs would be placed near the camera CCUs, a similar one near tally-capable video monitors or multiviewers, and some units with just GPIs near the Production Video Switcher.

Units might be scattered among the facility but the GPIO wiring will be short and simple this way. From each unit, a serial cable connects to the serial BUS.

The Serial Bus is nothing but a panel with 15 DB9 connectors wired in parallel. One of those connects to the Master Linux hosts; the others, to PI units.

It is highly recommended to use a networked Device Server equipment instead of connecting the BUS to computer physical serial ports (via RS485/422-to-RS232 adapter, of course). There are several advantages on doing that:

* Facilitates future expansion of the topology.
* Removes the need for (not always reliable) RS485/422-to-RS232 adapters.
* Allows the Master Linux host to be virtual. This is specially interesting if you opt for an automatic-fail-over arrangement using two hosts.

Units are provided with the Microcontroller pre-programmed and all necessary components except relays and optocoupler. The engineer in charge of preparing the unit is responsible for adding relays to those GPIOs destined to be GPOs and optocouplers to those serving as GPIs. Although we can configure GPIs and GPOs in any order, it is recommended to place GPIs in consecutive order starting at GPIO-1 and GPOs to the end.

Once these components have been installed on the board, the unit address needs to be set by jumpers. The address is a 4-digits binary number; a jumper represents a binary 1, no jumper represents binary 0. Some units do not have jumpers because the address is set via serial port using a configuration utility (supplied) called gpconfig.

When the unit is power-up, if the address is zero, the Firmware configures GPIO ports automatically: by sensing the ports pins, it discovers which pin has a relay attached and which, an optocoupler. Initially, the unit is not setup. This is signaling with a blinking ALARM LED. To do the setup, set the address to zero, make sure there is no external GPI connected and power cycle the unit. The ALARM LED will blink for a short while, then it will turn off.

For jumperless units, connect the serial port to a RS-422 port (or suitable adapter) of a Configuration PC where gpconfig and other utilities are installed; then run gpconfig to do the appropiate setup.

In general terms, a GPO is a boolean command (output) whereas a GPI is a boolean stilumus (input); contact closures is only a particular implementation of this concept. Since GP-LOGIC manages GPIOs in abstraction, the nature (implementation) of those, should be irrelevant to it (generally speaking).

Particularly interesting is the case of serial and networked protocols, as in the case of most Production Video Switchers and MultiViewers, to which GP-LOGIC should be able to communicate serially and extract GPIOs from their datagrams.

Instead of PI units, software would be utilized. This software (we can call it Virtual Units) would run in the Master Linux host encoding/decoding data from serial protocols into "virtual GPIOs", then passing this translated info to the Master Software by the mean of UNIX sockets (named pipes defined in the file system). This "info" can actually be formatted in terms of the same serial protocol used by PI units, so it is irrelevant to the Master Software whether it comes from a Virtual Unit or a real one.

Adding support to serial and networked protocols gets reduced to the creation of the appropriate Virtual Units software.