capítulo 2: métodos y materialesbibing.us.es/proyectos/abreproy/11981/descargar... · lenguaje...

Métodos y materiales

17

Capítulo 2: Métodos y materiales

Los sistemas embebidos son sistemas de altas prestaciones diseñados para ejecutar un

conjunto de aplicaciones concretas y que, sobretodo, van a estar integrados en sistemas

portables.

Generalmente están controlados por un DSP que no es más que un procesador digital

diseñado específicamente para aplicaciones de procesamiento de señales, de modo que

son capaces de manejar datos de forma más eficiente que un procesador de propósito

general. Así, permiten realizar un procesado digital en tiempo real similar al de un

ordenador corriente con la ventaja de poder ser integrado en sistemas portables, pero

también con las limitaciones que ello conlleva.

Los sistemas embebidos se caracterizan por unas condiciones de diseño muy estrictas,

que se refieren principalmente a tiempos de ejecución que permitan respuestas en

tiempo real, consumos de potencia suficientemente bajos como para proporcionar cierta

autonomía al dispositivo portable y coste razonable, de modo que el sistema represente

una solución viable al igual que interesante para los usuarios.

Estas características de portabilidad y de respuesta en tiempo real, hacen de los sistemas

embebidos una tecnología muy interesante desde el punto de vista de las aplicaciones

biomédicas, que en muchas ocasiones requieren de ambas propiedades.

2.1. Funcional

La implementación de un algoritmo de procesado digital de señales desde su diseño

hasta su ejecución en un sistema embebido no es un proceso trivial, por lo que resulta

conveniente tener a priori una visión general de los pasos a seguir.

Por ello, se va a seguir un procedimiento general e independiente de tecnología para

desarrollar este tipo de algoritmos para sistemas embebidos, desde su ideación hasta su

implantación en el dispositivo final. Como dispositivo final podemos entender cualquier

tipo de dispositivo integrado capaz de almacenar y/o ejecutar una determinada


18

aplicación dentro de un sistema embebido en tiempo real. Las características más

importantes de este procedimiento son, que por una parte se trata de un procedimiento

general no sujeto implícitamente a ningún tipo de plataforma ni tecnología concreta y,

por otra, que este procedimiento es extensible a cualquier tipo de señal y de

procesamiento que se desee realizar dentro de un sistema embebido.

Un algoritmo de procesamiento de señal, en general, es diseñado inicialmente haciendo

uso de una herramienta matemática cuyo entorno de desarrollo integrado (IDE) permite

tanto la programación en un lenguaje de alto nivel de computación matemática, como la

simulación del algoritmo en términos de verificación y test en un PC, permitiendo de

este modo una depuración dinámica del código y acelerando así su implementación.

Una vez implementado el algoritmo de procesamiento, el siguiente paso consistiría en

compilar el código fuente para generar el archivo binario ejecutable, de forma que el

código de la aplicación pueda ser ejecutado en el dispositivo final, que en el caso de

sistemas embebidos se trata generalmente de un DSP.

La unidad central de procesamiento (CPU) del DSP ejecuta directamente código objeto,

el cual contiene instrucciones en lenguaje máquina, por lo que es indispensable generar

dicho código a partir de la compilación del código fuente de la aplicación. Para esta

tarea existen multitud de programas y entornos de desarrollo integrados de aplicaciones

embebidas, normalmente proporcionados por los mismos fabricantes de dispositivos

integrados, que permiten crear el archivo objeto ejecutable correspondiente a partir del

código programado y facilitan además el acceso al hardware, posibilitando incluso

grabar la aplicación en la memoria RAM del DSP. De este modo y como puede

deducirse, el dispositivo seleccionado para el sistema embebido determinará en gran

medida el entorno de desarrollo integrado concreto con el que se trabaja para llevar a

cabo esta tarea.

Sin embargo, por lo general en la elaboración de aplicaciones embebidas, el código

resultante del diseño de la aplicación en el lenguaje de programación propio del

software de desarrollo matemático, no resulta de utilidad. Esto se debe a que el lenguaje

de programación en el que se ha diseñado el algoritmo puede no ser compatible con los

lenguajes de programación aceptados por los compiladores del entorno de desarrollo

integrado con el que generar el archivo ejecutable. El código a partir del cual es posible

generar el código máquina ejecutable por el procesador se trata normalmente de un


19

lenguaje de medio o alto nivel al que vamos a denominar código intermedio, ya que

actúa como puente entre el código en lenguaje de programación en el que se ha

diseñado el algoritmo y el código en lenguaje máquina del procesador en el que se va a

ejecutar. Evidentemente se requiere de una conversión del código desarrollado

originalmente al lenguaje de programación intermedio.

La figura de un lenguaje de programación intermedio, tiene su justificación en la gran

cantidad de herramientas de procesamiento matemático que existen, dado que no sería

factible tener un software específico para generar código máquina a partir de cada una

de ellas. Por ello resulta conveniente tener un punto de confluencia de todas ellas en un

lenguaje que sea empleado por las herramientas de generación de código máquina

ejecutable.

Una vez obtenido el código intermedio de la aplicación, podemos optimizarlo

convenientemente. De esta forma conseguimos un código optimizado e independiente

de plataforma, de modo que puede ser integrado en cualquier sistema embebido.

A partir de él, ya es posible generar el archivo binario ejecutable por medio del entorno

de desarrollo de aplicaciones embebidas. El archivo binario resultante de la compilación

es un archivo entendible por el procesador del DSP y contiene una imagen binaria

directamente ejecutable del programa. Generalmente incluye, no sólo información del

programa en sí, sino además otro tipo de información complementaria que ayuda al

sistema operativo a la ejecución de la aplicación. Por ello, el archivo ejecutable es

específico de la plataforma concreta que lo genera. Si se desea, y una vez obtenido el

archivo ejecutable, es posible generar el archivo binario plano que puede ser grabado en

cualquier tipo de memoria de almacenamiento del sistema, ya sea la memoria RAM

externa tanto síncrona dinámica (SDRAM) como asíncrona (flash). En la Figura 1 se

puede observar el diagrama funcional completo que se ha seguido.

Figura 1: Diagrama funcional del procedimiento de implementación de aplicaciones embebidas.


20

2.2. Procesado digital de señales biológicas

2.2.1. Procesado digital de señales biológicas en sistemas

embebidos

