Estudio de NesC y TinyOS

1
Estudio de NesC y TinyOS

• José Ulloa Suárez

2
Objetivos

• Profundizar en la programación con el lenguaje
  NesC.
• Entender el modelo de abstracción de Hardware que
  presenta TinyOS para facilitar la programación e
  implementación de aplicaciones.
• Descripcción del entorno de desarrollo y
  herramientas existentes.

3
Esquema Presentación

• NesC Avanzado
• Introducción
• Descripción del lenguaje
• Diseño con NesC
• Interfaces
• Implementación
• Ejemplo
• Concurrencia, Carrera de Datos
• Interfaces Parametrizadas
• Optimización
• Abstracción de Hardware
• A que se refieren, y porque son necesarios.
• Niveles de Abstracciones de Hardware
• Herramientas de Trabajo.
• Conclusiones.

4
NesC Introducción

• NesC es un meta-lenguaje de programación basado
  en C, orientado a sistemas embebidos que
  incorporan el manejo de redes inalámbricas.
• NesC fue diseñado para soportar el modelo de
  programación de TinyOS, el que posee una
  arquitectura basada en componentes, un simple
  modelo de concurrencia y operaciones bi-fases.
• Realiza optimizaciones en la compilación del
  programa, detectando posibles carreras de datos
  que pueden ocurrir producto de modificaciones
  concurrentes a un mismo estado, dentro del
  proceso de ejecución de la aplicación.
• En general, simplifica el desarrollo de
  aplicaciones, reduce el tamaño del código, y
  elimina muchas fuentes potenciales de errores.

5
Descripción del Lenguaje
Los archivos de NesC son de tres tipos
interfaces, módulos y de configuración.
6
Identificadores y sus reglas.
7
Interfaces

• Las aplicaciones son construidas a partir de
  componentes, las cuales proveen y usan
  interfaces. Una interfaz es el único punto de
  acceso de una componente.
• Las interfaces son bidireccionales, poseen
  eventos y comandos.
• Operaciones bi-fase quedan claramente definidas
  al definir los comandos/eventos en la misma
  interfaz

8
Implementación de Componentes

• Dos tipos de componentes, módulos y
  configuraciones
• Los módulos proveen el código de la aplicación,
  implementando una o más interfaces.
• Configuraciones son usadas para unir (cablear)
  una componentes a otras componentes, conectando
  las interfaces de una a la otra.
• El cableado de componentes via interfaces permite
  un control del flujo del programa.

9
Ejemplo de una componente
10
Concurrencia y Carreras de Datos

• El código de TinyOS se ejecuta tanto
  asincrónicamente (interrupciones) como
  sincrónicamente (ejecución de tareas).
• Las carreras de datos se presentarán
  principalmente en estas dos situaciones
• Cualquier modificación a un estado compartido
  desde un código asincrónico es una condición
  potencial de carrera de datos.
• Cualquier modificación de un estado compartido
  desde un código sincrónico, que es también
  modificado desde un código asincrónico es una
  condición potencial de carrera de datos.
• La concurrencia en NesC está profundamente
  relacionada con los códigos asincrónicos, ya que
  son las interrupciones las que generan múltiples
  solicitudes de ser atendidas. Para manejarla,
  NesC provee dos herramientas secciones atómicas
  y tareas. En el código mostrado a continuación
  Timer.fired y ADC.dataReady son códigos
  asincrónicos.

11
Concurrencia y carrera de datos

• El evento Timer.fired es señalizado
  periódicamente, así ADC.getData es llamado para
  obtener un nuevo dato. Como busy es accedido por
  un código asincrónico su uso es protegido por una
  declaración de atómica que realiza un
  test-and-set de la variable. Una vez que el
  valor haya sido obtenido, el ADC.dataReady es
  señalizado.
• El envío del mensaje no es una operación de
  tiempo crítico, por lo cual se procede a
  postear una tarea sendData. Postear implica
  que la operación se realizará cuando el
  procesador este desocupado.

12
Interfaces Parametrizadas

