Pónte cómodo, agarra palomitas y refresco que esta respuesta se me ha alargado tanto por acumulación de varias preguntas/respuestas de este hilo.
CaleBit:
Al principio lo hice ocupando una interrupción, mientras el bucle estaba mostrando los mensajes de bienvenida, al detectar el pulso del coin o botón (que se me quemó, pero compraré otro), me mostraba un registro en el monitor y en la lcd, el problema aquí era que solo me mostraba uno solo y lo repetía cada vez que leía la interrupción y no hacía el salto al siguiente registro, además, lo mostraba un poco rápido, y volvía de nuevo al bucle, me aconsejaron que esta no era la forma correcta de hacerlo que mejor lo hiciera leyendo el pin con digitalRead y haciendo las pruebas de las correcciones que agradezco infinitamente a Lucario
De nada.
Aunque de ser así, tendrás que implementar máquina de estados para no quedarte atascado en el "demo" y no detectar el botón a tiempo. La idea era leer un registro por cada pulso, entonces esta rutina no tenía que ser cíclica (cosa que hice en mi sugerencia por la falta de entendimiento), y la variable File debe ser global (o static).
Las rutinas de interrupción realmente no se crean para "repentinamente" cambiar el flujo de ejecución del programa principal, sino para atender tareas cortas pero que tienen prioridad de atención. No vas a dejar de ver televisión (programa principal) solo porque fuiste a atender el teléfono (interrupción).
No digo que no sea posible; lo que pasa es que por algo no se debe hacer.
Una de las razones son las "operaciones moleculares", que usualmente suelen ser operaciones matemáticas con float y otros tipos de datos de más del "ancho" del CPU (en este caso, 8 bits); en general las operaciones matemáticas combinadas en una sola línea son "moleculares".
Lo opuesto a la "operación molecular", es la "operación atómica"; la cuál, por definición, no se puede dividir; o mejor dicho, no se puede interrumpir. Las atómicas básicamente son aquellas que se pueden ejecutar una sola instrucción máquina; cabe aclarar que una instrucción máquina no necesariamente equivale a una línea de código (excepto en lenguaje ensamblador).
A todo esto, ¿entonces qué tiene de malo hacerlo? ¿Recuerdas cuando dije que las operaciones atómicas no se pueden interrumpir? Bueno pues ese el problema: sólo las atómicas.
Imagina que en plena suma de dos int se dispara una interrupción, se ejecuta su respectiva rutina pero al terminar, en vez de retomar esa suma, ejecuta otro proceso completamente distinto. ¿Qué ocurrió con la suma? La respuesta puede variar dependiendo del momento exacto en que se disparó, pero las posibilidades son: se realizó con éxito (en el mejor de los casos), la variable del resultado tiene un valor incorrecto (no es ni el anterior ni el esperado), o no ocurrió absolutamente nada (en el peor de los casos).
Sé que en "demo" no hay operaciones matemáticas, ¿pero en print, clear y setCursor? Ahí quizá sí; el no completar la ejecución como se debe, podría incluso ser fatal.
Utilizar una interrupción para alterar el flujo del programa principal es mucho más complicado de lo parece (y no recomendado por lo antes dicho); y no, no hablo de simplemente modificar el valor de una "bandera" porque eso implicaría máquina de estados de todos modos (es igual que con digitalRead).
Es tan complicado como estudiar la estructura de la pila de ejecución ("stack" en inglés) para así poder alterar el valor previo a la interrupción del "program counter"; lo cual debería resultar, efectivamente, en la alteración del flujo del programa principal posterior a esta rutina. Con decirte que eso solo es posible hacerlo con un fragmento de código en ensamblador, quizá eso te eche para atrás y prefieras mejor quedarte con lo de la máquina de estados.
Encima habrían otros efectos secundarios como perder el rastro de la pila, que a la larga provoca cuelgues por el desbordamiento de esta; a menos que con más código ensamblador, conviertas la rutina de mostrar un contacto, en algo parecido a una interrupción (capacidad de retornar al punto en el que realmente estaba) pero con poder usar Serial y delay.
Tengo entendido que eres principiante, así que si quieres evitar tanta confusión, te sugiero que prosigas con lo de la máquina de estados y nos preguntes por dónde te perdiste. Pero eso sí, ¡que se vea un esfuerzo de tu parte!
CaleBit:
estuve investigando un poco y me parece que es el efecto rebote, alguna idea para solucionar esto
Por software: un pequeño delay apenas se detecta el pulso.
Por hardware: un condensador de 10 uF paralelo al botón.
CaleBit:
1-Una primera duda el coin que tengo funciona también como un botón, es decir al entrar una moneda, sería como pulsar un botón?
Correcto. Al pasar la moneda, se cierra un circuito durante una fracción de segundo; pero lo suficiente para que el programa lo detecte mientras no esté atascado en retrasos.
CaleBit:
¿Al poner el cable en pin 2 este espera el pulso para activarse(HIGH)?, o todo el tiempo esta entregando un voltaje porque si es así como podría conocer su estado.
Eso de sí se conecta a tierra o a voltaje depende de la lógica de la salida: el "estado activo" puede ser alto o bajo. O también determina en un botón u otro contacto simple si usar resistencia pull-up o pull-down (usados para estabilizar los estados digitales, pero no soluciona los rebotes).
CaleBit:
Alguien conoce la sintaxis de esta función?
millis() no requiere parámetros. Retorna un unsigned long que representa los milisegundos transcurridos desde que el Arduino se enciende o reinicia. Se desborda cada 49.71 días.
CaleBit:
Gracias y disculpen tantas molestias.
¿Molestias de qué? Para eso estamos, y con más razón para los que apenas empiezan