Bitcloud es la ltima generacin de software embebido totalmente funcional de Atmel para Zigbee. La pila proporciona una plataforma de desarrollo de firmware seguro y de confianza para aplicaciones wireless que corren en hardware Atmel. Bitcloud ha sido diseado para soportar un extenso ecosistema de aplicaciones de usuario que atienden a diversas necesidades y que permiten un amplio espectro de personalizacin Bitcloud se ha desarrollado para cumplir con las expecificaciones de ZigBee y Zigbee PRO de sensorizacin y control wireless. (pag6)

2 Arquitectura de de la pila BitCloud2.1 Lineas Generales de la Arquitectura BitcloudLa arquitectura interna de BitCloud persigue la separacion de la pila de red en las capas lgicas descritas por la IEE802.15.4 y la especificacin Zigbee. A pesar de que el ncleo de la pila contiene la implementacin propia del protocolo, BitCloud contine capas adicionales que implementan los servicios compartidos ( por ejemplo, la seguridad, el task manager, y el power manager), la capa de abstracin hardware (Hardware Abstraction Layer HAL) y el paquete de soporte a la placa (Board Suppoprt Package BSP). Las API's proporcionadas por estas capas estn fuera del mbito de la funcionalidad del ncleo de la pila. Sin embargo, estas capas adicionales ayudan a reducir significativamente la complejidad y simplifican la integracin. El manual de referencia del API de BitCloud da informacin detallada tanto de todas las API's pblicas como de su uso.

La capa ms alta del ncleo de la pila, APS, proporciona el nivel visible de aplicacin ms alto relacionada con la API de networking . ZDO proporcionada un set totalmente compatible con la API de Zigbee Device Object(ZDO) que permite el manejo principal de la red (iniciarla, resetearla, formarla, unir elementos...). ZDO tambin define el tipo de dispositivo Zigbee y mantiene los comandos de red que implementa la pila (Pag 7) Se incluye tres servicios verticales: el task manager, la seguridad, y el power manager. Estos servicios estn disponibles para el aplicacin de usuario, pero tambin pueden ser utilizados por las capas ms bajas. El Task Manager, que es el scheduler de la pila, gestiona el uso del MCU por los componentes internos de la pila y por la applicacin de usuario. El Task Manager implementa un scheduler cooperativo basado en prioridad especifcamente diseado para el tipo de pila multicapa y las demandas de tiempo crtico de los protocolos de red. Las rutinas del power manager son las responsables del apagado de todos los componentes de la pila y el salvado del estado del sistema cuando ste se echa a dormir y de sus restaurado cuando ste se levanta El HAL incluye una set completo de API's para el uso de los recursos (EEPROM,

sleep, y watchdogs) asi como de los drivers... BSP incluye un set completo de drivers para el manejo de perifricos estandar incluidos en una placa de desarrollo.

2.2 Convenio de NombresPara manejar el alto numero de funciones de API disponibles al usuario, se emplea una conveccion de nombres que simplifique la tarea de manejar y comprender las aplicaciones de usuario. Estas son sus reglas bsicas: 1. El nombre de cada funcin del API lleva el prefijo de la capa en la cual reside. Por ejemplo la funcin ZDO_GetLqiRssi reside en la capa ZDO de la pila 2. Cada prefijo del nombre es seguido por un guion bajo, _, que separa el prefijo del nombre descriptivo de la funcionalidad 3. El nombre descriptivo de la funcin debe contener un prefijo Get o Set, indicando si la funcin devuelve el parmetro solicitado o si sta fija un parmetro de la capa subyacente. 4. El nombre descriptivo de la funcin puede contener uno de los siguientes sufijos: 1. Req o Request se corresponde con una solicitudo ascrona desde la aplicacin de usuario 2. Ind se corresponde con una indicacin asncrona o evento propagado por la pila al espacio de usuario. 3. Los nombres terminados en Conf son callbacks definidas por el usuario para peticiones asincronas que confirman la ejecucin de una peticin. 5. Cada nombre de tipo o estructura termina con un sufijo _t, indicativo de tipo. 6. Los nombres de variables enumeradas y de macros van siempre en mayusculas.

(Pag 8)

2.3 Layout del sistema de ficherosEl layout del sistema de ficheros sigue la arquitectura de la pila, con algunas carpetas extras que constituyen las subcapas aadidas. Entre los componentes distribuidos en forman de binarios, se incluyen los directorios lib e include que contienen los ficheros de cabecera y las librerias. Entre los componentes distribuidos en forma de cdigo fuente se incluyen los subdirectorios obj y src. El fichero Makefile continen el script necesario para construir dichos componentes. Las aplicaciones se proporcioanan siempre como ficheros fuente y ficheros

cabecera, el script Makefile, as como los ficheros de proyecto para los IDEs soportados. La misin pricipal del Makefile es compilar la apllicacin usando los ficheros de cabecera que se encuentran en los respectivos directoriso de compoennetes y linkar el fichero objeto resultante con las librerias. El resusltado de la image binaria es una aplicacin de compilacin cruzada que pude ser grabada y depurada en la plataforma final. Para ms informacin sobre cmo modificar el del entorno de desarrollo y compilacin se debe consultar [4]

Carpeta

Codigo fuente presente? Raiz de la pila No Si Si Si No No Si No No No Si

Descripcin

BitCloud Components APS BSP ConfigServer HAL MAC_PHY NWK PersistDataServ er Security SystemEnviron ment ZDO WSNDemo

Subcapa de soporte a la aplicacin Drivers de referencia para placas de desarrollo soportadas Subcapa para almacenamiento de parmetro genricos Drivers de referencia para plataformas soportadas Capas fisica y de control de acceso al medio Capa de red Acceso a EEPROM y al manejo de parmetro persistentes Servicios de seguridad Funcin Main y Task Manager Subcapa Zigbee Device Object Aplicacin completa para que demuestra la adquisicin de datos, seguridad y el power management.

(Pag 09)

3 Programando aplicaciones de Usuario3.1 Programacin basada en eventosLos sistemas de basados en eventos son un paradigma de programacin muy comunos en sistemas embebidos de pequeo tamao en los que existe una significativa limitacin de memoria y un pequeo espacio para el desenvolvimiento de todo el sistema operatibo. Programacin basada en eventos hace referencia a la arquitectura y estilo de programacin basados en pares de invocaciones de una funcin API funto con una notificacin ascrona resultado de la llamada a la API..... En lenguaje de programacin esto significa que la aplicacin de usuario provee unas capas subyacente con un puntero a funcin, que las capas ms altas llaman cuando una peticin es atendida.

En un sistema completamente basado en eventos, todo el codigo de usuario se ejecuta en callbacks

(Pag 10)

3.2 Mecanismo de Peticion/Confirmacin e IndicacinTodas las aplicaciones basadas en el SDK de BitCloud se escriben en un estilo de programacin basada en eventos. De echo todas la interfaces internas de la

pila son definidas en terminos de solicitudes y su correspondiente callback. Cada capa define un numero de callbacks para ser invocadas por capas inferiores, e invoca callbacks definidas por capas superiores. Existe un tipo genrico de callbacks definidas por el usuario que son responsables de la ejecucin del codigo de la aplicacin que son ejecutadas por el task hadler. APL_TaskHandler es el nombre reservado a la callback que la pila conoce como task handler. El mecanismo de peticin/confirmacin es una instancia particular del modelo de programacin basado en eventos. La peticin es una llamada ascrona a la pila subyacente para ejecutar una accin en medio de la aplicacin de usuario. La confirmacin es el callback que se ejecuta cuando dicha accin es completada y el resultado de esa accin est disponible. El mecanismo de Peticin/Confirmacin es una instancia particular del modelo de programacin basado en eventos. Puesto de forma simple, una peticin es una llamada ascrona a la capa subyacente para ejecutar una accin en medio de la aplicacin de usuario; la confirmacin es la funcin de callback que se ejecuta cuando dicha accin se ha completado y el resultado est disponible para la aplicacin usuario Por ejemplo considerese la peticin ZDO_StartNetworkReq(&networkParams), que solicita a la capa ZDO iniciar la red. El argumento networkParams es un struct definido en zdo.h como ZDO_StartNetworkReq_t:typedef struct { ZDO_StartNetworkConf_t confParams; void (*ZDO_StartNetworkConf)(ZDO_StartNetworkConf_t *conf); } ZDO_StartNetworkReq_t;

El primer campo es una estructura que se utiliza para la devolver una respuesta desde la pila (los parmetros actules de la red) a la peticin. El ltimo campo es un puntero a funcin con el valor de la callback actual. La peticin ZDO_StartNetworkReq(&networkParams) est emparejada con una funcin de callback definida por el usuario que corresponde a la siguiente declaracinstatic void ZDO_StartNetworkConf(ZDO_StartNetworkConf_t *confirmInfo) { }

por lo tanto la peticin debe ser precedida de una asignacin del puntero de callback:networkParams.ZDO_StartNetworkConf = ZDO_StartNetworkConf;

Este ejemplo ilustra una instancia particular del uso del mecanismo peticin/confirmacin, pero todos usos siguen el mismo proceder. Fijese en que la necesidad de desacoplar la peticin de la respuesta es especialmente importante cuando la peticin puede tomar una cantidad de tiempo no especificada. Por ejemplo, cuando se solicita el inicio de la red, las capas subyacentes puede realizar un escaneo que puede tomar un