• Una interfaz parametrizada permite a una
  componente proveer múltiples instancias de esta
  interfaz la cual se encuentra caracterizada por
  un valor asignado ya sea en tiempo de ejecución o
  en tiempo de compilación.
• Es necesario primero comentar que una componente
  es capaz de proveer múltiples instancias de una
  interfaz y asignarles diferentes nombres.
• En otras palabras , prove 256 diferentes
  instancias de la interfaz Timer.
• Para evitar conflictos de uso de valores es que
  existe la posibilidad de usar la función contante
  unique(), la cual genera en tiempo de compilación
  un identificador único, en este caso se ocupa
  así unique("Timer")

provides interface StdControl as
fooControl interface StdControl as
barControl
provides interface Timeruint8_t id
configuration SingleTimer provides interface
Timer provides interface StdControl impleme
ntation components TimerC Timer
TimerC.Timerunique("Timer") StdControl
TimerC
13
Optimización

• Las optimizaciones reducen eficientemente el uso
  de la memoria de programa, como también la
  sobrecarga en la ejecución de las aplicaciones
• Las dos principales fuentes de reducción de
  códigos son
• Eliminación de códigos muertos, es decir
  recortar todas las definiciones redundantes, o
  códigos que no realizen ninguna función, lo que
  generalmente reduce cerca de un 9 del total.
• In-lining también reduce el código cerca de un
  16. In-lining sólo crea un 1 de mejora en la
  utilización de la CPU. Códigos intensivos en CPU
  no estan dominados por llamados de funciones.

14
Esquema Presentación

• NesC Avanzado
• Introducción
• Descripción del lenguaje
• Diseño con NesC
• Interfaces
• Implementación
• Ejemplo
• Concurrencia, Carrera de Datos
• Interfaces Parametrizadas
• Optimización
• Abstracción de Hardware
• A que se refieren, y porque son necesarios.
• Niveles de Abstracciones de Hardware
• Herramientas de Trabajo.
• Conclusiones.

15
Abstracción de Hardware

• El objetivo principal es poder entender como la
  programación de aplicaciones en TinyOS abstrae el
  control de los distintos módulos de hardware, ya
  sean entradas / salidas, buses de datos y
  mecanismos disponibles para la administración de
  energía.

16
Introducción

• Una de las principales metas en la programación
  de sistemas operativos es lograr portabilidad a
  distintas plataformas. Para poder lograr esto se
  hace necesario tener un esquema que sea capaz de
  abstraerse del hardware, misión para nada fácil.
• Específicamente las redes de sensores imponen una
  gran eficiencia en el uso de recursos (ahorro de
  energía es esencial), por lo que la modularidad
  que se quiere alcanzar a través de este módelo no
  debe comprometer estas variables.

17
Abstracción de Hardware

• Dos requerimientos aparentemente conflictivos.
• Implementación eficiente en el uso de energías
• ? Un bajo de nivel de abstracción.
• Rápido desarrollo de aplicaciones
• ? Alto nivel en abstracciones.
• Cúal es la solución?
• Arquitectura que sea facilmente reconfigurable
• ? Que permita al programador escoger el nivel de
  abstracción de hardware.
• Cómo organizar esta arquitectura?

Application
HA
Hardware Abstraction
HA
HA
Hardware
18
Abstracción de Hardware
19
Tres Capas

• Hardware Presentation Layer (HPL)
• Presentar las capacidades del hardware usando los
  conceptos nativos del sistema operativo.
• Hardware Adaptation Layer (HAL)
• Usa las interfaces provistas por las componentes
  de la HPL para construir las abstracciones que
  serán utilizadas por el programador, y que
  esconden la complejidad natural asociado con el
  uso de recursos de hardware.
• Hardware Interface Layer (HIL)
• Esta última capa se encarga de convertir las
  abstracciones HAL de un hardware específico, en
  interfaces independientes del hardware

20
Estudio de algunos módulos

• Unidad de Procesamiento
• Administración de la Energía
• Clocks y Timers
• Conversor Análogo-Digital
• Bus de Datos

21
MCU

• Abstraer las diferencias entre los variados MCU
  es el primer paso hacia un sistema operativo más
  exportable.
