Utilizando el polling con los GPIOs en los módems gprs Cinterion
Escrito por blogElectronica en 2.DISPOSITIVOS (práctico), Comunic. GSM/GPRSSi has trabajado alguna vez con los GPIO de los módems Cinterion TC65 o XT65 ( o sus terminales MTX) habrás comprobado que hay varias formas de trabajar con ellos. Hay comandos AT que nos permiten configurar un determinado GPIO como entrada o como salida y hay otros comandos AT que nos permiten saber el estado de un GPIO configurado como entrada (si hay un 1 ó un 0) o bien nos permiten cambiar el estado de una salida.
En uno de los ejemplos java que he ido poniendo por este blog, concretamente en el EJEMPLO_GPIO, utilizaba simplemente el comando AT^SGIO que devuelve el estado del pin en ese momento. Depende de la aplicación que queramos llevar a cabo puede ser suficiente con este comando AT, pero lo normal no es utilizar este sistema ya que la “frecuencia de barrido” que podemos conseguir es muy baja (además de cargar el sistema) y por tanto resulta muy complicado detectar cambios muy pequeños en el estado de un pin de entrada, es decir, que si por ejemplo tienes que detectar el pulso de detección de un volumétrico a lo mejor no lo cazas.
Lo mejor que puedes hacer para detectar los cambios de estado de las GPIOs es utilizar el polling. De esta manera el módem te devuelve un mensaje URC cada vez que se detecta el cambio en uno de sus GPIOs.
Veámoslo con un ejemplo. Imagina que quieres controlar las entradas GPIO1, GPIO2, GPIO3 y GPIO4 ¿Cómo lo hacemos?
Pues lo primero es habilitar los GPIOs, para ello enviamos:
AT^SPIO=1
Después configuramos los pines GPIO1, GPIO2, GPIO3 y GPIO4 como entradas, para ello:
AT^SCPIN=1,0,0
AT^SCPIN=1,1,0
AT^SCPIN=1,2,0
AT^SCPIN=1,3,0
Tras ello creamos un puerto, es decir, un puerto con todos aquellos GPIO que queramos involucrar en el polling:
AT^SCPORT=0,1,2,3
Al enviar este comando el comando AT nos devolverá un IDPort (un identificador de puerto), por ejemplo nos devuelve IDPort = 112
Y ya lo tenemos todo listo para activar el polling. Lo activamos haciendo:
AT^SCPOL=1,112
De esta manera cada vez que haya un cambio en una de las GPIO, el módem nos enviará un URC del estilo:
^SCPOL: 112, x
donde x puede valer de 0 a 1024, es decir, devuelve el estado de los 10 posibles GPIO que puedes controlar con el módem TC65.
Bueno, otro día más, ahora me voy a preparar la cena, que hoy dan CSI las vegas y es de la poca TV que veo en toda la semana. Y es que, la verdad, noto que cada vez me gusta menos la tele. ¿Me estaré haciendo mayor? :S
Post relacionados:
- Clases java InPort y OutPort para los módems gprs Cinterion y terminales MTX Como vimos hace ya un tiempo, con las nuevas versiones...
- Ejemplo de FTP Java para módems gprs Cinterion TC65 y XT65 Posiblemente en alguna ocasión tengas que hacer un programita en...
- Plataforma OTAP para módems gprs Siemens – Cinterion Hace tiempo que no escribo en el blog. Han sido...
- Cómo obtener la hora con los terminales MTX y módems Siemens / Cinterion Llevo casi un mes sin escribir en blogElectronica. Y es...
- Parámetro Autoexec de los módems Siemens / Cinterion Hoy voy a comentar por encima un parámetro importante...
Etiquetas: cinterion, modem, tc65, xt65
Entradas (RSS)
Hola Blogelectronica,
Muy bueno el post y muy interesante.
¿Se pueden crear varios “puertos”? ¿Sabes si hay un número límite?
De lo de la tele, no te estás haciendo mayor, te estás haciendo aún más inteligente
Salu2
Hombre, hola Kanemor!!!
Pues puedes crear tantos puertos como quieras, pero no puedes repetir GPIOs pues te dará error, por lo que el máximo nº de puertos que puedes definir es 10.
Salu2
El problema q he detectado con el polling, es q el modulo envia un URC con cada cambio de estado de cada pin en vez de contemplar todo el puerto. Es decir, si por ejemplo, el puerto cambia de tener un 3 (0011) a un 8 (1000) obtengo tres URC’s, uno por el bit menos significativo q se apago, otro por el segundo bit menos significativo q tambien se apago y recien en el tercer URC obtengo el dato q queria (esto, por supuesto, no se condice con la realidad, ya q los unos y/o ceros estan presentes a la entrada del puerto al mismo tiempo comandados por el clock de un latch, o sea, no creo q el modulo pueda distinguir el delay entre q levanta y baja el estado de cada pin lo cual debe estar en el orden de los nanosegundos o menos)
En definitiva, entre dos lecturas correctas siempre tengo basura y como no es un patron q se repita, no puedo filtrar la basura, conclusion: hacer polling sobre un puerto no sirve (o algo estoy haciendo mal…?)
Hola Paul,
pues la verdad es que me extraña lo que dices. Según el manual:
“There will be one URC reported for each polled pin whose has changed, and one for each polled port with one or more changed pins.”
debiera ser uno.
A ver si encuentro un hueco y lo pruebo. ¿Qué usas tú un TC65 o un XT65?
Salu2
TC65T – v2.0
Hola,
Estoy desarrollando un midlet que interactua con pulsadores sobre los GPIO 1 a 4.
Implemente exitosamente el polling sobre los GPIO 1, 2 y 4. Recibiendo exitosamente el evento URC al presionar cada pulsador.
Pero por alguna razon el GPIO3 no me responde por el polling pero si via el comando At^SGIO (me da 1 cuando presiono el pulsador y 0 cuando no lo hago) por lo que el pulsador esta andando correctamente.
A continuación dejo el log del retorno de los comandos que ejecuta el midlet:
14/05/09,17:23:17: AT^SPIO=1 OK
14/05/09,17:23:17: AT^SCPIN=1,3,0 OK
14/05/09,17:23:17: AT^SCPIN=1,2,0 OK
14/05/09,17:23:18: AT^SCPIN=1,1,0 OK
14/05/09,17:23:18: AT^SCPIN=1,0,0 OK
14/05/09,17:23:18: AT^SCPORT=0,1,2,3 ^SCPORT:112 OK
14/05/09,17:23:19: AT^SCPOL=1,112 OK
Estos son los comandos que me llegan via URC:
Pulsando GPIO4:
14/05/09,17:24:07: Evento: ^SCPOL:112,8
14/05/09,17:24:08: Evento: ^SCPOL:112,0
Pulsando GPIO2:
14/05/09,17:18:48: Evento: ^SCPOL:112,2
14/05/09,17:18:49: Evento: ^SCPOL:112,0
Pulsando GPIO1:
14/05/09,17:19:15: Evento: ^SCPOL:112,1
14/05/09,17:19:17: Evento: ^SCPOL:112,0
Mi duda es, ¿puede ser que el GPIO3 no permita polling?
Gracias.
Salu2
Hola Fernando,
me dejas desconcertado … ¿qué versión de TC65 tienes? Yo lo he probado en un TC65v3 sin problemas.
Salu2
Es posible lanzar una aplicación java cuando una GPIO de entrada cambia de 0 a 1?
Gracias
Hola Ismael,
en principio, hasta donde yo sé, no es posible con el MTX65i. La única manera de hacer eso que conozco sería usando un MTX65-ULP (el equipo estaría dormido hasta que se activa una GPIO y por tanto, al despertarse, arrancaría la aplicación java).
Salu2