Programación bare metal de un SoC: Prueba de concepto sobre la Orange Pi Zero Plus 
Los SoCs están diseñados para ejecutar sistemas operativos completos (Linux, Android, etc.). La programación bare metal de este tipo de chips es una tarea complicada y poco agradecida (normalmente no se justifica el uso de un SoC sin sistema operativo, para eso están los microcontroladores), sin embargo estos proyectos brindan una oportunidad única para conocer los entresijos del chip y de paso entender mejor cómo funcionan los SoCs en general.

Orange Pi Zero Plus

El corazón de la placa Orange Pi Zero Plus (la que se ha utilizado para esta prueba de concepto) es un SoC H5 de la marca AllWinner. Se trata de un ARM Cortex-A53 de cuadruple núcleo que implementa la arquitectura ARMv8-A (64 bits). En el arranque, todos los ARM de 64 bits arrancan en modo 32 bits, así que por simplicidad se ha decidido que la prueba de concepto se haga en el modo de arranque compatible ARMv7-A (32 bits, sin pasar a modo 64 bits) y utilizando sólo el primer núcleo (en el arranque sólo está operativo el núcleo 0, los núcleos 1, 2 y 3 están desactivados).

La secuencia de arranque del H5

El H5 implementa varias formas y modos de arranque, sin embargo, en la placa Orange Pi Zero Plus el modo de arranque que se usa es el que busca en la tarjeta de memoria (MicroSD) el bootloader. En el caso habitual, para cargar un sistema operativo, dicho bootloader sera el U-Boot u otro similar. Aunque en el manual de usuario del H5 se especifica de forma más detallada, se puede simplificar diciendo que al arrancar el H5 ejecuta una "boot ROM" (BROM) que no es modificable y que se encuentra cableada dentro del chip. Esta ROM se encarga de inicializar la tarjeta de memoria, de cargar el SPL (Second Program Loader) desde la tarjeta de memoria en la RAM y de ejecutar dicho código una vez está cargado en RAM. En terminología H5 este SPL hace las veces de boot loader.

En http://linux-sunxi.org/Bootable_SD_card#SD_Card_Layout se especifica la distribución de los datos en la tarjeta de memoria, dónde debe estar alojado el SPL (offset 8192) y lo que puede ocupar como máximo (32 KBytes). Según la documentación oficial (http://linux-sunxi.org/BROM#U-Boot_SPL_limitations), este SPL no puede ser código tal cual, sino que debe tener un formato y una especie de firma digital especial. Dicho formato se encuentra documentado y un programador desarrolló hace tiempo una pequeña utilidad llamada "mksunxiboot", open source, programada en C, que, a partir de un binario estándar, genera un binario firmado y reconocible por parte del SoC como un SPL válido (la firma no deja de ser una estructura de datos en la cabecera más un checksum). El código fuente de dicha utilidad (es un único fichero en C) se puede encontrar en https://github.com/amery/mksunxiboot/.

Haciendo nuestro propio SPL

