Proyecto: Cartel RGB 16x256px a 8 colores

[elgarbe]

Te agradeco mucho la respuesta y es tal cual como vos decis Juanjo, no hay forma de que entiendan todo el funcionamiento y aconsejar se torna complicado.
Lo que voy a ir haciendo es poner las implementaciones de las diferentes partes como para que quede registrado y quizá en esas implemetaciones puntuales me puedan aconsejar.

El primer punto que resolví fue el barrido de las filas para que sea automático por interrupcion.
Lo que hice fue elegir 4 salidas (PC4-PC7) contiguas para que sea bien fácil el manejo del decoder. Como decoder y habilitacion del mosfet de cada fila tengo un 74HC138. Entonces con las 4 señales PC4-PC7 voy activando una a una las salidas (poniendo en estado bajo) y habilitando cada mosfet P (necesitan un 0 al ser P).

El código es mas o menos así:

Código: C

1. #include "stm32f4xx.h"
2. #include "stm32f4_discovery.h"
3. #include "main.h"
4.  
5. /* TIMER handler declaration */
6. TIM_HandleTypeDef TIM_Handle;
7.  
8. /* SPI handler declaration */
9. SPI_HandleTypeDef SpiHandle;
10.  
11. volatile uint8_t ui8FilaActual=0;
12.  
13. int main(void)
14. {
15.         uint64_t MC = 0;
16. //      uint8_t i;
17.  
18.         /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
19.         HAL_Init();
20.  
21.         /* Configure the system clock */
22.         SystemClock_Config();
23.  
24.         GPIO_Init();
25.         TIM4_Config();
26.  
27.         MC |= 0x03 << 00;                               // MC = 11.6-8.1 mA
28.         MC |= 0x7F << 03;                               //BC Red = 100%
29.         MC |= 0x7F << 10;                               //BC Green = 100%
30.         MC |= 0x7F << 17;                               //BC Blue = 100%
31.                                                                         //SID = 0; LODVLT=0; LSDVLT=0; PSMODE=0 (no PWS)
32.         MC |= (uint64_t)0x96 << 40;             //WRITE_CMD: Bits 40 a 47 en 10010110b
33.         MC |= (uint64_t)0x01 << 48;             //Data Select Bit = 1
34.  
35.         send_config(MC);
36.         send_config(MC);
37.  
38.         while(1)
39.         {
40.                 efecto_02(500);
41.         }
42. }

La configuracion del timer:

Código: C

1. /*
2.  * Si quiero obtener 120Hz tengo que cambiar de línea 16x120 = 1920 Veces por segundo.
3.  * Necesito interrupcion cada 520uSeg.
4.  */
5. void TIM4_Config()
6. {
7.     __TIM4_CLK_ENABLE();
8.  
9.     TIM_Handle.Init.Prescaler = 42 - 1;         //El Clk del timer está en 84MHz. Lo reduzco a 2MHz
10.     TIM_Handle.Init.CounterMode = TIM_COUNTERMODE_UP;
11.     TIM_Handle.Init.Period = 1040;                      //1040 cuentas hasta interrupcion. 520 uSeg
12.     TIM_Handle.Instance = TIM4;                         //
13.     HAL_TIM_Base_Init(&TIM_Handle);             // Init timer
14.  
15.     HAL_TIM_Base_Start_IT(&TIM_Handle);         // start timer interrupts
16.  
17.     HAL_NVIC_SetPriority(TIM4_IRQn, 0, 1);
18.     HAL_NVIC_EnableIRQ(TIM4_IRQn);
19. }

y en la interrupcion:

Código: C