cantidad de tiempo significativamente mayor que el que estamos dispuestos a esperar bloqueados. Solo algunas llamadas al sistema, especialmente aquellas cuyo tiempo de ejecucin es previsible, son sncronas. Tambin las llamadas de una funcion definida por el usuario a otra son sncronas. Aparte de los pares peticin/confirmacin, hay casos en los que la aplicacin necesita ser avisada de la existencia de un evento externo. Estos casos no son una replica a una peticin especifica. Para estas situaciones, existen la posibilidad de crear callbacks definidas por usuario con un nombre especifico que son invocadas por la pila de forma ascrona. Entre estas se encuetran los eventos para indicar la perdida de conectividad, la disposicin de una subcapa para echarse a dormir, o la notificacin de que el sistema est ya en pie. (Pag 11) Regla 1: todas las aplicaciones de usuario se organizan en un conjunto de callbacks que se ejecutan al termino de una solicitud a la capa subyacente. Regla 2: La aplicacin del usuario es la responsable de declarar las callbacks que maneja los eventos no solicitados del sistema que interesen.

3.3 Planificador de tareas, prioridades y desalojo.Un aspecto importante del desarrollo de aplicaciones es la gestin del flujo de programa y el aseguramiento de que las diferentes partes de la aplicacin no interfieren con otras en ejecucin. En aplicaciones no embebidas, el sistema operativo gestiona tipicamente en el acceso a los recursos del sistemas y coordina, por ejemplo, que toda aplicacin reciba su parte equivalente de recursos. Debido a la multiple concurrencia de aplicaciones que coexisten en el mismo sistema ( algo conocido como multitasking), un sistema operativo como windows es muy complejo en comparacin a un sistema monotarea como es BitCloud. En el contexto de BitCloud, slo hay una tarea ejecutandose en la cima de la pila, de modo que la pelea por obtener los recursos del sistema no se da entre aplicaciones simultaneas sino entre la aplicacin de usuario y la pila que hay por debajo. Ambas, pila y aplicacin deben ejecutar su codigo en el mismo microcontrolador. En contraste con S.O. con desalojo en los cuales es ms adecuado un manejo mltiple de aplicaciones que sin embargo requiere una mayor sobrecarga de stos, los sistemas multitarea cooperativos son ms livianos. Sin embargo, requieren una cooperacin entre la aplicacin y el sistema operativo. Los sistemas con desalojo dividen el tiempo de CPU entre las diferentes aplicaciones (multiplexando por lo tanto transparentemente la CPU) de modo que a los desarrolladores les parezca que sus aplicaciones tienen el control exclusivo de la CPU. En cambio una aplicacin corriendo en un sistema multitarea cooperativo debe ser cuidadosa con la necesidad de ceder los recursos de los que dispone (principalmente, la CPU) a la capa subyacencte. Otro beneficio es que solo se necesita una capa. Lo que se traduce en un ahorro considerable de memoria. Volviendo al ejemplo de peticin/confirmacin, si ZDO_StartNetworkConf (una callback de usuario) se toma un tiempo muy largo en ejecutarse el SO estar bloqueando esperando que la callback le devuelva el control. Tenga en cuenta que las callback corren bajo la prioridad de la capa envolvente. Asi que ZDO_StartNetworkConf corre bajo el nivel de prioridad ZDO. Los usuarios deben ser cautos ejecutando largas secuencias de instrucciones, incluido instrucciones en funciones anidadas, en el entorno de una callback invocadada desde otra capa. Regla 3: Todas las callbacks de usuario se debe ejecutar en menos de 10 ms

Regla 4: Las callbacks corren bajo el nivel de prioridad de la capa envolvente. La estrategia para que las callbacks se ejecuten en menos de 10 ms es aplazar su ejecucin. La ejecucin aplazada es una estrategia que parte del contexto de ejecucion entre la callback y el planificador de tareas. El modo de conseguir una ejecucin aplazada es preservar el estado de la aplicacin y fijar una tarea en la cola de tareas con la llamada:SYS_PostTask(APL_TASK_ID);

La accin de fijar un tarea es sncrona, y el efecto de la llamada es notificar al planificador que en la cola de tareas hay una tarea aplazada por ejecutar. Para la aplicacin usuario, la cola de tareas se identifica siempre por APL_TASK_ID. El resultado de fijar una tarea es crear una llamada aplazada al manejador de tareas APL_TaskHandler, que, a diferencia de otras callbacks, corre bajo el nivel de prioridad de la aplicacin. (Pag 12) En otras palabras, el manejador de tareas de la aplicacin corre solo cuando todas las capas de mayor prioridad se han completado. Esto permite tiempos de ejecucin mayores en el contexto del manejador de tareas, que en el contexto de la callback. Regla 5: El manejador de tareas de la aplicacin corre solo cuando todas las capas de mayor prioridad se han completado Regla 6: El manejador de tareas de la aplicacin debe ejecutarse en menos de 50ms Otras ID de tareas interesantes son HAL_TASK_ID y BSP_TASK_ID, que hacen referencia a las tareas pertenecientes a la capa de abstracin hardware y al paquete de soporte de la placa. Cuando la aplicacin de usuario conlleva modificaciones en las capas HAL o BSP, en la ejecucin aplazada de callbacks de HAL o BSP debe utilizarse estos ID.

3.4 Aplicaciones con TimersHasta ahora, las tres formas de que el control de flujo se introdujera en el codigo de aplicacin eran: (1) a travs del manejador de tareas a continuacin de una invocacin de SYS_PostTask, (2) a travs de la callback de confirmacin invocada por la capa subyacente tras la ejecucin de una solicitud, y (3) a travs de notificaciones de eventos asncronos invocados por el SO. Hay que tener en cuenta que para ninguno de tres metodos existe un momento en el cual se sabe va a ser ejecutado. Una forma de asegurarse la ejecucin de una callback definida por el usuario en un momento especfico del futuro es el uso de timers. La pila provee de un interfaz de alto nivel para timers, que hace uso de un timer hardware de bajo nivel. Dicha interfaz es parte del HAL y su uso esta ilustrado en muchas aplicaciones de usuario ( BlinkApp.c). La idea general es que una estructura HAL_AppTimer_t contiene el intervalo del timer, (ya sea un timer cclico o que se dispara una sola vez) y la funcin de callback a ejecutar cuando el timer se dispara. La estructura se debe pasar a HAL_StartAppTimer y a HALStopAppTimer para iniciar y parar el timer.

3.5 Concurrencia e interrupcionesEl concurrencia es el trmino que se utiliza para referirse a los distintos threads independendientes que se ejecutan a la vez. En un sistema que utiliza desalojo con multiplexado en el tiempo de la CPU y en el cual corren multiples treads, la ejecucin de una funcin puede ser interrumpida por el planificador del sistema en un punto aleatorio, dando el control a otro thread en ejecucin que potencialmente puede ejecutar una funcin diferente de la misma aplicacin. Debido a la imposiblidad de predecir una interrupcin y al hecho de que dos funciones pueden compartir datos, el desarrollador debe asegurarse que el acceso a datos compartidos sea totalmente atmico. Como se explic previamente, en una aplicacin BitCloud un nico thread se comparte para ejecutar la aplicacin y el S.O. Cuando este thread realiza una tarea en una capa de la pila, ste adquiere la prioridad de la capa, pero ste es siempre el mismo. Simplemente est ejecutando un secuencia de funciones (no intercaladas entre ellas) de las diferentes capas de la pila y la aplicacin. Por lo tanto el control del flujo de ejecucin no puede encontrarse en ms de un callback de usuario en un mismo tiempo. En general, la ejecucin de multiples callbacks no puede ser intercalada, cada callback se ejecuta como un bloque de cdigo atmico. (Pag 13) A pesar de que el multiplexado de CPU no se usa, hay condiciones especiales donde se puede crear otro thread de control. Ocurre cuando emerge una interrupcin hardware, que puede interrumpir la ejecucin en un punto arbitrario ( el principal thread de control debe estar ejecutando codigo de la pila o de la aplicacin cuando esto ocurre ) para gestionar un evento fsico proveniente de un periferico del MCU. ( p.e. La USART o el canal SPI). Esto es anlogo al manejo de interrupciones hardware en otro tipo de sistemas.

En la anterior figura se ilustra un ejemplo de interaccin entre la aplicacin, la pila, el planificador de tareas, y las interrupciones hardware. En un principio el planificador ejecuta una tarea mediante la llamada a APL_TaskHandler. Cuando la aplicacin usuario se est ejecutando, sta es interrumpida por un evento hardware ( en gris). A la funcin que se ejecuta con la llegada de la interrupcin se la denomina servicio de interrupcin. Tras la ejecucin del servicio de interrupcin, se devuelve el control a la aplicacin de usuario, y una vez que sta ltima termina, el control es devuelto a planificador de tareas. ste selecciona una tarea de la capa MAC para ser ejecutada a continuacin. Mientras la funcin MAC_TaskHandler corre, invoca una callback de confirmacin en la capa ZDO que es interrumpida por otro evento hard. Notese que la capa MAC invoca otra callback en ZDO que a su vez invoca otra callback registrada por la aplicacin de usuario. Por lo tanto este ltimo callback se ejecuta con la prioridad de la capa MAC o MAC_TASK_ID. Las aplicaciones BitCloud puede crear rutinas de servicio de interrupcin que se ejecuten con la llegada de un evento hardware. Esto se usa, tpicamente, para la gestin de perifericos adicionales cuyos drivers no son parte del SDK y son, en cambio, aadidos por el usuario. La llamada para definir un servicio de interrupcin esHAL_RegisterIrq(uint8_t irqNumber, HAL_irqMode_t irqMode, void(*)(void) f);

irqNumber es el identificador correspondiente a una de las lineas IRQ hardware disponibles, irqMode especifica cuando el servicio de la interrupcin hardware se puede ejecutar, una vez el evento se ha notificado, y f es la callback definida por el usuario como servicio de interrupcin. Naturalmente, la ejecucin de un servicio puede ser interrumpida por la ejecucin de otra callback. As que si el servicio tiene acceso a una variable global que puede ser modificada por otra callback, este acceso a la variable compartida se debe realizar en acciones atmicas. Si existe un fallo en la ejecucin un acceso atmico, este puede desencadenar una condicin de carrera. (Pag 14) El acceso atmico se puede asegurar dividiendo cada acceso individual con las macros ATOMIC_SECTION_ENTER y ATOMIC_SECTION_LEAVE. Estas macros inician y terminan los que se conoce como una seccin crtica, un bloque de cdigo que ininterrumpible. Estas macros operan desabilitando las interrupciones hardware. Las secciones debe ser lo mas cortas posibles para reducir el tiempo que las interrupciones hardware son enmascaradas. En los microcontroladores AVR mediante el uso de flags, las interrupciones enmascaradas son salvadas

