Acuariofilia Madrid - Aula Arduino para principiantes.

Páginas: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119

(15-02-2016, 12:55 PM)ArturoS escribió: [ -> ]El tip actúa mas como interruptor conectando a masa la linea de leds alimentada desde la fuente y cuyo cierre de circuito a masa es interrumpido por el tip que cuando entra en conducción actúa como interuptor. La onda cuadrada recibida por la base es la que habilita estas conducciones y su alta frecuencia es la que hace imperceptible para el ojo humano esos cortes, observandose como una bajada de la intensidad lumínica.

La corriente generada por el pin es débil y mas tendente a debilitarse por la distancia, pero creo que en el rango de 1m no es significativa. Otro tema es que un cable, y cuanto mas largo mas, es susceptible de coger interferencias electromagnéticas cercanas que deformen su señal inicial, pero si no está cerca de cables que alimentan motores potentes el efecto puede ser insignificante.

Yo probaría conectando los tip alejados por un cable apantallado, conectando la camisa a GND (creo que los tipo telefonillo o ethernet pueden servir). Y si llegara a detectar cosas raras ya me pensaría poner ferritas, cambiar trazados o cosas mas complejas.

Vale, estaba confundido entonces. Así que es el propio tip el que hace de conmutador y no de amplificador. Por tanto es lógico que con mi montaje actual donde el tip está cerca de arduino pero lejos de la pantalla no tenga problemas, puesto que el pulso PWM de arduino tiene muy poco recorrido.

Tendré que hacer pruebas para ver si me puedo fiar para montar 4 cables de 1 metro llevando los pulsos PWM de arduino hacia los TIPS, y que esas señales no se corrompan. Con un cable ethernet (que tienen 8 pines) podría mandar por cada pin una señal PWM y 3 pines más de los restantes para conectar la sonda de temperatura de la pantalla, por ejemplo?

(14-02-2016, 10:48 PM)pedmar escribió: [ -> ]
(13-02-2016, 09:43 PM)Antonio Castro escribió: [ -> ]
(13-02-2016, 07:28 PM)pedmar escribió: [ -> ]Ya tengo todo lo necesario como comenté.
Ayer hice mi primera prueba de arduino, se que es una tontería pero me hacia ilusión. Puse a funcionar tres leds .... (si muy cutre) pero por algo tendré que empezar .

Según me valla complicando comentaré las dudas, que seguro me surjan a montones

En efecto. La mejor forma de empezar es dando el primer paso.

Si me pones una lista de cosas que ya tienes, te podré sugerir alguna práctica sencillita, o si lo prefieres me puedes pasar la lista por privado.

tengo todo lo que pedí.
arduino UNO

fuente de alimentación 9v

modulo 4 relés

modulo de relog

soporte de soldar con lupa y luz

protoboard o placa para tontos

conexion de corriente de la placa para tontos

mas una serie de componentes (potencimentros resistencias interruptores)

Pero quiero recuperar lo que hace semanas que estuve investigando... tengo que refrescar

Refresca tranquilo. Tienes un bonito kit. Te permitirá hacer muchas practicas sencillitas. Si te aburres de la lectura puedes intentar esto:

Practica 03 – Controlar el brillo de un LED con un potenciometro

(15-02-2016, 02:22 PM)Agamenon escribió: [ -> ]
(15-02-2016, 12:55 PM)ArturoS escribió: [ -> ]El tip actúa mas como interruptor conectando a masa la linea de leds alimentada desde la fuente y cuyo cierre de circuito a masa es interrumpido por el tip que cuando entra en conducción actúa como interuptor. La onda cuadrada recibida por la base es la que habilita estas conducciones y su alta frecuencia es la que hace imperceptible para el ojo humano esos cortes, observandose como una bajada de la intensidad lumínica.

La corriente generada por el pin es débil y mas tendente a debilitarse por la distancia, pero creo que en el rango de 1m no es significativa. Otro tema es que un cable, y cuanto mas largo mas, es susceptible de coger interferencias electromagnéticas cercanas que deformen su señal inicial, pero si no está cerca de cables que alimentan motores potentes el efecto puede ser insignificante.

Yo probaría conectando los tip alejados por un cable apantallado, conectando la camisa a GND (creo que los tipo telefonillo o ethernet pueden servir). Y si llegara a detectar cosas raras ya me pensaría poner ferritas, cambiar trazados o cosas mas complejas.