Las señales biológicas pueden ser de varios tipos. Las hay químicas, de tipo calorífico,

eléctricas y mecánicas. Esta variedad da lugar a diferentes técnicas de adquisición de las

señales, es decir, a diferentes tipos de transductores que son necesarios para poder

capturar la señal y transformarla en una señal eléctrica analógica que sirve de entrada al

DSP, donde se realiza una conversión analógico-digital para obtener así la señal digital

que puede ser procesada por la CPU del DSP. El procesamiento, eso sí, será diferente

según la aplicación concreta que se desee. Del mismo modo, cualquier tipo de señal

biomédica necesita de un filtrado analógico en su adquisición y a menudo de

amplificación. La mayoría de aplicaciones requieren además un filtrado digital previo al

procesado para la reducción de ruido, al tratarse de señales débiles con un importante

nivel de ruido e interferencias [18]. En la Figura 2 se muestra un modelo simplificado

de un sistema de procesado de señales biológicas.

Figura 2: Sistema básico sensor-DSP.

Las prestaciones de los dispositivos sensores y DSPs actuales facilitan el procesado

distribuido en sistemas embebidos. Este tipo de procesamiento proporciona robustez y

flexibilidad al sistema [20]. Por una parte, reduce la probabilidad de un fallo general y

por otra permite diseñar y desarrollar de forma modular las distintas unidades

funcionales que componen el sistema. De este modo, posibilita una implementación

gradual, dando lugar a la integración de nuevas aplicaciones a lo largo del tiempo. Así,

es posible poner en marcha unos módulos concretos con el objetivo de obtener una

funcionalidad mínima para agregar nuevas aplicaciones posteriormente.

DSP

A/D procesador

sensor

señal biológica

señal eléctrica

señal digital


21

Un ejemplo de aplicación muy común de sistemas de arquitectura distribuida es una red

de sensores para la captura y procesamiento de datos [21]. El uso de múltiples sensores

inteligentes de diferentes tipos para el procesamiento de un conjunto de señales

biológicas heterogéneas posibilita la generación de un conocimiento que permite

desarrollar sistemas de monitorización personalizada.

2.2.2. Filtrado previo de la señal

Las señales biomédicas suelen ser ruidosas por lo que el filtrado es una parte importante

del procesado de la señal para mejorar la relación señal a ruido. Por otra parte, en

ocasiones es necesario separar diferentes componentes de una señal para realizar

procesamientos distintos con cada una, en cuyo caso el filtrado también es una parte

importante dentro del procesamiento de la señal.

Podemos diferenciar dos tipos de filtros, los de respuesta finita (FIR) y lo de respuesta

infinita (IIR). Los filtros FIR presentan fase lineal y son siempre estables aunque son

poco eficientes computacionalmente tanto en ocupación en memoria como en tiempo de

ejecución. Por otro lado los filtros IIR son filtros lineales que consiguen cumplir

fácilmente con las condiciones de diseño en cuanto a frecuencias corte y bandas de

transición con un orden bajo. Sin embargo no tienen fase lineal, lo cual puede ser un

inconveniente según la aplicación de la que se trate. Son IIR los filtros Butterworth,

Tchebyscheb o elípticos. De ellos, son los elípticos los que consiguen una transición

más estrecha para un mismo orden en comparación con los otros dos, si bien presentan

rizado tanto en la banda de paso como en la de rechazo.

En algunas ocasiones no es posible eliminar ciertas componentes del ruido por medio de

filtros lineales sin eliminar parte de la señal de interés. En estas circunstancias y cuando

lo que se desea principalmente es eliminar picos de ruidos, es posible emplear filtros

medianos [25]. Los filtros medianos son filtros no lineales que permiten ponderar

ciertos valores de la secuencia de datos en función de los valores de las muestras

próximas.


22

2.2.3. Estimación del espectro

Con el procesamiento de una señal biológica lo que se pretende es extraer la

información útil de la señal. Según el tipo de señal puede resultar interesante obtener la

información contenida en el dominio de la frecuencia, en el dominio temporal o en

ambos a la vez. Según esto se requerirá un método de análisis u otro.

El análisis del contenido espectral resulta de interés en el procesado de la mayoría de

señales biológicas [26]. Si este análisis se realiza además en un sistema en tiempo real,

el cálculo tendrá que ser rápido y eficiente. La respuesta en frecuencia se calcula

generalmente mediante DFT (Discrete Fourier Transform); sin embargo, en la práctica

se utiliza un método computacionalmente más rápido y eficiente de calcularla. Este

método es la FFT (Fast Fourier Transform). Matemáticamente, la DFT y la FFT son

equivalentes; sin embargo, en el cálculo de una DFT de N puntos se requiere un total de N� operaciones, mientras que la FFT necesitan N. log� N operaciones para completarlo

[19]. De esta forma se consigue reducir el número de operaciones y el tiempo de

cálculo, lo cual resulta relevante en los sistemas embebidos.

La mayoría de señales biomédicas no son estacionarias y en algunas ocasiones la

información temporal de la señal no se puede obviar, sino que aporta una serie de

información adicional importante. En este caso pueden emplearse los métodos tiempo-

frecuencia o los métodos tiempo-escala (también conocido como análisis Wavelet), los

cuales asumen que la señal no es estacionaria en el tiempo y permiten conocer la

distribución espectral así como el instante de tiempo en el que se da dicha distribución.

Un ejemplo de aplicación de estas técnicas son las imágenes médicas [26].

En la mayor parte de las señales biológicas resulta fundamental el análisis frecuencial

para extraer la información útil de las mismas. Es el caso, por ejemplo, de señales como

el ritmo cardíaco, los sonidos del corazón y los estomacales e intestinales, el

movimiento de ojos y otras respuestas motoras [26], así como las señales recogidas por

medio de pruebas como los electromiogramas (EMG), electroencefalogramas (EEG) y

electrocardiogramas (ECG).

Los métodos modernos de estimación espectral pueden clasificarse en paramétricos y no

paramétricos. A continuación vamos a ver estas técnicas de forma más amplia.


23

Los métodos no paramétricos calculan la densidad espectral de potencia a partir de la

propia señal estimando la secuencia de autocorrelación a partir de los datos disponibles

y calculando su transformada en el dominio de la frecuencia. Estos métodos son

computacionalmente eficientes, no obstante el resultado es muy dependiente de la