para gestionarlas ms adelante. Regla 7: Las secciones crticas no deven sobrepasar los 50us de duracin.

3.6 Estructura tpica de una aplicacinLa estructura de una aplicacin BitCloud es significativamente diferente a la de un tpico programa en C que se ejecuta en una plataforma no embebida. Como anteriormente se dispuso: 1 Cada aplicacin define un unico gestor de tareas de aplicacin, que contiene el total del cdigo de la aplicacin de usuario ( incluido el cdigo accesible a travs llamadas a subfunciones) 2 Toda aplicacin define un numero de callbacks que se ejecutan cuando se completa una peticin asncrona de la capa subyacente. 3 Toda aplicacin define un numero de callbacks de nombres conocidos que se ejecutan con el procesamiento de un evento por la pila 4 Toda aplicacin mantiene un estado global que es compartido ente las callbacks y el manejador de tareas de usuario. La funcin main est embebida dentro de la pila. Una vez la pila se inicializa, el control es transferido de main a planificador de pila, que comienza a invocar, los distintos manejadores de tarea en un order de prioridad ( de mas alto a ms bajo), invocando eventualmente al APL_TaskHandler, que es el punto de entrada a la aplicacin. Tras la llamada inicial al manejador de tareas de la aplicacin, el control es transferido continuamente entre la pila y las callbacks como se ha mostrado en la figura anterior. Una aplicacin puede ser dividida en un conjunto de archivos escritos en C. Para simplificar, aqu se considera la existencia de un nico archivo./******************************* #include directives *******************************/ ... #include #include #include #include /******************************* FUNCTION PROTOTYPES *******************************/ ... /******************************* GLOBAL VARIABLES *******************************/ AppState_t appState = APP_INITING_STATE; ... /******************************* IMPLEMENTATION *******************************/ /******************************* Application task handler *******************************/ void APL_TaskHandler() { switch (appState)

{case APP_IN_NETWORK_STATE: ... break; case APP_INITING_STATE: //node has initial state ... break; case APP_STARTING_NETWORK_STATE: ... break; } } /******************************* Confirm callbacks *******************************/ static void ZDO_StartNetworkConf(ZDO_StartNetworkConf_t *confirmInfo) { ... if (ZDO_SUCCESS_STATUS == confirmInfo->status)

{appState = APP_IN_NETWORK_STATE; ... SYS_PostTask(APL_TASK_ID); } } void ZDP_LeaveResp(ZDP_ResponseData_t *zdpRsp) { ... } /******************************* Indication callbacks *******************************/ void ZDO_WakeUp_Ind(void) { ... if (APP_IN_NETWORK_STATE == appState)

{appState = APP_STARTING_NETWORK_STATE; ... SYS_PostTask(APL_TASK_ID); } } void ZDO_MgmtNwkUpdateNotf(ZDO_MgmtNwkUpdateNotf_t *nwkParams) { ... }

(Pag 16) El anterior esqueleto de cdigo es representativo de la mayoria de aplicaciones. Invariablemente, hay un estado global, representado en este caso por la variable appState al cual acceden desde las callbacks y desde el manejador de tareas. En aplicaciones del mundo real, el estado se representa por un determinado nmero de variables. Adviertase que un tpico manejador de tareas cambia el estado de las variables al ejecutar cdigo para un estado particular, que es una plantilla de programacin compartida por todas las aplicaciones ejemplo incluidas en el SDK. El desarrollador debe primero considerar su aplicacin en trminos de mquina de estados. El mapeado de esa mquina de estados es el mtodo natural de programacin basada en eventos. Tengase en cuenta tambin el uso de la funcin del gestor SYS_PostTask. p.e. la aplicacin aplaza

a propsito el procesamiento de la indicacin de prdida de conectividad.(:::). La callback simplemente cambia el valor de la variable de estado appState y devuelve el control a la capa desde la que fue invocada (ZDO). Este estilo de programacin es totalmente consistente con un sistema multitarea cooperativo, y permite a la pila manejar tareas de una prioridad ms alta antes de devolver el control a la tarea aplazada

(Pag 17)

4 La interfaz ConfigServerla pila de BitCloud provee de un extenso set de parmetros de configuracin que determinan los diferentes aspectos del comportamiento de la red y sus nodos. Estos parmetros son accesibles a travs de la interaz ConfigServer (abreviado CS). Este capitulo introduce ligeramente la interfaz CS. Un completo listado y descripcin se puede encontrar en la documentacin de la API. Todos los parmetros CS se pueden dividir en dos categorias: persistentes y no persistentes. Los persistentes se almacenan en la memoria EEPROM y sus valores son accessibles por la aplicacin y la pila tras el reset HW del nodo. Los parmetros no persistentes son almacenados en la memoria RAM y tras un reset HW son reinicializados a sus valores por defecto. El fichero ConfigServer.h incluye un comentario seguido de cada ID de parmetro indicando si ste es persistente o no.

4.1 Leyendo/escribiendo parmetros CSConfigServer.h contiene la definicin de todos los parmetros CS y su valores por defecto. Sin embargo, si es necesario la aplicacin puede de asignar nuevos valores a los parmetros mediante cualquiera de los mtodos que se describen a continuacin: Definiendolos en el Makefile de la aplicacin Mediante funciones de lectura/escritura de CS

4.1.1 Definicin de parmetros CS en el makefileEl mtodo ms simple para asignar un valor a un parmetro CS es definirlo en el makefile de la aplicacin. En este caso el valor por defecto asignado en configServer.h es obviado y el valor asignado por el makefile es el que se aplica en el parmetro. Por ejemplo, al aadir la siguiente linea al makefile, se fija la energa de emisin de RF en 3dBm:+= -DCS_RF_TX_POWER=3

En las aplicaciones BitCloud las variables de entorno CFLAGS son automaticamente inicializadas durante el proceso de compilacin del proyecto de modo que el simple hecho de aadir la lnea de arriba es suficiente para asignar el valor deseado al parmetro. A pesar de que el mtodo es simple, solo permite la configuracin del parmetro en tiempo de compilacin y no permite modificaciones en tiempo de ejecucin.

4.1.2 Funciones de Lectura/EscrituraPara permitir la lectura/escritura en tiempo de ejecucin ConfigServer provee de las correspondientes funciones API: CS_ReadParameter y CS_WriteParameter. Ambas funciones requieren del ID del parmetro y de un puntero a un valor de parmetro como argumentos. El ID de parmetro identifica el a que parmetro se aplica la funcin y se construye aadiendo _ID al final del nombre del parmetro.

(Pag 18) El siguiente cdigo ejemplifica como una aplicacin puede leer y escribir el parmetro de energa de salida de RF. (CS_RF_TX_POWER)int8_t new_txPwr=3; // variable for writing new value int8_t curr_txPwr; // variable for reading current value CS_ReadParameter(CS_RF_TX_POWER_ID, &curr_txPwr); CS_WriteParameter(CS_RF_TX_POWER_ID, &new_txPwr);

(Pag 19)

5 Un vistazo a la redComo se vio con anterioridad la pila de BitCloud sigue la estructura de la especificacin de Zigbee PRO que permite a las aplicaciones interactuar directamente solo con las componentes APS y ZDO del ncleo de la pila. Este enfoque simplifica significativamente el desarrollo de aplicaciones a la vez que garantiza que la aplicacin no interfiere en el protocolo de red y por lo tanto el comportamiento siempre cumple la especificacin Zigbee PRO. En este capitulo se introducen brevemente las principales caractersticas de la red de la pila BitCloud, y se describe las correspondientes interacciones entre la aplicacin y el ncleo de la pila.

5.1 Creacin y unin a una redA pesar del uso del termino inicio de red desde el punto de vista de la aplicacin no hay diferencia entre los procedimiento que se sigue para crear un red y el que se sigue para unirse a sta. La aplicacin BitCloud deber ejecutar el procedimiento de red en los tres pasos que se describen con detalle en esta seccin: 1- Configurar los parmetros del nodo 2- Especificar los parmetros de la red 3- Realizar una peticin de inicio de red 4- Recibir la confirmacin de inicio de red Adviertase que todos los parmetros CS mencionados en la seccin 5.1 no se podr modificar si el dispositivo ya est unido a la red. Sin embargo los parmetros no mencionados en la seccin 7.1 se pueden modificar una vez el nodo ha abandonado la red.

5.1.1 Parmetros del Nodo5.1.1.1 Tipo de Dispositivo

La especificacin Zigbee diferencia entre tres tipos de dispositivos que pueden estar presentes en una red: coordinador, router y dispositivo final. la principal responsablilidad del nodo coordinador (C) es la de formar la red con las caractersticas deseadas. Tras la formacin de la red otros nodos se pueden unir a ella va el coordinador o los routers ya presentes en la red. El nodo coordinador puede ejecutar funciones de enrutado. Debido a que la direccin esttica asociada al coordinador es 0x0000, solo un nico dispositivo de este tipo es permitido en la red. Un nodo router (R) permite el envio transparente de datos a travs de l desde otros nodos a la direccin de destino. Pero por supuesto el tambin puede enviar su propia informacin. Al igual que el coordinador el nodo router puede ser capaz de aadir nuevos nodos a la red.