Vale, estaba confundido entonces. Así que es el propio tip el que hace de conmutador y no de amplificador. Por tanto es lógico que con mi montaje actual donde el tip está cerca de arduino pero lejos de la pantalla no tenga problemas, puesto que el pulso PWM de arduino tiene muy poco recorrido.

Tendré que hacer pruebas para ver si me puedo fiar para montar 4 cables de 1 metro llevando los pulsos PWM de arduino hacia los TIPS, y que esas señales no se corrompan. Con un cable ethernet (que tienen 8 pines) podría mandar por cada pin una señal PWM y 3 pines más de los restantes para conectar la sonda de temperatura de la pantalla, por ejemplo?

Te doy mi opinión. Un metro para PWM no me parece una gran distancia.

Los cables de los sensores, es mejor que vallan apantallados por separado cada un de ellos.

Los cables de salida en teoría pueden apantallarse juntos para evitar que emitan señales que puedan causar interferencias, pero puede no hacer falta, yo no he visto montajes con cable apantallado para PWM.

Los cables de salida PWM de Arduino a 5v creo que aguantarán perfectamente sin perder señal en cables de uno o dos metros.

Para proteger los LEDs de las deformaciones indeseables de ondas con pico, se podría poner una ferrita en los cables que llevan la potencia, pero tampoco creo que haga falta.

Volviendo al tema de nuevo IDE 1.6.7

Retomando el tema desde el principio, son varias cosas las que me han llamado la atención en esta nueva versión del IDE Arduino.

La primera es que el nuevo compilador ha considerado error la conversión de una cadena a puntero a caracter.

Código:
char Pt1;

Pt1= "Cadena de texto";

Tal como ya dije, ignoro el trabajo que podría suponerme la eliminación de todos los warning: deprecated conversión from string constant to 'char*' [-Wwrite-strings].
Habría sido más correcto lo siguiente:

Código:
const char Pt1;

Pt1= "Cadena de texto";

Hay muchos más cambios, pero este me preocupó. Más que nada porque CAO1 es un programa con 9000 líneas de código, pero he seguido investigando.

Por lo menos en Linux, se pueden tener dos IDEs de distintas versiones y compilar con uno o con otro.

El nuevo compilador es mucho más quisquilloso, pero su inteligencia a la hora de detectar partes potencialmente conflictivas me ha impresionado. Hila muy fino.

He compilado programas más pequeños y hasta el momento los cambios que he tenido que hacer no han resultado especialmente complicados.

Si duda, para mis nuevos programas merecerá la pena pasarse a la nueva versión, y para CAO1 creo que tendré que sacar una copia de la versión actual y probar a actualizar todo el software con prudencia. Me llevará tiempo.

Otra cosa que me ha llamado mucho la atención es que ahora ya no solo viene como IDE Arduino sino como IDE Arduino - Geguino.

Sospecho que detrás de tantos cambios, podría haber algunas razones... digamos "políticas" relacionadas con los nuevos acuerdos que se han firmado como resultado de la aparición de la nueva marca Genuino.

Sobre la nueva marca Genuino, decir que Arduino es una marca registrada a nivel mundial y es propiedad exclusiva de uno de los socios originales que estaba encargado de la fabricación del hardware. Al ser Hardware Abierto y Código Abierto, cualquiera puede fabricarlo.

El caso es que los otros socios originales del proyecto se han aliado y han firmado un acuerdo con Adafruit para fabricar Arduinos con su propia marca y su propio Logotipo "Genuino".

Por lo tanto, las marcas Arduino y Genuino van a convivir previsiblemente durante mucho tiempo. Desconozco los detalles de la riña pero si cualquiera de las partes que se han separado decide hacer algo diferente y valioso, ya sea Hardware o Software, el otro podrá copiarlo y hacer negocio con ello.

hola buena tarde, alguien sabe qué puedo hacer si no encuentro el TIP 141? creo que solo hay TIP 142 en mi localidad y otros de nomenclatura mayor.

Gracias Smile

(20-02-2016, 10:41 PM)edzvlogs escribió: [ -> ]hola buena tarde, alguien sabe qué puedo hacer si no encuentro el TIP 141? creo que solo hay TIP 142 en mi localidad y otros de nomenclatura mayor.

