(27-11-2014, 10:08 AM)Alvaro escribió: [ -> ]Hola Antonio.
Yo este tema no opino mucho porque no tengo ni idea de programación. De hecho le cogí algo de asco jejeje.
Sin embargo te digo que si voy leyendo lo que vais poniendo y las estadísticas del foro dicen que la gente tiene interés en este tema, así que te invito a que sigas divagando como bien dices, pues es una fuente de conocimiento para todos.
Estoy totalmente de acuerdo contigo.
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.
Ya he dicho muchas veces que entrar de primeras en el mundo de la programación con C++ es posible, pero no me parece la forma ideal de empezar por su complejidad.
He localizado un artículo que me ha parecido interesante para aquellos que no tienen noción alguna y que se plantean dar los primeros pasos en la programación. Yo os recomiendo el lenguaje Python pero hay otras muchas alternativas.
El artículo contiene enlaces muy interesantes.
Por qué deberías aprender a programar
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.
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
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?
(12-12-2014, 01:49 PM)Kaedi escribió: [ -> ]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?
Buenas Kaedi
Te invito a pasarte por el
Área de Presentaciones y nos cuentes más de ti .
(12-12-2014, 01:49 PM)Kaedi escribió: [ -> ]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?
Bienvenido al foro Kaedi.
Yo lo que me estoy dando cuenta es que es muy habitual tener no un acuario sino una insatación de acuarios. El I2C es para cableado de muy corta distancia y dispribuir periféricos I2C a cierta distancia definitivamente no es muy buena idea. Ignoro si reduciendo la velocidad del reloj se podrá aumentar algo las distancias pero para mí la solución pasa por usar unidades de Arduinos más sencillas a modo de repetidores de esas señales y con la posibilidad de funcionalidades añadidas. Para cableado de pocos metros entre Arduinos se puede usar comunicación serial entre ellos. Es decir, pienso en una unidad central y varios perifericos inteligentes aunque más senicillos y que podrían usar un Arduino pro mini.
Me falta bastante para diseñar algo así porque lo suyo sería implementar un protocolo de comunicaciones a medida para controlar esa red de periféricos inteligentes, pero también se puede desarrollar de momento pequeñas unidades Arduino que realicen tareas muy simples de forma autónoma y dejar para más adelante el tema de comunicarlas entre si.
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.
Mirad esto:
¿Consiguen antes sus objetivos los programadores lentos?
Yo soy de los lentos. La nueva versión de CAO1 (1.1.0) tendrá novedades importantes. Estoy en ello y también estoy reconsiderando un nuevo enfoque donde existan controladores más sencillos que se puedan comunicar entre sí.
Feliz navidad a todos¡¡¡¡
(25-12-2014, 10:19 PM)vipar escribió: [ -> ]Hola, en primer lugar felicitar las fiestas a todos y en segundo lugar para animar a nuestro amigo Antonio que esta haciendo una labor encomiable, no he posteado asta ahora porque no lo he necesitado de momento; pero si para dar animos a todos y que no decaiga estre post. Supongo que como yo, hay mucha gente que lo sigue y que aun no ha posteado y que lo hara en su momento.Mi proyecto es sencillo, para un gambario de 40 litros, muy plantado, co2 e iluminación led. Practicamente lo tengo todo para el proyecto y probado casi todo, no tengo prisa , voy poco a poco.
Bueno lo dicho Felices fiestas y que no decaiga este post
Yo perdí casi todas las gambas que tenía por calor así que espero poder hacer algo para refrigerar el gambario y para evitar que el nivel de agua baje en exceso durante una ausencia prolongada, de otra forma en agosto volverá a peligrar mi gambario.
![[Imagen: Bouncing-Light-Tree.png]](http://lasindias.com/wp-content/uploads/2014/12/Bouncing-Light-Tree.png)