1. /*
2.  * Si miro en el osciloscopio la señal Ade direccion (PC4) tengo que ver un período de 2x 520useg
3.  * ya que en cada interrupcion esa señal cambia de valor. El periodo será entonces de 1.04 mseg y una F
4.  * de 961.5 Hz
5.  * VERIFICADO CON OSCILLOSCOPIO.
6.  */
7. void TIM4_IRQHandler(void)
8. {
9.     if (__HAL_TIM_GET_FLAG(&TIM_Handle, TIM_FLAG_UPDATE) != RESET)      //In case other interrupts are also running
10.     {
11.         if (__HAL_TIM_GET_ITSTATUS(&TIM_Handle, TIM_IT_UPDATE) != RESET)
12.         {
13.             __HAL_TIM_CLEAR_FLAG(&TIM_Handle, TIM_FLAG_UPDATE);
14.  
15.             GPIOC->ODR &= ~(0xF << OFFSET_VERT_PINS);           //Pongo en 0 los 4 bits del barrido Vertical
16.             GPIOC->ODR |= ui8FilaActual<< OFFSET_VERT_PINS;
17.             ui8FilaActual++;
18.             if(ui8FilaActual == 16)
19.                 ui8FilaActual=0;
20.         }
21.     }
22. }

Con esto consigo que el panel esté constantemente barriendo de forma horizontal y en la variable ui8FilaActual tengo la fila actual (en realidad tengo la proxima fila a activar.

Entonces si quiero provar de encender el panel completo de colores tengo este efecto:

Código: C

1. void efecto_02(uint16_t velocidad)
2. {
3.         uint8_t j;
4.  
5.         for(j=0;j<3;j++)
6.         {
7.                 HAL_Delay(velocidad);
8.                 if(j==0)
9.                 {
10.                         all_R();
11.                 }
12.                 else if(j==1)
13.                 {
14.                         all_G();
15.                 }
16.                 else
17.                 {
18.                         all_B();
19.                 }
20.  
21.         }
22. }
23.  
24. void all_R(void)
25. {
26.         send_data(0x0000249249249249, 0x0000249249249249);
27. }
28.  
29. void all_G(void)
30. {
31.         send_data(0x0000492492492492, 0x0000492492492492);
32. }
33.  
34. void all_B(void)
35. {
36.         send_data(0x0000924924924924, 0x0000924924924924);
37. }

De este modo cuando envío el dato para encender los 32 led de la fila en color rojo, al estar barriendo verticalmente obtengo el encendido del panel entero.

El paso siguiente sería poder sacar los datos por el SPI, paso previo para arar el buffer de video y habilitar el DMA.

Saludos!

[KILLERJC]

Como que me perdi completamente. Estuve leyendo y por mas que lo lei despacio a los ultimos 2 post me perdi feo.

Hasta ahora lo que entendi fue:

- Crear un buffer de [16][98] El cual tenga todos los bits incorporados. Asi con el DMA enviarlo por el SPI. Y da justo el tamaño en bits.
- Al tema de las filas las activas con 2 74HC138, 3-to-8 decoder Necesitas 16 filas, asi que son 2, o tal ves estes usando uno solo y activas 2 filas a las ves.
- Las filas estan activadas por un temporizador, el cual dispararia el DMA para que envie todos los datos, tal ves con acceso a una memoria Externa. Sino son 1.6Kb de unicamente el buffer de video. ( Puede entrar tranquilamente tal ves en el micro y no necesitar esa memoria externa ).

Lo que no me quedo claro es... que intentas hacer con el buffer, queres cambiarlo "on-the-fly"? Creo haber leido que decias que eran 2 textos nomas. Queres generarlos cuando comienza el micro? o va a estar guardado en algun lugar? Solo es texto ? o imagen ?.
Por todo esto me encuentro muy perdido xD.

[juaperser1]

Me recuerda un poco a la forma de refrescar un display de segmentos que hice, solo que lo hice de una forma un poco diferente, no trataba los display como digitos si no como led, es decir cada digito tenia 8 led, y tenia un total de 8x4=32 led, y la función era mas compleja de esta forma pero podía encender los segmentos como me daba la gana con una función que cambiaba los datos a representación a led, lo tuyo es mucho mas complejo pero en esencia es parecido.

te falta hacer esa función que cambie texto o imágenes a led.

un saludo

[elgarbe]

Como que me perdi completamente. Estuve leyendo y por mas que lo lei despacio a los ultimos 2 post me perdi feo.

Hasta ahora lo que entendi fue:

- Crear un buffer de [16][98] El cual tenga todos los bits incorporados. Asi con el DMA enviarlo por el SPI. Y da justo el tamaño en bits.
- Al tema de las filas las activas con 2 74HC138, 3-to-8 decoder Necesitas 16 filas, asi que son 2, o tal ves estes usando uno solo y activas 2 filas a las ves.
- Las filas estan activadas por un temporizador, el cual dispararia el DMA para que envie todos los datos, tal ves con acceso a una memoria Externa. Sino son 1.6Kb de unicamente el buffer de video. ( Puede entrar tranquilamente tal ves en el micro y no necesitar esa memoria externa ).

Lo que no me quedo claro es... que intentas hacer con el buffer, queres cambiarlo "on-the-fly"? Creo haber leido que decias que eran 2 textos nomas. Queres generarlos cuando comienza el micro? o va a estar guardado en algun lugar? Solo es texto ? o imagen ?.
Por todo esto me encuentro muy perdido xD.

El problema no son ustedes, soy yo que digo una cosa y despues otra.
Los primeros 2 puntos son correctos, pero son 98bytes porque cada TLC necesita 49 bits (2*49 * 8)bits. De esos 49 bits, 48 son informacion de ON/OFF de cada salida y 1 bit para indicar si son datos o comando. Al ser 2*8 TLC's los bits adicionales me agregan 2byte a lo que sería un buffer de video con solo datos on/off (3 * 256bits = 96 byte)

Ahora bien, el cartel que vendimos, es bien sencillo, solo 2 textos, que entran se cargan por USB y entran en la RAM enteros los dos. Entonces podría resolver solo esta aplicacion haciendo que la aplicacion de la PC haga todos los cálculos a nivel de bit's y mande los 16x98 bytes listos para que lo tome el DMA.
Peeeero, siempre hay un pero, me gustaría hacer algo lo más genérico posible para resolver esta aplicacion y cualquiera otra que quiera, ya que estos paneles son "standar" y espero poder usarlos en varios proyectos o hasta venderlos como módulos de led RGB para terceros.

Entonces la respuesta es si, tengo que tratar de cambiar el texto on the fly.

Teniendo en cuenta eso hay 3 puntos claves que definen el proyecto:

• Los TLC necesitan 49 bits, siendo 48 info util real. Esto me da a pensar en 2 buffer. Uno de video con 16x96 bytes con solo info de video. En este buffer las funciones de alto nivel escriben texto/gráfico. Estas funciones son standar y puedo reutilizar cualquier librería gráfica
• El segundo buffer es el real que necesitan los TLC. Este posee 16x98 bytes (para mi cartel) y encima cada 6byte tengo 6bytes que tengo que invertir debido al error de hard que cometi con el conector. El pasaje del otro buffer a este son movimientos de bits, eso estaría bueno hacerlo en asembler creo
• El timer se encarga del barrido vertical y la idea es, envío la fila actual por DMA (siguiendo un flag) y cuando el timer interrumpe, cambio de fila y mando la señal de LATCH para mostrar lo que ya está en los registros internos de los TLC.

Saludos!

[KILLERJC]

Si Eso pensaba yo, la libreria grafica que hagas debe hacer ese "buffer" de [16][96]. Seria lo mas facil de crear, pero luego incorporarle el 0 a todo ese array es EL dolor de cabeza. Yo no entiendo al tipo que se le ocurrio hacerlo de esa forma... de usar 49 bits siendo que un SPI envia de a 8.  Entonces tenes que crear una funcion que transforme 48 bytes en 49bytes (2 de estos y tenes tus 98 bytes) Y esa parte es el dolor de cabeza y mas consumidor de tiempo del core. Obviamente todos punteros Por ahi estoy pensando en comenzar de atras, es decir desde el byte 49, un contador el cual su AND va a servir para ambos bytes trabajados, el que esta y el que le sigue,. Fiero fiero muy fiero por que feo es poco, muchos AND , Pero va a ser un loop pequeño, eso es lo bueno

[elgarbe]

Si Eso pensaba yo, la libreria grafica que hagas debe hacer ese "buffer" de [16][96]. Seria lo mas facil de crear, pero luego incorporarle el 0 a todo ese array es EL dolor de cabeza. Yo no entiendo al tipo que se le ocurrio hacerlo de esa forma... de usar 49 bits siendo que un SPI envia de a 8.  Entonces tenes que crear una funcion que transforme 48 bytes en 49bytes (2 de estos y tenes tus 98 bytes) Y esa parte es el dolor de cabeza y mas consumidor de tiempo del core. Obviamente todos punteros Por ahi estoy pensando en comenzar de atras, es decir desde el byte 49, un contador el cual su AND va a servir para ambos bytes trabajados, el que esta y el que le sigue,. Fiero fiero muy fiero por que feo es poco, muchos AND , Pero va a ser un loop pequeño, eso es lo bueno

Podrían haver puesto un pin más para distinguir dato/comando, no?

[KILLERJC]

Exactamente lo que yo pensaba.. En que habran pensado cuando lo hicieron.... hasta las memorias vienen en bytes y estos tipos se complican asi. Tal ves era para eliminar otro pin de control. Pero gracias a eso destruyeron lo bueno del sistema de shift-registers.

Por otro lado mirando el datasheet de mi micro, posee la seleccion de distintos valores tamaño de datos a enviar en el SPI. En ves de ser de 8 SI o SI podria hacerlos de 4 a 16 bits en el modo comun, nada de QSPI o Bi-SPI. Tal ves jugando un poco con esto se podria hacer 5 de 8 bits + 1 de 9 bits. Raro, normalmente estoy acostumbrado a solo 8 bits xD, Y feo por que hay que estar cambiando el tamaño del envio lo cual lo hace horrible y no manejable por el DMA

Con lo cual!!!!!!! tambien es posible hacerlo de 7 bits, y no de 8. Entonces te llevaria a enviar 7 de 7 bits y tenes los 49 bits enviados. lo que si pasa a ser un buffer de [16][112] ( ya que desperdicias el LSB - 224 bytes mas )

Y por ultimo no se que es mas facil, si la libreria grafica genere los [16][96] y luego lo transforme en [16][98] o [16][112].

Ventajas y Desventajas:

a 7 bits (14 puede ser): Mas RAM necesario para el buffer de salida pero no importa cuantos TCL tengas, siempre siempre va a ser valido.

a 8 bits (Mejor 16 que es lo mismo ): Menos RAM necesario para el buffer de salida, pero para que funcione debe haber un multiplo par de TCL. Lo cual tenes implementado

Cosas que se me ocurren xD

[elgarbe]

El stm32f411 (un M4F) puede transmitir 8 o 16 bits por frame.
Pero el LPC11u67 (M0+) puede transmitir de 4 a 16 bits. Este micro es mucho más acorde para esta aplicacion. Estoy probando con el 411 por que tengo esa placa de evaluacion....

El tema de 7 bits u 8 bits.... lo tengo que pensar un poco más. Ahora lo que si creo que tengo que separar el buffer de video con el buffer que va a usar el DMA con el SPI para sacar los datos y hacer una funcion de acomodar los bits. Por que incluso los datos de los TLC pares tengo que invertir los 48bits por la cagada del conector alereves.

Otro tema es la codificacion del color del pixel y la codificacion de la fuente. Por cada pixel necesito 3 bits. Entiendo que en el buffer de video lo tengo que considerar así. Pero la fuente estimo que la tengo que hacer monocromática y la funcion que graba el texto en el buffer de video debería tener como parámetro el color y transformar cada bit de la fuente en los 3 bits que corresponden al color. Me explico?

Saludos!

[juaperser1]

oye leonardo y ¿si el color se lo pones en una matriz de 3 dimensiones? la 3 dimensión seria el color.

un saludo

[elgarbe]

oye leonardo y ¿si el color se lo pones en una matriz de 3 dimensiones? la 3 dimensión seria el color.

un saludo

mmmm, tendría que pensarlo un poco a ver como implementarlo y las ventajas de trabajar así...

[elgarbe]

Hace un tiempo estuve trabajando con un OSD para un estabilizador de vuelo (http://www.todopic.com.ar/foros/index.php?topic=42254.0) y tuve que trabajar con algo de video.

En ese momento, la idea era más o menos esta:

Definicion del buffer de video:

Código: C

1. #define PIX_Y       16         //Reveer PIX_Y y LAST_LINE. Ver en extint.c
2. #define PIX_16_X    2
3. #define FNT3_H      14          //Pixel heigh for Font 3
4.  
5. extern const short fnt3[];
6. uint16_t membuff1[PIX_Y][PIX_16_X];

parte de la fuente es esta:

Código: C

1. // Character bitmaps for Berlin Sans FB Demi 12pt
2. const uint16_t fnt3[] =
3. {
4.     // @0 ' ' (14 pixels wide)
5.     0b0000000000000000, //
6.     0b0000000000000000, //
7.     0b0000000000000000, //
8.     0b0000000000000000, //
9.     0b0000000000000000, //
10.     0b0000000000000000, //
11.     0b0000000000000000, //
12.     0b0000000000000000, //
13.     0b0000000000000000, //
14.     0b0000000000000000, //
15.     0b0000000000000000, //
16.     0b0000000000000000, //
17.     0b0000000000000000, //
18.     0b0000000000000000, //
19.  
20.     // @0 '!' (14 pixels wide)
21.     0b0000000110000000, //        ##
22.     0b0000000110000000, //        ##
23.     0b0000000110000000, //        ##
24.     0b0000000110000000, //        ##
25.     0b0000000110000000, //        ##
26.     0b0000000110000000, //        ##
27.     0b0000000110000000, //        ##
28.     0b0000000110000000, //        ##
29.     0b0000000000000000, //
30.     0b0000000110000000, //        ##
31.     0b0000000110000000, //        ##
32.     0b0000000000000000, //
33.     0b0000000000000000, //
34.     0b0000000000000000, //
35.  
36.     // @28 '"' (14 pixels wide)
37.     0b0000011011000000, //      ## ##
38.     0b0000011011000000, //      ## ##
39.     0b0000011011000000, //      ## ##
40.     0b0000011011000000, //      ## ##
41.     0b0000000000000000, //
42.     0b0000000000000000, //
43.     0b0000000000000000, //
44.     0b0000000000000000, //
45.     0b0000000000000000, //
46.     0b0000000000000000, //
47.     0b0000000000000000, //
48.     0b0000000000000000, //
49.     0b0000000000000000, //
50.     0b0000000000000000, //
51. ......

Y tenía 2 funciones básicas para imprimir caracteres/texto en ek buffer:

Código: C

1. void put_char(short X, short Y, char Car);
2. void put_string(short X, short Y, char *pcString);
3.  
4. void put_char(uint16_t X, uint16_t Y, char Car){
5.         uint16_t i;
6.  
7.         for(i=Y; i<(Y+FNT3_H); i++)
8.                 membuff1[i][X] = fnt3[(Car - 32) * FNT3_H + (i-Y)];
9. }
10.  
11. // ***********************
12. // Funcion para enviar una cadena de caracteres
13. void put_string(uint16_t X, uint16_t Y, char *pcString){
14.         int i = 0;
15.         // loop through until reach string's zero terminator
16.         while (pcString[i] != 0) {
17.                 put_char(X, Y, pcString[i]); // print each character
18.                 X++;
19.                 i++;
20.         }
21. }

como ven la funcion put_string es totalmente portable, de echo es copia de una funcion para LCD. Acá lo importante es la implementacion del put_char.
El secreto de put_char está la referenciación del código ASCII del caracter a escrivir con la posicion del primer uint16_t de dicho caracter.
Como la fuente arranca por el " " (ASCII 32) al código ascii del caracter a imprimir le restamos 32. Luego lo multiplicamos por la altura de la fuente. Esto es porque cada FNT3_H (14 en este caso) uint's16_t tenemos la primer fila del siguiente caracter. Luego hay un offset que tiene en cuenta la Fila actual y el lazo for que recorre las 14 filas que compone un caracter en la fuente que creamos.

Entonces si en el main hacemos:

Código: C

1. put_string(0, 0, "elgarbe");

conseguiríamos que esos caracteres se almacenen en el buffer de video (membuff1). El problema de este método es que la coordenada X no es en pixeles, sino que es en caracteres y el ancho del caracter está puesto en la fuente elegida. En este caso era para imprimir en una pantalla de monitor y una fuente de 16x 14 era mas o menos linda (aunque la relacion no parece que quede linda, 16 de ancho por 14 de alto?). Para este cartel necesito una fuente de 8x12 más o menos... Como hacer las fuentes lo mostraré despues. Por ahora solo plantear la idea de llenado de buffer.

Dibujar un punto no es mucho más dificil:

Código: C

1. //-----------------------------------------------------------------------
2. // Dibuja un pixel
3. //-----------------------------------------------------------------------
4. void OSD_punto(unsigned short x, unsigned short y, char color){
5.     short CarX;
6.     char PosCar;
7.  
8.     CarX = x/16;                                //Calculo en que Short cae el pixel
9.     PosCar = 15-( 16 * ((float)x/16 - CarX));   //Calculo la posicion dentro del Short del pixel
10.     x = (unsigned short)(1<<(PosCar));            //Armo el Short con ese pixel encendido
11.     membuff1[y][CarX] |= x;                     //Pongo el Short completo en el buffer
12. }

En este caso hay que tener encuenta que el buffer almacena uint16_t por lo que un punto en X debe ser referenciado a un bit dentro de los uint16's_t que forman una fila del cartel.

Y dibujar una línea?
Pues implementaciones standares:

Código: C

1. //-----------------------------------------------------------------------
2. // Dibuja una linea desde (x1,y1) a (x2,y2) de color (0 o 1)
3. //-----------------------------------------------------------------------
4. void OSD_linea(unsigned short x1, unsigned short y1, unsigned short x2, unsigned short y2, char color)
5. {
6.    //Declaro variables-------------------
7.    signed short  x, y, incremento_x, incremento_y, distancia_x, distancia_y;
8.    signed short P;
9.    short i;
10.  
11.    //Calculo las diferencias entre las coordenadas de origen y destino
12.    distancia_x = fabs((signed short)(x2 - x1));
13.    distancia_y = fabs((signed short)(y2 - y1));
14.  
15.    //Inicializo x e y con las coordenadas de origen
16.    x = x1;
17.    y = y1;
18.  
19.    //Calculo el sentido de los incrementos (positivos o negativos)
20.    //en funcion de la posicion del origen y el destino
21.    if(x1 > x2) incremento_x = -1; else incremento_x = 1;
22.    if(y1 > y2) incremento_y = -1; else incremento_y = 1;
23.  
24.    //Si la distancia horizontal es mayor a la vertical...
25.    if(distancia_x >= distancia_y)
26.    { P = 2 * distancia_y - distancia_x;
27.       for(i=0; i<=distancia_x; ++i)
28.       {
29.           OSD_punto(x, y, color);
30.  
31.          if(P < 0)
32.          { P += 2 * distancia_y;
33.             x += incremento_x; }
34.          else
35.          { P += 2*distancia_y - 2*distancia_x;
36.             x += incremento_x;
37.             y += incremento_y;}
38.       }
39.    }
40.  
41.    //Si la distancia vertical es mayor a la horizontal...
42.    else
43.    { P = 2 * distancia_x - distancia_y;
44.       for(i=0; i<=distancia_y; ++i)
45.       { OSD_punto(x, y, color);
46.          if(P < 0)
47.          {  P += 2 * distancia_x;
48.             y += incremento_y; }
49.          else
50.          {  P += 2 * distancia_x - 2 * distancia_y;
51.             x += incremento_x;
52.             y += incremento_y; }
53.       }
54.    }
55. }

Bien, con esto queda planteada la forma de trabajar con el buffer de video. Ahora quedaría la traduccion de color (3bit por cada bit del buffer de video), la inversion de los datos de los TLC impares y el envío por el SPI.

Saludos!

[juaperser1]

buen ejemplo de modularidad si señor

[KILLERJC]

Vi que leo escribio antes que yo . De todas formas esto es lo que habia escrito

Quedaria algo asi :

Asi:
Buffer Leds: [16][16] - Estos indican solo los leds que se encienden, nada de color
Buffer Color: [3][16][16] - 3 arrays con colores, podria haber resumido un color antes, pero eso implica que un color si o si va.

O asi:
Buffer Color: [3][16][16]

El primero permite un grafico mas simple. ya que solo creas monocromatico y luego le agregas el color como quieras.
El segundo estas olbigado a incluir el color en la parte de graficar.

Tambien en el caso de que no solo sea un bit, sino 8 para un PWM por ejemplo. la parte grafica del primero no cambiaria. solo cambiaria la del color. Esto suponiendo que agregas el color aparte (Lo cual no tenes distincion de si es texto o no lo realizado en el array monocromatico).
Pero si supongamos queres hacer un texto color rojo, por ahi conviene pasarle el color de entrada y tener el 2do caso, complicando un poco mas el tema de la escritura de color

Aun asi te manejarias como si fuera monocromatico cada uno. esto facilita pasar el proceso grafico -> buffer , pero complica lo de generar el buffer -> buffer para TCL , ya que le quitas la parte de juntar los 3 bits y se lo pasas al otro.

[elgarbe]

Entiendo, entiendo... el tema es que me parece que para el buffer de los TLC debe ser una matriz de 2 dimensiones, para poder utilizar el DMA. O sea que cada fila del cartel tiene que ser una sucesion de bits (48 + 1 por TLC) de modo que el DMA los tome y sauqe la fila completa.
En cuanto al buffer de video o gráfico, tendría que ver como son las implementaciones standar. Como manejan por ejemplo las librerías graficas un bmp...

saludos!

[KILLERJC]

Si, yo hablaba solo de la generacion de la parte grafica. es decir pasar de tener un string, pasarlo a un mapa de bits, y que tenga su color.
Luego necesitarias otro codigo que transforme eso en el array que va a usar el DMA. Como empaquetar de a 3 bits, y mas etc.

El bmp
https://en.wikipedia.org/wiki/BMP_file_format

Sino vas a tener que crearte o buscar uno que transforme de BMP a hex xD
La otra posibilidad es que todo lo que vaya a donde se guarda estas "imagenes" por ejemplo. sea generado afuera por una computadora, Y que el micro solo lo unico que haga es leer ( usa SD por ejemplo, o una EEPROM ) llevar a RAM solamente la imagen a mostrar ( se podrian tener 2 buffers, asi mientras se muestra una se llena la otra ) y nada mas. Todo lo demas lo haria el DMA..

Y con eso se podria realizar una muestra de varias imagenes, si hay texto tomarlo como una imagen completa tambien, me refiero no tener un escribir_panel("Hola"), si que directamente cargue la imagen. Si el cliente desea cargar nuevas imagenes o una SD o un USB (pendrive ) que se conecte y asi actualizar la EEPROM con los nuevos datos.

Podes tener en la flash las "imagenes" del menu de configuracion, si es que posee algun menu.
Si queres extenderlo a mas paneles solo agregas un salida/entrada de sincronismo ( suponiendo que pones un integrado cada X paneles)