If you’ve ever worked with GPIOs from Cinterion TC65 or XT65 (or their MTX terminals), you will have realized that there are different ways to work with them. There are AT commands that allow us to set a specific GPIO as an input/output and there are other AT commands that let us know the status of the GPIO set as an input (1 or 0) or even allow us to change an output status.

In one of the Java examples that I have been posting on this blog, specifically in the GPIO EXAMPLE, I simply used the command AT^SGIO which returns the pin status at that point in time. So it depends on the application that you want to run as this AT command could suffice, but this system isn’t usually used as we obtain a very low “sweep frequency” (in addition to loading the system) and therefore it’s very complicated to detect very small changes in the input pin status. If for example you have to detect a volumetric detection pulse, you might not catch it.

modem-entrada-digital

The best thing to do to detect GPIO status changes is to use polling. This way the modem sends you a URC message each time a GPIO change is detected.

Let’s look at an example. Imagine that you want to control GPIO1, GPIO2, GPIO3 and GPIO4 inputs. How do we do it?

Well the first thing you need to do is enable the GPIOs, to do this send:

AT^SPIO=1

Then, configure the pins GPIO1, GPIO2, GPIO3 and GPIO4 as inputs, to do this:

AT^SCPIN=1,0,0

AT^SCPIN=1,1,0

AT^SCPIN=1,2,0

AT^SCPIN=1,3,0

After that we create a port, i.e. a port with all of the GPIOs that we want to involve in the polling process:

AT^SCPORT=0,1,2,3

By sending this command, the AT command will return an IDPort (port identifier) e.g. it will response with IDPort = 112

And now we have everything ready to activate polling. We activate doing this:

AT^SCPOL=1,112

This way whenever there is a change in one of the GPIOs, the modem will send us a URC in this style:

^SCPOL: 112, x

X can be worth 0-1024 i.e. it returns the status of the 10 possible GPIOs that you can control with the TC65 modem.

Well I’ll be back another day, I’m going to go and make dinner now as today CSI Las Vegas is on and it’s the only bit of TV I watch all week. The truth is every time I watch the TV I realize that I like is less and less. Am I getting old?! :S


Post relacionados:

  1. InPort and OutPort Java Classes for Cinterion GPRS Modems and MTX Terminals As we saw some time ago, new Java classes have...
  2. Java FTP example for Cinterion GPRS modems TC65 and XT65 You will possibly at some point have to make a...
  3. Locating Difficult Reproduction Failures in TC65/XT65 Cinterion Modems If you develop applications in Java for GPRS TC65, XT65 (or their MTX65 or MTX65+G terminals...
  4. (Español) Ejemplos Java para módems de Siemens Over the last few months I have been getting a...
  5. How to get the time with MTX terminals and Siemens/Cinterion modems I haven’t written on blogElectronica for nearly a month. For...








Tags: , , ,
9 Responses to “Using GPIO Polling in Cinterion GPRS Modems”
  1. kanemor says:

    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 :D

    Salu2

    • blogElectronica says:

      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

  2. Paul says:

    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…?)

    • blogElectronica says:

      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

  3. Fernando says:

    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

    • blogElectronica says:

      Hola Fernando,

      me dejas desconcertado … ¿qué versión de TC65 tienes? Yo lo he probado en un TC65v3 sin problemas.

      Salu2

  4. Ismael says:

    Es posible lanzar una aplicación java cuando una GPIO de entrada cambia de 0 a 1?

    Gracias

    • blogElectronica says:

      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

  5.  
Leave a Reply

Puedes publicar un comentario aquí si quieres, pero te recomiendo que uses el nuevo foroElectronica.com para introducir comentarios. Te contestaré más rápido. Recuerda que debes registrarte si no lo estás para publicar un comentario.