Presentación de una particular solución de software para administrar y controlar un módulo GSM operado por comandos AT de manera no bloqueante, cumpliendo las restricciones que imponen estos dispositivos, encapsulando su comportamiento y restringiendo el acceso concurrente al mismo, evitando el uso de complejos mecanismo de exclusión mutua y los extensos bloqueos de la CPU ante la espera de respuestas. A su vez, se presentará un simple y autónomo algoritmo para identificar eficientemente las respuestas del módulo GSM, logrando así una solución robusta, eficiente, flexible, fácil de mantener, probar y extender, respetando lo que se conoce como los principios del código limpio. La solución propuesta se basa en la aplicación del paradigma de la programación reactiva o dirigida por eventos mediante máquinas de estados Statecharts.

1. Manejo flexible, robusto y
eficiente de módulos GSM
Ing. Leandro Francucci (francuccilea@gmail.com)
Vortex
10 de agosto de 2016
1

2. Objetivo
 La aplicación de la solución propuesta tiene por objetivos:
 Simplificar, optimizar y flexibilizar una aplicación de
embedded software que utiliza un módulo GSM, por medio de las
máquinas de estados y la programación reactiva, como así también
del uso de los principios del diseño ágil.
 Comprender las bases de la programación dirigida por
eventos como alternativa a la programación tradicional.
2

3. Agenda
 Introducción a la problemática y manejo tradicional de módulos
GSM en embedded systems
 Descripción de la solución propuesta
 Aplicación del paradigma de la programación reactiva para el
envío de comandos y recepción de respuestas
 Identificación de respuestas solicitadas y no solicitadas en
diversos contextos
 Definición de respuestas como patrones
 Mecanismo de recepción
 Búsqueda de patrones
 Ejemplo
 Funcionamiento y detalles de la implementación
3

4. Problemática
Introducción a la problemática y manejo
tradicional de módulos GSM en embedded systems
4

5. Comandos AT
Modelo cliente servidor
 Generalmente, un módulo GSM se administra por medio de
comandos AT, lo cual implica enviar un comando y esperar la
recepción de una respuesta. Modelo cliente-servidor.
 Servidor: módulo GSM. Recibe y procesa las solicitudes (comandos
AT) una por vez, enviando una respuesta en consecuencia.
 Cliente: envía la solicitud y espera una respuesta como resultado.
 De forma tal que, una próxima solicitud deberá esperar la respuesta del
comando previo
 La recepción de la respuesta implica que el módulo está listo para recibir
nuevos comandos
5

6. URC
 Por lo general, el módulo notifica asincrónicamente la ocurrencia
de ciertos eventos, sin necesidad de comandos previos
 Estas notificaciones por lo general se denominan URC (Unsolicited
Result Code)
 Los URC rompen el modelo cliente-servidor
Lo expuesto se aplica a cualquier tipo de módulo que utiliza
comandos AT, ya sea GSM, GPS, dial-up, etc.
6

7. Solución tradicional
Envío y recepción sincrónica
7
client serialInvolved task:
(1) Send command
(2) Wait response
(3) Parseresponse
(4) Return response
 Durante el envío
del comando y la
espera de la
respuesta client
permanece
bloqueado.
 ¿Qué
consecuencias
tiene este
modelo?.
 ¿Qué ocurre si durante la espera de
respuesta recibimos un URC?.
 ¿Qué ocurre si el módulo no responde?.

8. Solución tradicional
Envío y recepción sincrónica temporizada
8
client serial
getStringTimed(response, 1000)
 Evitamos bloqueos
inesperados e
indefinidos.

9. Solución tradicional
Recepción asincrónica
9
+CSQ: <rssi>,<ber>rnOKrn
client serial delay module
 La intención del retardo es asegurar que el módulo procesó y respondió al
comando previo, es el tiempo inter-comando.
 Mediante algún mecanismo, serial notifica a client.
 La recepción y procesamiento de la respuesta se efectúa en un contexto
de ejecución independiente.

10. Solución tradicional
Respuesta ignorada
10
client serial delay module
rnrnOKrn
 Aún con el tiempo
inter-comando,
gran parte de las
respuestas a
comandos se
ignoran.
 ¿Qué ocurre si la
respuesta
condiciona la
ejecución
posterior?.
 ¿Qué ocurre si
recibimos un URC?
 Este retardo debe asegurar la
respuesta de todos los comandos
utilizados por el sistema.