fidelidad de la estimación de la autocorrelación, por lo que la resolución en frecuencia

va a estar limitada por la longitud de los datos de los que se disponga, entre otros

factores.

Los métodos paramétricos permiten construir un modelo, o proceso lineal, del sistema

que generó la señal asumiendo ruido blanco como entrada y estimando una serie de

parámetros a partir de los datos disponibles. La salida del modelo se va comparando con

la señal de entrada, modificando los parámetros del modelo hasta que ambos coincidan.

Cuando esto ocurra, la característica espectral del modelo será la estimación espectral

de la señal de entrada [26]. Esto se debe a que la entrada del modelo es ruido blanco que

es espectralmente plano, por lo que el espectro a la salida es directamente la magnitud

de la función de transferencia del modelo. En la Figura 3 se detalla gráficamente cómo

se realiza la estimación espectral en los modelos paramétricos.

Figura 3: Algoritmo de funcionamiento de los modelos paramétricos. Tomado de [26].

De este modo, podemos decir que los procesos lineales permiten modelar una secuencia

de datos como la salida de un filtro lineal ante una señal de entrada aleatoria. Así, para

el análisis del espectro mediante un modelado paramétrico de la señal, se busca el tipo

de modelo más adecuado de entre los existentes según el tipo de datos de la aplicación

que se esté tratando, estimando también el orden óptimo de dicho modelo.

Ajuste deparámetros

ModeloLineal

Comparación

Cálculo delespectro

Ruidoblanco

Señal deentrada

Espectroestimado

Salida delmodelo


24

En la práctica del procesado digital de señales se emplean sobretodo los modelos

lineales debido a que permiten obtener una mejor estimación espectral en comparación

con los otros métodos, especialmente con secuencias de datos cortas.

Modelo paramétrico

En el modelado lineal de procesos aleatorios existen 3 tipos básicos de estructuras que

atienden a una función H(z) racional. Se trata de los modelos autorregresivo (AR) o

todo-polos, de promedio móvil (MA) o todo-ceros y autorregresivo y de promedio móvil

(ARMA). En la Figura 4, donde �[ ] es ruido blanco, pueden verse estos tipos.

Figura 4: Tipos de modelos lineales. (a) Modelo AR. (b) Modelo MA. (c) Modelo ARMA.

De ellos, el modelo AR es el más empleado debido a que su diseño es relativamente

sencillo en comparación con los otros dos modelos, además de que puede encontrarse

disponible gran cantidad de teoría para su análisis [27]. Asimismo, el modelo AR

consigue una buena estimación del espectro para secuencias finitas y es adecuado para

representar picos abruptos de frecuencia, como es el caso, por ejemplo, de las señales de

acelerometría.

Podemos encontrar varios métodos para la estimación de los parámetros del modelo

autorregresivo [27]. Todos ellos calculan los mismos parámetros de forma diferente.

Por nombrar algunos de ellos podemos citar el método de la covarianza, el método de la

autocorrelación o el método de Burg.

w[n] x[n]

w[n] x[n]

w[n] x[n]

(a)

(b)

(c)


25

Orden óptimo del modelo paramétrico

Además de elegir el tipo de método, es igualmente importante seleccionar un orden

apropiado para el modelo paramétrico autorregresivo. El orden nos da una idea de la

exactitud con la que se estima el modelo por lo que se busca un valor del orden que

represente el proceso correctamente a la vez que minimice la complejidad del modelo.

Al tomar un orden demasiado bajo se corre el riesgo de suavizar el espectro, del mismo

modo que un orden excesivamente alto también puede tener efectos negativos al

suponer la posible introducción de picos en el espectro.

Si los datos pueden ser efectivamente descritos por un modelo AR de orden finito, la

varianza del error de predicción teórica se hace constante una vez que se alcanza el

orden del modelo [27]. Aunque existen diferentes criterios para determinar el orden

óptimo del modelo paramétrico, todos ellos buscan el que minimice el error de

predicción del modelo a través de funciones de coste. Si este orden es muy elevado

(supera el máximo N/2) se toma el valor en el que el valor criterio empieza a decrecer

lentamente [27].

Es posible acotar el rango de órdenes adecuados para el modelo según las características

de la señal de entrada. Según Shiavi [28], si el número de muestras N es bajo el rango

de selección del orden sería (N/3, N/2).

Aunque hay otros criterios, para seleccionar el orden óptimo del modelo se han elegido

tanto métodos que vienen siendo tradicionales, como el Criterio de Información Teórica

de Akaike (AIC) o el criterio de Mínima Longitud de Descripción de Rissanen (MDL),

como métodos más recientes como es el Criterio de Información Combinada (CIC).

Este criterio fue desarrollado por Boersen [29] y entre sus principales características

destaca su robustez para señales con un número finito de muestras además de que, junto

con el método Burg de estimación, supone una combinación muy fiable en la práctica

en el modelado autorregresivo [31].

A continuación se detallan los criterios para la selección del orden del modelo AR:

AIC ��(�) = � ln �� + 2�

MDL ��(�) = � ln �� + � ln �


26

CIC ��(�) = � � !"(#)$ + %&' () 1 + +(,,∙)1 + +(,,∙)�

/01 − 1 , 3 5 +(,,∙)�/01 6

Donde,

N: número de muestras

P: orden

σ89� : error de predicción

RES(p) ≈ v(i, Burg) v(i, Burg) = 1 (N + 1 − i)D

2.2.4. Procesado digital de las señales para la detección de

caídas

En la sección anterior, se han expuesto algunas de las técnicas empleadas en el

procesamiento de señales biológicas. En este apartado se detalla el tipo de

procesamiento llevado a cabo en el caso concreto de las señales de acelerometría.

El algoritmo de detección de caídas trata este tipo de señales de forma que permite

extraer la información necesaria para determinar si el evento recogido en ellas se

corresponde o no con una caída. Ha sido diseñado por los investigadores del Grupo de

Ingeniería Biomédica y está implementado en el portable de monitorización del

movimiento humano diseñado por este mismo grupo [16].

Se trata de un sistema de procesado distribuido formado básicamente por un sensor

acelerómetro inteligente (IAU) y un servidor personal (PSE) [16]. El primero lleva a

cabo un procesado previo mientras que el segundo se encarga del procesado definitivo

[12],[17]. La IAU se encarga de recoger los datos captados por el sensor acelerómetro

