#977
05-12-2014, 10:57 AM
(Última modificación: 05-12-2014, 10:58 AM por
Antonio Castro.)
Tanto el lenguaje C como el lenguaje C++ son lenguajes de programación antipáticos.
Ambos están muy enfocados a la obtención de un código eficiente para las máquinas, cosa que es muy importante en este tipo de aplicaciones.
Voy a divagar sobre programación orientada a objetos en CAO1. En este tipo de programación es frecuente estructurar en objetos la aplicación. Ademas de las funcionalidades que suelen incorporar los objetos, estos se caracterizan por usar una serie de atributos que a todos los efectos podríamos decir que son las variables internas de esos objetos.
Se da la circunstancia de que yo guardo en la EEPROM un montón de parámetros del sistema para poder reconfigurarlo y que conserve esta configuración aunque se interrumpa la alimentación eléctrica.
¿Pueden ser tratados esos parámetros como si fueran atributos de ciertos objetos?
Muchos de mis objetos en la versión actual de CAO toman datos de la EEPROM al inicializarse. Es decir al inicio, algunos atributos del objeto toman su valor inicial desde la EEPROM.
El problema surge cuando entramos en el menú de parametros y efectuamos un cambio de valores en algunos de los parametros para reconfigurar el sistema. En ese momento habría que actualizar el objeto afectado por esos valores.
1) SOLUCIÓN MEDIANTE REINICIALIZACIÓN DE TODO EL SISTEMA
Una forma muy simple pero bastante burda de hacerlo sería obligando a reinicializar todo el sistema después de cada cambio de parámetros. Sería muy sencillo de programar pero no me pareció demasiado práctico hacerlo así pero que duda cabe, funcionaría perfectamente.
2) SOLUCIÓN DE USAR DATOS DE LA EEPROM PARA LA INICIALIZACIÓN DE LOS MÓDULOS DEL SISTEMA
Para evitar tener que reiniciar todo el sistema, lo que hago es marcar en cada módulo un estado que indique su necesidad de ser reinicializado o no, y como esto es algo que ocurre en unos cuantos módulos, implemente un módulo base que sirve para ayudar a gestionar todos los módulos parametrizables del sistema. Con ello al salir del menú de configuración de parametros, el sistema podría mostrar un mensaje informando que una serie de módulos van a ser reinicializados.
Esta es una forma elegante de hacerlo. Todo muy orientado a objetos, pero hay otra forma de hacerlo.
3) SOLUCIÓN DE LECTURA DIRECTA DE DATOS EN LA EEPROM
En lugar de que los objetos tengan estos atributos (recordemos que un atributo es una variable) que deban ser inicializados, podríamos suprimir ese atributo y en cada ocasion que se requiera conocer el valor del mismo leerlo directamente en la EEPROM. Esto provocaría muchísimas lecturas en la EEPROM ya que en lugar de tratar los datos de la EEPROM como datos para inicializar atributos y variables del sistema, lo trataríamos como si fueran las propias variables y atributos.
En CAO1, los datos en la EEPROM solo van a variar cuando el usuario desee cambiar la configuración. No se puede usar una EEPROM como si fuera una variable normal escribiendo en ella cuando nos plazca, porque algunas de las operaciones de escritura son destructivas y se desgastaría la EEPROM rápidamente. Por el contrario se pueden leer las veces que queramos sin riesgo de desgastarlas.
Usar directamente las posiciones de la EEPROM en sustitución de variables y atributos de objetos tiene ventajas e inconvenientes. La principal ventaja es que ya no haría falta reinicializar ningún objeto, porque no existirían tales atributos pendientes de actualizar, siempre se acudiría directamente a la EEPROM. El inconveniente consiste en que cuando se reinicia un objeto puede ocurrir que otro que depende de el deba de ser reinicializado igualmente.
Es decir, el inconveniente de este tipo de solución de lectura directa, es que un simple cambio en un atributo puede comportar otros cambios. Por ejemplo, el objeto fotoperiodo guarda tres parametros que luego sirven para calcular los momentos de inicio de cada uno de los periodos: Alba, Dia, Ocaso, y Noche.
Estos dos enfoques son muy diferentes a la hora de hacer uso de la EEPROM. En la próxima versión de CAO1 que me llevará bastante tiempo de desarrollo cambiaré la forma de hacerlo a esta tercera forma de hacer las cosas. Eso me va a obligar a hacer modificaciones masivas en el código con el riesgo de introducir nuevos errores o a provocar efectos colaterales en algunas partes que son algo delicadas.
CONCLUSIÓN
En este momentos parece un poco temerario por mi parte lanzarme a una aventura en la cual después de muchos cambios, las cosas funcionarían más o menos de la misma manera, pero tengo tengo la sensación de que este nuevo enfoque va a resultar mejor a la larga por dos motivos: Uno, porque la reinicialización de según que módulos es algo que está pensado para ser hecho una sola vez y podría complicarme las cosas en algunos módulos en el futuro. Segundo, porque me voy dando cuenta de que en la EEPROM no solo se puede usar para dejar configurado el sistema para que funcione de una cierta forma, sino para darle órdenes puntuales. Los parámetros son como los mandos del sistema. Una de órdenes podría ser forzar un apagado de las luces o un encendido de las mismas con independencia del momento del día.
No es esto lo único que estoy haciendo, también añadiré parámetros y funcionalidad a CAO1. Me llevará mi tiempo, pero si tenéis preguntas o estáis tratando de automatizar algo en vuestro acuario, comentarlo y compartir vuestras ideas.
#979
12-12-2014, 11:59 AM
Hola Buenos días.
He estado leyendo un poco por este intenso foro y primeramente he de decir que también me apunto al club de las dudas a cerca del ruido.
El proyecto básicamente contiene un Arduino Mega y 6 LCD. La comunicación entre ambos la hacemos mediante I2C.
El arduino está alimentado mediante una fuente de alimentación 230Vac/9Vcc, y las LCD se alimentan directamente de los 5V del Arduino.
La idea es que dependiendo del estado de ciertas entradas digitales en el Arduino, los LCD muestren el estado de dichas entradas. Hasta aqui todo aparentemente facil....
El problema ha venido una vez esta todo montado, ya que nos hemos encontrado con el problema de las interferencias, es decir todo funciona correctamente hasta que deja de hacerlo.... en los LCD aparecen caracteres extraños y el sistema "se cuelga". Supongo que tenemos interferencias por radio y por la alimentacón, ya que hemos probado a alimentar el sistema mediante USB e incluso mediante una pila de 9 V y el problema continua....
He intentado adjuntar una imagen para que os hagais una mejor idea de lo que tenemos montado pero no se como se hace.... existe posibilidad de enviarla a algún e-mail?
La duda principal es si las interferencias me están "loqueando" el Arduino?, el Bus I2C?, los LCD?, las 3 cosas? Tiene solución?
Muchas Gracias.
#980
12-12-2014, 12:42 PM
En el bus i2c debes asegurarte de que el cableado sea lo más corto posible
Yo en pruebas puse un cable de unos 60 cm y salen caracteres extraños. Con unos 20cm no me pasa
#981
12-12-2014, 01:49 PM
Mi proyecto supera los 20 cm, estríamos hablando de que el LCD más alejado será sobre 1 mt, pero claro tenemos 6 LCD !!!!!
Estoy barajando la posibilidad de cambiar el bus de comunicación entre Arduino y LCD?? cual será la mejor solcuión para esta aplicación?
#984
13-12-2014, 09:58 AM
Kaedi, un par de preguntas. Supongo que de alguna forma conseguiste que tus LCDs usara direcciones I2C diferentes para poder mostrar información diferente,. La segunta pregunta es si has probado a usar cable apantallado.
#987
24-12-2014, 03:32 AM
Feliz navidad a todos¡¡¡¡