11. Solución tradicional
Falta de sincronismo – Ruptura del modelo
11
clientBclientA serial
putString( AT+CREG=1rn )
 De no asegurar el
procesamiento de un
comando, mediante la
recepción de su
respuesta, en un sistema
concurrente dos o más
tareas pueden enviar
comandos solapados.
 Algunos módulos tratan
esta situación como
errónea.

12. Solución tradicional
Sincronismo en bare-metal
12
clientBclientA serial delay
delay(500)
 En un sistema
cooperativo no
apropiativo,
utilizando la
ejecución
sincrónica, las tareas
envían sus
comandos de
manera secuencial,
sin solaparse.
 ¿Qué impacto tiene
este modelo en el
sistema?

13. Solución tradicional
Sincronismo con OS/RTOS
13
clientBclientA serial delay
delay(500)
 En un sistema
apropiativo, con
máxima utilización de
CPU, aún utilizando la
ejecución sincrónica, el
envío de comandos
entre tareas puede
solaparse.

14. Observaciones generales
 Apropiación prolongada de la CPU.
 Probables bloqueos indefinidos. Poca robustez.
 No se respeta el modelo cliente servidor, falta de sincronismo.
 Prolongados retardos.
 Análisis de respuesta por método de fuerza bruta.
 Diseño rígido y viscoso, respecto a cambios en el módulo.
14

15. Solución propuesta
Más eficiente, robusta y flexible
15

16. Las premisas
 El software de una aplicación que administra y controla un módulo
externo manejado por comandos AT, debería ser tal que:
 Envíe comandos AT, y en función de estos espere un conjunto de
respuestas posibles.
 Notifique la recepción de respuestas no solicitadas.
 Durante la espera de respuesta no se apropie de la CPU.
 Notifique si no recibe respuesta alguna ante un comando enviado.
 Secuencie el envío de comandos, al ritmo que imponga el módulo en
cuestión.
 Incorpore las temporizaciones requeridas por el módulo relacionadas
con los comandos.
16

17. Estructura17
Client evOpen()
evClose()
evComand(cmd, aoDest, waitResponseTime, interCmdTime,
data, nData)
evURC()
ModuleManager
StringParser
 Aquellas tareas que requieran enviar comandos y recibir sus
respuestas, como así también URC, son clientes de la entidad
ModuleManager, la cual cumple las premisas propuestas.
 La ejecución de ModuleManager es independiente a la de sus
clientes.
 Por otro lado, la recepción y procesamiento de las respuestas y
URC se realiza en un contexto de ejecución independiente al de
ModuleManager y sus clientes.
 En lenguaje UML, estas entidades se denominan objetos activos.

18. Comportamiento de
ModuleManager
18
ModuleManager
inactive
evOpen/
evCommand(cmd, aoDest, waitResponseTime,
interCommandTime, data, ndata)/ defer()
evURC/ notifyURC()
active
idle
inProgress
evToutWaitResponse/
noResponse()
evCommand(cmd,
aoDest,
waitResponseTime,
interComandTime,
data,
ndata)/ sendCommand()
waitInterCmdTime
evResponse(fwdEvent)/ sendResponse()
[isInterComandTime()]/ startDelay()
[else]/ moreCommand()
evToutInterCommandTime/
moreCommand()
evClose/
/ initialization()

19. Observaciones
 No existe conexión lógica entre el dispositivo y los clientes que requieren enviar
comandos, recibir respuestas o URC. El vínculo entre estos es ModuleManager. Esto
permite encapsular el comportamiento del módulo, y restringir así el acceso
concurrente al mismo.
 Cuando un cliente requiere enviar un comando al módulo, lo hace enviando el
evento apropiado a ModuleManager.
 El comando representado por la cadena de caracteres lo envía exclusivamente
ModuleManager al módulo.
 El ModuleManager posee una cola de comandos, la cual permite recibir nuevos
comandos aún cuando el módulo externo se encuentre en procesamiento.
Evitando bloquear la ejecución de aquellos clientes que esperan respuestas y
garantizando el acceso concurrente al dispositivo. Hasta aquí, la solución se basa
en el patrón de diseño objeto activo[1].
 Cada comando que reside en la cola del ModuleManager posee un cliente
asociado.
 StringParser envía a ModuleManager una notificación indicando la recepción
de la respuesta. El contexto de ejecución de StringParser puede ser tarea o
ISR.
 La notificación de la respuesta se redirige al cliente correspondiente.
 Los URC se envían a los clientes que los requieran.
