user-interface - para - sistema de gestion de bibliotecas
Biblioteca de gráficos para sistemas integrados sin Linux? (11)
Parece que cualquier tipo de biblioteca gráfica como DirectFB o MiniGui requiere algún tipo de sistema operativo subyacente como Linux o uClinux.
Tengo el reto de escribir un software para un microcontrolador con solo flash de 512 kb, una pantalla LCD y una pantalla táctil para visualizar y manejar algunas imágenes y piezas de la GUI.
¿Conoces alguna biblioteca que solo necesite un puntero a la memoria de video que también pueda manejar líneas, imágenes y fuentes?
Si sus requisitos para la interactividad y los widgets de la GUI son muy modestos (o si está bien diseñando sus propios widgets), eche un vistazo a LibGD . Dibuja la imagen que deseas que aparezca en la pantalla usando las funciones de la biblioteca, y luego escríbela en el búfer de cuadros usando gdImagePngToSink ().
Lo importante de lo que debería preocuparse es el controlador de la pantalla LCD y la pantalla táctil. Hay una gran cantidad de bibliotecas C (no gratuitas) para esa tarea. Un google rápido me dio estos resultados: Simplify Technologies y Ramtex .
Si desea encontrar algo de código abierto, comience desde el tipo de su controlador y busque foros de dispositivos integrados (incluso si no es ARM, puede portar fácilmente el código C). Algunas sugerencias:
Además, algunos fabricantes de kits ofrecen un SDK (con y sin Linux) con sus placas. La compra de una placa generalmente le da la licencia para usar el código. Busque tablas de desarrollo con el mismo controlador LCD.
Supongo que algo como FreeDOS, combinado con DJGPP como una cadena de herramientas, y Allegro como una biblioteca de gráficos podría encajar en 512k de flash y aún así hacer un trabajo razonable (supongo que tienes un x86 que tiene varios Mb de ram aquí )
Pero estas cosas son muy específicas de x86 (no obstante, Allegro).
Es complicado obtener un kernel de Linux y una cantidad útil de software de espacio de usuario dentro de 512k (pero es posible obtener ALGO en)
Hemos utilizado "PEG", la versión C ++, de Swellsoftware durante muchos años. Es un software comercial, no gratuito, pero el controlador de pantalla subyacente puede usar solo un puntero a la memoria de gráficos y proporcionan muchos controladores de muestra para diferentes tipos de hardware de gráficos. Escribimos nuestros propios controladores personalizados para nuestro hardware propietario, utilizando los controladores de muestra como referencia. Siempre hemos tenido algún tipo de RTOS, pero creo que PEG + también puede funcionar sin un sistema operativo.
Compruébelo aquí: http://www.swellsoftware.com/
buena suerte,
Cuando incorpore una solución de terceros, podría haberla escrito usted mismo.
Para la mayoría, si no para todos los entornos, la pantalla es solo una matriz bidimensional de píxeles. A veces paletizado a veces no, pero eso no importa, puede escribir el suyo como quiera.
Hay toneladas de códigos gratuitos para dibujar líneas y arcos, etc.
El asesino puede ser fuentes, pero creo que encontrará que una aplicación de terceros masticará toda su memoria simplemente haciendo fuentes, usted tiene recursos limitados por lo que querrá precomputar las fuentes y simplemente copiar los bits.
Haga una matriz bidimensional de datos, haga todo su trabajo en su host favorito al principio, es trivial guardar archivos .bmp si quiere ver lo que está dibujando, y trivial convertir una serie de archivos .bmp en una video si quieres ver alguna acción.
Si usa C genérico y no hay llamadas de libc (escriba su propio memcpy, memset, etc.) este código se ejecutará en cualquier lugar, en el host para el desarrollo y en el destino.
Las fuentes van a ser tu asesino, tienes que calcularlas previamente, pero logras meter esa información lo más pequeña posible, y en tiempo de ejecución extraer los datos y copiar los bits de cada letra en la pantalla virtual lo más rápido que puedas .
O simplemente compre una de las muchas soluciones de lcd que hacen todo esto por usted y simplemente envíe comandos como "¡Hola, mundo!" en algunos (x, y) usando azul como primer plano y blanco como fondo.
Básicamente, creo que las soluciones que no son OS todavía usarán demasiadas bibliotecas y serán demasiado grandes para su aplicación específica. Los arreglos en 2d de bytes o píxeles son triviales para administrarse. Incluso si está escribiendo una aplicación para una plataforma de escritorio, lo haría de esta manera y en el último minuto copie la actualización de la pantalla completamente reordenada a alguna biblioteca dependiente del sistema operativo (permite la máxima portabilidad de un sistema operativo o no a otro).
No es gratis, pero es bueno en sistemas de recursos bajos: http://www.tat.se y sus productos Kastor y Cascades. Solo requiere un puntero a la memoria de video, malloc y algo que se parece a un sistema de archivos. Los dos últimos requisitos tampoco son absolutamente necesarios. No se requiere un sistema operativo.
Probablemente necesite comprimir fuentes usando Run Length Encoding (RLE). Consulte el formato de archivo .pcx para ver ejemplos, aunque probablemente sea mejor diseñar un RLE personalizado. No especificó la profundidad de bits de la pantalla LCD, pero las fuentes necesitan un bit por píxel si no se necesita antialiasing, o un máximo de tres BPP con antialiasing. Cada personaje debe tener su propio ancho porque el texto monoespaciado no es agradable. Debe renderizar directamente desde la fuente comprimida RLE a la pantalla, usando una rutina optimizada.
SDL es una biblioteca gráfica muy portátil. Se usa en sistemas Linux embebidos, pero creo que se puede usar sin un sistema operativo. Lo bueno de SDL es que puedes usar Windows / Linux para desarrollar y probar tu UI, y luego enfocarte en tu sistema embebido. ¡No se necesitan cambios al código de la aplicación!
También puede utilizar la biblioteca de Geometría Anti-Grain ( http://www.antigrain.com/about/index.html ) en la parte superior de SDL. Con una pantalla LCD de 16 o 24 bits, produce gráficos deslumbrantes. Puede ser demasiado grande para su entorno, porque mi ejecutable en un sistema ARM / Linux era de aproximadamente un megabyte. Contenía SDL, AGG y libfreetype2 para la representación de fuentes. AGG también es un poco lento, pero produce resultados hermosos.
Deberías probar EasyGUI .
easyGUI es un software / biblioteca de gráficos GUI específicamente diseñado para trabajar en pequeños sistemas embebidos.
No se necesita un sistema operativo. Un ejecutivo cíclico básico es suficiente. 512kb de Flash deberían estar más que bien. La biblioteca que proporciona easyGUI es muy flexible y ayuda a minimizar la cantidad de Flash que necesita.
Admite fuentes, gráficos, mapas de bits, pantallas táctiles y un montón de controladores de video listos para usar.
Además, es realmente económico (sin tarifas de licencia, solo una cantidad fija por asiento) y viene con un programa de PC para diseñar pantallas y generar código. El programa de PC tarda un tiempo en acostumbrarse, pero al final es muy agradable probar ciertas cosas en la PC y luego simplemente generar y ver si se ejecuta en su objetivo.
Tienen una aplicación de demostración en su sitio web. Vale la pena echarle un vistazo.
Para la huella más pequeña posible, realmente debes considerar RamTEX. Lo he usado en dos proyectos con PICS de 8 bits. El espacio ROM era de aproximadamente 35K en mis aplicaciones con ~ 1K para RAM (la cantidad depende de si necesita memoria RAM para la pantalla). El espacio ROM depende de las características gráficas que desee o necesite.
Ofrecen una fuente completa y el precio por única vez es bastante bueno, menos de $ 1000 (tenga en cuenta que los precios que figuran en su sitio web deben convertirse a dólares, o cualquiera que sea su moneda). No hay regalías o restricciones por producto.
Proporcionan una cantidad de fuentes de diferentes tamaños y estilos, y llamadas de dibujo básicas (línea, píxeles, recuadro, etc.). No tiene ningún "objeto" definido, como botones o menús, pero pude implementar un menú emergente sin demasiados problemas. Admite "viewports" que se pueden usar para definir cuadros de texto, menús, etc., cada uno con sus propios atributos.
También viene con un simulador que se ejecuta en una PC para que pueda desarrollar el código de visualización en su escritorio antes de pasar a un sistema integrado.
(vieja pregunta, pero quería publicar mis hallazgos sobre el tema)
Para obtener gráficos de alta calidad, la Geometría Anti-Grain es una buena opción. Se compila a aproximadamente 50kB y se puede personalizar para escribir en todo tipo de framebuffers y dispositivos de renderizado: http://www.antigrain.com/
Para la interfaz de usuario, Gwen parece una buena opción. Es fácil de transportar y se puede personalizar para mostrar los controles de mapas de bits o simplemente los formularios de rectángulo / círculo / línea: https://github.com/garrynewman/GWEN
Entonces, si también está seleccionando un RTOS, NuttX tiene su propio subsistema de gráficos y kit de herramientas de widgets: http://nuttx.sourceforge.net/