triaxial. El dispositivo realiza además un procesado temporal preliminar para determinar

si el evento recogido se trata de un impacto. En caso de que así sea, las muestras son

almacenadas y enviadas al PSE para un procesamiento más exhaustivo. El PSE analiza

en profundidad los datos procedentes de la IAU mediante el algoritmo de detección de

caídas, el cual lleva a cabo tanto un análisis temporal como espectral de la señal, y


27

determina si el impacto detectado por la IAU se trata o no de una caída. En caso de que

así sea, envía la correspondiente notificación a la unidad de acceso remoto (RAU) que

es el dispositivo encargado de remitir la información a los servicios de teleasistencia.

La arquitectura del sistema de monitorización puede observarse en la Figura 5.

Figura 5: Arquitectura del sistema de monitorización diseñado por el GIB [16].

De este modo, el algoritmo, ejecutado desde el PSE, recibe la información de un evento

en forma de tres señales de acelerometría (una por cada eje de aceleración) procedentes

de la IAU; las procesa y, por último, realiza la clasificación del evento en función del

resultado obtenido tras el procesamiento.

Estas señales presentan unas características particulares por lo que, de entre las técnicas

presentadas anteriormente en este capítulo, se tomarán aquellas que resulten más

convenientes para esta aplicación concreta. En la Figura 6, pueden verse ejemplos de

este tipo de señal.


28

Figura 6: Ejemplo de señal de acelerometría a la salida del acelerómetro triaxial. Aceleración (eje y) frente a

muestras en el tiempo (eje x).

El procesado consta en primer lugar de un enventanado temporal de la señal. De este

modo, el algoritmo internamente procesa un menor número de muestras con los

beneficios computacionales que ello conlleva y por otra parte, realiza un análisis más

exhaustivo de la señal.

Las señales de acelerometría son señales muy ruidosas por lo que resulta necesario un

filtrado previo que reduzca los picos de ruido y mejore la relación Señal-Ruido de la

señal recibida. Para ello se hace uso de un filtro mediano de media 3 [25].

Dado que el acelerómetro mide la suma de todas las aceleraciones presentes en cada eje

de aceleración, como la componente de aceleración debida a la gravedad (componente

estática) y la componente debida al movimiento del cuerpo (componente dinámica)

entre otras [25], se realiza un segundo filtrado con tal de separar la componente de

aceleración gravitacional y la componente debida al movimiento del cuerpo. Para ello se

implementa un filtro elíptico. Estos filtros son lineales y consiguen implementar un

filtro de menor orden para unas especificaciones dadas o, visto desde otro punto de

vista, consiguen una transición más estrecha para un mismo orden en comparación con

otro tipo de filtros lineales. Por otra parte, los filtros elípticos no tienen fase lineal pero

esto no supone un inconveniente ya que en el procesado de las señales de acelerometría

la fase no aporta información útil.

La componente de aceleración gravitacional aporta información acerca de la orientación

del dispositivo [25] por lo que el análisis temporal de la misma puede ayudar a


29

determinar la postura del sujeto que está siendo monitorizado. Para ello se calcula el

ángulo formado por la aceleración de la gravedad con la correspondiente aceleración

vertical del sensor acelerómetro [25].

Por último el procesado espectral de la componente dinámica de la aceleración ofrece

información adicional sobre el evento producido para confirmar si el posible impacto

previamente detectado por el sensor acelerométrico [12],[16] es una caída.

Otra característica importante de este tipo de señales que conviene tener en cuenta en su

análisis frecuencial, es que presentan picos abruptos como se puede apreciar en la señal

representada en la Figura 6. En la estimación espectral del algoritmo se emplean

modelos lineales. En concreto se ha tomado el modelo AR debido a tres motivos

fundamentales:

• su sencillez con respecto de otros modelos,

• realiza una buena estimación del espectro para secuencias finitas,

• es adecuado para representar picos abruptos de frecuencia, lo cual es muy

importante al tratarse de señales de acelerometría.

En cuanto a la estimación de los parámetros del modelo AR, podemos encontrar varios

métodos expuesto en el apartado de Materiales y Métodos. Sin embargo, se ha optado

por utilizar el método de Burg, que estima los parámetros del modelo directamente de

los datos disponibles sin necesidad de realizar cálculos intermedios [27].

2.3. Generación y optimización de código para sistemas

embebidos

Los entornos de desarrollo de procesado matemático son muy útiles para el diseño de

algoritmos ya que permite la implementación y prueba de código de forma

relativamente sencilla y rápida. Las características de los lenguajes de alto nivel propios

de estos entornos de programación, además de su flexibilidad o la simplicidad y

claridad de su interfaz, facilitan a los diseñadores el desarrollo de los algoritmos de

procesamiento de señales, que se desearán implementar posteriormente en sistemas


30

embebidos. Un ejemplo muy representativo es Matlab, de Mathworks, que es una de las

herramientas de este tipo más usadas en el mundo.

Los DSPs ejecutan código en lenguaje máquina, que es el conjunto de códigos que

contienen operaciones básicas directamente compilables o interpretables por la unidad

central de procesamiento de un circuito integrado programable [30] como pueden ser no

sólo los DSPs, sino también los microprocesadores, microcontroladores, etc. El lenguaje

máquina se genera mediante software específico a partir de un código fuente en

lenguaje de programación de medio o alto nivel, el cual puede no coincidir con el

lenguaje de programación de la herramienta de computación matemática en el que se

diseña inicialmente la aplicación.

La optimización de aplicaciones, resulta fundamental en los sistemas embebidos. La

ocupación en memoria y el tiempo de ejecución del programa son los indicadores más

empleados en la medida del rendimiento de un sistema de tiempo real y aunque es

deseable que ambos sean mínimos especialmente en las aplicaciones biomédicas de

monitorización, es complicado o en ocasiones imposible optimizar más de un indicador

a la vez y generalmente la mejora de uno va en detrimento del otro [24]. Por ello, en

cada aplicación concreta se hará un estudio de los requisitos para determinar cuál de

estos aspectos es más crítico en el sistema, bien para intentar mejorar uno de ellos o

bien para buscar un equilibrio entre ellos en la fase de optimización si por el contrario

resulta más beneficioso.

En este apartado se van a describir todos aquellos entornos de programación que nos

sirven como herramienta para alcanzar uno de los objetivos concretos del proyecto

