Firmware Architecture (PI units)

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.