Manejo flexible, robusto y

eficiente de módulos GSMIng. Leandro Francucci (francuccilea@gmail.com)

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