AHJJJJ! ¡qué fallo!

He comenzado con las pruebas del nuevo sistema, y debo decir antes de nada que todo va funcionando perfectamente (por ahora) así que estoy bastante contento con lo que he diseñado y construido.

Sin embargo me he encontrado con algunas pegas respecto de la famosa placa de comunicaciones por USB.  Así como las pruebas que hice el año pasado con las placas de comunicación por puerto serie no me dieron pega alguna, con esta si que estoy teniendo dificultades.

En primer lugar hay una cuestión estética:  Ya que la comunicación es USB, hay que meter un driver en el ordenador para manejar las comunicaciones con la placa. MicroPik suministra el driver, pero no se de dónde lo ha sacado, porque al cargarlo en Windows aparece un mensaje diciendo poco menos que que es pirata y que allá usted si carga eso. Mal empezamos. De todas formas yo cargué el programa, y aparentemente todo funciona bien.

El segundo tropiezo viene de lo siguiente: En la página Web de MicroPick dicen que con la placa se acompaña un programa para probarla y el código abierto (lo que los del negocio llamamos "los fuentes")  de ese mismo programa. Eso mismo ocurría con la anterior placa de comunicaciones.

Efectivamente el programa de prueba funciona bien y maneja la placa (al menos en cuanto a salidas, que es lo que me interesa) perfectamente, pero claro, no es más que un pequeño programa de demostración para ver que todo funciona.

Lo interesante para mi es disponer del código fuente del programa para a partir de él desarrollar los programas que yo quiero, tal como hice el año pasado. Sin embargo me encuentro con que el código que mandan está incompleto, y falta precisamente la parte más interesante que es la comunicación por USB.

Les he mandado varios correos y me están dando largas, pero no veo que vayan a darme una solución. Mala cosa. Y además inexplicable, porque si tienen el programa ejecutable que funciona bien, ¿porque no envían los fuentes de ese ejecutable.?

Quizá pudiera llegar a tener lo que necesito a base de hacer pruebas, pero me disgustaría tener que llegar a eso, cuando lo suyo es que me lo dieran hecho, tal como lo ofrecen.

De todas formas, ambos problemas pueden tener solución, pero esta tarde me he encontrado con un problema que no la tiene porque es un tema de concepto. Me refiero a la forma de captar las entradas digitales.

En la placa anterior que compré el año pasado, la captura de entradas digitales es por un evento. (el evento OnCom del control de comunicaciones). Esto quiere decir que sin hacer nada desde el programa, cuando el estado de las entradas varía, se activa el evento, y se puede programar hacer lo que se quiera. Sin  embargo con esta nueva placa, es el programa quién tiene que preguntar por el estado de las entradas y como respuesta, el microcontrolador de la placa le informa de su estado.

Seguramente mis lectores no se habrán dado cuenta de la importancia de esto. pero quedará claro de forma inmediata: Las entradas digitales están conectadas a los contactos reed que detectan el paso de los trenes, de forma que cuando una locomotora con imán pasa sobre uno de los reeds, se cierra el circuito y varía el estado de esa entrada. Pero ese estado cambiado dura unas fracciones de segundo, porque inmediatamente la locomotora ha pasado y el reed vuelve a su estado anterior.

Con el sistema de la placa por puerto serie, en el momento de que la locomotora pasa sobre el reed se produce un evento y el programa se entera siempre de que esto ha sucedido. En cambio si es el programa el que tiene que preguntar cada x tiempo por el estado de las entradas (de cada una de las entradas....) ¿cada cuánto tiempo tiene que preguntar por ese estado? ¿cada milisegundo? Está claro que es inviable, porque el programa no podría hacer otra cosa que averiguar el estado de las entradas. De hecho, en los aparatos que funcionan por impulsos  de corriente (los desvíos por ejemplo) el programa está parado mientras dura el impulso (típicamente 100 a 500 milisegundos). Como coincida una locomotora pasando por un reed en ese momento no se podría detectar su paso.

Resulta que en las centrales digitales comerciales, parece que también se da este caso, según algún comentario que he leído recientemente. Los usuarios se quejan de que falla la detección de trenes cuando hay mucho movimiento, y parece que las últimas versiones de centrales han corregido este defecto utilizando el sistema de eventos o interrupciones en lugar del "polling" que es como se llama la forma que exige que el programa muestree continuamente las entradas. No voy yo ahora a caer en ese fallo.

Total, que a pesar de que había pensado que esta placa era una buena solución. me estoy convenciendo de que más vale lo malo conocido, sobre todo cuando lo conocido no es malo. Lo bueno del caso es que todo mi diseño es perfectamente válido, tanto para la placa de puerto serie como para la USB, de manera que puedo continuar las pruebas con la placa de puerto serie, y si se resuelven los problemas del USB no habrá ningún problema en cambiar.

Lo que si es cierto es que los de MicroPik han caído varios enteros en mi apreciación. Ya veremos como termina este asunto, pero no me gustaría seguir dependiendo de ellos. De momento ya he pedido un libro de programación de microcontroladores.

Y... no he dicho nada de la fotografía de cabecera. Bueno no es más que una foto de las pruebas que voy haciendo, pero ha quedado bonita. A mi estas fotografías cercanas de aparatos electrónicos me parecen muy atractivas.