Un nodo final (ED) solo puede enviar y recibir datos que han sido reenviados hacia o por el nodo destino a travs de los nodos padres del nodo final al que actualmente esta asociado. Solo los nodos finales tienen la capacidad de echarse a dormir.

(Pag 20) El tipo de dispositivo se define por el parmetro CS_DEVICE_TYPE de tipo DeviceType_t. Este parmetro se puede fijar a uno de los siguientes valores: DEVICE_TYPE_COORDINATOR (o 0x00) para el coordinador, DEVICE_TYPE_ROUTER (o 0x01) y DEVICE_TYPE_END_DEVICE (o 0x02) para el router y el dispositivo final respectivamente. Adicionalmente el parmetro booleano CS_RX_ON_WHEN_IDLE se debe fijar a true en los nodos coordinador y router mientras que en los dispositivos finales que pueden echarse a dormir, este se deber fijar a falso para indicar la recepcin indirecta mediante peticiones sonda como se describe en la seccin 5.3.4.1 El cdigo que sigue a continuacin es un ejemplo de como configurar un dispositivo como nodo final:DeviceType_t deviceType = DEVICE_TYPE_END_DEVICE; bool rxOnWhenIdle = false; CS_WriteParameter(CS_DEVICE_TYPE_ID, &deviceType;

5.1.1.2 Direccionado de un dispositivo

En concordancia con el standard Zigbee, cada dispositivo debe ser identificado unvocamente mediante una direccin extendida (de 64 bits), tambin llamada direccin MAC o direccin IEEE. En la pila BitCloud la direccin extendida se determina con el parmetro CS_UID y como cualquier otro parmetro CS puede ser fijado como se describe en la seccin 4.1. Es la responsabilidad del usuario el asignar una direccin nica a cada dispositivo antes de ejecutar los procedimientos de inicio de red. Tngase en cuenta que en algunas placas entrenadoras (ejemplo, RZRaven, o MeshBean), si CS_UID se fija a 0 en tiempo de compilacin, la direccin extendida se asignar al valor obtenido por el UID del chip EEPROM externo localizado en la placa, lo que asegura la unicidad de todos los dispositivos que se tenga de la misma placa de desarrollo. Cuando se une a una red Zigbee, cada dispositivo es identificado por lo que se conoce como direccin corta (16 bits), tambin denominada como direccin de red (NWK). Esta es la direccin usada en las cabeceras de cada frame durante el intercambio de datos. En BitCloud las direcciones cortas puede ser seleccionadas aleatoriamente por la pila durante la unin a la red o asignadas por la aplicacin de usuario a un valor deseado antes de proceder a unirse a una red. Es crtico asegurarse de que todos los nodos de la red usan el mismos mecanismo de adquisicin de direccin. El parmetro booleano CS_NWK_UNIQUE_ADDR especifica si la direccin se asignar al unirse a la red (false), o si el nodo ya especifica su direccin antes de unirse (true). En este ltimo caso la direccin deseada se asignar a CS_NWK_ADDR. Si se utiliza este tipo de mecanismo de adquisicin de direccin siempre se deber dar el valor 0x0000 al coordinador de red, cosa que la pila hace con el direccionamiento automtico. Despus de unirse a una red, un dispositivo puede leer su propia direccin corta del campo shortAddr en el argumento de la funcin de callback

ZDO_StartNetworkConf registrada para la solicitud de inicio de red como se describe en la seccin 5.1.3 Solicitud de inicio de red y confirmacin (Pag 21) En el esquema de asignacin automtica aleatoria de direccin un mecanismo de resolucin de conflictos detecta y resuelve situaciones en las que la direccin escogida aleatoriamente parece no ser nica, como por ejemplo cuando se une a la red un nodo con las misma direccin ya presente en la red. Despues de que la direccin de red es actualizada, la aplicacin del nodo correspondiente es informada va ZDO_MgmtNwkUpdateNotf() con el status ZDO_NWK_UPDATE_STATUS (0X8E) y el nuevo valor de direccin en el argumento. En redes de direccionamiento manual la aplicacin de usuario es la responsable de resolver dichos conflictos. An as, Bitcloud ofrece asistencia en estos casos mediante la llamada a la funcin ZDO_MgmtNwkUpdateNotf() con el status ZDO_STATIC_ADDRESS_CONFLICT_STATUS (0x95) en el nodo que ha detectado el conflicto ( que puede diferrir del nodo que tiene el conflicto de direccin)

Adviertase que la organizacin de la red (topologa) que se muestra en la figura 5-1a) casi siempre difiere del que se usa en realidad de enlaces de transmisin directa que se utiliza para enrutar los datos a travs de la red.. En la figura 5-1b se muestra un modelo de enlaces de transmisin directa en la que todos los nodos se encuentran en el rango de seal de cada otro.

5.1.1.3 Parmetros relacionados con la topologa

Adems de los parmetros de nodo y de red de destino descritos en este captulo es fundamental que antes de unirse a una red, el nodo configure los parmetros que tienen un impacto sobre la organizacin de la red y por lo tanto pueden ser utilizados para lograr el comportamiento y rendimiento adecuando en la red. Para un nodo final el CS_NEIB_TABLE_SIZE es el primordial de estos parmetros, pues determina el nmero mximo de potenciales padres que este nodo puede elegir durante el proceso de unin a la red. Entre los nodos detectados capaces de tener un nodo hijo, aquel con las mejores cualidades de enlace es el elegido. Sin embargo para un nodo enrutador CS_NEIB_TABLE_SIZE tiene efectos adicionales, tambin limita el numero de padres entre los que puede escoger. Los nodos coordinadores y enrutadores pueden limitar el nmero de hijos directos que les pueden enlazar configurando el parmetro CS_MAX_CHILDREN_AMOUNT que define el nmero de hijos totales (enrutadores + nodos finales) que puede tener.

CS_MAX_ROUTER_CHILDREN_AMOUNT define el mximo de enrutadores entre los hijos, y por lo tanto, la diferencia entre estos dos parmetros especifica el nmero mximo de dispositivos finales que se pueden directamente conectar a esto nodo al mismo tiempo. Adviertase que la siguiente relacin debe cumplirse siempre en nodos coordinadores y routers:CS_NEIB_TABLE_SIZE > CS_MAX_CHILDREN_AMOUNT >= CS_MAX_ROUTER_CHILDREN

(Pag 22) La profundidad mxima de la red se define mediante CS_MAX_NETWORK_DEPTH, que especifica el mximo nmero de saltos posibles en la red, desde un nodo perteneciente al coordinador. Si este lmite es alcanzado en la unin de un router a la red, este no ser capaz de enlazar ningn hijo, aunque cualquiera de los anteriores parmetros se lo permitiera. CS_MAX_NETWORK_DEPTH tienen un impacto directo en muchos de los intervalos de tiempo de espera dentro de la pila, por lo tanto para que el correcto funcionamiento de la red est garantizado ste debe tener el mismo valor en todos los nodos de la red.

5.1.2 Parmetros de red destinoAntes de proceder a iniciar una red, el nodo es responsable de fijar los parmetros que deciden si este nodo desea formar la red (coordinador) o si el nodo desea unirse a la red. Estos parmetros son: Tipo de modulacin, tambin llamado pgina del canal.(CS_CHANNEL_PAGE) Frecuencia del canal, que se especifica via mscara del canal (CS_CHANNEL_MASK) PAN ID extendido de 64 bit (CS_EXT_PAN_ID) Los parmetros de seguridad.

CS_CHANNEL_PAGE define el tipo de modulacin a ser usado por el dispositivo. Este parmetro se ignora para frecuencias de 2.4GHz, mientras que en la banda 868/915 Mhz solo se aceptan los valores 0 y 2. Para la banda de 780 Mhz debe ser siempre 5. CS_CHANNEL_MASK es un campo de 32-bit que determina los canales de frecuencia soportados por el nodo. Los 5 bits superiores deben ser siempre 0, los 27 restantes indican el estatus de disponibilidad para cada uno de estos 27 canales ( 1 = soportado, 0 = no soportado) (Pag 23) La tabla 5-1 muestra la distribucin de canales a travs de toda la banda de frecuencias de la IEE802.15.4, y muestra la velocidad de transmisin del medio fsico para las distintas pginas del canal.

CS_EXT_PAIN_ID es el identificador extendido de 64-bit de la red que es verificado durante el proceso de asociacin. Por lo tanto los dispositivos que desean unirse a cierta red deben configurar su PAN ID igual al del coordinador de la red. Si CS_EXT_PAN_ID es fijado a 0x0 en un router o dispositivo final, entonces el nodo se unir a la primera red detectada en el aire. Durante la formacin de la red el coordinador selecciona otro identificador de red: este nuevo PAN_ID de red de 16 bit es usa en las cabeceras de las tramas durante el proceso de intercambio de datos en vez del de 64 bit que es mas pesado. Por defecto el PAN_ID de red (16-bit) se genera de forma aleatoria, y si un coordinador durante la formacin de la red detecta otra red con el mismo PAN_ID extendido (64-bit) entonces selecciona de forma automtica un PAN_ID de red (16-bit) diferente para evitar conflictos durante la transmisin de datos. (Pag 24) Sin embargo este mecanismo conlleva un comportamiento indeseado en ciertas ocasiones: si se resetea el nodo coordinador, y este reinicia la red con el mismo PANID extendido y en el mismo canal, puede encontrarse con un router de la anterior red y por lo tanto formar una red con un PANID de red diferente. Sin embargo se requiere que el coordinador se una a la misma red donde anteriormente actuaba y que participe en el intercambio de datos. Por lo tanto, para forzar a que el coordinador se una a la antigua red, se recomienda que el PANID se predefina en el nivel de aplicacin antes de iniciar la red tal y como se muestra en el siguiente ejemplo:bool predefPANID=true; uint16_t nwkPANID=0x1111; CS_WriteParameter(CS_NKW_PREDEFINED_PAN_ID, &predefPANID); CS_WriteParameter(CS_NWK_PANID_ID, &nwkPANID);

