Table of Content  Branch Up  

Architecture

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.