buen día a todos. como el titulo lo dice quiero crear un archivo en una microSD y guardar un array con 48,960 elementos, como ven. son demasiados elementos entonces no cabrían en la memoria eeprom de arduino (y necesito almacenar al menos 3 arrays de ese tamaño), ustedes preguntaran por que tantos elementos. Y la respuesta es que esos arrays contendran la información de imágenes de 240204, de una pantalla que no es la ili.. o alguna que ya tenga librerías de arduino, ya tengo un programa que me enciende la pantalla, dibuja lineas, etc. pero necesito desplegar imágenes y como no puedo contener tanta información en la SRAM, la solución que tengo en mente es crear un archivo en una microSD que contenga todos esos valores hexa decimales.
pero no soy muy bueno con el manejo de arrays. tengo en mente algo como:
1 accede al archivo en la microSD
2 accede al primer carácter(que equivale al color rojo)
3 lo guarda en el buffer.(con desplazamiento de 11 bit a la derecha)
4 accede al segundo carácter.(equivalente al color verde)
5 lo desplaza 4 bits a la izquierda y lo suma al buffer
6 accede al tercer carácter.(equivalente al color azul)
7 lo suma al buffer
8 enviar lo contenido en el buffer por SPI(si la pantalla funciona por SPI)
y debe hacer lo con los (240204)= 48960 pixeles, 3 valores en hexadecimal por cada pixel.
claro que si existe alguna forma de guarda hexa decimales de 4 posiciones (16bit) solo serian 48 960 elementos si no eso por 3.
encontré esta guía, pero no me sirve de mucho por que utilizan pantallas con librerias existentesen arduino y dado que la mia no es tiene libreria no me es de mucha utilidad. https://www.prometec.net/shield-mega-tft-imagen/
espero alguien entienda mi enfoque, gracias.
Supongo que a esa pantalla lo que le transmites son los tres "canales" de cada pixel, y que el modo de operar está de tal forma que el flujo de datos corresponde a la información de cada uno de los 48960 pixeles (sin tener que especificar coordenadas); algo así como un "modo bitmap".
Se puede incluso almacenar los datos de cada pixel en su forma binaria, así los archivos son más pequeños, menos carga para el Arduino, y por ende se carga la imagen más rápidamente. Si la resolución, paleta de colores, y método de codificación de la imagen, son constantes; entonces es posible hasta predecir cual debería ser el tamaño del archivo y hasta obtener la información de un único pixel en determinada posición X y Y.
Es fácil: recuerda que una imagen es una matriz bidimensional; entonces, si un pixel ocupa n bytes, una fila de esa matriz requerirá n*240 bytes. En otras palabras: cada n*240 bytes del archivo representan una fila completa de la imagen (pixeles en una línea X cuya posición Y depende del orden en que se lea este vector).
Como la imagen se compone de 204 filas, el tamaño total del archivo debe ser de al menos n240204 bytes; recordando que n es la cantidad de bytes necesarios para representar un único pixel.
PD: ¿por qué hablas de desplazar bits? ¿La paleta de colores no es de 24 (8 rojo, 8 verde y 8 azul)?
No la paleta es de 16 bits RGB565, gracias encontré una forma de hacer muy lenta pero sirve, codificando cada componente como un ASCII(para poder guardar en la microSD), por que no encontré información de alguna libreria de arduino que logre manejar ficheros codificados con unicode16 bits.
la forma con lo que consegui hacerlo es bastante ineficiente en cuanto a lectura y peso de los archivos, pero sirve.
Saludos
Porque no miras el post de TFTLCD en hardware y los que ha escrito junto con LightCalamar en Documentación y usas una pantalla FT8XX que puede almacenar imagenes y no tendrás que lidear con los problemas que detallas.
Esta todo explicado, asi que te lo aconsejo.
Si me dices que ya compraste la pantalla te respondo: perderás mas dinero tratando de programar lo que quieres que comprar una solucion de hardware que en poco tiempo te resuelve el problema y ademas tiene la flexibilidad para hacer eso y mas.
Eduardosanchez:
gracias encontré una forma de hacer muy lenta pero sirve, codificando cada componente como un ASCII(para poder guardar en la microSD), por que no encontré información de alguna libreria de arduino que logre manejar ficheros codificados con unicode16 bits.
¿Estas haciendo un programa que haga dicha conversión con el Arduino? ¿O para PC?
Entiendo que la codificación/paleta destino es RGB565, ¿pero cuál es el origen? ¿RGB de 24 bits?
creo que la carga de la imagen a la pantalla sera como dibujarla a mano...
es mi opinion.
Lucario448:
¿Estas haciendo un programa que haga dicha conversión con el Arduino? ¿O para PC?
Entiendo que la codificación/paleta destino es RGB565, ¿pero cuál es el origen? ¿RGB de 24 bits?
Hola Lucario, Utilizo un scrip creado en un programa llamado Octave(como e Mathlab pero version gratuita), ahi puedo cargar imagenes png y convertirlas a formato RGB565.
surbyte:
Porque no miras el post de TFTLCD en hardware y los que ha escrito junto con LightCalamar en Documentación y usas una pantalla FT8XX que puede almacenar imagenes y no tendrás que lidear con los problemas que detallas.
Esta todo explicado, asi que te lo aconsejo.Si me dices que ya compraste la pantalla te respondo: perderás mas dinero tratando de programar lo que quieres que comprar una solucion de hardware que en poco tiempo te resuelve el problema y ademas tiene la flexibilidad para hacer eso y mas.
Jajaja te parecera genial lo que he creado IMG_20180220_152308.jpg - Google Drive
jajaja tarde algunos meses pero ESTA VIVO! y al ver la imagen entenderas por que no es cualquier pantalla.
Si no me equivoco, tu problema ahora es el siguiente:
Eduardosanchez:
No la paleta es de 16 bits RGB565, gracias encontré una forma de hacer muy lenta pero sirve, codificando cada componente como un ASCII(para poder guardar en la microSD), por que no encontré información de alguna libreria de arduino que logre manejar ficheros codificados con unicode16 bits.
la forma con lo que consegui hacerlo es bastante ineficiente en cuanto a lectura y peso de los archivos, pero sirve.
Primero que nada, la librería SD lo que maneja son "archivos binarios"; lo que quiere decir que el contenido no necesariamente debe ser solo texto. Para efectos de manipulación, un archivo es básicamente un vector ("array" en inglés) unidimensional de bytes.
Cuando hablamos de "binario", se suele entender que su contenido es completamente arbitrario; en otras palabras, ese conjunto de 1 y 0 podría representar texto, imagen, audio, video, etc; es la aplicación lectora la que interpreta el contenido de dicho archivo según para lo que fue programado.
Por esta razón, es confuso hablar de Unicode de 16 bits (texto) cuando el flujo de bytes se supone que representa una imagen.
Ahora la pregunta es: ¿estás satisfecho con lo que tienes, o todavía buscas cómo mejorar?
Sobre el tamaño del archivo, tenemos que: una imagen se compone de 240*204 = 48960 pixeles; y la paleta de colores es de 16 bits.
Entonces tenemos que se requiere mínimo de 48960 * 2 = 97920 bytes (aprox. 96 KB). Reducir el tamaño aún más sería aplicando alguna forma de compresión; sin embargo, eso ralentizaría la carga ya que el Arduino no tiene suficiente poder de procesamiento (mucho menos memoria RAM) para ejecutar el algoritmo de descompresión sin aumentar el tiempo.
Desconozco el formato en que Octave exporta la imagen, pero sí sé que con los bytes "crudos" el proceso se agilizaría bastante.
El tiempo de carga se puede mejorar de dos formas:
- Mejorando la codificación del archivo resultante.
- Observando el código para buscar todas las formas posibles de optimización.
Hola de nuevo, de echo si quiero mejorar pero pienso que arduino no me es lo suficientemente poderoso, estoy intentando migrar me a los ARM Cortex, y si en realidad lo que hice es crear un archivo codificado en ASCII entonces para un pixel esta formado por 3 letras, con la libreria sdfat puede accesar a cada linea(que para mi es una fila de pixeles,(si si son 240 pixeles son 240*3 caracteres), y bueno una imagen completa tarda como 3 segundos en aparecer.
Saludos.
Ve a humor y debate y lee sobre el STM32
Eduardosanchez:
y si en realidad lo que hice es crear un archivo codificado en ASCII entonces para un pixel esta formado por 3 letras, con la libreria sdfat puede accesar a cada linea(que para mi es una fila de pixeles,(si si son 240 pixeles son 240*3 caracteres), y bueno una imagen completa tarda como 3 segundos en aparecer.
Lo que me temía. Aparte de tener que hacer la conversión de texto a binario, todavía tiene que convertir RGB888 (24 bits) a RGB565 (16 bits).
Creeme, si el archivo solo contuviera los bytes "crudos"; la carga se agilizaría considerablemente.
Lo otro sería (como dije antes) observar el código de la rutina de la carga; posiblemente haya algo que se pueda mejorar.
Lucario448:
Creeme, si el archivo solo contuviera los bytes "crudos"; la carga se agilizaría considerablemente.
Lo otro sería (como dije antes) observar el código de la rutina de la carga; posiblemente haya algo que se pueda mejorar.
Claro entiendo esa parte pero al no tener un conocimiento mas avanzado sobre el manejo de la información tuve que emplear esa opción.
Pero espero pronto lograr entender esos algoritmos quizas ahsta despues pueda decodificar imagenes en png jpg etc..
Saludos.