Si el PANID de red se predefine en un nodo no coordinador, solo ser posible el ingresar en una red con el mismo PANID extendido y de red configurado en el nodo.

5.1.3 Solicitud de Inicio de red y ConfirmacinLa aplicacin BitCloud es totalmente responsable de inicializar la red. La figura 5.2 muestra un diagrama con la secuencia del procedimiento de inicio de red, secuencia que es idntica en todo tipo de dispositivos. Una vez los parmetros de red se han fijado adecuadamente, la aplicacin puede comenzar con el procedimiento de inicio de red ejecutando la llamada ascrona ZDO_StartNetworkReq(). Tras finalizar el procedimiento de inicio/unin a red, el componente ZDO informa a la aplicacin sobre el resultado del procedimiento de acuerdo a la funcin de callback registrada con el argumento de tipo ZDO_StartNetworkConf_t que contiene el status del procedimiento ejecutado, as como informacin de la red iniciada, obteniendo la direccin de red del nodo, etc. Se recibe el status ZDO_STATUS_SUCCESS si el procedimiento se ejecut con xito , mientras que ZDO_FAIL_STATUS indica que el inicio de red fallo.

Despus de que un nodo final se une a la red su nodo padre recibe una notificacin via ZDO_MgmtNwkUpdateNotf() con el campo ZDO_CHILD_JOINED_STATUS (0X92). Las direcciones de red y extendida se devuelve como campo del argumento tambin. Sin embargo dicho notificacin no es emitida cada vez que un router se une a la red porque no existen padres dedicados para los nodos hijo tipo router. (Pag 25)

5.2 Perdida del padre y abandono de la redLos nodos presentes en una red Zigbee pueden abandonar sta por dos razones: Perdida del padre. Como en una topologa de malla, un router no tiene nodos padres dedicados, este causa solo se d en nodos finales Se solicita el abandono de la red. Esta solicitud puede ser emitida tanto (a) por la aplicacin que corre en el nodo como (b) por un nodo remoto La primera razn (a) es vlida para todo tipo de dispositivos. Mientras que la segunda (b) se aplica a routers y dispositivos finales unicamente.

5.2.1 Perdida de padre por un nodo final.En la figura 5-3 se muestra los mensajes de notificacin emitidos por la pila en un nodo final si la conexin con su padre se pierde. La primera notificacin ZDO_NETWORK_LOST_STATUS es expedida por la funcin ZDO_MgmtNetworkUpdateNotf() cuando un nodo final no puede alcanzar su nodo padre. Tras recibir este mensaje la aplicacin puede relizar cualquier accin pero no debe iniciar un proceso de unin a la red. Este se iniciar automaticamente cuando el hilo de la pila reciba el control. La pila intentar encontrar un nuevo padre para el nodo. El resultado es transmitido a la aplicacin via ZDO_MgmtNwkUpdateNotf(). El status ZDO_NETWORK_STARTED_STATUS significa que el nodo ha conseguido unirse de nuevo a la red con los parmetros indicados en el argumento de ZDO_MgmtNwkUpdateNotf(). Si el procedimiento de reintento de unin falla la aplicacin recibe una notificacin con el estatus ZDONETWORK_LEFT_STATUS. Tras esto, la aplicacin es responsable de cambiar los parmetros de red y si es necesario iniciar un nuevo procedimiento de formacin de red como se describe en Formacin y unin a la red

5.2.1.1 Notificacin de prdida de hijo

Con asiduidad es importante para un nodo padre poder registrar cuando se ha perdido un hijo. Como se mencion anteriormente debido a que solo los dispositivos finales se pueden asociar como nodos hijo, esta nofificacin no ser expedida en un nodo router si otro router se apaga o deja de emitir seal. La principal dificultad del seguimiento de eventos de prrdida de hjos viene del hecho de que un nodo final es propenso a tener periodos de inactividad (sleep) y por lo tanto no se realizan intercambio de informacin durante intervalos largos de tiempo incluso si el nodo final se encuentra en la red y preparado para enviar informacin en cuanto finalize su periodo de inactividad. (Pag 26) Por lo tanto, para asegurar que un nodo hijo est fuera de la red y simplemente no se ha echado a dormir, el nodo padre debe conocer la duracin de los intervalos de inactividad del nodo hijo ( p.e. Tener el mismo CS_END_DEVICE_SLEEP_PERIOD). Par un nodo padre esto implica que sus hijos se levanten periodicamente y envien alguna solicitud. Si durante el intervalo de tiempo calculado como:CS_NWK_END_DEVICE_MAX_FAILURES * (CS_END_DEVIE_SLEEP_PERIOD + CS_INDIRECT_POLL_RATE)

un hijo no entrega ninguna trama de solicitud, el nodo padre asume que ese hijo ha abandonado la red y por lo tanto se lanza la callback ZDO_MgmtNwkUpdateNotf() con el status ZDO_CHILD_REMOVED (0x93). Y en sus argumentos, se indica la direccin extendida del nodo hijo que abandon la red

5.2.2 Abandono de la redEn muchas situaciones es conveniente que un nodo abandone la red en respuesta a ciertos eventos. (o incluso forzar a un nodo que se desasocie de la red el mismo). BitCloud permite que la aplicacin de cualquier tipo de nodo inicie este proceso usando la funcin ZDO_ZdpReq():static ZDO_ZdpReq_t zdpLeaveReq; //set corresponding cluster ID zdpLeaveReq.reqCluster = MGMT_LEAVE_CLID; zdpLeaveReq.dstAddrMode = EXT_ADDR_MODE; zdpLeaveReq.dstExtAddr = 0; // for own node address shall be 0 zdpLeaveReq.ZDO_ZdpResp = ZDO_ZdpLeaveResp; // callback //for own node address shall be 0 zdpLeaveReq.req.reqPayload.mgmtLeaveReq.deviceAddr = 0;

//specify whether to force children leave or not zdpLeaveReq.req.reqPayload.mgmtLeaveReq.removeChildren = 0; //specify whether to perform rejoin procedure after network leave zdpLeaveReq.req.reqPayload.mgmtLeaveReq.rejoin = 1; ZDO_ZdpReq(&zdpLeaveReq); // request network leave

Si en el cdigo de arriba la direccin de destino se fija a la direccin de un nodo remoto. Entonces despus de llamara a ZDO_ZdpReq (&zdpLeaveReq), el nodo transmitir una trama comando al nodo destino solicitandole el abandono de la red. El diagrama de secuencia para el procedimiento de abandono de red se muestra en la figura 5.4 (el nodo abandona la red de motu propio) y en la figura 5.5 (el nodo abandona la red debido a una solicitud remota). (Pag 27)

5.3 Intercambio de informacinObviamente el proposito de establecer una red Zigbee es el realizar un intercambio de informacin entre nodos remotos segn los solicite la funcionalidad de la aplicacin. En esta seccin se da un vistazo a la configuracin del nodo, los parrametros de transmisin y las funciones del API Bitcloud responsbles de la comunicacin en el nivel de aplicacin.

5.3.1 Registro de puntos finalesDentro de la Zigbee la informacin es intercambiada entre los llamados puntos finales. Para que sea posible la comunicacin en el nivel de aplicacin cada nodo debe registrasr al menos un punto final mediante el uso de la funcin APS_RegisterEndPoint() con el argumento de tipo APS_registerEndPointReq_t. El argumento especifica un descriptor de punto final (campo simpleDescriptor) que incluye tanto parmetros como un ID de punto final (nmero del 1 al 240), ID de perfil de aplicacin, numero y lista de grupos de entradas y salidas. Adems el campo APS_DataInd seala la funcin callback a ser llamada cada vez que se reciban datos destinados a este punto final. (Pag 28)

El fragmento de cdigo que sigue ejemplifica como registrar y definir un punto final ep1 con un ID de perfil 1 y sin ningn tipo de limitacin en cuanto a I/O.// Specify endpoint descriptor static SimpleDescriptor_t simpleDescriptor = {1, 1, 1, 1, 0, 0, NULL, 0, NULL}; // variable for registering endpoint static APS_RegisterEndpointReq_t endpointParams; // Set application endpoint properties endpointParams.simpleDescriptor = &simpleDescriptor; endpointParams.APS_DataInd = APS_DataIndication; // Register endpoint APS_RegisterEndpointReq(&endpointParams);

5.3.2 Configuracin del ASDUPara poder realizar la transmisin de datos por si misma, la aplicacin primero deber crear una solicitud de transmisin del tipo APS_DataReq_t, que especifica la longitud del ASDU (campos asdu y asduLength), fijar varios parmetros de transmissin y definir la funcin de callback (campo APSDataConf) que ser ejecutada para informar a la aplicacin del resultado de la transmisin. Debido a que la pila necesita que el ASDU se guarde en la memoria RAM como un bloque continuo de datos con unas caractersticas especificas, la aplicacin deber construir dicha estructura como se muestra en la figura 5.6

La maxima longitud permitida para el frame de datos es de 53 bytes en datos cifrados y 84 bytes para transmisiones no seguras. (Pag 29) El siguiente extracto de cdigo ejemplifica como crear una solicitud de envo con la correcta estructura ASDU:// Application message buffer descriptor BEGIN_PACK typedef struct { uint8_t header[APS_ASDU_OFFSET]; // Header uint8_t data[APP_ASDU_SIZE]; // Application data uint8_t footer[APS_AFFIX_LENGTH - APS_ASDU_OFFSET]; //Footer } PACK AppMessageBuffer_t; END_PACK static AppMessageBuffer_t appMessageBuffer; // Message buffer APS_DataReq_t dataReq; // Data transmission request dataReq.asdu = appMessageBuffer.data; dataReq.asduLength = sizeof(appMessageBuffer.data);

