Paso 1: Sistema Resumen
El concepto de DemUino gira en torno a un equipo de controlador de base y en particular AVR de 8 bits bestias usando las bibliotecas de Arduino. En un esfuerzo por mantener el proyecto hasta la fecha tuve que adaptarla para utilizar teclados USB y medios de almacenamiento modernos – SD o microSD con adaptadores – apoyo a archivos de texto sin formato PC (grasa).
El problema principal con esta "actualización" es el sacrificio de enormes recursos en código flash y RAM demanda ya sea estática o dinámica. Sin embargo, el uso de un sistema de procesador dual alivia el dolor de la pérdida horrible y proporciona a una especie de sentimiento vale la pena el esfuerzo cuando el proyecto llega a un resultado tangible utilizable. El sistema se puede construir con ambos procesadores siendo algo atmega328s, que reproduce toda la funcionalidad de DemUino versión 1.66 pero con sólo un poco más de 700 bytes de RAM libre. El uso de un atmega644 como el principal procesador de manejo de la tarjeta SD y la delegación de puerto USB, master I2C y RS232 (PC data) a un atmega328 construye un sistema más capaz mejor con más de 1300 bytes libres para DemUinoDuo versión 1.0 incluyendo SD FAT funcionalidad. La pantalla es un texto estándar de 4 x 20 LCD (modo paralelo) impulsado por el puerto GPOUT del regulador de máxima en el escudo de host USB.
La página siguiente muestra la arquitectura del sistema. La decisión de transferir el control USB al atmega328 se basó en la difícil naturaleza de la función Usb.Task() que necesita para funcionar sin trabas en un bucle continuo y predecible. El procesador principal, atmega644, necesita servicio de todo tipo de situaciones y aún espere cosas sucedan aparte de retrasos de usuario sólo. Las prensas de teclado se envían sobre el bus I2C causando controladores de eventos en el MCU principal para responder oportuna y darles de comer al programa que se producen. Hay un flujo continuo de 21 bytes a la vez tratada como un grupo/paquete de datos desde el esclavo atmega644 (#3 en el bus I2C) para el maestro atmega328 comandos LCD o datos de sincronización. El esclavo EEPROM externo presente no es actualmente dirigido por el maestro.
Hay un retardo de 200ms para repetición de oprimir cualquier tecla para registrar. En el lado del controlador primario las peticiones de LCD se limpian con un 5ms demora y el lazo de keyboardavailable() introduce un 5ms retrasar demasiado. Sin embargo, si el programa de usuario no utiliza los comandos LCD entonces un vacío para bucle por sí mismo contando hasta 1000 se ejecuta en unos 126ms para un total de 1002 declaraciones. Una asignación a una variable en el mismo bucle aumenta el tiempo de ejecución a 535ms para un total de declaraciones de 2002.
El escudo de host USB se hace por la buena gente de http://www.tkjelectronics.dk/ y necesito dar las gracias a Kristian Lauszus en el https://github.com/Lauszus por responder amablemente a mis preguntas y también para el serie opti-bootloader de la atmega644.
La unidad fue realmente construida y fotografiada usando las tablas DemUino2 y SD2RS232 para ahorrar dinero. El esquema presentado en las páginas siguientes es la forma sugerida de la construcción de la unidad que requiere menos piezas de lo que se percibe en las fotos.
Durante el arranque la unidad comprueba la presencia de una SD card y si no encuentra entonces el zumbador suena durante un segundo. El LOGO puede aparecer enseguida pero esperar hasta que las luces de un abrir y cerrar teclado momentáneamente antes de escribir, en la felicidad.
El hardware actual ofrece posibilidades de desarrollo muy bueno, definitivamente mejor que lo que dirijo en la actualidad con la versión 1.0 del código liberado. Aparte de la optimización necesaria para salvar la flash y RAM espacio (sin alterar la biblioteca SD voraz) existe la posibilidad indómita del atmega328 soporte como módulo GPIO por sí mismo y por supuesto el empleo de la EEPROM externa como un repositorio de datos.