Manejo Flexible Robusto y Eficiente de Módulos GSM
-
Upload
leandro-francucci -
Category
Software
-
view
47 -
download
0
Transcript of Manejo Flexible Robusto y Eficiente de Módulos GSM
Manejo flexible, robusto y
eficiente de módulos GSMIng. Leandro Francucci ([email protected])
Vortex
10 de agosto de 2016
1
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
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
ProblemáticaIntroducción a la problemática y manejo
tradicional de módulos GSM en embedded systems
4
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
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 (UnsolicitedResult 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
Solución tradicionalEnvío y recepción sincrónica
7
client serialInvolved task:(1) Send command(2) Wait response(3) Parse response(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?.
Solución tradicionalEnvío y recepción sincrónica temporizada
8
client serial
getStringTimed(response, 1000) Evitamos bloqueos
inesperados e
indefinidos.
Solución tradicionalRecepción asincrónica
9
+CSQ: <rssi>,<ber>\r\nOK\r\n
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.
Solución tradicionalRespuesta ignorada
10
client serial delay module
\r\n\r\nOK\r\n
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.
Solución tradicionalFalta de sincronismo – Ruptura del modelo
11
clientBclientA serial
putString( AT+CREG=1\r\n )
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.
Solución tradicionalSincronismo 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?
Solución tradicionalSincronismo 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.
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
Solución propuestaMás eficiente, robusta y flexible
15
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
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.
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()
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
Envío de comandos20
Evento Command
recibido por
ModuleManager
Abstracción de
módulo
Envío de comando
Envío de comandos21
Otra alternativa
Implementación
para SIM5216
Implementación
para SIM900
Estructura de comandos22
e: RKH_SIG_Tnref: rui8_tpool: rui8_t
RKH_EVT_T
cmd: const char [MMGR_MAX_SIZEOF_CMDSTR]aoDest: RKH_SMA_T *waitResponseTime: RKH_TNT_TinterCommandTime: RKH_TNT_Tdata: 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,evCloseSessionmevEndSession,evETSITout,evInCallConnected,evInCallRejected,evLineError,evLineChange,evLineReleased,evCommand,evURC,evRing,evResponse,
<<enumeration>>
<<usage>>
id: Char [MMGR_MAX_SIZEOF_ID]
ID
Recepción de respuestas23
Evento Response
recibido por ModuleManager
Definición y envío de respuesta sin argumentos desde StringParser
Recepción de respuestas24
Definición y envío
de respuesta con
argumentos desde StringParser
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?
Identificando respuestas 26
Patrones
De acuerdo con la norma ITU-T V.250 - Serial asynchronous automaticdialling 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: “\r\n”.
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: “\r\nOK\r\n\r\n<value>\r\n”
Llamamos a las respuestas patrones
27
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
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
Á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): “ring\r\n”
30
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
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
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
Funcionamiento
Ahora el algoritmo transita a un nuevo nodo (manteniendo la búsqueda) si el caracteringresado 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
Modelo de comportamiento
del algoritmo
35
Ejemplo práctico36
Estructura37
type: unsigned charname: char *
SSPBase
SSPNodeNormal
branchAction()
patt: unsigned char *
SSPBranch
trnAction()
SSPNodeTrn
branchTbl
target
Estructura38
Detalles de la
implementación
39
Preguntas40
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: Superstructureversion 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-DrivenProgramming for Embedded Systems,” Elsevier, October 1, 2008.
[8] Kernighan & Ritchie, "C Programming Language (2nd Edition)", April 1, 1988.
41