Si se usa el esquema de asignacin manual de direcciones el nodo fuente deber tener un conocimiento total del destinatario de los datos, tanto su direccin de red como el ID del perfil, el punto final y los grupos de entrada soportados. En el esquema de asignacin automtica estos parmetros se fijan durante el proceso de binding.

5.3.3 Transmisin del ASDUTras crear la estructura correcta de envio y que todos los parmetros sean fijados como se requiere, la aplicacin puede transferir el ASDU a la capa APS para ejecutar la trasmisin por el aire usando la funcin APS_DataReq(). La figura 5.7 ilustra el diagrama de secuencia en el nodo fuente durante la transmisin

Si es la primera vez que la aplicacin enva datos entonces APS_DataReq() automticamente realizara una peticin de enrutado y encontrar el camino directo al destino deseado. Es ms, en todo momento la ruta se mantiene actualizada teniendo en cuenta los posibles cambios en la topologa de la red y en la calidad de los enlaces radio. La aplicacin puede fijar un mximo nmero de saltos permitidos para la trasmisin de datos ( y por lo tanto una latencia mxima) fijando el correspondiente campo de radio en la peticin de trasmisin (APS_DataReq_t). (Pag 30) Como el protocolo Zigbee permite una comunicacin bidireccional, la aplicacin puede solicitar un reconocimiento de la recepcin de la trama en el nivel de aplicacin (APS ACK) fijando acknowledgedTransmission en el campo txOption del la solicitud de envio a 1. En este caso a la aplicacin se la notifica el xito de la entrega de la trama (APS_SUCCESS_STATUS) mediante la funcin callback de confirmacin que se registr, solo si despues de que el ACK de la trama correspondiente haya sido recibido. Si durante el intervalo CS_ACK_TIMEOUT no se recibe ACK entonces se emite la funcin callback con APS_NO_ACK_STATUS. Las transmisiones sin APS ACK's tienen una mayor tasa de envo pero no son seguras, puesto que no se puede confirmar el envo de una trama. En estos casos si todos los parmetros se fijan correctamente, se llama a la callback con APS_SUCCESS_STATUS tras la emisin de la trama por el medio fsico (aire). La instancia de APS_DataReq_t solo puede ser reutilizada tras la confirmacin de que la callback a sido ejecutada.

5.3.3.1 Transmisiones Broadcast

Adems de trasmisiones nodo a nodo, las aplicaciones pueden enviar datos en modo broadcast donde las tramas de datos son enviadas con destino a todos los nodos de la red o a nodos con caractersticas especificas. Los siguientes enumerados se pueden usar en la aplicacin BitCloud como direccin destino para un mensaje de broadcast: todos los nodos de la red: BROADCAS_ADR_ALL (o 0xFFFF) todos los nodos con el parmetro rxOnWhenIdle igual a 1: BROADCAST_ADDR_RX_ON_WHE_IDLE (o 0xFFFD) todos los nodos router: BROADCAS_ADDR_ROUTERS (o 0xFFFC)

Las tramas broadcas no pueden ser confirmadas y se deben trasmitir con acknowledgedTransmission en el campo txOptions de la solicitud de envo fijado a 0 A nivel de red, el procedimiento broadcast se ejecuta de la siguiente manera: despus de llamar a APS_DataReq(), el dispositivo enva la trama tres veces. Cada nodo, tras recibir una copia de la trama (las dems son ignoradas) decrementa el radio de trasmisin en uno y si es mayor que cero reenva la trama otras tres veces a sus vecinos. Este procedimiento se repite en los dems nodos hasta que el radio de trasmisin llega a cero. Adems de difundir la trama sobre la red, la aplicacin puede configurar la transmisin de modo que la trama sea entregada a todos los puntos finales registrados en los nodos destino. Esto se puede realizar fijando el campo dstEndpoint en la solicitud de envo a APS_BROADCAS_ENDPOINT ( 0xFF). Esta difusin a nivel de nodo tambin se puede ejecutar mediante transmisiones punto a punto. Al igual que las tramas unicast, el mensaje broadcast puede ser enviado con un limite de saltos ( configurando el campo radio). Si el radio es fijado a 0 el mensaje llegar a todos los nodos de la red.

5.3.4 Recepcin del ASDUComo se indic en el pargrafo 5.3.1 para permitir el intercambio de informacin en el nivl de aplicacin, todo nodo receptor deber registrar al menos un punto final con la indicacin de una funcin de callback para el procedimiento de recepcin de datos. Tras la recepcin de una trama por el nodo, la pila verifica si el destino indicado en la cabecera de la trama coincide con los distintos puntos finales registrados en el nodo. En caso de coincidencia, la correspondiente callback, especificada en el campo APS_DataInd de la solicitud de registro de un punto final (APS_RegisterEndpointReq_t), se ejecutar con un argumento de tipo APS_DataInd_t. Este argumento contiene el mensaje de la aplicacin (el campo ASDU) as como informacin sobre las direcciones fuente y destino, punto final, perfil, etc. (Pag 31)5.3.4.1 Escrutinio del nodo final

En las redes Zigbee se usa un mecanismo de escrutinio (polling) para entregar los datos a los dispositivos finales. La figura 5.8 muestra el principio general del mecanismo pollig

Una vez se ha recibido una trama destinada a un nodo hijo o una trama broadcast con el radio de transmisin por encima de cero y con la direccin de destino igual a 0XFFFF, el nodo padre almacena la trama y espera a una solicitud del hijo. Cuando el nodo final despierta, pregunta a su nodo padre cada CS_INDIRECT_POLL_RATE milisegundos. Adviertase que este escrutinio es realizado en la capa de red y es transparente a la aplicacin. Despus de recibir una solicitud de informacin desde un nodo final, el nodo padre debe transmitir una nica trama e indicar si hay ms tramas para transmitir o no.

5.4 Gestin de energaEn las redes Zigbee, el nivel de consumo de energa es habitualmente una de las pricipales preocupaciones porque en muchas aplicaciones no todos los dispositivos pueden ser alimentados de red general. La pila BitCloud proporciona una API que permite cambiar entre modos despierto y dormido as como apagar el chip de radio para reducr el consumo de energa. Siguiendo el estandar ZigBee, PRO BitCloud mantiene mecanismos de gestin de la energa en nodos finales nicamente. Para evitar consecuencias en la estabilidad de la red, los nodos routers y coordinadores deberan siempre permanecer en modo activo. (Pag 32)

5.4.1 Modos activo y suspendido para dispositivos finalesIndependientemente de su status en red ( unido a una red o no) un dispositivo final puede estar en modo activo o modo suspendido. Tras ser alimentado, un nodo siempre comienza en modo activo y tiene su MCU alimentado y activo, con el chip RF listo para realizar operaciones Rx/Tx. La aplicacin puede llamar a cualquier procedimiento BitCloud y puede ejecutar callbacks y recibir notificaciones. En modo suspendido, el chip RF se apaga mientras que el MCU es puesto en un modo especial de bajo consumo. La aplicacin no podr realizar ningun tipo operacin radio, ni comunicar con

perifricos externos. Para poner los dispositivos finales a dormir, la aplicacin debe llamar a ZDO_SleepReq() con un argumento de tipo ZDO_SleepReq_t. Tras la confirmacin, la callback indicara el estado de ejecucin y si se devuelve ZDO_SUCCESS_STATUS el nodo entrara en modo suspendido. Hay dos formas de levantar el nodo: una planificada y otra a travs de una interrupcin IRQ De manera planificada, el nodo se levantar tras un intervalo de tiempo en milisegundos especificado por CS_END_DEVICE_SLEEP_PERIOD. A la aplicacin se la notifica que el nodo se va a levantar a travs de la funcin ZDO_WakeUpInd.CS_END_DEVICE_SLEEP_PERIOD no deber ser modificado en tiempo de ejecucin. La figura 5.9 muestra el diagrama de secuencia de llamadas de la pila para los procedimientos de dormir y levantar de forma planificada el nodo.

En el proceso de levantamiento por la llegada de una interrupcin IRQ el MCU se activa tras recibir el evento IRQ registrado. Sin embargo debido a que la notificacin de este evento debe ser lanzada directamente por el componente HAL, la pila de red no es consciente de ello. Por lo tanto para traer toda la pila de vuelta a un estado operativo la aplicacin deber llamar a la funcin ZDO_WakeUpReq. Despues de que la callback registrada para esta solicitud devuelva ZDO_SUCESS_STATUS, la pila, el chip RF y el MCU estan completamente activos. Adviertase que si se llama a IRQ_callback desde un estado de inactividad y el timer que controla el tiempo de inactividad esta fijado deacuerdo a CS_END_DEVICE_SLEEP_PERIOD, este se parar y comenzara de nuevo a la siguiente llamada a ZDO_SleepReq() (Pag 33) Ambos mtodos pueden combinarse en una aplicacin para gestionar el consumo de energa. Si CS_END_DEVICE_SLEEP_PERIOD se fija a cero, solo una interrupcin hardware puede levantar el nodo de un estado suspendido a su estado activo.

5.4.2 Apagar el chip RFEn muchos escenarios se puede requerir que el MCU permanezca operando (p.e. para proposistos de procesado de datos ) mientras que el chip de RF se apaga para reducir el consumo de energa. Este caso es contemplado por la pila BitCloud, posibilitando el apagado del mecanismo de polling en un dispositivo final y por lo tanto el del chip RF. Para apagar la radio, la aplicacin deber llamar a la funcin ZDO_StopSyncReq(). Para encenderla de nuevo (y permitir el polling) la aplicacin deber llamar a ZDO_StartSyncReq(). Cuando se use este mecanismo sera importante tener en cuenta que el nodo padre espera solicitudes de polling de su nodo hijo, y que si no las recibiera durante un cierto periodo de tiempo, eliminar el nodo de la red. Tengase en cuenta que este mecanismo nicamente est disponible en nodos finales.