Para hacer la prueba de concepto bare metal bastará con hacer un pequeño programa que haga de SPL. En este caso se ha optado por hacer el típico blinker que actúe sobre una de las salidas GPIO de la placa a la que conectaremos un led para comprobar que el invento funciona. Usaremos la salida GPIO12 (se podría usar cualquier otra) que se corresponde con el pin 3 del puerto de expansión de la Orange Pi Zero Plus (http://linux-sunxi.org/Orange_Pi_Zero_P ... nsion_Port).



A continuación necesitaremos cualquier toolchain "arm-none-eabi" que tengamos a mano, puede ser tanto descargada de algún repositorio como compilada por nosotros mismos (ver post en este mismo blog). Se trata de una toolchain diseñada para hacer programas bare metal para arquitecturas ARM de 32 bits. En principio hay dos formas de hacerlo: la elegante y lenta y la "sucia" y rápida. La forma elegante y lenta obliga a escribir un linker script que nos permita pasar casi cualquier programa que queramos a un SPL, sin embargo la forma sucia y rápida, aunque no da tanta libertad, sí que nos permite hacer la prueba de concepto de forma rápida.

#include <stdint.h>

void spl() __attribute__ ((section(".spl")));

void spl() {
    volatile uint64_t n;
    const uint64_t WAIT = 20000ULL;
    const uint32_t CCU_BASE = 0x01C20000;
    *((volatile uint32_t *) (CCU_BASE + 0x0068)) |= 0x00000020;   // PIO clock enable
    const uint32_t PIO_BASE = 0x01C20800;
    *((volatile uint32_t *) (PIO_BASE + 0x0004)) = 0x77717777;  // PA12 como pin de salida
    while (true) {
        *((volatile uint32_t *) (PIO_BASE + 0x0010)) = 0x00001000;   // PA12 := 1
        for (n = 0; n < WAIT; n++)
            ;
        *((volatile uint32_t *) (PIO_BASE + 0x0010)) = 0x00000000;   // PA12 := 0
        for (n = 0; n < WAIT; n++)
            ;
    }
}


Como se puede apreciar, escribimos el código en una función a la que podemos ponerle el nombre que queramos y, mediante atributos del compilador, le decimos que debe estar en la sección ".spl" (esta etiqueta es arbitraria, la sección podría llamarse ".pepejuan"). Nótese que no estamos usando variables globales y no estamos referenciando nada que esté fuera de la propia función en sí (todo el código está autocontenido). Esta limitación es importante, pues, como se verá más adelante, sólo usaremos como código SPL lo que esté dentro de la sección ".spl" que se ha definido en tiempo de compilación.

A la hora de escribir el código se recurrió al manual de usuario oficial del H5 (https://linux-sunxi.org/File:Allwinner_H5_Manual_v1.0.pdf): en la sección "CCU" (sub sección "Gating and reset") se explica cómo habilitar el reloj para el módulo PIO (el encargado de controlar los pines GPIO), mientras que en la sección "Port Controller (CPUx-PORT)" se explica como habilitar y usar los pines GPIO. Para compilar y generar el fichero binario que transferiremos a la tarjeta MicroSD haremos lo siguiente:

arm-none-eabi-g++ -mtune=cortex-a7 -fno-exceptions -fno-rtti -nostartfiles -c -o spl.o spl.cc
arm-none-eabi-objcopy -O binary -j .spl spl.o spl.bin
mksunxiboot spl.bin spl_with_signature.bin


Primero se genera el fichero "spl.o", a continuación usando la utilidad objcopy extraemos en forma binaria el código que se encuentra en la sección ".spl" desde dentro de "spl.o" hacia "spl.bin" y, como tercer paso, invocamos la utilidad "mksunxiboot" para generar, a partir de "spl.bin", un "spl_with_signature.bin" que sí puede ser transferido tal cual a la tarjeta MicroSD. Como se puede apreciar, se le dice al compilador que genere código compatible Cortex-A7 (para que genere código siguiendo la arquitectura ARMv7-A). Para los que tengan curiosidad por el código que ha generado el compilador, se puede desensamblar dicho código mediante el siguiente comando:

arm-none-eabi-objdump -D spl.o


A continuación cogemos el fichero "spl_with_signature.bin" que acabamos de generar, lo copiamos tal cual a partir del offset 8192 de la tarjeta de memoria y arrancamos la Orange Pi Zero Plus con dicha tarjeta de memoria insertada:

dd if=spl_with_signature.img of=/dev/sdb bs=1024 seek=8

Et voilà :



Todo el código fuente está disponible en la sección soft.

[ añadir comentario ] ( 1211 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente
  |    |    |    |   ( 3 / 2510 )
Multitarea apropiativa en microcontroladores: prueba de concepto sobre Arduino Leonardo 
Existen dos tipos básicos de multitarea: la multitarea colaborativa y la multitarea apropiativa. En un post anterior se abordó la implementación de la multitarea cooperativa de forma extensa por lo que ahora le toca el turno a la multitarea apropiativa: en este modelo el sistema "no se fia" de las tareas y de forma periódica arrebata ("se apropia") el control del procesador a la tarea actualmente en ejecución para ceder el control del mismo a otra tarea. Es el mecanismo utilizado por los RTOS en sistemas embebidos y por los sistemas operativos mas grandes (Linux, Windows, OSX, etc.).

Principios

Un sistema con multitarea apropiativa debe por tanto poseer mecanismos que permitan interrumpir la ejecución de la tarea actualmente en curso y que permitan también reanudar la ejecución de otra tarea que haya sido interrumpida previamente. Este mecanismo debería ser lo más transparente al usuario (a las tareas) posible por lo que normalmente se utilizan las interrupciones. Las interrupciones en la totalidad de los procesadores que las implementan (no conozco ningún procesador que no las tenga) permiten ejecutar código de forma no solicitada por la tarea actualmente en ejecución y a raiz de un evento externo al flujo actual de la tarea.

En el momento que se produce la interrupción (la causa puede ser externa al procesador: entradas de datos, pines de entrada que cambian de estado o interna: división entre cero, instrucción no reconocida, etc.) el procesador almacena en la pila del sistema la dirección de la siguiente instrucción que se va a ejecutar y hace que el contador de programa apunte a la primera instrucción del código de interrupción. Este código de interrupción que se ejecuta a raiz del evento suele denominarse ISR (Interrupt Service Routine).



Normalmente existirán diferentes orígenes de interrupción y diferentes vectores de interrupción. Por ejemplo un procesador podría tener dos orígenes de interrupción (el cambio de estado de un pin de entrada y el desbordamiento de un contador interno) y un solo vector de interrupción por lo que se ejecutará la misma ISR para cualquiera de los dos eventos que se produzca. En estos casos, obviamente, el procesador siempre provee mecanismos para que la ISR sea capaz de discernir cuál ha sido la causa de que ella se esté ejecutando (algún registro de estado, por ejemplo).

Lo normal es tener aproximadamente la misma cantidad de orígenes de interrupción que de vectores de interrupción, de tal forma que podemos definir una ISR para cada origen de interrupción. Nótese que una ISR no es más que un trozo de código. En algunos sistemas las ISR no se diferencian en nada de una función normal (por ejemplo, ARM Cortex-M) que debe terminar como todas las funciones con algún tipo de instrucción "ret", mientras que en otros sistemas se debe utilizar algun tipo de instrucción especial normalmente a la hora de regresar: por ejemplo los microcontroladores AVR deben terminar sus funciones ISR con la instrucción "reti" (RETurn from Interrupt). Sin embargo, salvo estas excepciones, dentro de una ISR se puede poner el código que se quiera: no deja de ser un trozo de código como cualquier otro.

Una ISR sencillita

Consideremos inicialmente una ISR sencillita que vamos a compilar para Arduino Leonardo (microcontrolador ATmega32U4):

#include <avr/interrupt.h>
#include <avr/io.h>
#include <stdint.h>

using namespace std;

ISR(TIMER0_OVF_vect) {
    PORTC ^= 0x80;
}

int main() {
    PRR1 |= 0x80;
    DDRC |= 0x80;
    TCCR0B |= 0x05;
    TIMSK0 |= 0x01;
    sei();
    while (true)
        ;
    return 0;
}

$ /ruta/avr/bin/avr-g++ -std=c++11 -DF_CPU=16000000UL -mmcu=atmega32u4 -Os -g -c -o test.o test.cc
$ /ruta/avr/bin/avr-g++ -std=c++11 -DF_CPU=16000000UL -mmcu=atmega32u4 -Os -c -o test.elf test.o

Como se puede ver, usando el compilador avr-g++ se puede hacer de forma muy sencilla un código con soporte para interrupciones en C++. En este caso tenemos un sencillo blinker de toda la vida: cada vez que el Timer 0 se desborda se cambia el estado del bit de salida y hace cambiar de estado a su vez un led conectado a él. Para comprobar de forma detallada cómo funciona el invento podemos desensamblar el fichero ELF generado por el compilador:

$ /ruta/avr/bin/avr-objdump -D test.elf

En la dirección 0 de la memoria tenemos los diferentes vectores de interrupción. Como se puede apreciar está definido el vector 0 (denominado vector de reset ya que en muchos procesadores, como el AVR, el reset se trata como una interrupción más por lo que el vector de reset indica qué código debe ejecutarse nada más encenderse el procesador) y el vector 23 (que se corresponde en el ATmega32U4 con la interrupción de desbordamiento del Timer 0):

Disassembly of section .text:

00000000 <__vectors>:
0: 0c 94 56 00 jmp 0xac ; 0xac <__ctors_end>
4: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
8: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
c: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
10: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
14: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
18: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
1c: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
20: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
24: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
28: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
2c: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
30: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
34: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
38: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
3c: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
40: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
44: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
48: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
4c: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
50: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
54: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
58: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
5c: 0c 94 62 00 jmp 0xc4 ; 0xc4 <__vector_23>
60: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
64: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
68: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
6c: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
70: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>
74: 0c 94 60 00 jmp 0xc0 ; 0xc0 <__bad_interrupt>

Si nos vamos al código que ha generado el compilador para la ISR correspondiente al vector 23:

000000c4 <__vector_23>:
c4: 1f 92 push r1
c6: 0f 92 push r0
c8: 0f b6 in r0, 0x3f ; 63
ca: 0f 92 push r0
cc: 11 24 eor r1, r1
ce: 8f 93 push r24
d0: 88 b1 in r24, 0x08 ; 8
d2: 80 58 subi r24, 0x80 ; 128
d4: 88 b9 out 0x08, r24 ; 8
d6: 8f 91 pop r24
d8: 0f 90 pop r0
da: 0f be out 0x3f, r0 ; 63
dc: 0f 90 pop r0
de: 1f 90 pop r1
e0: 18 95 reti

Vemos que lo primero que hace la ISR es guardar en la pila (PUSH) los registros R1, R0, SREG y R24 que son registros que utiliza ("ensucia") para hacer la operación:

PORTC ^= 0x80;

Y, tras realizar dicha operación, restaura de nuevo dichos registros en orden inverso desde la pila (POP) antes de regresar (RETI). Esta forma de operar hace que la tarea principal (el bucle infinito que hay en la función "main") no se da cuenta de que es interrumpido de forma periódica ya que la ISR se encarga de salvaguardar y restaurar los registros que utiliza de forma transparente. La función "main" como mucho puede notar que cada cierto tiempo, entre instrucción e instrucción, pasan más ciclos de lo normal :-).

Conmutación entre tareas

Como se comentó más arriba, cuando se produce una interrupción, los procesadores guardan siempre en la pila la dirección a donde el contador de programa (PC) debe regresar una vez que la interrupción ha terminado de servirse (cuando la ISR termine de ejecutarse). En el caso del ATmega32U4 el procesador empuja en la pila 3 bytes en dos de los cuales almacena la dirección de memoria de la siguiente instrucción que iba a ejecutar (aunque el ATmega32U4 tiene un espacio de direccionamiento de 16 bits, el núcleo AVR que utiliza es el mismo que tienen otros procesadores AVR que tienen un espacio de direcciones de más de 16 bits, de ahí los 3 bytes que se reservan en la pila para la dirección de retorno de la interrupción).

Si lo que queremos es conmutar entre tareas lo que hay que hacer nada más empezar la ejecución de la función ISR es guardar absolutamente todo el estado del procesador y esto se consigue en el caso de AVR apilando los 32 registros generales (desde R0 hasta R31) más el registro de estado SREG en la pila del sistema (PUSH).

ISR(TIMER0_OVF_vect) __attribute__ ((naked));

ISR(TIMER0_OVF_vect) {
    asm volatile (
        "push r0\n"
        "push r1\n"
        "push r2\n"
        "push r3\n"
        "push r4\n"
        "push r5\n"
        "push r6\n"
        "push r7\n"
        "push r8\n"
        "push r9\n"
        "push r10\n"
        "push r11\n"
        "push r12\n"
        "push r13\n"
        "push r14\n"
        "push r15\n"
        "push r16\n"
        "push r17\n"
        "push r18\n"
        "push r19\n"
        "push r20\n"
        "push r21\n"
        "push r22\n"
        "push r23\n"
        "push r24\n"
        "push r25\n"
        "push r26\n"
        "push r27\n"
        "push r28\n"
        "push r29\n"
        "push r30\n"
        "push r31\n"
        "in r0, 0x3f\n"
        "push r0\n"

A continuación, y como el top de la pila es algo cambiante a medida que se va ejecutando código, guardamos en una variable global la dirección de memoria del actual top de la pila: esto nos permitirá acceder cómodamente a los registros que acabamos de guardar independientemente de que empujemos más cosas en ella:

        // update stackPointerReference
        "push r0\n"
        "in r0, 0x3e\n"
        "sts stackPointerReference + 1, r0\n"    // sph
        "in r0, 0x3d\n"
        "sts stackPointerReference, r0\n"        // spl
        "pop r0\n"
    );
    stackPointerReference = (volatile uint8_t *) ((((uint32_t) stackPointerReference) + 1) | 0x800000);   // 23-th bit to 1 for SRAM address space

Poner a 1 el bit 23 del puntero stackPointerReference es un artificio necesario en avr-gcc ya que en ese entorno de compilación esa es la forma en la que se diferencian los punteros a memoria de datos de los punteros a memoria de programa (hay que recordar que los AVR tienen arquitectura Harvard).

Tras tener adecuadamente inicializado el puntero "stackPointerReference" podemos proceder a realizar la conmutación de tareas en sí. En nuestro caso se asume una política de tipo Round-robin en la que todas las tareas tienen exactamente el mismo tiempo de proceso. Lo que haremos será, partiendo de una lista de N tareas, cada vez que se ejecute la interrupción de desbordamiento del Timer 0, cambiaremos de la tarea i-ésima a la tarea ((i + 1) MOD N)-ésima, con lo que nos aseguramos que cuando llegamos a la última tarea de la lista volvemos a empezar por la primera y así sucesivamente.

Para cada tarea definimos un objeto de clase Task:

class StackFrame {
    public:
        uint8_t sreg;
        uint8_t r[32];
        uint8_t pc[3];
        void setPC(void *f) { this->pc[0] = 0; this->pc[1] = ((uint32_t) f) & 0x000000FF; this->pc[2] = ((((uint32_t) f) >> 8) & 0x000000FF); };
} __attribute__ ((packed));

class Task {
    public:
        StackFrame stackFrame;
        bool started;
        void (*run)();
        Task() : started(false) { };
};

Cada tarea tiene una copia del marco de pila ("stack frame") de la última vez que fue interrumpida, un booleano para indicar si la tarea ha sido iniciada o no y un puntero a una función que apunta a la primera instrucción de dicha tarea. En nuestro caso vamos a asumir, sin pérdida de generalidad, que nuestras tareas nunca terminan (no vamos a controlar lo que ocurre cuando la tarea termine).

Definimos además de forma global un array de punteros a objetos de tipo Task, una variable "currentTaskIndex" que indica la actual tarea que está en ejecución y el puntero "stackPointerReference" del que hablamos antes.

const uint16_t MAX_TASKS = 4;
volatile uint16_t numTasks;
volatile Task tasks[MAX_TASKS];
volatile uint16_t currentTaskIndex;
volatile uint8_t *stackPointerReference;

Los primero que hacemos tras calcular el valor de "stackPointerReference" es trabajar con la tarea actual:

    Task *currentTask = (Task *) &tasks[currentTaskIndex];
    if (currentTask->started) {
        // copy stack data to currentTask->stackFrame
        memcpy((void *) &currentTask->stackFrame, (const void *) (stackPointerReference + 1), sizeof(StackFrame));
    }
    else {
        // replace return address on currentTask->data with currentTask->run
        memset((void *) &currentTask->stackFrame, 0, sizeof(StackFrame));
        currentTask->stackFrame.setPC((void *) currentTask->run);
    }

Si ya está iniciada copiamos los registros que acabamos de apilar (en los PUSH masivos que hicimos al principio de la ISR) al campo "stackFrame" del objeto Task correspondiente a la tarea actual: esto es, ponemos a salvo los registros de la tarea actual pues nos disponemos a hacer una conmutación a la siguiente tarea.

En caso de que la tarea actual no esté iniciada lo que hacemos es borrar el campo "stackFrame" del objeto Task correspondiente a la tarea actual e inicializamos, dentro de esta estructura "stackFrame", los bytes correspondientes al contador de programa para que apunten a la primera instrucción de la tarea actual. Esto hará que cuando se restaure el marco de pila ("stack frame") de esta tarea se inicie dicha tarea (puesto que el contador de programa irá a la primera instrucción de dicha tarea).

A continuación trabajamos con el objeto de tipo Task correspondiente a la tarea siguiente:

    uint16_t nextTaskIndex = currentTaskIndex + 1;
    if (nextTaskIndex == numTasks)
        nextTaskIndex = 0;
    Task *nextTask = (Task *) &tasks[nextTaskIndex];
    if (nextTask->started) {
        // replace stack data with nextTask->stackFrame
        memcpy((void *) (stackPointerReference + 1), (const void *) &nextTask->stackFrame, sizeof(StackFrame));
    }
    else {
        // replace return address on stack with nextTask->run
        ((StackFrame *) (stackPointerReference + 1))->setPC((void *) nextTask->run);
        nextTask->started = true;
    }

En caso de que la siguiente tarea a iniciar ya esté iniciada ("started") simplemente sobreescribimos todo el marco de pila (los datos que metimos en la pila con los PUSH masivos del principio de la ISR) con los bytes de campo "stackFrame" de la siguiente tarea, lo que provocará una conmutación a la tarea siguiente en el momento que retornemos de la interrupción. En caso de que la siguiente tarea no esté iniciada aún hacemos lo mismo que en caso de la tarea actual: inicializamos, dentro de la estructura "stackFrame" los bytes correspondientes al contador de programa para que apunten a la primera instrucción de la tarea siguiente y, a continuación, marcamos la tarea como iniciada ("started = true").

Antes de terminar actualizamos la variable global "currentTaskIndex" para que apunte a la tarea a la que se le va a entregar el control de la CPU y hacemos una restauración normal de la pila (POP masivos) antes de terminar definitivamente con la instrucción "RETI".

    currentTaskIndex = nextTaskIndex;
    asm volatile (
        "pop r0\n"
        "out 0x3f, r0\n"
        "pop r31\n"
        "pop r30\n"
        "pop r29\n"
        "pop r28\n"
        "pop r27\n"
        "pop r26\n"
        "pop r25\n"
        "pop r24\n"
        "pop r23\n"
        "pop r22\n"
        "pop r21\n"
        "pop r20\n"
        "pop r19\n"
        "pop r18\n"
        "pop r17\n"
        "pop r16\n"
        "pop r15\n"
        "pop r14\n"
        "pop r13\n"
        "pop r12\n"
        "pop r11\n"
        "pop r10\n"
        "pop r9\n"
        "pop r8\n"
        "pop r7\n"
        "pop r6\n"
        "pop r5\n"
        "pop r4\n"
        "pop r3\n"
        "pop r2\n"
        "pop r1\n"
        "pop r0\n"
        "reti\n"
    );
}

Para la prueba de concepto se implementaros dos tareas muy sencillas: cada una hace parpadear un led a una velocidad diferente:

void task1() __attribute__ ((naked));

void task1() {
    DDRD |= 0x04;     // PD2 (D0 on Arduino Leonardo) as output
    while (true) {
        PORTD ^= 0x04;
        for (volatile uint32_t i = 0; i < 66000; i++)
            ;
    }
}

void task2() __attribute__ ((naked));

void task2() {
    DDRC |= 0x80;     // PC7 (D13 on Arduino Leonardo) as output
    while (true) {
        PORTC ^= 0x80;
        for (volatile uint32_t i = 0; i < 200000; i++)
            ;
    }
}


Consideraciones adicionales

Nótese que tanto la ISR como las funciones "tarea" ("task1" y "task2") son declaradas con el atributo "naked". Este atributo indica al compilador que no genere código preámbulo ni postámbulo (el código ensamblador relacionado normalmente con el manejo de parámetros y valores de retorno).

En el caso de las funciones "task1" y "task2" se ha usado este atributo por una cuestión de coherencia ya que no se trata de funciones que son invocadas de forma normal desde otra parte del programa y además se trata de funciones que no terminan nunca de ejecutarse.

El caso de la función ISR es más delicado porque en ese caso sí que es necesario usar el atributo "naked". Como se vió en la primera prueba con la interrupción del Timer 0, para el siguiente código:

ISR(TIMER0_OVF_vect) {
    PORTC ^= 0x80;
}

El compilador generaba instrucciones PUSH y POP de los registros que utilizaría, antes y después de la operación "PORTC ^= 0x80" respectivamente. En nuestro caso necesitamos que el apilado (PUSH) y desapilado (POP) de registros sea siempre igual y masivo y que esté perfectamente controlado por nosotros por lo que definimos la función con el atributo "naked" y nos encargamos nosotros de escribir de forma explícita el código ensamblador de preámbulo y postámbulo de la ISR.



Todo el código puede descargarse de la sección soft.

[ añadir comentario ] ( 6552 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente
  |    |    |    |   ( 3 / 4215 )
Compilar la toolchain de GNU para ARM 
Hace tiempo publiqué las instrucciones para compilar la toolchain de GNU para ARM "bare metal" (sin sistema operativo, arm-none-eabi) basada en GCC 5.1 y newlib. Dichas instrucciones no son aplicables para las versiones actuales de GCC (7.2 a día de hoy) por lo que a continuación indico las instrucciones actualizadas a las nuevas versiones de binutils, gcc y newlib.

Se trata de una toolchain para sistemas "bare metal", sin sistema operativo, por lo que no tiene soporte para multihilos ni para librerías dinámicas.

binutils 2.29

mkdir -p /opt/baremetalarm/src
mkdir -p /opt/baremetalarm/build
cd /opt/baremetalarm/src
wget https://ftp.gnu.org/gnu/binutils/binutils-2.29.tar.bz2
tar xf binutils-2.29.tar.bz2
chown -R root:root binutils-2.29
cd ../build
mkdir binutils-2.29
cd binutils-2.29/
../../src/binutils-2.29/configure --prefix=/opt/baremetalarm --target=arm-none-eabi --disable-nls --disable-multilib
make
make install


gcc 7.2.0 (stage 1)

cd /opt/baremetalarm/src
wget https://ftp.gnu.org/gnu/gcc/gcc-7.2.0/gcc-7.2.0.tar.gz
wget https://ftp.gnu.org/gnu/gmp/gmp-6.1.2.tar.bz2
wget https://ftp.gnu.org/gnu/mpc/mpc-1.0.3.tar.gz
wget https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.6.tar.gz
tar xf gcc-7.2.0.tar.gz
tar xf gmp-6.1.2.tar.bz2
tar xf mpc-1.0.3.tar.gz
tar xf mpfr-3.1.6.tar.gz
mv gmp-6.1.2 gcc-7.2.0/gmp
mv mpc-1.0.3 gcc-7.2.0/mpc
mv mpfr-3.1.6 gcc-7.2.0/mpfr
chown -R root:root gcc-7.2.0
cd ../build/
mkdir gcc-7.2.0-stage-1
cd gcc-7.2.0-stage-1/
export PATH=/opt/baremetalarm/bin:${PATH}
../../src/gcc-7.2.0/configure --prefix=/opt/baremetalarm --target=arm-none-eabi --enable-languages=c --without-headers --disable-nls --disable-multilib --disable-threads --disable-shared --disable-libssp --with-newlib
make all-gcc all-target-libgcc
make install-gcc install-target-libgcc


newlib

cd /opt/baremetalarm/src
git clone git://sourceware.org/git/newlib-cygwin.git
cd ../build
mkdir newlib
cd newlib
../../src/newlib-cygwin/configure --prefix=/opt/baremetalarm --target=arm-none-eabi --disable-multilib
make
make install


gcc 7.2.0 (stage 2)

cd /opt/baremetalarm/build
mkdir gcc-7.2.0-stage-2
cd gcc-7.2.0-stage-2/
../../src/gcc-7.2.0/configure --prefix=/opt/baremetalarm --target=arm-none-eabi --enable-languages="c,c++" --disable-nls --disable-multilib --disable-threads --disable-shared --disable-libssp --with-newlib
make
make install


El compilador de C++ de GCC 7.2 compila por defecto en modo C++14 y soporta prácticamente todo el estándar C++17.

[ añadir comentario ] ( 1886 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente
  |    |    |    |   ( 3 / 3622 )
Implementación de un dispositivo USB en STM32 desde cero 
El STM32F103 es un microcontrolador muy asequible que incluye interfaz USB 2.0. La mayoría de desarrollos USB realizados para esta serie de microcontroladores utiliza la librería STM32Cube, desarrollada por el propio fabricante, de libre uso y que abstrae de los entresijos del protocolo al programador. Abordar, sin embargo, el desarrollo de esta funcionalidad desde cero en este o en otros microcontroladores permite profundizar y mejorar en el conocimiento del propio protocolo USB.



Un repaso rápido del protocolo USB

Aunque aquí intentaré desgranar a grandes rasgos el protocolo, recomiendo siempre las dos grandes y mejores fuentes de información sobre el mismo:

USB made simple
USB in a nutshell

Es de lo mejorcito que hay al respecto por la red ya que el documento oficial es un poco infumable. A nivel eléctrico, se trata de un protocolo serie asíncrono que utiliza dos hilos de señal balanceada. El protocolo consiste en una serie de "endpoints" multiplexados en tiempo y enumerados. Hay tres tipos de endpoint:

Control: usado para transferencias de control del dispositivo. Identificación, configuración, etc.

Bulk: usado para transferencias masivas de datos con control de errores (menos ancho de banda).

Interrupt: usado para transferencias pequeñas de datos pero con tiempo mínimo de entrega garantizado.

Isochronous: usado para transferencias masivas de datos sin control de errores (máximo ancho de banda).

Cada endpoint tiene un número asociado y un tipo. El estándar USB reserva el endpoint 0 como un endpoint de control sobre el que el host (ordenador) envía los mensajes de configuración iniciales al dispositivo que acaba de conectarse.

La secuencia ya se describió en un post anterior en el que se abordó el mismo proyecto pero utilizando el microcontrolador ATmega32u4 de AVR pero la volvemos a indicar a continuación:

1. El host detecta que hay un dispositivo conectado (detecta una resistencia pull up en D+ o en D-)

2. El host inicia una secuencia de reset poniendo a nivel bajo las líneas D- y D+ durante al menos 2.5 us.

3. El host envía un paquete de SETUP para pedir el descriptor de dispositivo al dispositivo. Este descriptor indica el tipo de dispositivo, el código de fabricante, código de producto, etc. Esta primera petición se realiza siempre indicando en el campo longitud la longitud máxima y en la respuesta proveniente del dispositivo, el host es capaz de deducir el tamaño máximo de buffer con el que trabaja el dispositivo. Hay que tener en cuenta que en el caso de dospisitivos low-speed los paquetes son siempre de 8 bytes de datos mientras que en dispositivos full-speed los paquetes pueden ser de 8, 16, 32 o 64 bytes.

4. Tras esta primera petición de descripción de dispositivo el host suele iniciar de nuevo una condición de reset y, a continuación vuelve a pedir el descriptor de dispositivo pero con el tamaño ajustado al tamaño indicado por el dispositivo en la primera petición.

5. Cada dispositivo tiene asignada una dirección en el bus que, tras es reset, es siempre 0. En este instante lo habitual es que el host envíe un paquete de SETUP de tipo SET_ADDRESS para indicarle al dispositivo que a partir de ahora el host se va a comunicar con el dispositivo usando una dirección concreta diferente a 0 y que el dispositivo debe recordar para posteriores paquetes que se transmitan.

6. Ya con la nueva dirección de bus configurada, el host envía otro paquete de SETUP para solicitar el descriptor de configuración. Este descriptor es más grande que el anterior e incluye información sobre la clase de dipositivo y los endpoints que utiliza. El descriptor de dispositivo indica en un campo cuántas configuraciones posee el dispositivo, que suele ser siempre 1, por lo que el host normalmente sólo pide un descriptor de configuración.

7. El host (normalmente el driver instalado en el host) decide qué configuración quiere activar (que suele ser la única) en el dispositivo enviando un paquete de SETUP de tipo SET_CONFIGURATION. A partir de este instante el dispositivo queda conectado y con sus endpoints preparados para recibir y enviar datos propios de la funcionalidad del dispositivo.

La secuencia puede variar ligeramente en función del sistema operativo del host. Hay que recordar que en el protocolo USB el host es siempre el que envía "tokens" al dispositivo, incluso para traer datos desde el dispositivo. Cuando el host quiere enviar datos a un dispositivo hace transferencias de tipo SETUP y OUT mientras que cuando quiere recibir datos del dispositivo, el host hace transferencias de tipo IN pero siempre es el host el que pregunta. Un dispositivo no puede enviar datos a un host hasta que el host mande un token de tipo IN al dispositivo.

Implementación en el STM32F103

La serie STM32F103 es la serie más sencilla y baratita de toda la familia STM32 con soporte USB 2.0 full-speed (en el momento que escribo esto se puede conseguir una placa mínima de desarrollo con STM32F103 por menos de 3 ¤ en AliExpress). La documentación de referencia para programar el módulo USB es algo oscura y no está pensada para que te sumerjas mucho en ella, sino para que utilices la librería STM32Cube que, aunque es open source y permite un uso sin restricciones, su uso le quita toda la gracia al concepto de programar un microcontrolador desde cero :-).

A continuación puede verse la implementación de un dispositivo USB consistente en dos endpoints sencillos de tipo bulk (uno de entrada y otro de salida). La razón para implementar un dispositivo así es el hecho de que desde Linux el driver "usbserial" permite intercambiar datos con cualquier dispositivo USB que cumpla que tenga un endpoint bulk de salida y otro de entrada sin importar su clase, ni el código de fabricante ni de producto. Es un driver ideal para depurar dispositivos USB y que instancia un "/dev/ttyUSB0". Escribiendo en "/dev/ttyUSB0" se envían bytes a través del endpoint de salida mediante paquetes OUT mientras que leyendo de "/dev/ttyUSB0" se reciben bytes desde el dispositivo a través del endpoint de entrada mediante paquetes IN que envía el host.

La función usbDeviceInit se encarga de inicializar los tranceptores y de activar la interrupción de "USB Reset":

void usbDeviceInit() {
    // enable USB clock
    RCC_APB1ENR |= (((uint32_t) 1) << 23);
    // enable USB interrupts
    NVIC_ENABLE_IRQ(20);
    NVIC_SET_PRIORITY(20, 0);   // highest priority
    // enable analog transceivers
    USB_CNTR &= ~(((uint16_t) 1) << 1);
    for (uint32_t i = 0; i < 20000; i++)
        ;
    USB_CNTR &= ~(((uint16_t) 1) << 0);
    USB_ISTR = 0;
    // enable and wait for USB RESET interrupt
    USB_CNTR |= (((uint16_t) 1) << 10);
}

A continuación definimos los diferentes descriptores del dispositivo (descriptor de dispositivo, descriptor de configuración y descriptor de cadena 0 que indica los idiomas disponibles en el dispositivo):

const UsbDeviceDescriptor MyUsbDeviceDescriptor = {
    0x12,      // descriptor size
    0x01,      // descriptor type (device)
    0x0110,    // USB protocol version 1.10
    0x00,
    0x00,
    0x00,
    0x08,      // max packet size for control endpoint 0 = 8 bytes
    0xF055,    // vendor id
    0x0001,    // product id
    0x0100,
    0x00,
    0x00,
    0x00,
    0x01       // num configurations
};

...

const UsbConfigurationDescriptor MyUsbConfigurationDescriptor = {
    0x09,    // descriptor size
    0x02,    // descriptor type (configuration)
    0x0020,  // configuration (9) + interface (9) + endpoint (7) + endpoint (7) = 32
    0x01,    // num interfaces = 1
    0x01,    // this configuration number = 1
    0x00,
    0x80,    // bus powered (not self powered)
    0x20,    // 32 * 2 = 64 mA
    {           // interface descriptor
        0x09,   // descriptor size
        0x04,   // descriptor type (interface)
        0x00,   // interface number (zero based)
        0x00,
        0x02,   // num endpoints = 2
        0xFF,   // class = vendor defined
        0xFF,   // subclass = vendor defined
        0x00,
        0x00
    },
    {             // in endpoint descriptor
        0x07,     // descriptor size
        0x05,     // descriptor type (endpoint)
        0x81,     // in endpoint 1
        0x02,     // bulk endpoint
        0x0008,   // max packet size = 8 bytes
        0x0A      // 10 ms for polling interval
    },
    {             // out endpoint descriptor
        0x07,     // descriptor size
        0x05,     // descriptor type (endpoint)
        0x02,     // out endpoint 2
        0x02,     // bulk endpoint
        0x0008,   // max packet size = 8 bytes
        0x0A      // 10 ms for polling interval
    }
};

...

const UsbString0Descriptor MyUsbString0Descriptor = {
    0x04,            // descriptor size
    0x03,            // descriptor type (string descriptor)
    0x0409           // 'en_US' language id
};


const uint16_t MyUsbStatus = 0x0000;

Los buffers de recepción y transmisión USB en el caso de STM32 deben ser direccionados y accedidos de forma particular. Desde el punto de vista del subsistema USB, la anchura del bus de datos es de 16 bits, en lugar de 32 bits aunque los datos están alineados a 32 bits. Gráficamente se ve mejor:

Offset desde el punto de     Offset desde el punto de
vista del controlador USB vista del programa (CPU)
0 0
1 1
2 4
3 5
4 8
5 9
6 12


Como se puede ver, por cada palabra de 32 bits direccionada desde la CPU sólo se puede acceder a los 16 bits menos significativos. Para leer los 2 primeros bytes de la memoria USB desde la CPU hay que acceder a los 4 primeros bytes de dicha memoria (como si fuese un entero de 32 bits) y quedarnos con los 16 bits menos significativos. Los siguientes 2 bytes no están en los 16 bits más significativos de la primera palabra de 32 bits, sino en los 16 bits menos significativos de la siguiente palabra de 32 bits y así sucesivamente. Teniendo en cuenta esta particularidad se implementan dos funciones de acceso a esta memoria USB para copiar hacia y desde ella:

void usbCopyFromPacketSRAM(volatile uint32_t *packetSRAMSource, volatile uint16_t *destination, uint16_t bytes) {
    volatile uint32_t *p = (volatile uint32_t *) packetSRAMSource;
    volatile uint16_t *q = destination;
    uint16_t n = bytes >> 1;
    if (bytes & 1)
        n++;
    for (uint16_t i = 0; i < n; i++, p++, q++)
        *q = (uint16_t) (*p & 0x0000FFFF);
}


void usbCopyToPacketSRAM(volatile uint16_t *source, volatile uint32_t *packetSRAMDestination, uint16_t bytes) {
    volatile uint32_t *p = (volatile uint32_t *) packetSRAMDestination;
    volatile uint16_t *q = source;
    uint16_t n = bytes >> 1;
    if (bytes & 1)
        n++;
    for (uint16_t i = 0; i < n; i++, p++, q++)
        *p = (uint32_t) *q;
}

A continuación definimos las rutinas de interrupción correspondientes. Primero escribimos la rutina usbDeviceISRReset, que se ejecuta en caso de que se genere una interrupción de "USB Reset" provocada por una condición de reset en el bus USB. Dicha condición de reset es iniciada por el host en cuanto detecta un nuevo dispositivo conectado a una de sus bocas USB (es el paso 2 de la secuencia descrita anteriormente):

void usbDeviceISR()  __attribute__ ((section(".usblp")));

...

void usbDeviceISRReset() {
    // prepare buffer descriptor table for endpoint 0 (control)
    USB_BTABLE = 0;
    // endpoint 0 (bidireccional)
    USB_ADDR0_TX = 24;
    USB_COUNT0_TX = 0;   // 8
    USB_ADDR0_RX = 32;
    USB_COUNT0_RX = (((uint16_t) 4) << 10);   // 2 * 4 = 8 bytes
    // endpoint 1 (in, tx)
    USB_ADDR1_TX = 40;
    USB_COUNT1_TX = 0;   // 8
    USB_ADDR1_RX = 40;
    USB_COUNT1_RX = (((uint16_t) 4) << 10);   // 2 * 4 = 8 bytes
    // endpoint 2 (out, rx)
    USB_ADDR2_TX = 48;
    USB_COUNT2_TX = 0;   // 8
    USB_ADDR2_RX = 48;
    USB_COUNT2_RX = (((uint16_t) 4) << 10);   // 2 * 4 = 8 bytes
    // device address = 0
    USB_DADDR = ((uint16_t) 1) << 7;   // enable usb function
    usbNextAddress = 0;
    // prepare endpoint 0 for rx setup packets
    USB_EP0R = (((uint16_t) 1) << 9);
    usbDeviceEPRSetRxStat(USB_EP0R, STAT_NAK);
    usbDeviceEPRSetTxStat(USB_EP0R, STAT_NAK);
    usbDeviceEPRSetDtogRx(USB_EP0R, 0);
    usbDeviceEPRSetDtogTx(USB_EP0R, 0);
    // prepare endpoint 1 and endpoint 2
    USB_EP1R = 1;
    usbDeviceEPRSetRxStat(USB_EP1R, STAT_NAK);
    usbDeviceEPRSetTxStat(USB_EP1R, STAT_VAL);
    usbDeviceEPRSetDtogRx(USB_EP1R, 0);
    usbDeviceEPRSetDtogTx(USB_EP1R, 0);
    USB_EP2R = 2;
    usbDeviceEPRSetRxStat(USB_EP2R, STAT_VAL);
    usbDeviceEPRSetTxStat(USB_EP2R, STAT_NAK);
    usbDeviceEPRSetDtogRx(USB_EP2R, 0);
    usbDeviceEPRSetDtogTx(USB_EP2R, 0);
    // enable complete transfer interrupt
    USB_CNTR |= (((uint16_t) 1) << 15);
}

A continuación se define la rutina principal que atiende las interrupciones USB, usbDeviceISR. Esta función llama, en caso de darse una condición de reset a la función usbDeviceISRReset definida arriba:

void usbDeviceISR() {
    uint16_t istr = USB_ISTR;
    if (istr & (((uint16_t) 1) << 10)) {
        usbDeviceISRReset();
        USB_ISTR = 0;
    }
    else if (istr & (((uint16_t) 1) << 15)) {   // correct transfer interrupt
        USB_ISTR = 0;
        uint16_t epNum = istr & 0x000F;
        if (epNum == 0) {
            if (istr & 0x0010) {
                // out/setup packet
                if (USB_EP0R & (((uint16_t) 1) << 11)) {
                    // setup packet
                    usbCopyFromPacketSRAM((uint32_t *) USB_EP0RXBUF, usbRxBuffer, USB_COUNT0_RX & 0x03FF);
                    UsbSetupPacket *setupPacket = (UsbSetupPacket *) usbRxBuffer;
                    if ((setupPacket->bmRequestType == 0x80) && (setupPacket->bRequest == 0x06)) {
                        bool stall = false;
                        if ((setupPacket->wValue >> 8) == 1) {
                            ep0DataPtr = (uint8_t *) &MyUsbDeviceDescriptor;           // get_descriptor (device)
                            ep0DataCount = (sizeof(MyUsbDeviceDescriptor) < setupPacket->wLength) ? sizeof(MyUsbDeviceDescriptor) : setupPacket->wLength;
                        }
                        else if ((setupPacket->wValue >> 8) == 2) {
                            ep0DataPtr = (uint8_t *) &MyUsbConfigurationDescriptor;    // get_descriptor (configuration)
                            ep0DataCount = (sizeof(MyUsbConfigurationDescriptor) < setupPacket->wLength) ? sizeof(MyUsbConfigurationDescriptor) : setupPacket->wLength;
                        }
                        else if ((setupPacket->wValue >> 8) == 3) {
                            ep0DataPtr = (uint8_t *) &MyUsbString0Descriptor;    // get_descriptor (string)
                            ep0DataCount = (sizeof(MyUsbString0Descriptor) < setupPacket->wLength) ? sizeof(MyUsbString0Descriptor) : setupPacket->wLength;
                        }
                        else {
                            usart1SendString("\tg?");
                            usart1SendHexValue(setupPacket->wValue >> 8);
                            usart1SendString("\r\n");
                            ep0DataCount = 0;
                            stall = true;
                        }
                        if (stall)
                            usbDeviceEPRSetTxStat(USB_EP0R, STAT_STA);
                        else {
                            uint16_t size = (ep0DataCount > 8) ? 8 : ep0DataCount;     // copy bytes to packet SRAM
                            usbCopyToPacketSRAM((uint16_t *) ep0DataPtr, (uint32_t *) USB_EP0TXBUF, size);
                            USB_COUNT0_TX = size;
                            ep0DataCount -= size;
                            ep0DataPtr += size;
                            usbDeviceEPRSetTxStat(USB_EP0R, STAT_VAL);
                        }
                        usbDeviceEPRSetRxStat(USB_EP0R, STAT_STA);
                    }
                    else if ((setupPacket->bmRequestType == 0x00) && (setupPacket->bRequest == 0x05)) {
                        usbNextAddress = setupPacket->wValue;
                        USB_COUNT0_TX = 0;
                        usbDeviceEPRSetTxStat(USB_EP0R, STAT_VAL);
                        usbDeviceEPRSetRxStat(USB_EP0R, STAT_STA);
                    }
                    else if ((setupPacket->bmRequestType == 0x00) && (setupPacket->bRequest == 0x09)) {
                        USB_COUNT0_TX = 0;
                        usbDeviceEPRSetTxStat(USB_EP0R, STAT_VAL);
                        usbDeviceEPRSetRxStat(USB_EP0R, STAT_STA);
                    }
                    else if ((setupPacket->bmRequestType == 0x80) && (setupPacket->bRequest == 0x00)) {
                        usbCopyToPacketSRAM((uint16_t *) &MyUsbStatus, (uint32_t *) USB_EP0TXBUF, 2);
                        USB_COUNT0_TX = 2;
                        usbDeviceEPRSetTxStat(USB_EP0R, STAT_VAL);
                        usbDeviceEPRSetRxStat(USB_EP0R, STAT_STA);
                    }
                    else {
                        usart1SendString("\tother setup packet\r\n");
                        usart1SendString("x: ");
                        usart1SendHexValue(setupPacket->bmRequestType);
                        usart1SendString(" ");
                        usart1SendHexValue(setupPacket->bRequest);
                        usart1SendString("\r\n");
                    }
                }
                else {
                    // out packet
                    usbCopyFromPacketSRAM((uint32_t *) USB_EP0RXBUF, usbRxBuffer, USB_COUNT0_RX & 0x03FF);
                    // TODO process data
                }
            }
            else {
                // in packet
                if (usbNextAddress != 0) {
                    USB_DADDR = (((uint16_t) 1) << 7) | (usbNextAddress & 0x007F);
                    usbNextAddress = 0;
                }
                else {
                    uint16_t size = (ep0DataCount > 8) ? 8 : ep0DataCount;
                    usbCopyToPacketSRAM((uint16_t *) ep0DataPtr, (uint32_t *) USB_EP0TXBUF, size);
                    USB_COUNT0_TX = size;
                    ep0DataCount -= size;
                    ep0DataPtr += size;
                    usbDeviceEPRSetTxStat(USB_EP0R, STAT_VAL);
                    usbDeviceEPRSetRxStat(USB_EP0R, STAT_VAL);
                }
            }
            USB_EP0R &= 0x0F0F;    // ctr_rx = 0, ctr_tx = 0
        }
        else if (epNum == 1) {
            if (istr & 0x0010) {
                // out packet
            }
            else {
                // in packet 
            }
            usbDeviceEPRSetTxStat(USB_EP1R, STAT_VAL);
            usbDeviceEPRSetRxStat(USB_EP1R, STAT_NAK);
            USB_EP1R &= 0x0F0F;    // ctr_rx = 0, ctr_tx = 0
        }
        else if (epNum == 2) {
            if (istr & 0x0010) {
                // out packet
                usbCopyFromPacketSRAM((uint32_t *) USB_EP2RXBUF, usbRxBuffer, USB_COUNT2_RX & 0x03FF);
                usart1SendString("rx '");
                usart1SendBytes((uint8_t *) usbRxBuffer, USB_COUNT2_RX & 0x03FF);
                usart1SendString("'\r\n");
            }
            else {
                // in packet 
            }
            usbDeviceEPRSetTxStat(USB_EP2R, STAT_NAK);
            usbDeviceEPRSetRxStat(USB_EP2R, STAT_VAL);
            USB_EP2R &= 0x0F0F;    // ctr_rx = 0, ctr_tx = 0
        }
        //USB_ISTR = 0;
    }
}

Lo primero que hace la rutina es identificar el endpoint por el que se ha producido la transacción. En caso de que la transacción se haya producido a través del endpoint 0 se comprueba si es un token SETUP u OUT y, si es un token SETUP, se parsea y se mira a ver si el host está mandando algo (configuraciones) o si lo está pidiendo (descriptores). Si el host está pidiendo algo, hay que rellenar el buffer de transmisión con los datos que necesita, pues la siguiente transacción que realizará el host a través del endpoint 0 será utilizando uno o varios tokens IN y para entonces los datos tienen que estar ya preparados en dicho búffer.

Recordemos algunos elementos básicos sobre cómo son las transferencias USB a través del endpoint 0:

Control: Es un endpoint que debe ser siempre configurado como de tipo "Control" y es bidireccional. Un dispositivo puede definir endpoints de control adicionales pero el endpoint 0 de control siempre debe estar disponible.

Transacciones SETUP: Los endpoints configurados como de control permiten transferir un tipo especial de token denominado SETUP. Este token puede ser de entrada o de salida (siempre desde el punto de vista del host).

Transacciones SETUP de salida: El host manda un token SETUP, a continuación envía cero o más tokens OUT con datos anexos y por último manda un token IN para que el dispositivo mande 0 bytes a modo de ACK.

Transacciones SETUP de entrada: El host manda un token SETUP, a continuación envía cero o más tokens IN para recibir datos del dispositivo y al final el host manda un token OUT con 0 bytes anexos a modo de ACK hacia el dispositivo.

Si la transacción se ha producido en el endpoint 1 o 2, se asume que es una transacción simple de tipo bulk:

Endpoint 1: Es un endpoint configurado como de tipo IN y en esta implementación no hace nada, pues el STM32 no manda ningún dato cuando es leido a través del USB.
Endpoint 2: Es un endpoint configurado como de tipo OUT. Por lo tanto, el STM32 recibe por aquí los datos que son enviados desde el host y los manda formateados a través de la USART.

Nos limitamos a mandar por la USART1 todo lo que entra a través del endpoint de tipo "bulk out", mientras que las lecturas desde el host al endpoint de tipo "bulk in" devuelven siempre 0 bytes.

Para cargar el módulo "usbserial" en el kernel simplemente hay que hacer:
modprobe usbserial vendor=0xf055 product=0x0001

Esto nos permite comunicarnos con el dispositivo desde la misma shell:
echo "Hola, caracola" > /dev/ttyUSB1

Partiendo de este código se pueden implementar multitud de dispositivos USB en este microcontrolador (Mass storage, HID, DFU, etc.). Todo el código fuente puede descargarse desde la sección soft.

Quiero agradecer a Jian Jiao (mculabs.net) la ayuda prestada a la hora de comprender algunos entresijos en la programación del módulo USB del microcontrolador STM32.

[ añadir comentario ] ( 2280 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente
  |    |    |    |   ( 3 / 4429 )
Programación del microcontrolador LPC810 en C++ desde cero 
El LPC810 es un microcontrolador con núcleo ARM Cortex-M0+ en encapsulado DIP8 y con reloj interno. Es bastante limitado (4Kb de memoria flash y 1Kb de memoria RAM) pero el encapsulado DIP8 y el reloj interno permiten montar proyectos sencillos en protoboard, lo que le da un valor educativo muy alto. Un micro ideal para introducirse en los 32 bits cuando se viene del mundo de los 8 bits.

Características generales

El LPC810 es un ARM Cortex-M0+ en encapsulado DIP8 que incluye un multiplicador rápido de 1 ciclo, 4 Kb de memoria flash, 1 Kb de memoria RAM, un reloj interno a 12 MHz overclockeable hasta 30 MHz, bootloader por puerto serie, I2C, SPI e interface de depuración compatible JTAG. El bootloader no ocupa espacio en los 4Kb de memoria flash sino que reside una zona de memoria aparte lo que facilita mucho la programación y la configuración del linker script y del compilador.

Núcleo ARM Cortex-M0+

Todos los ARM Cortex-M mapean, tras el reset, la tabla de vectores en la posición 0x00000000 con el siguiente contenido:

dirección     tamaño   contenido
0x00000000 4 puntero de pila
0x00000004 4 puntero a la primera instrucción a ejecutar
...
0x0000003C 4 puntero al manejador del SysTick (timer)
...

Hay más vectores en la tabla. Sólo he indicado los más relevantes para nuestro ejemplo y por ahora nos centraremos en los dos primeros vectores (puntero de pila y vector de reset), que son los más importantes.

Bootloader

Cuando el chip LPC810 se reinicia o se enciende se ejecuta el código del bootloader. Dicho código comprueba, entre otras cosas, si el pin ISP (pin 5) del chip está a masa, si lo está, entra en modo programación (es el modo usado para tostar el integrado), en caso contrario comprueba si el código almacenado en la memoria flash es "correcto". La forma de ver si el código cargado en la memoria flash es correcto es sumando las 8 primeras palabras de 32 bits (que coincide con los 8 primeros vectores de la tabla de vectores que se vieron antes), si el resultado es 0, se considera que el código el válido y se arranca, en caso contrario se entra en modo programación (como si el pin ISP hubiese estado a masa).



El programa que se ha utilizado para tostar el LPC810 es el lpc21isp (open source) y éste ya se encarga de calcular el valor que debe tener la posición de memoria correspondiente al vector de interrupción 7 para que la suma de los 8 primeros vectores valga 0. Ni en el linker script ni en el código fuente hay que preocuparse por este valor.

Fichero de startup y linker script

En anteriores posts en los que se abordaba la programación de otro microcontrolador de la familia ARM Cortex-M (el K20 de Freescale, de la placa Teensy), utilizaba una combinación de código ensamblador y de código C para realizar la secuencia de arranque. En este caso se ha optado por abordar el código de arranque (startup) sólo en lenguaje C/C++ para facilitar la claridad. Recordemos, antes de seguir, que el formato de fichero objeto (.o) y el formato ejecutable (.elf) de salida del gcc organizan su contenido por secciones. Las secciones básicas de cualquier fichero objeto o ejecutable ELF son las siguientes:

- “.text”, que es la sección que incluye el código.
- “.data”, que es la sección que incluye las variables globales inicializadas.
- “.bss”, que es la sección que incluye las variables globales sin inicializar (realmente sí se inicializan, pero a cero).

La secuencia de arranque que se sigue normalmente en cualquier sistema embebido para los programas hechos con gcc la podemos resumir como sigue:

1. Se copia la parte de la flash que incluye las variables globales en RAM (sección “.data” de los ficheros objeto).

2. Se inicializa a cero la parte de la RAM en la que van alojadas las variables sin inicializar (sección “.bss” de los ficheros objeto).

3. Se recorre la lista de punteros a funciones acabada en 0 alojada en la sección “.ctors”. Cada entrada es una función que hay que invocar.

4. Se recorrer la lista de punteros a funciones alojada en la sección “.init_array”. Cada entrada es una función que hay que invocar.

5. Se invoca a la función “main”.

6. Al terminar “main” (cosa que no suele ocurrir en un microcontrolador) se recorre la lista de punteros a funciones alojada en la sección “.fini_array”. Cada entrada es una función que hay que invocar.

7. Por último se recorre la lista de punteros a funciones (acabada en 0) y alojada en la sección “.dtors”.

8. En este instante se supone que se regresa al sistema operativo, pero como somos un sistema embebido nos “colgamos” (while (true) ; )

Se puede observar que las secciones “.ctors” y “.init_array” sirven para lo mismo, igual que las secciones “.dtors” y “.fini_array”. Hace algunos años gcc utilizaba las secciones “.ctors” y “.dtors” pero en las ultimas versiones esta usando las secciones “.init_array” y “.fini_array” (dejando las correspondientes “.ctors” y “.dtors” vacias) por compatibilidad y homogeneidad con la librería de C de GNU (glibc).

Siguiendo los pasos descritos, podemos escribir nuestro fichero de arranque “startup.cc”. Dentro de este código fuente, la función “void _startup()” es el punto de entrada:

void _startup() __attribute__((section(".startup"), naked));

void _startup() {
	_initDataRAM();
	_initBssRAM();
	_initClock();
	_callConstructors();
	_callInitArray();
	main();
	_callFiniArray();
	_callDestructors();
	while (true)
		;
}


Como se puede apreciar la función “void _startup()” tiene definidos los atributos.

- section(“.startup”)
- naked

Los atributos son una característica exclusiva de gcc (no forman parte del estándar del lenguaje C) y permiten controlar de forma fina la generación del código por parte del compilador gcc. En este caso se le dice al compilador que el código de la función “void _startup()” no lo coloque en la sección estándar “.text” (que es, por defecto, donde va el código), sino que lo coloque en una sección aparte y que llame a dicha sección “.startup”. El atributo “naked” le indica al compilador que no genere código preámbulo ni postámbulo para la función (preparación de la pila para variables locales, etc.), en otras palabras: le estamos diciendo al compilador que se limite a generer el código del cuerpo de la función, que el resto será responsabilidad nuestra.

¿Qué sentido tienen estos atributos? El poner el código de esta función en una sección aparte llamada “.startup” nos permite forzar en el linker script a que el código de esta función se sitúe al principio del vector de reset, mientras que el atributo naked nos permite reducir al mínimo ese código (no necesitamos código preámbulo ni postámbulo puesto que esa función no es llamada por nadie ni termina nunca).

SECTIONS {
	. = 0x00000000 ;
	.cortex_m0plus_vectors : {
		LONG(0x10000400);
		LONG(0x000000C1);
	}
	. = 0x0000003C ;
	.cotex_m0plus_vector_systick : {
		LONG(SYSTICK_ADDRESS + 1);
	}
	. = 0x000000C0 ;
	.text : {
		_linker_code = . ;
		startup.o (.startup)
		*(.text)
		*(.text.*)
		*(.rodata*)
		*(.gnu.linkonce.t*)
		*(.gnu.linkonce.r*)
	}
	SYSTICK_ADDRESS = . ;
	.systick : {
		*(.systick)
	}

	...

}

Como se puede ver para la tabla de vectores sólo hace falta definir los dos primeros valores (puntero de pila y vector de reset). El vector de reset está fijado a 0xC1 ya que el código de startup empieza en la posición de memoria 0xC0 (justo después de la tabla de vectores en los LPC810). En la tabla de vectores se ponen las direcciones con el bit 0 a 1 ya que se trata de un ARM Cortex-M y sólo soporta el juego de instrucciones Thumb (16 bits por instrucción).

La función “_startup” ademas de los pasos descritos (“.data”, “.bss”, “.init_array”, etc.) se encarga también de configurar el reloj del sistema en el LPC810 para que vaya a la máxima frecuencia permitida. En el arranque, el LPC810 utiliza su reloj interno RC, que va a 12 MHz. Estos 12 MHz pueden aumentarse configurando la PLL hasta llegar a los 30 MHz

Inicialización de variables globales

La función “void _startup()” invoca a varias funciones antes y después de invocar la función “main()”. La función “void _initDataRAM()” inicializa las variables globales inicializadas (que no están a cero) copiando una parte de la memoria flash hacia la RAM:

extern "C" {
	extern unsigned char flash_sdata;
	extern unsigned char ram_sdata;
	extern unsigned char ram_edata;
}

void _initDataRAM() {
	// init .data section (global variables) with flash data
	unsigned char *from = &flash_sdata;
	unsigned char *to = &ram_sdata;
	while (to != &ram_edata) {
		*to = *from;
		from++;
		to++;
	}
}


Mientras que la función “void _initBssRAM()” llena de ceros la zona de la memoria RAM indicada por la sección “.bss” (variables sin inicializar).

extern "C" {
	extern unsigned char ram_sbssdata;
	extern unsigned char ram_ebssdata;
}

void _initBssRAM() {
	// init .bss section with zeros
	unsigned char *p = &ram_sbssdata;
	while (p != &ram_ebssdata) {
		*p = 0;
		p++;
	}
}


A continuación las funciones “void _callConstructors()” y “void _callInitArray()” son las encargadas de llevar a cabo las inicializaciones “complejas”, invocando una o a una cada una de las funciones incluidas en la lista correspondiente (“.ctors” y “.init_array”). Estas llamadas se encargan de hacer estas inicializaciones (por ejemplo, cuando declaramos un objeto global, es preciso llamar a su contructor antes de que se ejecute la funcion “main”).

Prueba de concepto: parpadeo

Como prueba de concepto se ha desarrollado un pequeño programa muy sencillo que hace parpadear un led conectado a uno de los pines del integrado. Lo único que necesitamos es una toolchain con el target “arm-none-eabi” configurado (aquí los pasos para compilar una desde cero). Para controlar el parpadeo se ha usado la interrupción SysTick, esta interrupción está disponible en todos los ARM Cortex-M y consiste en un timer con un contador descendente de 24 bits que, cuando llega a 0, dispara dicha interrupción SysTick y vuelve a cargarse con el valor inicial.



1. En el linker script “lpc810.ld” incluimos una sección especial, que denominamos “.systick” y hacemos que la entrada 15 de la tabla de vectores (dirección de memoria 0x0000003C) apunte a la dirección de la memoria flash donde residirá la sección “.systick”.

SECTIONS {
	. = 0x00000000 ;
	.cortex_m0plus_vectors : {
		LONG(0x10000400);
		LONG(0x000000C1);
	}
	. = 0x0000003C ;
	.cotex_m0plus_vector_systick : {
		LONG(SYSTICK_ADDRESS + 1);
	}
	. = 0x000000C0 ;
	.text : {
		_linker_code = . ;
		startup.o (.startup)
		*(.text)
		*(.text.*)
		*(.rodata*)
		*(.gnu.linkonce.t*)
		*(.gnu.linkonce.r*)
	}
	SYSTICK_ADDRESS = . ;
	.systick : {
		*(.systick)
	}

	...

}

2. En el código fuente de nuestro programa definimos una función “systick” (aunque podemos ponerle el nombre que queramos) y mediante los atributos de GCC, le decimos al compilador que debe ir alojada en la sección “.systick”.

void systick()  __attribute__ ((section(".systick")));

Esto hace que nuestra función “systick” quede alojada en la seccion “.systick” de la memoria de programa. El vector de interrupción 15 apuntará, por tanto, a esta función “systick”.

3. En el cuerpo de la función “void systick()” simplemente escribimos un 1 en el bit 2 del registro “NOT0”. Escribir un 1 hace que el bit PIN0_2 cambie de estado.

void systick() {
	// change PIO0_2
	NOT0 = (1 << 2);
}

4. En la función “int main()” configuramos el PIN0_2 como pin de salida GPIO, configuramos el SysTick para que utilice reloj del sistema / 2 como fuente de reloj y en el registro de cuenta metemos el valor 15000000 (el reloj del sistema va a 30 MHz, por lo que si contamos hasta 15000000 usando un reloj de 30/2 = 15 MHz, tendremos una interrupción por segundo).

// PIN0_2 is output
PINENABLE0 = 0xFFFFFFBF;
DIR0 = (1 << 2);
// enable systick for interval = 1 second at 30 MHz
SYST_RVR = 15000000ULL;
SYST_CVR = 0;
SYST_CSR |= 0x03;   // clock source for systick is system clock / 2 = 15 MHz

5. A partir de este instante la funcion “systick” será invocada internamente una vez por segundo, provocando el parpadeo. Lo lógico ahora es “no hacer nada”, aunque hay varias formas de no hacer nada. Se puede siemplemente hacer un blucle infinito de toda la vida:

while (true)
        ;

Aunque en este caso lo más adecuado sería poner el procesador en algún modo de baja potencia para que esté medio dormido entre invocación e invocacion de la interrupción “systick”. Un término medio entre ambas aproximaciones es usar la instrucción “WFI” (Wait For Interrupt”) que hace que parte del procesador se pare (no avanza ni siquiera el contador de programa) hasta que se dispare alguna interrupción.

while (true) {
	// WFI (wait for interrupt) instruction, enters low power mode
	asm volatile ("wfi");
}



Todo el código fuente puede descargarse de la sección soft.

[ añadir comentario ] ( 2302 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente
  |    |    |    |   ( 3 / 2136 )

<< <Anterior | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | Siguiente> >>