Gracias

Puedes usar el TIP140, TIP141, o TIP142 que son NPN. Los TIP145, TIP146 y TIP147 son diferentes, son PNP.

Pero hay un hilo interesante sobre la posibilidad de usar transitores mosfets IRF540 para el dimeo en CAO1

(21-02-2016, 11:19 AM)Antonio Castro escribió: [ -> ]
(20-02-2016, 10:41 PM)edzvlogs escribió: [ -> ]hola buena tarde, alguien sabe qué puedo hacer si no encuentro el TIP 141? creo que solo hay TIP 142 en mi localidad y otros de nomenclatura mayor.

Gracias

Puedes usar el TIP140, TIP141, o TIP142 que son NPN. Los TIP145, TIP146 y TIP147 son diferentes, son PNP.

Pero hay un hilo interesante sobre la posibilidad de usar transitores mosfets IRF540 para el dimeo en CAO1

hola muchas gracias por el link! Smile

revisaré y veré cual es más sencillo utilizar o encontrar en mi caso!

Continuo haciendo pruebas con el IDE 1.6.7.
Me gustan mucho un montón de cosas. He descubierto gran cantidad de cosas mejorables y varios errores en CAO1 gracias al uso del IDE 1.6.7 y a la gran cantidad de avisos que proporciona. Algunos de ellos hilando muy fino.
Creo que este compilador está obligando a la revisión de un montón de librerías pero tantos cambios masivos tienen siempre consecuencias. Yo me quejaba del destrozo que podría suponerme en CAO1 porque tiene 9000 lineas. He logrado suprimir los errores graves y la mayoría de los avisos (warnings). Mi primer resultado fue un programa CAO1 que no funcionaba. El LCD hacía cosas raras.

Recordemos que la librería "LiquidCrystal_I2C" es una librería externa.

Me he hecho un programita de prueba muy sencillo para el LCD para averiguar si era algún tema relacionado con la librería.

Código:
/*

 *************************************************************************

 *  (C) Antonio Castro Snurmacher

 *  Licencia de uso:Creative Commons Attribution-NonCommercial-ShareAlike 

 *------------------------------------------------------------------------

 *************************************************************************

 */

// ********************************************************

// Includes de librerías de proposito general de Arduino

// ********************************************************

#include <Arduino.h>

#include <Wire.h>

#include <LiquidCrystal_I2C.h>

// ****** Instanciar objetos ******

#define LcdAddress          0x27                // Direccion I2C para el LCD  

LiquidCrystal_I2C           lcd_i2c(LcdAddress, 20, 4);

char Linx[21];

unsigned int cont=0;

// ***************************************************************************

void LcdIni(){

    lcd_i2c.init(); 

    lcd_i2c.backlight();

    lcd_i2c.clear();

}

// ***************************************************************************

void LcdLine(const char *cad, unsigned int Lin){

    char CadAux[21];

    strncpy(CadAux, cad, sizeof(CadAux));

    CadAux[20]='\0'; // Truncar.

    lcd_i2c.setCursor(0, Lin);

    lcd_i2c.print( "                    ");    

    lcd_i2c.setCursor(0, Lin);

    lcd_i2c.print(CadAux);    

}

// ***************************************************************************

// ***************************************************************************

char Int2Ch(unsigned int index){

    return 'A'+(index%26);

}

// ***************************************************************************

// setup(): 

// Se procede a inicializar todos los módulos y en su caso a configurarlos.

// ***************************************************************************

void setup(void) {

    Serial.begin(9600);

    Serial.println();

    Serial.println();

    LcdIni();

    LcdLine("Prueba del LCD", 0);

    delay(4000);

}

// ******************************************************************************************

// loop()

// bucle principal de la aplicación.

// ******************************************************************************************

void loop(void) {

    cont++;

    snprintf(Linx,20, "milli()=%lu", millis());

    LcdLine(Linx,0);

    for (int i=0; i<20; i++){

        Linx[i]=Int2Ch(i+cont);

    }

    LcdLine(Linx,1);

    LcdLine(Linx,2);

    LcdLine(Linx,3);

    delay(1000);

}

En 1.6.4 me toma la que yo descargué y que instalé en
/home/antonio/Arduino/libraries/LiquidCrystal_I2C