como es la implementación de algoritmos de procesado digital en el DSP de un sistema

embebido a partir de su diseño experimental, cumpliendo con las condiciones de diseño

del sistema.

2.3.1. Embedded Matlab

Matlab es muy útil para el diseño de algoritmos ya que permite la implementación y

simulación de la aplicación de un modo más bien sencillo, ágil y dinámico. Ofrece a los

diseñadores de software un entorno muy atractivo en el que desarrollar sus aplicaciones

por las características particulares del lenguaje Matlab. Sin embargo, por lo general, no


31

es posible generar aplicaciones ejecutables por dispositivos integrados a partir de él. Por

este motivo es necesario convertir el código diseñado a un determinado lenguaje de

programación a partir del cual sea posible generar el código en lenguaje máquina

ejecutable por el DSP.

En un primer momento puede pensarse en la reprogramación manual del código inicial

como única solución. Este procedimiento representa una opción real si el tamaño del

código a implementar es abordable, pero puede suponer un problema si no lo es al ser

necesario invertir más recursos o, lo que es más importante, más tiempo para lograrlo.

Otra desventaja de este procedimiento se halla en la necesidad de repetir de nuevo la

verificación que conlleva implícitamente la tarea de implementación de código, como si

de un nuevo algoritmo se tratara. Así pues, puede resultar muy interesante, además de

provechoso, la conversión automática de código Matlab a lenguaje intermedio. Uno de

los lenguajes de programación más utilizados que sirven de puente para la generación

de código máquina es el lenguaje C, por lo que Matlab dispone de nuevas herramientas

que abordan esta cuestión y que pueden facilitar la conversión de Matlab a lenguaje C

reduciendo el coste de desarrollo y verificación del algoritmo final. Estas herramientas

pueden convertir una parte del lenguaje Matlab, llamado Embedded Matlab, a código C

embebido.

Embedded Matlab es el subconjunto dentro del lenguaje de programación Matlab que

soporta la generación de código eficiente para el prototipado y desarrollo de sistemas

embebidos. Está formado por más de 270 operadores y funciones tradicionales de

Matlab además de alrededor de 90 funciones para el desarrollo de software en punto fijo

[32].

Cabe destacar algunas de las características de Matlab que soporta Embedded Matlab

como arrays de más de una dimensión, operaciones con matrices, números complejos,

diferentes tipos de variables y clases numéricas, aritmética de punto fijo, estructuras de

control de flujo (if, switch, while, for), subfunciones, variables persistentes, estructuras,

caracteres o llamadas a funciones de Matlab entre otras características [33]. Puede

emplearse en diversas tareas como la generación de código C desde código Matlab,

generación de funciones C-MEX (C Matlab Executable) desde código Matlab para la

verificación desde Matlab del código C generado, generación de código HDL

(Hardware Description Language) desde código Matlab, integración de código Matlab


32

en Simulink o integrar código C en Matlab, entre otros. De entre estas características

resulta de especial interés la capacidad de generación de código C a partir de código

Matlab, además de poder verificar el código C generado dentro del entorno Matlab.

Para ello es necesario contar con Real-Time Workshop (RTW) que se trata del back-end

o motor específico para la generación de código C embebido a partir de funciones de

Embedded Matlab en Simulink, Stateflow o en código Matlab plano por medio de su

característica Real-Time Workshop Embedded Coder. Así pues, Real-time Workshop es

la herramienta que genera y ejecuta código C independiente para desarrollo y

verificación de algoritmos modelados en Simulink o en código Embedded Matlab, de

modo que permite obtener código eficiente para aplicaciones en tiempo real al mismo

tiempo que permite realizar todo el proceso, desde el diseño del algoritmo hasta la

consecución del código C, sin salir del entorno Matlab.

Limitaciones de Embedded Matlab

No todos los elementos de Matlab son susceptibles de convertirse a C, solamente el

subconjunto Embedded Matlab, que soporta parte de los operadores y de las funciones

de Matlab pero no todos. Aquellos elementos presentes en el código que no estén

incluidos en el subconjunto generan errores en la compilación, los cuales son

convenientemente señalados en un informe en formato html. En el desarrollo de un

algoritmo en Matlab, normalmente no se presta atención a estas limitaciones pero es

interesante conocerlas ya que, si se tienen en cuenta desde un principio, es posible evitar

el trabajo de reprogramación que suponen los errores que se ponen de relieve en la

compilación.

Embedded Matlab no soporta [33]: Cell arrays (son matrices cuyas celdas pueden

contener datos de distinto tipo), la dualidad comando/función, variables dinámicas,

variables globales, funciones anidadas, objetos, “sparse matrices” y las declaraciones

“try” y “catch”.

Conviene tener en cuenta algunas de las diferencias entre el lenguaje Matlab y el

lenguaje C de cara a una posterior conversión de uno a otro, de esta forma es posible

salvar algunas de las limitaciones de Embedded Matlab.


33

En una primera toma de contacto se evidencia que Matlab no necesita declarar las

variables antes de ser utilizadas; en cambio en lenguaje C es necesario declarar las

variables previamente. En la declaración se especifica, además del nombre de la

variable, el tipo y, en caso de tratarse de arrays, la longitud de los mismos. Además,

Matlab utiliza por defecto variables de precisión doble de 64 bits (double). Si no se

especifica el tipo de cada variable en la implementación en Matlab, todas pasarán a ser

del mismo tipo que eran originalmente, es decir de tipo “double” lo que de ningún modo

resulta eficiente en el código C resultante. Otra diferencia importante reside en la forma

de manejar los arrays. En lenguaje C han de tratarse elemento a elemento, tanto en la

asignación como en la operación mediante bucles for. En Matlab se simplifica bastante,

ya que la asignación puede realizarse como si de una variable entera se tratase mediante

el operador “=”, del mismo modo que se puede operar elemento a elemento añadiendo

el operador “.” a la operación que se quiere realizar. También existen diferencias

importantes entre ambos lenguajes en lo que a archivos de cabecera, definición de

funciones y paso de parámetros se refiere.

En cuanto a la utilización de la memoria se encuentran diferencias sustanciales. Matlab

asigna la memoria dinámicamente por lo que el tamaño de las variables puede cambiar

en tiempo de ejecución. Sin embargo, en sistemas embebidos es preferible la asignación

estática de la memoria, de modo que las variables tienen una longitud fija definida en su