5.5 SeguridadBitCloud proporciona dos niveles de seguridad en la red ZigBee; sin seguridad, y nivel de seguridad standard. Por lo tanto existen dos tipos de librerias localizadas en el directorio lib/: una sin seguridad y otra que incluye soporte a seguridad. La eleccin de una librera en particular se debe realizar en el fichero Makefile cuando se compila la aplicacin. En el ejemplo de aplicacin de BitCloud, esta eleccin se realiza basandose en los valores del parmetro SECURITY_MODE. Si se requiere soporte a seguridad, ademas de incluir las libreras adecuadas, los parmetros CS_ZDO_SECURITY_STATUS y CS_NETWORK_KEY deben ser configurados para permitir la adecuada operacin de la red. CS_ZDO_SECURITY_STATUS=0. Todos los dispositivos en la red deben tener preconfigurado el mismo parmetro CS_NETWORK_KEY en el Makefile CS_ZDO_SECURITY_STATUS=3. Uno de los dispositivos de la red (por lo general el coordinador) debe ser configurado como Centro de Confiabilidad (Trust center), y tener

CS_NETWORK_KEY definido en el Makefile. En todos los dems nodos en la red se debe fijar CS_APS_TRUST_CENTER_ADDRESS para que sean capaz de establecer conexin con el Trust Center, pero no deben tener CS_NETWORK_KEY definido. Adviertase que activar la opcin de seguridad incrementa el tamao de la memoria de programa. Y por lo tanto en muchas aplicaciones la memoria de programa puede agrandarse hasta no ser capaz de entrar en la memoria disponible. En estos casos, se puede decrementar parmetros tales como CS_NEIB_TABLE_SIZE, CS_ROUTE_TABLE_SIZE, CS_MAX_CHILDREN_AMOUNT y otros parmetros que tienen impacto en la asignacin de memoria tal y como se describe en la seccin 6.

6. CONTROL DEL HARDWARE ADICIONALAdems de la funcionalidad de red descrita en la seccin 5, el API de BitCloud proporciona un extenso soporte a las interfaces mas comunes de HW tales como USART, TWI, SPI, ADC, GPIO, IRQ, etc. La Capa de Abstraccin Hardware (HAL) de BitCloud es la responsable de interactuar entre los mdulos Atmel y los perifricos externos. Este captulo arroja un poco de luz sobre las principales interfaces HW soportadas en BitCloud.

6.1 Bus USARTLa pila BitCloud proporciona un API para soporte de la interface serie Univerval Synchronous /Asynchronous Receiver/Transmitter (USART). Para permitir la comunicacin mediante interfaz USART la aplicacin primero debe configurar el correspondiente puerto USART usando una variable global esttica de tipo HAL_UsartDescriptor_t. Se requiere fijar todos los parmetros USART ms comunes tales como modo sincrono/asincrono, baudrate, flow control, modo de paridad, etc. Adviertase que a pesar de que el nombre USART es generalmente usado en este capitulo para hacer referencia al API. es lo mismo que para las interfaces asincronas o sincronas (UART / USRT). Para modo de operacin asincrono, el descriptor debe ser fijado a USART_MODE_ASYNC. La recepcin y transmisin de datos a travs de la USART se puede configurar para trabajar tanto en modo callback o en modo polling como se describe ms abajo. Los ajustes de la USART se deben realizar usando la funcin HAL_OpenUsart() con un argumento apuntando una la variable global de tipo HAL_UsartDescriptor_t con la configuracin deseada del puerto. El valor devuelto indica si el puerto se ha sido abierto de manera satisfactoria y puede ser usado para el intercambio de datos. Cuando no haya necesidad de mantener activo el puerto USART, la aplicacin deber cerrarlo usando la funcin HAL_CloseUsart().

6.1.1

Modo callback de la USART

El siguiente fragmento de cdigo muestra como configurar el puerto USART para que tanto las operaciones Tx y Rx sean ejecutadas en modo callback.HAL_UsartDescriptor_t appUsartDescriptor; static uint8_t usartRxBuffer[100]; // any size maybe present appUsartDescriptor.rxBuffer = usartRxBuffer; // enable Rx appUsartDescriptor.rxBufferLength = sizeof(usartRxBuffer); appUsartDescriptor.txBuffer = NULL; // use callback mode appUsartDescriptor.txBufferLength = 0; appUsartDescriptor.rxCallback = rxCallback; appUsartDescriptor.txCallback = txCallback; HAL_OpenUsart(&appUsartDescriptor);

La siguiente figura 6.1 ilustra el correspondiente diagrama de secuencia para el uso de la USART en modo callback

Para la transmisin de datos se debe llamar a la funcin HAL_WriteUsart() con un puntero hacia el buffer de datos a ser transmitido y con la longitud del buffer como argumentos. Si se devuelve un valor mayor de cero, la funcin registrada como txCallback en el descriptor de la USART se ejecutar despues de notificar a la aplicacin que la transmisin ha finalizado. La USART es capaz de recibir datos si los campos rxBuffer y rxBufferLength del correspondiente descriptor de la USART no son NULL y cero respectivamente. Para el modo callback el campo rxCallback deber apuntar a la funcin que se ejecutar siempre que llegen datos al rxBuffer de la USAR con el nmero de bytes recibidos como argumento. Conocido este nmero, la aplicacin debe reenviar los datos recibidos desde el rxBuffer de la USART hacia el buffer de la aplicacin usando la funcin HAL_ReadUsart() 6.1.2 USART en modo polling En el modo polling las operaciones Tx/Rx de la USART utilizan los correspondientes buffers cclicos fijados por el descriptor USART. As tanto el punter del buffer como la longitud de este deben ser fijados a un valor distinto de cero para su uso en modo polling, mientras que las correspondiente funcin de callback se fijar a NULL. La figura 6.2 ilustra el diagrama de secuencia para Tx7Rx en modo polling. La principal diferencia en la operacin Tx entre los modos callback y polling reside en que en esta ltima tras la llamada a HAL_WriteUsart() todos los datos utiizados en la transmisin como argumento, son movidos cclicamente del txBuffer al descriptor de la USART. Y por lo tanto la aplicacin puede reusar la memoria ocupada por los datos. La funcin HAL_IsTxEmpty() se usa para verificar tanto que hay suficiente espacio en el txBuffer como para verificar cuantos bytes han sido realmente transferidos. En contraste con el modo callback, a la aplicacin no se la notifica el evento de recepcin de datos. Sin embargo, de la misma forma que en el mtodo callback, los datos recibidos son guardados

automaticamente en el rxBuffer cclico y la aplicacin puede obtenerlos usando la funcin HAL_ReadUsart(). En el caso del overflow de los txBuffer o rxBuffer, el resto de los datos se pierde. Para evitar la prdida de datos, la aplicacin deber controla el nmero de bytes escritos que devuelve HAL_WriteUsart() y si es posible usar HW flow control.

6.1.2Gestin de las seales de control de flujo ( CTS/RTS/DTR ) Adems de las operaciones de lectura/escritura de datos, BitCloud proporciona una API para el manejo de las seales CTS/RTS/DTR del puerto serie que soporte control de flujo HW (depende de plataformas). Mirar la documentacin de la API para una descripcin detallada de las correspondientes funciones. 6.2Interface del Bus serie Two-wire 6.2.1 Definicin del Bus serie Two-wire La interface serie Two-wire (TWI) es compatible con el protocolo de Philips I2C. El bus TWI es ideal para aplicaciones tpicas de microcontrolador. El protocolo TWI permite a los diseadores del sistema conectar hasta 128 dispositivos diferentes usando nicamente dos lneas de bus bidireccionales, una para el reloj (SCL) y otra para datos (SDA), el nico dispositivo hardware externo que se necesita para implementar el bus es una resistencia pull-up por cada lnea del bus TWI. Todo dispositivo conectado al bus tiene su direccin y los mecanismos para resolver la problemtica del bus es inherente al protocolo TWI. 6.2.2 Terminologa TWI Las siguientes definiciones son frecuentemente usadas en esta seccin 6.2.3 Transferencia de datos y formato de trama 6.2.3.1 Transmitiendo Bits. Cada Bit transmitido por un bus TWI es acompaado por un pulso de la seal de reloj. As pues el nivel de tensin de la lnea de datos debe permanecer estable mientas la seal de reloj este alta. La nica excepcin a esta regla es la generacin de las condiciones de inicio y parada de transmisin.