Las librerías externas pueden instalarse de distintas formas y yo mis programas los tengo en /home/antonio/Arduino/sketchbook/... y las librerías externas en /home/antonio/Arduino/libraries/...

La LiquidCrystal_I2C que yo descargué en su momento ha funcionado perfectamente con varios IDEs, pero con el IDE 1.6.7 hace cosas extrañas en la pantalla y al final no se puede leer nada porque termina una una línea de letras en vertical que va cambiando y nada más

Parece ser que el problema no está en el propio IDE 1.6.7 sino que es causado por un mal comportamiento de la biblioteca LiquidCrystal_I2C. Pareceser que la última implementación de la biblioteca Wire necesita saber cuántos caracteres se escriben y la biblioteca LiquidCrystal informaba 0, deteniendo por ello la escritura después de escribir el primer carácter. De hecho, parece que el problema fue corregido pero la solución no fue liberada o no se sabe donde descargar la librería corregida, por lo que se necesita aplicar la corrección manualmente en las primeras líneas del fichero LiquidCrystal_I2C.cpp .

inline size_t LiquidCrystal_I2C::write(uint8_t value) {
send(value, Rs);
return 0; // ERROR DEBERÍA SER return 1;
}

Realmente tiene pinta de ser un tema que habrá causado muchos problemas a mucha gente.

Ignoro que más sorpresas surgirán en mi intento de migración de CAO1 a la versión 1.6.7.

Magnífico trabajo depurando para la 1.6.7. Realmente esto del software funciona así, los estándares van cambiando, igual que la metodología, los patrones de diseño y la propia tecnología. Es muy habitual tener que refactorizar el código. En un código tan modular como CAO, aunque sean muchas líneas de código totales, es más fácil refactorizar porque el sistema está mucho más desacoplado.

Si estás depurando cosas Antonio, echa un ojo a un bug que he detectado en la versión actual de CAO.

Cuando activas el modo autosleep me ha ocurrido varias veces (no siempre) que cuando llega la hora de volver a encenderse y comenzar el día se queda el arduino pillado. Hay que resetearlo. Ya digo que solo pasa a veces. Evidentemente no es algo crítico, simplemente desactivas el modo autosleep y listo, pero es un bug que tiene una funcionalidad que podría ser interesante.

Otra cosa y como sugerencia para ese modo... no hay forma de apagar la pantalla?? porque el modo autosleep realmente lo que hace (o al menos en mi versión) es dejar la pantalla encendida pero sin que se refresquen caracteres. Es decir, se queda iluminada y en completo azul. Un comportamiento más deseable sería apagarla, y luego volver a encenderla al salir del modo sleep, no?

tengo un par de componentes mas para trastear Big Grin

pero me temo que para utilizar este LCD necesito una libreria que no se como localizar.

ademas de una sonda temperatura:
DALLAS
18B20
1148C4
+139AH

(21-02-2016, 09:10 PM)pedmar escribió: [ -> ]tengo un par de componentes mas para trastear pero me temo que para utilizar este LCD necesito una libreria que no se como localizar.

ademas de una sonda temperatura:
DALLAS
18B20
1148C4
+139AH

Uff no sabría decirte esa pantalla. Yo siempre he usado esta http://www.banggood.com/IIC-I2C-2004-204...08616.html, es I2C por lo que las conexiones son mucho más sencillas y la librería es la LiquidCrystal. Tu pantalla es de conexión serial, así que no vale esa. En el propio enlace de la tienda que has pasado aparece abajo para descargarte lo que supongo que será su librería, este es el enlace http://www.sparkfun.com/datasheets/LCD/SerLCD-v2.zip.

Para el sensor de temperatura yo uso la propia librería de dallas http://milesburton.com/Main_Page?title=D...ol_Library y la OneWire http://www.pjrc.com/teensy/td_libs_OneWire.html

(21-02-2016, 06:20 PM)Agamenon escribió: [ -> ]Magnífico trabajo depurando para la 1.6.7. Realmente esto del software funciona así, los estándares van cambiando, igual que la metodología, los patrones de diseño y la propia tecnología. Es muy habitual tener que refactorizar el código. En un código tan modular como CAO, aunque sean muchas líneas de código totales, es más fácil refactorizar porque el sistema está mucho más desacoplado.

