Problemas de administración de memoria con ATTiny85

3

La configuración es la siguiente:
Tengo un pequeño programa para manejar matrices led de 8x8 de un solo color utilizando 595 registros de desplazamiento que ATTiny85 proporciona datos a través de USI como SPI Master. Subo el programa a ATTiny85 usando Arduino Uno. El programa se compila y carga mediante el complemento Visualmicro para VS2010 o Arduino IDE (ambos con los mismos resultados). El programa compilado tiene una longitud de 2970 bytes (36.3% de la memoria del chip)

Los problemas son:

  1. El problema de la matriz: no puedo declarar la matriz que tiene más de 296 bytes.
    Tengo una matriz que contiene una representación binaria de una fuente para mostrar caracteres en matrices de LED. El tamaño deseado para esta matriz es de 760 bytes. Se declara de la siguiente manera:

    byte font[] =
    {
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Char 032 ( )
        0x30, 0x78, 0x78, 0x30, 0x30, 0x00, 0x30, 0x00, // Char 033 (!)
        ...
        0xE0, 0x30, 0x30, 0x1C, 0x30, 0x30, 0xE0, 0x00, // Char 125 (})
        0x76, 0xDC, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00  // Char 126 (~)
    }// 760 bytes total
    

    Si me refiero al primer elemento de la matriz en el código, recibo el 648º elemento [primer byte del carácter de fuente 113 (q)]. Toda la matriz está en mal estado. Los bloques de 8 bytes o más (n * 8bytes) del contenido de las matrices se mezclan entre sí y con áreas de la memoria que no tienen ninguna relación . Si trato de mostrar texto en las matrices, veo caracteres completamente diferentes o un poco de desorden (creo que lo que realmente veo es el mismo programa que se ejecuta en la memoria; es genial pero inútil). Si reduzco la matriz a 296 bytes, todo funciona bien.

  2. El problema del puntero : para solucionar el problema # 1, dividí la matriz en 3 matrices más pequeñas (296 bytes como máximo). Declaré el puntero para apuntar a la matriz de fuente adecuada dependiendo del carácter a "render". No puedo apuntar este puntero a ninguna matriz dentro del bloque "if"

    char c1='a';  //character to display
    byte font1[]={...};  //binary font representation split in to 3 arrays
    byte font2[]={...};  
    byte font3[]={...};
    byte  ascii_offset1= 32,ascii_offset2= 69,ascii_offset3= 106;  //offset for each array
    byte * font_ptr1=font1; //This works fine. 
    font_ptr1=font3;        //This also worked fine in tests. 
    
    if(c1>=ascii_offset3)  
    {   
        font_ptr1=font3;  //This DOESN'T work at all
        c1-=ascii_offset3
    }
    else ...
    

De hecho, creo que esa línea, comentada como no funciona, en realidad está colgando el ATTiny. No veo nada en las matrices, a excepción de unos pocos LED que se iluminan constantemente.

En el caso del problema # 1, sospecho que el compilador o el enlazador estropea algo. Pero el # 2 es un misterio total para mí. Pensé que tal vez se trata de un desbordamiento de pila, pero de acuerdo con la documentación, el tamaño de la pila está limitado solo por el tamaño de la SRAM, es suficiente y además no asigno ninguna memoria de forma dinámica.

    
pregunta Tomek

2 respuestas

7

Sigue los pasos en esta publicación para verificar tu uso de RAM:

Comprobando la huella de memoria en Arduino

Mi conjetura es que usted ha pasado porque el tamaño de RAM del ATTiny85 es de 512 bytes. En su croquis, font se almacenará en la memoria RAM. Quieres almacenarlo en la memoria del programa FLASH. Siga estas instrucciones para hacerlo:

enlace

    
respondido por el geometrikal
2

Ahora que Geometrikal ha respondido a tu pregunta, he aquí un consejo sobre cómo podrías haberte descubierto: inspecciona el mapa de memoria (también llamado a veces "listado"). Dependiendo de qué compilador esté usando (no estoy familiarizado con el IDE de Arduino, pero avr-gcc / wingcc como el backend que estoy adivinando), por lo general solo toma un parámetro de línea de comandos para que el compilador genere la memoria. mapa también. En los extremos frontales de GCC, la opción para pasar es -Wl,-Map=filename.map

El mapa de memoria es un archivo de texto que consta de símbolos, su dirección de inicio, dirección de finalización y la cantidad de espacio que se utiliza. La salida variará para diferentes compiladores, pero generalmente contendrá al menos esto:

Memory Configuration

Name             Origin             Length             Attributes
text             0x0000000000000000 0x0000000000002000 xr
data             0x0000000000800060 0x000000000000ffa0 rw !x
eeprom           0x0000000000810000 0x0000000000010000 rw !x
fuse             0x0000000000820000 0x0000000000000400 rw !x
lock             0x0000000000830000 0x0000000000000400 rw !x
signature        0x0000000000840000 0x0000000000000400 rw !x
*default*        0x0000000000000000 0xffffffffffffffff

Como una descripción general de cada segmento, y luego una imagen más detallada que dirá el tamaño de cada símbolo, lo que significa cada variable o función utilizada.

Tuviste el presentimiento de que tu problema estaba relacionado con la memoria. Mi reacción natural a esto es generalmente inspeccionar el mapa de memoria y ver si algo se ve mal :)

Si hubiera conocido la limitación de memoria de ATTiny, hubiera buscado en el mapa de memoria y descubrió que algunos arreglos ocupaban 760 bytes en la RAM en lugar de FLASH, lo habrían sabido.

La herramienta size en la suite GNU-binutils también generará el tamaño de cada segmento, pero generalmente no puede generar el tamaño de cada símbolo, ya que ese conocimiento se puede perder durante la compilación.

    
respondido por el Morten Jensen

Lea otras preguntas en las etiquetas

Comentarios Recientes

As. Múltiples fallas de firmware cuando se utiliza la recuperación. Imagen de ROM no válida en el inicio fallido. 3 problemas no relacionados y errores individuales en 15 líneas de código diferentes que dan falsos positivos. Culpo mi error al diseño IDC basado en CPU del ARM Cortex-A53 y Hi-X no puede entender el A53L por esa razón. Se producen muchos accesos al ATTiny138 en el controlador de memoria y creo que he encontrado un acuerdo de E / S realmente estrecho entre esta lógica en la CPU ARMv7 de 32 bits.... Lees verder