Ir al contenido principal

Entradas

Modelo de transacción fiable en sistemas intercomunicados

Los embedded systems utilizan los protocolos de comunicación para enviar y recibir información crítica, tanto entre procesadores internos, como con actores externos. Dentro del mismo sistema, algunos mensajes pueden ser más críticos que otros, requiriendo un alto nivel de fiabilidad en su transferencia al medio. Para aumentar este factor en un medio poco fiable o cuando se requiere una fiabilidad extraordinaria, puede recurrise al mecanismo de transacción, el cual disminuye la probabilidad de ocurrencia de ciertos problemas, que en determinados sistemas, como los médicos, pueden incurrir en fallas muy severas. El presente artículo describe la aplicación del mecanismo de transacción "exactamente una vez" (EO - exactly once) [3], sobre un sistema que controla un motor, monitorea su velocidad de salida, su temperatura y su presión de aceite, y provee una interfaz al usuario. El sistema en cuestión intercambia información entre sus actores, utilizando el par...

Statecharts implementados mediante tablas de estados

El presente artículo tiene por objetivo mostrar las bases de una implementación de máquina de estados Statechart [2,3,5,6] en lenguaje C (compatible con C++), cuyo objetivo fundamental es lograr una representación en código fuente simple, directa, transparente, legible, flexible y compacta, que permita determinar de un sólo vistazo la topología del diagrama que representa, y así lograr una implementación sencilla de modificar, mantener e interpretar. Incluso que facilite la generalización, la reutilización, la transportabilidad, como así también la generación de código automático. Si bien dicha implementación busca maximizar la legibilidad, no descuida ni la eficiencia en el uso de recursos ni la velocidad de ejecución.

Identificación de respuestas a comandos AT en ISR. Intérprete de comandos.

Gestionar un módulo GSM por comandos AT, recibir, buscar e interpretar tanto las respuestas a comandos como las no solicitadas (URC) no es una cuestión menor si se requiere una solución eficiente, robusta y flexible. Sabiendo que cada comando AT tiene por resultado un conjunto posible de respuestas y que estas se representan por cadenas de caracteres codificadas en ASCII, en principio, el software que las recibe tiene por objetivo identificarlas de acuerdo al comando enviado, sin olvidar la detección de aquellas no solicitadas, aún cuando aguarda la respuesta a un comando enviado. También se lo conoce como intérprete de comandos AT. La intención del presente artículo es proponer una solución a esta problemática, siguiendo las ideas de la publicación Administración de módulos GSM en sistemas reactivos , basada en la estructura de datos tipo árbol y los autómatas finitos, también conocidas como máquinas de estados finitas.

Administración de módulos GSM en sistemas reactivos

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. Hasta aquí, el esquema obedece a un simple modelo del tipo cliente-servidor, en el cual el módulo externo o dispositivo se comporta como servidor de comandos, procesando las solicitudes y enviando en consecuencia el resultado obtenido al cliente conectado. En este caso, el cliente es aquel que envía el comando y espera indefectiblemente una respuesta como resultado. De forma tal, que una próxima solicitud deberá esperar la respuesta del comando previo, ya que los módulos GSM tradicionales no permiten recibir un comando mientras se encuentre en procesamiento, por lo tanto, desde el punto de vista del cliente, la respuesta implica que el módulo está nuevamente listo para recibir comandos. Si así no fuera, puede que el comando se descarte o bien el procesamiento en curso se aborte. Otra de las problemáticas surge con las respuestas no solicitadas ...

Eventos y acciones en contexto

La intención del artículo es promover y fundamentar el uso de las máquinas de estados en aquellos sistemas que reaccionan ante eventos, formalmente sistemas reactivos , típicos entre los embedded systems . Sistemas reactivos y la programación orientada a eventos Los sistemas reactivos son aquellos que en gran parte reaccionan contínuamente a estímulos externos e internos. Estas reacciones dependen de los eventos que recibe el sistema y de su contexto actual. Generalmente, se manifestan por medio de acciones. Inclusive, podrían cambiar el contexto del sistema. Por contexto entendemos una situación, modo o estado particular en el cual el sistema reside. Obviamente, puede que ciertos eventos no provoquen reacciones sobre el sistema, o bien que estas no generen acciones o cambios de contexto. Por otro lado, el conjunto de reacciones establecidas dependiente de los eventos recibidos para un contexto particular define el comportamiento dinámico de un sistema reactivo.  ...

Extendiendo el formalismo de máquinas de estados - I

Cuando modelamos el comportamiento de un sistema mediante máquinas de estados no siempre todo es bonito, claro y sencillo, en ciertas ocasiones debemos tomar diversas estrategías para resolver los pocos obstáculos que presenta el formalismo convencional de máquinas de estados. A continuación resumo algunas de las problemáticas que he enfrentado al diseñar sistemas utilizando máquinas de estados, exponiendo el problema y luego presentando una o varias soluciones posibles extendiendo el formalismo convencional por medio de Statecharts.

Optimice su código

Incorporar ciertas técnicas de optimización durante la escritura de un programa, especialmente en el mundo embedded, es realmente una gran ventaja. Me refiero a "programar optimizando". Por supuesto, sin que esto arruine la legibilidad y simplicidad del programa o altere su comportamiento. Para ello se requieren sólidos conocimientos del lenguaje y del compilador en uso. Hace algunos años, he asistido a varias clases en las cuales el profesor Eduardo A. Martinez transmitió estas y otras prácticas, útiles al momento de escribir un buen programa en lenguaje C. Por suerte, él mismo ha resumido parte de sus clases en los siguientes artículos: Optimece su código - Parte 1 Optimece su código - Parte 2