declaración. Es por ello que, en lenguaje C, los arrays se suelen sobredimensionar pues

una vez definidos no pueden crecer.

Algo que no se tiene en cuenta en el diseño de algoritmos en Matlab y sí en el diseño

de aplicaciones embebidas es la importancia de analizar el algoritmo para asegurarse de

que opera de forma eficiente, dentro de la ocupación en memoria requerida y de los

recursos de los que se dispone con la finalidad de reducir la complejidad computacional

y el total de memoria ocupada. En función de los recursos requeridos y de los

disponibles puede ser necesario que el algoritmo sea especificado con tipos de datos de

punto fijo para su implementación embebida [34].


34

Funciones C-MEX

Una de las características de Embedded Matlab es que permite verificar el código C

generado dentro del entorno Matlab, es decir, es posible compilar código C en funciones

que pueden ser llamadas desde Matlab. Este tipo de funciones son las funciones MEX

que permiten aprovechar el alto rendimiento de C, C++ o Fortran mientras se trabaja en

Matlab.

En definitiva, las funciones C-MEX no son más que funciones en código C que tienen

la particularidad de ser ejecutables desde Matlab dando la posibilidad de trabajar con

funciones en código Matlab y funciones en código C simultáneamente. De este modo,

se permite una conversión y verificación escalada del código al poder verificar cada

parte del código convertido dentro del algoritmo completo aunque éste no se haya

convertido en su totalidad.

Pasos para la conversión de código de Embedded Matlab a C

Antes de generar el código C fuente, es recomendable comprobar el algoritmo mediante

la generación de funciones C-MEX. El comando utilizado es el mismo tanto en la

generación de funciones C-MEX como en la generación de funciones C, se diferencian

por las opciones que especificamos según el caso.

Por todo esto, a continuación se va a comentar cómo generar una función C-MEX para

la comprobación del algoritmo. Después, se explica detalladamente cómo generar una

función en código C embebible y compilarla en una librería.

• Comprobación del algoritmo: generación de funciones C-MEX:

En este primer paso, no se genera código C fuente sino que se crea una función C-MEX,

es decir, una función en código C ejecutable desde Matlab pero sin llegar a ser

funciones C ejecutables por sí mismas. De este modo se puede verificar desde Matlab

que al pasar a código C el algoritmo sigue comportándose del mismo modo, esto es, que

el algoritmo no ha sido alterado a causa de la conversión y que la función C-MEX sigue

realizando la misma tarea que la función original en Matlab.

Se utiliza el pragma %#eml en la función que queremos comprobar.


35

Después, desde la línea de comandos se introduce:

emlc -o nombrefuncionx -report nombrefuncion.m -eg{z}

Donde,

-o: indica que se genere función C-MEX.

-report: indica que se genere un informe de compilación.

-eg{z}: la entrada de la función se especifica mediante un ejemplo en la variable z,

que ha de ser declarada previamente.

Como se ha explicado, la entrada de la función se especifica a través de una variable

que sirve como ejemplo del tipo de parámetro que tendrá la función como entrada. Hay

que tener en cuenta que la función C-MEX sólo admitirá como válidas aquellas entradas

que sean del mismo tipo, longitud, tamaño, etc. que la variable que se utilizó como

ejemplo cuando fue generada.

La nueva función generada puede ser llamada en el entorno Matlab del mismo modo

que una función Matlab ordinaria. Así, simplemente sustituyendo la función original por

su correspondiente función C-MEX se podrá comprobar si el código generado realiza la

misma función que el código original Matlab.

• Generación de código C:

Una vez verificada la función, se genera el código fuente, obteniendo la función C y los

demás archivos necesarios para su compilación. Desde la línea de comandos se

introduce:

emlc -c -T RTW -report nombrefuncion.m -eg{z}

Donde,

-c: indica que se genere código C.

-T RTW: genera código C embebible y lo compila en una librería.

-report: indica que se genere un informe de compilación.

-eg{z}: la entrada de la función se especifica mediante un ejemplo en la variable z,

que ha de ser declarada previamente.


36

Profundizando en la forma en que Embedded Matlab implementa el código C

automáticamente, cabe destacar algunos puntos importantes. Embedded Matlab vuelve

constantes todas aquellas variables que dependen a su vez de otras variables que

considera constantes. Por ello puede ser necesario editar el código C generado en

algunos casos. Por otra parte, en la conversión automática que lleva a cabo RTW, define

los tipos de datos en todos los casos. Por ejemplo, real_T hace referencia al tipo double

así como real32_T equivale a single de Matlab. En la Tabla 1 se muestran las

equivalencias de forma más completa.

Matlab C RTW

double double real_T

single float real32_T

int32 long long int int32_T

int16 long int int16_T

int8 short int int8_T

uint32 unsigned long long int uint32_T

uint16 unsigned long int uint16_T

uint8 unsigned short int uint8_T

int int int_T

uint unsigned int uint_T

boolean - boolean_T

char char char_T

Tabla 1: Equivalencias de los tipos de variables básicas en Matlab, lenguaje C y Real-Time Workshop.

2.3.2. Compilador de C de propósito general

Uno de los lenguajes de programación más utilizados y especialmente en el desarrollo

de sistemas embebidos, es el lenguaje C. Este lenguaje es muy utilizado debido su

extendido uso en entornos académicos y profesionales. Su portabilidad, el grado de

optimización en cuanto a eficiencia, ocupación en memoria y velocidad de

procesamiento que es posible alcanzar en aplicaciones embebidas son características

que dan lugar precisamente a que pueda ser compilado por un gran número de entornos

de desarrollo integrados.


37

Bloodshed Dev-C++ es un entorno de desarrollo integrado para lenguaje C/C++ de libre

acceso [35] y costa de un editor de texto y un compilador de código fuente. El

compilador traduce el programa fuente completo a un programa de bajo nivel que puede

ser ejecutado directamente por un procesador [30].

Se considera interesante en el desarrollo de aplicaciones ya que permite llevar a cabo

una verificación de un programa en lenguaje C de forma independiente en un entorno

totalmente separado de otras herramientas que pueden ser empleadas en el proceso de

desarrollo de software embebido, como pueden ser Matlab o Code Composer Studio.

Con ello, se persigue conseguir que el código escrito sea independiente de plataforma,

de modo que al tratarse de código fuente plano, pueda ser compilado por cualquier