19

20. Envío de comandos20
Evento Command
recibido por
ModuleManager
Abstracción de
módulo
Envío de comando

21. Envío de comandos21
Otra alternativa
Implementación
para SIM5216
Implementación
para SIM900

22. Estructura de comandos22
e: RKH_SIG_T
nref: rui8_t
pool: rui8_t
RKH_EVT_T
cmd: const char [MMGR_MAX_SIZEOF_CMDSTR]
aoDest: RKH_SMA_T *
waitResponseTime: RKH_TNT_T
interCommandTime: RKH_TNT_T
data: rui8_t *
nData: rui8_t
Command
forwardEvt: RKH_SIG_T
Response
value: rui16_t
Reg16
evBusy,
evError,
evFRM,
evFTM,
evInError,
evOk,
evLineFailure,
evNoCarrier,
evNoDialTone,
evReadReg16,
evID
<<enumeration>>
<<usage>>
evAlertInCall,
evCloseSessionm
evEndSession,
evETSITout,
evInCallConnected,
evInCallRejected,
evLineError,
evLineChange,
evLineReleased,
evCommand,
evURC,
evRing,
evResponse,
<<enumeration>>
<<usage>>
id: Char [MMGR_MAX_SIZEOF_ID]
ID

23. Recepción de respuestas23
Evento Response
recibido por
ModuleManager
Definición y envío de respuesta sin argumentos
desde StringParser

24. Recepción de respuestas24
Definición y envío
de respuesta con
argumentos desde
StringParser

25. Diseño flexible
 Lo más probable es que por algún motivo (disponibilidad, costo, características,
obsolescencia, etc) el módulo deba cambiarse.
 Entonces necesitamos abstraernos por software de las particularidades de estos.
 Dependiendo de las necesidades de la solución, estos pueden seleccionarse en
momento de compilación, linkeo o en ejecución.
25
Client evOpen()
evClose()
evComand(cmd, aoDest, waitResponseTime, interCmdTime,
data, nData)
evURC()
registerURCReceiver()
unregisterURCReceiver()
ModuleManager
formatSetCOLP()
formatHangup()
<<abstract>>
ModuleCmd
formatHangup()
Sim900
formatHangup()
Sim5216
StringParser
 ¿Qué ocurre si diferentes clientes receptores requieren los URC, y
estos se definen durante la ejecución?

26. Identificando respuestas26

27. Patrones
 De acuerdo con la norma ITU-T V.250 - Serial asynchronous automatic
dialling and control, el DCE (en este caso módulo GSM) puede emitir
respuestas del tipo código de resultado.
 Este se compone de tres partes: <encabezado><resultado><epílogo>
 Generalmente, el encabezado y epílogo suelen ser: “rn”.
 Hay tres tipos de códigos de resultado
 Final: indica la culminación de una acción y que está disponible para recibir
un nuevo comando. Ej: “OK”, “ERROR”.
 Intermedio: informa el progreso de una acción. Ej: “CONNECT”.
 No solicitado: indica que se produjo un evento no asociado directamente
con un comando. Ej: “RING”.
 Las respuestas pueden contener información. Ej:
“rnOKrnrn<value>rn”
 Llamamos a las respuestas patrones
27

28. Mecanismo de recepción
 El software que busca e identifica patrones podría:
 Ejecutarse en contexto de interrupción, específicamente en ISR de
recepción, la búsqueda se realizar “on-line”.
 Almacenar en ISR los caracteres recibidos, para luego realizar la
búsqueda fuera de interrupción.
 Ser una combinación de las anteriores, en la cual la ISR identifica
cadenas válidas y notifica al algoritmo que comience la búsqueda
sobre esta última.
 Otras.
 Estas soluciones requieren conocer, antes de comenzar la
búsqueda, el conjunto de cadenas a esperar de acuerdo al
comando enviado y los URC disponibles.
28

29. Búsqueda de patrones
Se pretende diseñar un mecanismo tal que cumpla con las siguientes
premisas:
 La búsqueda se realiza “on-line”
 Conoce las respuestas esperadas, de acuerdo al comando
enviado
 Identifica los URC
 Las búsquedas se realizan sobre cadenas codificadas en ASCII
 Permite buscar cadenas con formato y argumentos (patrones)
 Los patrones se especifican en tiempo de compilación
 Su entrada debe ser intuitiva, visualmente clara y flexible
 Deben minimizar su uso de RAM
 No requieren pre-procesamiento
 Posee un simple mecanismo de notificación al encontrar un patrón