6.2.3.2 Condiciones de inicio y parada de transmisin El Master inicia y termina cada transmisin de datos. La transmisin se inicia cuando el master lanza la condicin START en el bus, y termina cuando lanza la condicin de STOP. Entre estas dos condiciones, se considera que el bus est ocupado, y ningn otro master debera intentar apoderarse del bus. Un caso especial ocurre cuando se lanza una nueva seal de START entre dos condiciones de START y STOP. A esto se le llama REPEATED START, y se usa cuando el master desea iniciar una nueva transferencia sin renunciar al control del bus. Tras un REPEATED START, el bus se considera ocupado hasta la siguiente seal de STOP. Esto es idntico al comportamiento de la seal START, y por lo tanto START se usar de aqu en adelante para describir tanto START como REPEATED START a no ser que se indique otra cosa. Como se representa en la siguiente figura. Las condiciones de START y STOP se indican con un cambio en el nivel de SDA cuando la seal de SCL est en alto. 6.2.3.3 Formato del paquete de direccin. Todos los paquetes direccin transmitidos por el bus TWI son de 9 bits de longitud, y consisten en 7 bits de direccin, un bit de control READ/WRITE, y el bit ACK. Si el bit READ/WRITE est alto, indica operacin de lectura, en otro caso se ejecutar una operacin de escritura. Cuando el esclavo reconoce que est siendo direccionado, deber realizar el reconocimiento, poniendo un nivel bajo el la lnea SDA en el noveno ciclo de SCL (el ACK). Si la esclavo direccionado estuviera ocupado, o por alguna otra razn no puede responder a la solicitud del master, la lnea SDA debe permanecer alta en el ciclo de reloj de ACK. El Master puede entonces transmitir la condicin de STOP o la de REPEATED START para iniciar una nueva transmisin. Un paquete de direccin consistente en la direccin del esclavo mas el bit READ/WRITE se denomina SLA+R o SLA+W respectivamente. El MSB del byte de direccin es el que primero se transmite. Las direccines de los esclavos se pueden fijar libremente, pero la direccin 0000 0000 se reserva para broadcast. Cuando se lanza un broadcast, todos los esclavos deben responder poniendo a nivel bajo la seal SDA en el ciclo ACK. El broadcast se usa cuando el Master desea transmitir el mismo mensaje a varios de los esclavos del sistema. Tengase en cuenta que realizar un broadcast seguido de un bit Read carece de significado y podra causar problemas si varios esclavos comienzan a trasmitir diferentes datos. Toda direccin con el formato 1111 xxxx se reserva para futuros propsitos. 6.2.3.4 Formato del paquete de datos Todos los paquetes de datos transmitidos por el bus TWI son de 9 bits de longitud, y consisten en un byte de datos y un bit ACK, durante la transmisin de datos, el Master controla la lnea de reloj y las condiciones START y STOP, mientras que el receptor es responsable de la generacin del ACK. Como se dijo con anterioridad, el ACK se genera poniendo a nivel bajo la seal ACK en el noveno ciclo de reloj SCL Si el receptor deja la lnea SDA en alto, se genera NACK. Cuando al receptor le llega el ltimo byte, o por alguna razn no

puede recibir ms bytes, deber informar al transmisor enviando un NACK tras el ltimo byte. 6.2.3.5 Combinado paquetes de direccin y datos en una transmisin Una transmisin consiste bsicamente en una seal de START, un SLA+R/W, uno o ms paquetes de datos y una seal de STOP. Un mensaje vacio consistente en una secuencia de START + STOP est prohibida. Adviertase que la lnea SCL se usa para implementar la gestin del bus entre el Master y el Esclavo. El esclavo puede prolongar el tiempo que SCL permanece bajo. Esto es til si la velocidad del reloj marcada por el Master es demasiado rpida para el esclavo, o si el esclavo necesita ms tiempo para procesar la transmisin de datos. El tiempo que el esclavo mantiene bajo la lnea SCL no afecta al tiempo que SCL permanece alto, tiempo controlado por el Master. Como consecuencia, el esclavo puede reducir la tasa de transferencia prolongando el duty cycle de SCL. La figura 6.9 muestra una tpica transmisin de datos. Adviertase que se pueden transmitir ms de un byte de datos entre SLA+R/W y la seal de STOP, dependiendo del protocolo software implementado por la aplicacin La aplicacin BitCloud solo puede desempear la funcionalidad del Master TWI. Al igual que en otros interfaces HW, el interfaz TWI debe ser primero configurado y activado para la comunicacin. Tras esto, se puede ejecutar los procedimientos de lectura/escritura con un dispositivo TWI esclavo. Como se muestra en la anterior figura , las operaciones de lectura/escritura en bus TWI se ejecutan de forma asncrona, Tras la llamada a HAL_WriteI2cPacket() o HAL_ReadI2cPacket() la aplicacin no podr ejecutar ninguna accin con el bus TWI as como con la memoria asignada al argumento de tipo HAL_i2cParams_t hasta que la funcin callback vuelva. 6.3Bus SPI Dependiendo de la plataforma MCU, el componente HAL de la pila BitCloud puede implementar el protocolo SPI sobre el bus USART (plataformas AVR) o un bus SPI autntico cuando ste este disponible. Sin embargo las correspondientes llamadas a la API definida en el fichero spi.h son independientes de la plataforma subyacente y la nica diferencia aparece en la configuracin SPI, ms concretamente en los campos de la variable esttica de tipo HAL_SpiDescriptor_t. La aplicacin Bitcloud soporta nicamente el modo Master SPI. En la figura 6.11 se muestra un diagrama de secuencia del las llamadas a la API relacionadas con el bus SPI. El mecanismo comn en otras interfaces HW tambin se aplica en el bus SPI. Lo primero que se debe hacer es configurar y abrir con xito el puerto ( ejecutando HAL_OpenSpi() con argumento apuntando a la variable de tipo HAL_spiDescriptor_t y la funcin callback). Tras esto se puede proceder al intercambio de datos usando la funcin

asncrona HAL_WriteSpi(). Para el intercambio de datos sncrono entre dispositivos maestro y esclavo se debe usar la funcin HAL_ReadSpi. Si la funcin de callback no se fijo a NULL, la aplicacin sale de la funcin cuando HAL_WriteSpi() o HAL_ReadSpi() se llama y tras esto la funcin de calback informa a la aplicacin de que la transaccin SPI a terminado. Si el argumento de la callback en HAL_OpenSpi() fue NULL, la transaccin SPI se realizar mientras dura la llamada a la funcin de lectura/escritura. Por ltimo, si no se espera ms intercambio de datos, el bus SPI se debe cerrar para liberar los recursos ocupados. 6.4 Interface GPIO Bitcloud provee de un amplio set de comandos para la gestin de entradas y salidas, tanto I/O standard como de aquellos pines que se reservan para otras interfaces pereo que pueden ser usados tambin como I/O standard. Las nombres de las funciones y macros relacionadas con las GPIO se definen en el fichero gpio.h del componente HAL_HWD. Las llamadas a funcin tienen la forma GPIO_#pin_name#_#function_name#(). 6.5 ADC Bitcloud provee de una API independiente de la plataforma para el convertidor analgico-digital. Como en otras interfaces, el ADC se debe configurar primero antes de ser usado mediante la funcin HAL_OpenAdc() pasando un puntero a una variable global HAL_AdcParams_t que contenga los parmetros de configuracin. Dicha funcin devuelve el status del ADC indicando si la operacin de apertura se ha realizado correctamente. La operacin puede fallar debido a alguna de las siguientes razones: El puerto ADC se se abri El argumento de la funcin es NULL La resolucin es mayor de RESOLUTION_10_BIT Se le pasa un valor incorrecto para el voltaje de referencia (param->voltageReference) Se usan RESOLUTIO_10_BIT para frecuencias de muestreo mayores a 9600

Despues de inicializar el ADC con xito, la lectura del canal que se desee muestrear se puede realizar usando la funcin HAL_ReadAdc(). El resultado se devuelve mediante una funcin callback a un buffer especificado como registro en la funcin HAL_OpenAdc(). Para cerrar el interface ADC se debe usar la funcin HAL_CloseAdc()

6.6

Otras funcionalidades del HAL.

El componente HAL de la pila BitCloud tambin provee soporte a las siguientes interfaces: 1-Wire IRQ Aplicaciones timer, tiempo del sistema Watchdog

La documentacin de la pila contiene la informacin sobre las funciones API que se deben usar para la gestin de las interfaces mencionadas. A pesar de estar disponibles en el componente HAL, las siguientes funciones son nicamente usadas para su ejecucin interna dentro de la pila por lo que las aplicaciones de usuario deben evitar en la medida de lo posible su uso: HAL_ReadEeprom/HAL_WriteEeprom Sleep Timer 7 MEMORIA Y ASIGNACIN DE RECURSOS. 7.1 RAM La memoria RAM es un recurso usado por la Pila para almacenar parmetros runtime, tales como tablas de vecinos, tablas de enrutado, tablas de hijos, etc. A peticin de la pila, algunos valores de ciertos parmetros almacenados en la EEPROM son almacenados frecuentemente en la RAM para facilitar su posterior recuperacin. La pila de llamadas reside tambin en la RAM y es compartida tanto por el SO BitCloud como por la aplicacin usuario. Para conservar la RAM, el usuario debe abstenerse del uso de funciones recursivas, funciones que tomen muchos parmetros, funciones que declaren extensas variables y/o arrays locales, o funciones que pasen extensos parmetros a la pila. Regla del sistema 8: No se debe pasar ninguna estructura a la pila, como por ejemplo el paso de estructuras como argumentos de funciones. Pasa un puntero en su lugar que apunte a esta. Regla del sistema 9: Se deben usar variables globales en vez de variables locales, siempre y

cuando sea posible. El uso de callbacks definidos por el usuario aseguran que las estructuras se pasen mediante puntero. El usuario debe verificar que esto tambin se cumbple en las funciones locales que este defina. Regla del sistema10: La aplicacin de usuario no debe utilizar funciones recursivas. Es recomendable que la mxima profundidd de llamadas invocadas por el usuario no sobrepase el nmero de 10, teniendo cada funcin no ms de 2 parmetros como argumento cada una. En su conjunto, la demanda de RAM por la pila se debe consensuar con la demanda de la aplicacin de usuario. Afortunadamente, el consumo total de RAM usada para mantenimiento de datos de la pila es un parmetro de usuario configurable. El ConfigServer (o CS) se distribulle con el cdigo fuente, para permitir al usuario afinar los parmetros runtime de la pila. Mediante estos parmetros se puede manejal el tamao total de los datos que la pila almacena en la RAM para tablas. La siguiente lista muestra estos parmetros y proporciona una frmula simple para calcular el consumo de RAM basado en el valor del parmetro.

(1): Varios buffers (CS_NWK_ROUTE_DISCOVERY_OBJ_SIZE y CS_JOIN_IND_OBJ_AMOUNT) pueden depender de CS_NWK_DATA_IND_BUFFER_SIZE. En el peor de los caso se deben sumar 51*p bytes que sern asignados pro cada entrada. Las condiciones exactas se pueden obtener de los ficheros configServer.h y configServer.c La suma total de RAM consumida por la pila se puede calcular sumando la ltima columna a