herramienta de desarrollo de software e implementado en cualquier entorno ya sea un

DSP, un microcontrolador, etc.

2.3.3. Code Composer Studio

Code Composer Studio (CCS) es un entorno de desarrollo integrado para procesadores

digitales de señal, microcontroladores y procesadores de aplicación de Texas

Instruments (TI) [36]. Se trata de un software formado por una serie de procedimientos

desarrollados para el hardware concreto de los DSPs de Texas Instruments. Implementa

las capas de abstracción de hardware (HAL), las cuales funcionan como interfaz entre el

hardware y el software de aplicación de un sistema, de modo que facilita la tarea de

acceso al hardware por parte del usuario a través de un interfaz sumamente intuitivo,

tarea que, de otro modo, podría resultar dificultosa.

Este software está formado por un conjunto de elementos que permiten desarrollar y

depurar aplicaciones embebidas para dispositivos de Texas Instruments como distintos

compiladores, editor de código fuente o simuladores, dando la posibilidad de

seleccionar un target concreto dentro de la familia de DSPs de Texas Instruments.

Proporciona al usuario un único interfaz con el que abordar cada uno de los pasos a

seguir en el proceso de desarrollo de aplicaciones embebidas y permite así reducir el

tiempo invertido en el desarrollo e integración de software para DSPs.


38

CCS genera código ejecutable por el DSP a partir de código en lenguaje C en tres pasos

básicos: la compilación del código fuente de la aplicación, la construcción del archivo

ejecutable y la carga en la memoria RAM del target. A bajo nivel, este proceso implica

tres herramientas de generación de código fundamentales [37]: el compilador (compiler)

C/C++, el ensamblador (assembler) y el enlazador (linker). En primer lugar, CCS

genera código en lenguaje ensamblador a partir de código C, mediante el módulo

compilador de C/C++. A continuación, convierte el código ensamblador fuente en un

conjunto de archivos objeto de lenguaje máquina que el procesador del DSP puede

ejecutar, mediante el módulo llamado ensamblador. CCS también enlaza las secciones

separadas del código objeto que forman la aplicación y las combina en uno sólo para

producir un único archivo ejecutable con el módulo enlazador. En la Figura 7 se observa

este proceso de forma esquemática.

Figura 7: Proceso de generación de código ejecutable a partir de código fuente en lenguaje C.

Algunas familias de DSPs permiten el arranque de aplicaciones desde una memoria

externa. En la versión 3.3 y anteriores, CCS posibilita el manejo de scripts de

configuración del modo de arranque mediante el denominado CCS Scripting, el cual

está configurado para usar el intérprete de Perl ActivePerl (de la compañía ActiveState)

en su versión para el sistema operativo Windows. ActivePerl es un software que da

soporte a la ejecución de programas en lenguaje Perl por lo que es necesaria su

instalación junto con la de CCS. Así pues, para configurar el modo de arranque

ActivePerl proporciona dos herramientas software basadas en scripts que se ejecutan en

modo comando [38]. Por una parte, la aplicación genBootCfg.pl genera los ficheros de

configuración del arranque para cualquier modo. Por otra parte, necesariamente para la

conformación del arranque desde memoria externa, el software genAIS.pl genera el

programa binario de arranque a partir del fichero ejecutable enlazado .out creado en la

compilación del código fuente, y del fichero de configuración .cfg generado por la

aplicación genBootcfg.pl.

COMPILADORcódigo

ensamblador(.s)

ENSAMBLADORcódigoobjeto(.o)

códigofuente(.c)

ENLAZADORcódigo

ejecutable(.out)


39

En la generación de un archivo ejecutable podemos encontrar archivos de diferente tipo

de los cuales algunos son obligatorios, mientras que otros dependen de la aplicación

concreta:

• .c: código fuente de la aplicación.

• .h: archivos de cabecera.

• .lib: facilitados por TI, estos archivos proporcionan soporte para el dispositivo

DSP correspondiente.

• .asm: contiene instrucciones en lenguaje ensamblador.

• .cmd: contiene la configuración de las secciones de memoria.

Para compilar un programa sencillo, son necesarios los archivos de código fuente (.c) y

los archivos de cabecera (.h). En función de la aplicación concreta puede añadirse las

librerías correspondientes (.lib) y/o partes del código e instrucciones que ya se

encuentren en lenguaje ensamblador (.asm).

Si se desea compilar un programa más complejo o simplemente utilizar las herramientas

de depuración y análisis en tiempo real que ofrece el entorno CCS, es posible hacer uso

de la herramienta software DSP/BIOS [39]. DSP/BIOS es la parte de CCS para

aplicaciones en tiempo real. Está formado por una serie de elementos entre los que

podemos destacar el módulo de gestión del reloj del sistema (CLK), el gestor de

memoria (MEM), el gestor del registro de eventos (LOG), el gestor de intercambio de

datos en tiempo real (Real Time Data Exchange, RTDX), el gestor de estdísticas (STS)

o el gestor de multitarea (TSK). DSP/BIOS proporciona comunicación entre el host y el

target de forma eficiente (RTDX), así como instrumentación de tiempo real (RTA).

Consta de una interfaz gráfica para facilitar la configuración tanto de RTDX como de

RTA, además de la generación de archivos de configuración (.cmd) que permiten, entre

otros, organizar la memoria, definir tareas, hilos, interrupciones hardware y software

además de establecer sus prioridades.

La instrumentación RTA [40] permite monitorizar y depurar el programa en tiempo real

interfiriendo mínimamente en su tiempo de ejecución y ocupación en memoria. Está

formada por varias herramientas de distinta índole, que pueden ser bien de exposición


40

de mensajes de eventos por pantalla en un registro, bien de presentación de resultados

estadísticos o gráficos entre otros. Veamos estas herramientas con más detenimiento:

• Registro de eventos (Event LOG): En la depuración del código en aplicaciones

en tiempo real no se recomienda el uso de la función de biblioteca de C printf

contenida en la biblioteca RTS para mostrar mensajes por pantalla que nos

ayuden a determinar el correcto funcionamiento del programa. Se debe a que

requiere un número importante de ciclos de CPU para completarse, de forma que

puede alterar significativamente el normal funcionamiento del programa en

tiempo real [19]. En su lugar, es aconsejable la utilización de LOG_printf que

hace uso del registro de eventos. Es una función escrita directamente en lenguaje