29

30. Árbol
 Un gran desafío es lograr una búsqueda
“on-line” eficiente, evitando el método
tradicional de la fuerza bruta.
 El principio del método se basa en la
estructura de datos del tipo árbol, la cual
permite arreglar los patrones en un
diagrama como el de la figura.
 Por definición: un árbol es una estructura
de datos que imita la forma de un árbol
(un conjunto de nodos conectados). Un
nodo puede contener 0 o más nodos
hijos. Sólo puede haber un único nodo sin
padres, el raíz. El nodo sin hijos se
denomina hoja. El resto son ramas. Ej de
(1) a (2): “ringrn”
30

31. Algoritmo de búsqueda
Consiste en:
 Mientras el caracter recibido pertenezca a los esperado por el nodo actual, la
búsqueda continúa, caso contrario vuelve al root,
 la búsqueda termina con éxito, si se encuentra el nodo hoja, aquellos coloreados
en negro, en cuyo caso vuelve al root,
 la búsqueda se realiza en cada caracter recibido, lo que implica unas pocas
comparaciones de caracteres para determinar el próximo nodo. Esto demuestra
la eficiencia del método,
 el funcionamiento se resume al de un autómata finito, en donde el alfabeto de
entrada se forma por los caracteres enviados por el módulo, los estados por los
nodos y las transiciones por el enlace entre estos,
 cuando la búsqueda se realiza con éxito, el mecanismo notifica que ha sido
recibido el patrón en cuestión, el cual se forma desde el nodo root al nodo hoja.
 Por otro lado, para que el algoritmo identifique el comando enviado y con esto
los patrones a esperar, el método requiere habilitar el eco de comandos. Aunque
no es estrictamente necesario.
31

32. Nodo transparente
 En un nodo transparente, si el caracter recibido no coincide con
los esperados no transita al nodo root como lo hace el resto, por
el contrario, permanece en este hasta que arribe el caracter
esperado. Ej: ver (5).
 Son básicamente "comodines", los cuales se utilizan para la
búsqueda de patrones con datos variables.
32

33. Simplificando el árbol
 La representación de patrones
puede simplificarse respecto de la
figura anterior, agrupando los
nodos que se encuentren desde
uno que tenga más de un hijo
hasta un nodo hoja,
descendiendo en la jerarquía.
 La representación es más clara y
sencilla.
33

34. Funcionamiento
 Ahora el algoritmo transita a un
nuevo nodo (manteniendo la
búsqueda) si el caracter
ingresado es el último caracter de
la cadena esperada.
 Si el caracter ingresado no
coincide con el esperado, la
búsqueda falla y termina
volviendo a root.
34

35. Modelo de comportamiento
del algoritmo
35

36. Ejemplo práctico36

37. Estructura37
type: unsigned char
name: char *
SSPBase
SSPNodeNormal
branchAction()
patt: unsigned char *
SSPBranch
trnAction()
SSPNodeTrn
branchTbl
target

38. Estructura38

39. Detalles de la
implementación
39

40. Preguntas40

41. Referencias
[1] L. Francucci, “Administración de módulos GSM en sistemas reactivos”,
Embedded Exploited, http://embedded-
exploited.blogspot.com.ar/2012/12/administracion-de-modulos-gsm-en.html
[2] L. Francucci, “Identificación de respuestas a comandos AT en ISR. Intérprete
de comandos”, Embedded Exploited, http://embedded-
exploited.blogspot.com.ar/2012/12/identificacion-de-respuestas-
comandos.html
[3] D. Harel, "Statecharts: A Visual Formalism for Complex Systems", Sci. Comput.
Programming 8 (1987), pp. 231–274.
[4] RKH, “RKH Sourceforge download site,”, http://sourceforge.net/projects/rkh-
reactivesys/ , August 7, 2010.
[5] Object Management Group, “Unified Modeling Language: Superstructure
version 2.1.1,” formal/2007-02-05, Febrary 2007.
[6] B. P. Douglass, “Design Patterns for Embedded Systems in C,”, Elseiver,
October 7, 2010
[7] M. Samek, “Practical UML Statecharts in C/C++, Second Edition: Event-Driven
Programming for Embedded Systems,” Elsevier, October 1, 2008.
[8] Kernighan & Ritchie, "C Programming Language (2nd Edition)", April 1, 1988.
41