Si estás depurando cosas Antonio, echa un ojo a un bug que he detectado en la versión actual de CAO.

Cuando activas el modo autosleep me ha ocurrido varias veces (no siempre) que cuando llega la hora de volver a encenderse y comenzar el día se queda el arduino pillado. Hay que resetearlo. Ya digo que solo pasa a veces. Evidentemente no es algo crítico, simplemente desactivas el modo autosleep y listo, pero es un bug que tiene una funcionalidad que podría ser interesante.

Otra cosa y como sugerencia para ese modo... no hay forma de apagar la pantalla?? porque el modo autosleep realmente lo que hace (o al menos en mi versión) es dejar la pantalla encendida pero sin que se refresquen caracteres. Es decir, se queda iluminada y en completo azul. Un comportamiento más deseable sería apagarla, y luego volver a encenderla al salir del modo sleep, no?

Ya sabes que los bugs que no ocurren siempre son los peores. Me revisaré el código que tiene que ver con esa parte para ver si cazo algo. Si no veo nada y no me viene la inspiración será difícil dar con el fallo.

Respecto a la iluminación del LCD yo también había pensado que tener el LCD iluminado pero sin nada no queda bien, pero me temo que la librería LiquidCrystal Library no incluye ninguna función para apagar el LED del LCD. Tanto clear() como noDisplay() dejan encendido el LCD.

(21-02-2016, 09:32 PM)Agamenon escribió: [ -> ]
(21-02-2016, 09:10 PM)pedmar escribió: [ -> ]tengo un par de componentes mas para trastear pero me temo que para utilizar este LCD necesito una libreria que no se como localizar.

ademas de una sonda temperatura:
DALLAS
18B20
1148C4
+139AH

Uff no sabría decirte esa pantalla. Yo siempre he usado esta http://www.banggood.com/IIC-I2C-2004-204...08616.html, es I2C por lo que las conexiones son mucho más sencillas y la librería es la LiquidCrystal. Tu pantalla es de conexión serial, así que no vale esa. En el propio enlace de la tienda que has pasado aparece abajo para descargarte lo que supongo que será su librería, este es el enlace http://www.sparkfun.com/datasheets/LCD/SerLCD-v2.zip.

Para el sensor de temperatura yo uso la propia librería de dallas http://milesburton.com/Main_Page?title=D...ol_Library y la OneWire http://www.pjrc.com/teensy/td_libs_OneWire.html

la libreria del sensor DALLAS creo que ya me lo he descargado pero este enlace no funciona

Quítale el . final, se habrá colado en el copy & paste xD https://www.sparkfun.com/datasheets/LCD/SerLCD-v2.zip

(21-02-2016, 09:10 PM)pedmar escribió: [ -> ]tengo un par de componentes mas para trastear pero me temo que para utilizar este LCD necesito una libreria que no se como localizar.

ademas de una sonda temperatura:
DALLAS
18B20
1148C4
+139AH

He buscado por Arduino SerLcd

Nunca he usado un LCD Serial. Hay varios modelos. En lugar de usar el protocolo I2C usan el protocolo Serial.

Existe una página que te ofrece librérias y ejemplos de uso.

Ejemplos y librerias

En el ejemplo sugiere inicializar seleccionando como puerto serie Serial en pin 2. Veasé SerLCDConstructor

SoftwareSerial no es una maravilla, pero he mirado en el DataSheets la velocidad de comunicación que requiere el LCD, y admite 9600 baudios que es la velocidad más recomendable para SoftwareSerial. En resumidas cuentas, aunque no es un LCD muy popular, sí que parece posible usarlo.

Cuando yo empecé usando Arduino creo que compré uno muy parecido. Hay otros modelos de LCD Serial. Entonces no sabía lo que sé ahora y no fui capaz de usarlo. Además me lo cargué intentando hackearlo.

Hay un montón de hardware que parece servir, pero que no es apto para lo que uno necesita. En este caso creo que sí lo podrás usar y de paso todos aprenderemos de tu experiencia con este SerLcd.

Yo te ayudaré, tú tendrás que ir mirando por tu cuenta un poco los temas que menciono pero creo que se podrá sacar partido a ese hardware.

De momento intenta hacer funcionar el ejemplo.

El sensor DS18B20 tambien debería servir iremos poco a poco.