ensamblador por lo que es mucho más pequeña y tiene un tiempo de ejecución

mucho menor.

• Estadísticas STS (STS Statistics): Muestra las estadísticas de los objetos creados

por el usuario como tareas, interrupciones hardware o software, etc.

• Host Channel Control: Monitoriza los canales definidos por el programa entre el

host y el target. Permite asociar archivos a cada canal e iniciar la transferencia

de datos.

• Gráfica de ejecución (Execution Graph): Facilita la visualización de la actividad

de los distintos objetos en función del tiempo y la interacción entre ellos.

• Gráfica de carga de la CPU (CPU Load): Muestra la gráfica de carga de la CPU.

• Vista del Kernel (Kernel Object View): Ofrece una perspectiva general de la

configuración y el estado de los objetos ejecutados por el DSP. Proporciona

información útil como cual ha sido el espacio de memoria asignado y cuanto de

ese espacio se ha usado, indicando desbordamiento si existiese en algún caso.

CCS presenta además un modo simulador [41] que permite configurar un procesador

ficticio que también incorpora diversos tipos de DSPs y que puede resultar de gran

utilidad en la comprobación del funcionamiento y depuración de la aplicación como

fase previa a la verificación en el dispositivo real. Las herramientas RTA también se

encuentran disponibles en modo simulador, con la excepción de la gráfica de carga de la

CPU que únicamente puede emplearse en comunicación con un DSP real. No obstante,


41

este modo de operación no es aplicable en escenarios donde se requiera el uso de

elementos específicos del hardware y que implican principalmente manejo de puertos.

Aunque desde el punto de vista de la implementación de código resultaría más eficiente

programar directamente en código ensamblador, el compilador de CCS para

procesadores de la familia C6x puede alcanzar un rendimiento de más del 70%

comparado con el código escrito directamente en lenguaje ensamblador [37]. De este

modo, es posible obtener aplicaciones embebidas óptimas desde el programa

implementado en código C.

2.3.4. Método iterativo para implementación de software

El software de un sistema embebido se diseña específicamente para una plataforma

hardware determinada. Los métodos actuales de desarrollo tienen esto en cuenta y

proponen pautas para el despliegue de software y hardware embebidos en paralelo. Esto

es lo que se conoce como codesarrollo [21] y establece una serie de directrices para

implementar sistemas embebidos de forma coordinada y eficaz.

Tener clara la metodología de diseño que se va a seguir permite ahorrar tiempo a largo

plazo y adquirir un grado de conocimiento acerca del proceso que puede ser de utilidad

en futuros desarrollos. En el desarrollo de software embebido, es posible adoptar el

modelo Harmony Embedded Software (Harmony/ESW) [22] perteneciente a la familia

de procesos Harmony. Este método consiste en desarrollar un software funcional para

después, a partir de él, depurarlo y mejorarlo progresivamente mediante cambios

incrementales, hasta cumplir los requisitos deseados. Es un procedimiento iterativo

[21]-[23] en el que las fases que lo componen se recorren cíclicamente de forma que los

resultados de un ciclo determinan las acciones a llevar a cabo en el siguiente, lo que

permite aprovechar la experiencia recogida para mejorar el diseño en el siguiente ciclo y

optimizarlo rápida y dinámicamente. En la Figura 8 puede verse un esquema funcional

de este modelo iterativo.


42

Figura 8: Método de desarrollo de software embebido Harmony/ESW.

Una vez que la aplicación presenta el funcionamiento deseado y un comportamiento

estable, empieza la mejora de la aplicación en términos de optimización. Las principales

condiciones de diseño de los sistemas embebidos [21] en comparación con los que no lo

son, hacen referencia a aspectos tales como la ocupación en memoria y el tiempo de

ejecución de los algoritmos implementados.

Es posible optimizar en diferentes puntos a lo largo del desarrollo de una aplicación

embebida, pero lo más habitual es hacerlo sobre el código fuente. En este caso, el

programador implementa el código de la forma más óptima según el indicador que

desee mejorar. Cada uno de los cambios realizados se valida dando lugar a una

optimización iterativa, siguiendo el modelo Harmony/ESW como se observa en la

Figura 8. Además, en el código es posible escribir directrices que ofrecen una mayor

información sobre algunas partes del mismo de forma que se puede compilar más

eficientemente [24], pues la compilación del código fuente también lleva implícitamente

una fase de optimización. Es decir, para generar el programa de bajo nivel, el

compilador realiza en primer lugar un análisis del código para después pasar a la etapa

de síntesis, en la que pueden darse las optimizaciones según las opciones del

compilador.


43

2.4. Descripción del prototipo hardware del PSE

El prototipo del PSE está formado por un DSP de punto flotante de última generación

de Texas Instruments de la familia TMS320C6727. Su CPU opera a 300MHz y consta

de una memoria ROM de 384Kb y 256Kb de memoria RAM. Se ha incorporado una

memoria flash de 1Mb para albergar tanto código para el procesado de señal como

datos. Completa el módulo central un controlador que supervisa la actividad de la CPU

y del resto de elementos, con la finalidad de monitorizar el consumo de batería así como

su carga [12].

El módulo de comunicaciones está compuesto por todos aquellos dispositivos

necesarios para llevar a cabo la comunicación del PSE con el resto de elementos del

sistema. La comunicación del PSE con la IAU se establece mediante el estándar Zigbee,

para lo cual se emplea el transceptor CC2430 de Chipcom, fabricado por Texas

Instruments. Para la comunicación entre el PSE y RAU se realiza vía Bluetooth

mediante el transceptor STLC2500C de ST Microelectronics. Por últmo, el PSE se

comunica con el PC tanto mediante el conector JTAG como a través de infrarrojos con

el transceptor HSDL 3021 de Avago Technology.

El interfaz de usuario está formado por elementos tanto visuales como auditivos, de

modo que el usuario reciba información procedente del terminal. De este modo, el

usuario interactúa con el dispositivo a través del display LCD EM6125COG de EM

Microelectronics, el módulo de audio, con altavoz incluido, y el teclado de 4 botones

UB de Nikkai Switches. En la Figura 9 se muestra la arquitectura del PSE.

Figura 9: Diagrama de bloques de la arquitectura hardware del PSE. Tomado de [12].

capítulo 2: métodos y materialesbibing.us.es/proyectos/abreproy/11981/descargar... · lenguaje...

Documents