• NesC es un lenguaje de programación con una suite
  de compilación similar (gcc).
• Todas las macros se encuentran definidas en los
  archivos hardware.h de cada plataforma.
• También TinyOS se encarga de negociar con las
  distintas formas de acceder a los registros,
  usando los archivos de cabeceras (.h)
  disponibles en las librerías standard.
• Es importante mencionar que no se pretende
  aplicar el modelo de tres capas a la MCU, ya que
  las características del compilador más los
  archivos hardware.h, son suficientemente
  eficientes.

22
Administración de la Energía.

• Cada microcontrolador tiene un perfil diferente
  de administración de la energía.
• Atmel
• el tiempo que demora en despertar es de unos
  pocos milisegundos, se usa una componente HAL que
  evalúa cuando el próximo evento del timer
  ocurrirá, y sólo coloca al microcontrolador en
  modo sleep si el tiempo es mayor que lo que
  demoraría en despertar.
• MSP430
• demora alrededor de 6 microsegundos, por lo que
  apenas la MCU no esta procesando, se procede a
  cambiar a bajo consumo de energía,
  específicamente al modo sleep.
• Estas ventajas se logran principalmente gracias
  al diseño de hardware que poseen los
  microcontroladores, donde la gran mayoría de los
  módulos se encuentran conectados a la MCU. En la
  medida que se agreguen más dispositivos externos,
  se harán necesarios nuevos mecanismos para el
  manejo de la energía.

23
Clocks y Timers

• El módulo ocupado para las aplicaciones de Atmel
  era TimerM. Este módulo no pudo ser adaptado al
  microcontrolador MSP430, por lo que se diseñaron
  una nueva interfaz que se llamó Alarm, que
  acceden al tiempo actual y permiten setear
  alarmas en el futuro relativo a tiempo atrás.
  Cada interfaz debe describir la resolución de la
  alarma que provee, tal como TMilli, T32khz,
  TMicro .De esta forma cada plataforma exporta un
  número de interfaces, que corresponderán al
  numero máximo de alarmas soportadas por la
  plataforma.

24
Conversor ADC

• Diferencias entre Atmel y MSP430
• Atmel vs MSP430
• no puede modificar el tiempo en que se mantiene
  la muestra (sample-and-hold), sólo posee una
  referencia de voltaje individual para todos los
  canales y no soporta modos de conversión en
  secuencia.
• La clave se encuentra en la capa HAL, la que
  extiende los conceptos incluidos en el módulo
  ADCM desarrollado para Atmel.
• Para clarificar los cuatro modos de conversión
  que el MSP430 presenta, se han separado en las
  interfaces MSP430ADCSingle y MSP430ADC12Multiple
  para conversión simple y múltiple
  respectivamente.

25
Bus de Datos

• La abstracción que se propone, debe ser capas de
  exportar el manejo del reloj de control
  incluyendo los modos sincrónicos y asincrónicos,
  factores que pre-escalan el reloj, generación de
  baud-rate,etc.
• La funcionalidad de la capa HPL presenta dos
  rutas, una para los datos y otra para el control.
• Control Permite configurar la fuente del reloj
  principal, pre-escalar y seleccionar el
  baud-rate. Las interrupciones pueden ser
  habilitadas o deshabilitadas acá. A través de
  esta interfaz los dispositivos pueden ser
  apagados para ahorrar energía.
• Datos Esta interfaz se encarga del recibimiento
  y transmisión de bytes a través de los registros
  de hardware, así como también reportar
  interrupciones cuando se recibe algún dato.

26
Trabajo con TinyOS

• Ambiente de trabajo Cygwin
• Herramientas Gráficas
• Mote-View
• Surge-View
• Serial-Forwarder
• Simulador TOSSIM

27
Conclusiones

• Se ha profundizado en el aprendizaje del lenguaje
  NesC.
• Se ha estudiado el modelo de abstracción de
  Hardware que TinyOS presenta, clave para el
  desarrollo de aplicaciones.
• Se ha estudiado el ambiente de trabajo y algunas
  herramientas disponibles.