Memoria de imagen en microcontrolador [cerrado]

Estoy tratando de especificar un microcontrolador para una tarea muy simple. Todo lo que hace es mostrar una imagen al arrancar (que probablemente será en blanco y negro).

La pantalla en sí es de 240*240 y una profundidad de color de 12 bits, lo que significa que tendría una memoria total de (240*240*12)/(8*1024)=84KB. Esto me parece bastante alto. ¿No debería estar calculando para el peor de los casos? ¿Aquí entran en juego ciertas técnicas de compresión?

Tendré que dejar algo de espacio libre para un gestor de arranque, etc., que creo que también ocuparía bastante espacio.

¿En qué parte del micro se almacenará esta imagen antes de enviarla a través de SPI a la pantalla LCD?

EDITAR:

En el peor de los casos, podría ser una imagen en blanco y negro sin escala de grises. Lo que alivia un poco el problema.

Pero cualquier cosa con color, ¿hay algún material de lectura para ver aproximadamente cuánta memoria necesito para mi pantalla?

Previamente estaba pensando en animaciones con múltiples imágenes, pero con mis limitaciones de costos, la memoria parece ser una prima, por lo que esto está fuera de discusión.

Por último, en general, ¿es más barato encontrar un micro del tamaño adecuado o un micro realmente barato con memoria externa (EEPROM?)

Probablemente haya técnicas de compresión que podría usar, sí, pero también debe considerar la compensación del tamaño del código. El precio de la MCU depende en gran medida del tamaño del flash, incluso más que de la capacidad central, por lo que puede ser más económico usar un dispositivo de almacenamiento externo pequeño para almacenar la imagen y hacer que una MCU de gama baja la transfiera. Si se está enfocando seriamente en la producción, puede hacer ambas cosas, ya que las MCU generalmente ofrecen múltiples tamaños de flash en una huella y siempre puede no llenar el dispositivo flash externo. Por una vez, preocúpese más por lo que va a ser fácil: más fácil obtener la imagen internamente.
Si su imagen no tiene escala de grises, empaquetarla como un mapa de bits monocromático (1 bit por píxel) sería 12 veces más pequeña y requeriría poco código para volver a expandirse. Eso estaría bien para una imagen generada como un logotipo, pero malo para cualquier cosa pictórica. En la actualidad, su pregunta es demasiado amplia e inespecífica para poder responderla.
Editado para, con suerte, hacerlo más específico.
En términos de precios, decida su cantidad y compre en esa cantidad para MCU y flashes externos. Si desea animación basada en datos o color, definitivamente buscaría un flash SPI externo, pero la animación programática podría realizarse internamente. En términos de compresión, puede intentar comprimir fácilmente su imagen de varias maneras en la PC primero (o tal vez una raspberry pi si realmente desea ver el resultado en la pantalla), aunque deberá considerar el tamaño del código de descompresión para los candidatos prometedores.
Yo iría con la memoria fuera del chip. Hay chips FRAM basados ​​en SPI rápidos que puede leer y enviar los datos a la pantalla.
@CrossRoads FRAM tiene poco sentido para esto, es mucho más caro que el SPI FLASH básico y solo viene en tamaños relativamente pequeños. Por lo general, lo usaría solo cuando las restricciones de escritura/borrado de FLASH sean un problema, lo cual no es el caso aquí.
Es solo una opción. Siempre estoy dispuesto a velocidades de escritura rápidas. Supongo que 512K bytes sería un poco caro para almacenar, digamos, 6 imágenes diferentes a 84K cada una. digikey.com/product-detail/en/cypress-semiconductor-corp/…

Respuestas (2)

Permítame ser precipitado y predecir que en realidad está tratando de usar un ST7789. controlador/LCD basado (ya que Ebay está repleto de pantallas LCD baratas de 240*240 basadas en este controlador).

Si esto es cierto, lo primero que debe comprender es que el controlador LCD tiene un búfer de tramas RAM para almacenar la imagen, por lo que es posible que no tenga que suministrar tanta RAM/EEProm para el almacenamiento de imágenes como podría pensar. Las hojas de datos del ST7789 están aquí en Crystalfontz.

  1. Si se trata de fotos y similares, deberá poder almacenar las imágenes comprimidas o sin comprimir. Si los almacena comprimidos para ahorrar almacenamiento, necesita al menos un búfer parcial en el que descomprimirlos antes de enviarlos a la pantalla. La compresión previa a la resolución de la pantalla reducirá significativamente el almacenamiento requerido, pero debe definir tanto la resolución como la compresión (imagen/línea por línea) que desea usar.

  2. Si está tratando con imágenes basadas en sprites (para animación) o alfanuméricos, solo necesita almacenamiento para el contenido base y puede volver a dibujar, mover y rotar en su pantalla.

  3. Si está tratando con patrones que se crean mediante programación, casi no necesita memoria de almacenamiento y solo un búfer parcial para escribir en la pantalla.

Si su MCU está conectado a la red, puede ser posible enviar solo búferes parciales sin comprimir a la MCU y transferirlos inmediatamente a la pantalla. por ejemplo, un flujo UDP --> búfer --> visualización. Esto puede funcionar muy bien para conectividad IP adulta a 100 Mbps en una MCU decente.

Si desea ver los efectos de la compresión con pérdida en las imágenes que tiene, puede usar un servicio en línea como OptimiZilla para mostrar los efectos en el tamaño de almacenamiento. Por ejemplo, una imagen JPEG típica de 240*240 podría comprimirse de 26 kb (típico de la web) a solo 2,1 kb y seguir siendo bastante viable.

Su enfoque es correcto si desea que sea lo más genérico posible. Si no sabe nada sobre la imagen que alguien quiere cargar, debe asumir el peor de los casos. La compresión de imágenes tampoco puede salvarte, porque es teóricamente imposible comprimir todas las imágenes.

Para todo lo demás hay que poner límites. Por ejemplo, puede decidir que está bien con una imagen gris, en cuyo caso solo necesita 4 bits por píxel. Puede decidir permitir solo imágenes JPEG grandes de 16 kiB con un conjunto fijo de parámetros admitidos. JPEG no es tan pesado y fue diseñado para ser relativamente fácil de implementar con microcontroladores. Existen buenas herramientas externas que pueden reducir las imágenes a un tamaño de archivo determinado. Para una menor compresión y complejidad, elija un formato diferente, tal vez GIF o PNG. Por supuesto, esto requiere más espacio para la descompresión.

Por otra parte, la memoria flash I²C y SPI es barata y pequeña.

Memoria de imagen en microcontrolador [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v