Blog

The Twelve Of B105: Augmented Reality

mar18

Ha pasado un mes más, y con él llega otra entrega más de…

theTwelveOfB105

… en la que aprovecharemos para ahondar en otra temática de actualidad: la realidad aumentada.

Esta tecnología y relacionadas (conocidas como RX – realidad virtual, mixta, aumentada –) se introducen discretamente en nuestro día a día, impulsadas por gigantes de la talla de Microsoft, Google, Intel o Apple. Sólo echando una ojeada en las webs de Intel o Qualcomm podemos observar algunos de los últimos avances en el sector, los cuales probablemente disfrutemos con nuestro próximo smartphone, consola, etc.

Chicago-Bean-AR

El continuo desarrollo de dichas tecnologías RX nos deja en herencia dispositivos muy versátiles, algunos de los cuales ya está aprovechando nuestro grupo. En esta línea, el proyecto LAZARO utiliza Google Tango para la detección y caracterización de barreras arquitectónicas en edificios. Con la aplicación desarrollada, y un smartphone compatible, un operario podría realizar de forma sencilla e intuitiva medidas clave de las instalaciones, y caracterizar así el grado de accesibilidad para personas con movilidad reducida.

A día de hoy, seguimos valorando aplicar este y otros tantos avances de este campo en nuestra labor. Para saber más sobre nuestro trabajo, tanto en esta línea como en otras tantas descritas en números pasados, recordad que podéis visitarnos en las redes sociales, o contactar con nosotros directamente. ¡Os esperamos!

STM32F4: Consideraciones para el uso de la memoria flash (Parte I)

nandflash

Siguiendo la serie de tutoriales y guías sobre el uso de la placa de desarrollo STM32F411-DISCOVERY, hoy hablaremos de la escritura, lectura y manejo de la memoria flash del microcontrolador (MCU). Como ya sabréis, el STM32F411VET6 cuenta con 128 Kbytes de memoria SRAM y 512 Kbytes de flash. La principal diferencia entre estos dos tipos de memoria es que la flash, al contrario que la SRAM, es no volátil, es decir, no pierde la información que almacena al desactivar la alimentación.  Esta característica hace que, en general:

  • La memoria SRAM se destine para el almacenamiento y manipulación de datos parciales, variables locales, cambios de contexto, etc.
  • La memoria flash se utilice parte para la memoria de programa, donde se almacena el código del programa a ejecutar por el procesador, y parte para el almacenamiento de datos de configuración o de los procesos que se controlan y se quieren conservar tras una desactivación temporal del sistema.

En este artículo nos centraremos en este último tipo de memoria, aportando algunas claves importantes para su uso, así como una serie de consideraciones y buenas prácticas a tener en cuenta para evitarnos algunos problemas frecuentes.

Lo primero que es importante tener claro es cómo se organiza la memoria flash de nuestro microcontrolador. Esto suele variar bastante de unos a otros. En general, la memoria se divide en bloques o bancos, que a su vez se pueden subdividir en sectores. La siguiente unidad de división de la memoria serían las páginas y, por último, las palabras, que se componen de un determinado número de bytes. En general, la palabra suele ser la unidad mínima de lectura/escritura en flash aunque, en algunos casos, es posible hacerlo a nivel de byte, y en otros se opera en double-word, es decir, de dos en dos palabras simultáneamente.

Para saber la organización en particular de un microcontrolador, lo mejor es acudir al manual de referencia del mismo. A continuación, podéis consultar tres ejemplos distintos del propio STMicroelectronics, para que podáis comprobar de primera mano cómo en cada uno la organización es de una forma distinta:

Este último ejemplo, el STM32F411VE, se corresponde con el MCU de nuestra placa Discovery, y será el caso concreto que utilizaremos en este artículo. En la siguiente imagen se muestra la información principal de nuestra memoria.

flashMemory
Figura 1. Captura de la sección “Embedded Flash memory in STM32F411xC/E”

En la tabla anterior podemos observar que los 512 Kbytes de memoria flash que tiene el MCU según se especifica en sus características, son en realidad un gran bloque llamado Main memory.  A parte, vemos que existen otros tres bloques reservados para usos específicos y que, por lo tanto, no contabilizan como memoria flash.

Lo primero que debemos decidir es qué parte de la memoria principal queremos reservarnos para nuestra disposición. En este caso, utilizaremos el Sector 7, al que nos referiremos como USER_FLASH. Una vez tenemos esto claro, es muy importante asegurarnos de que ese sector no se va a utilizar para nada más, de modo que ni nosotros machaquemos información de otra utilidad, ni otra utilidad sobrescriba nuestra información. Para garantizar esto, es necesario editar el linker script de nuestro proyecto, que ha sido generado automáticamente por CubeMX, y se encuentra en la ruta:

Este fichero es el encargado de dar las instrucciones al linker del uso y tamaño de cada área de memoria y, por lo tanto, debe editarse con sumo cuidado. Se escapa del alcance de esta publicación explicarlo en detalle, por lo que únicamente daremos las indicaciones básicas de las modificaciones necesarias. Para profundizar en su comprensión, os dejamos algo de documentación.

En primer lugar, en la sección MEMORY del fichero STM32F411VETx_FLASH.ld, que es donde se especifican las áreas de memoria, debemos reducir FLASH en los 128 Kbytes correspondientes al Sector 7, y añadir USER_FLASH indicando sus permisos, dirección de origen y tamaño. Con ello, esta sección pasa de esta configuración:

A esta otra:

En segundo lugar, hay que editar el apartado SECTIONS del mismo fichero, que es donde se definen las distintas secciones de memoria, ya sean para guardar código o datos. En concreto, vamos crear una nueva para guardar nuestros datos no volátiles en el área de memoria USER_FLASH. De este modo, desde nuestro código de programa, podremos declararnos variables de cualquier tipo que se almacenen en dicha sección y, por lo tanto, sean no volátiles. Para ello, al principio de este apartado, antes de la sección .isr_vector, añadimos el siguiente código:

Con estos pasos, ya tendríamos nuestra área de memoria flash delimitada de una manera segura y preparada para utilizarse desde nuestro código.

Para probar que todo está correctamente, vamos a proceder a leer y escribir un dato en memoria flash. Para ello, partiremos del proyecto desarrollado en el tutorial previo STM32F4: Interrupción externa. En concreto, lo que haremos es aprovechar la interrupción producida al pulsar el botón de usuario para conmutar la frecuencia de parpadeo del LED verde entre dos valores, que definiremos en main.c dentro de USER CODE BEGIN Includes.

Sin embargo, lo que haremos es guardar la variable que contiene el valor del delay que se esté utilizando en cada instante en la memoria flash. De este modo, en cualquier momento el sistema puede apagarse o resetearse y, al volver a funcionar, mantiene la última frecuencia de conmutación que tuvo operativa. Para ello, en main.c, dentro de USER CODE BEGIN PV, nos declaramos la variable globar current_delay del siguiente modo:

Lo más llamativo de esta declaración es el atributo:

Esta parte es justo la que le indica al linker que la variable current_delay de tipo uint32_t debe guardarse en la sección .user_data_flash, en vez de donde se guardan las variables por defecto. De este modo, el valor de la variable es no volátil. Hay que tener en cuenta que si bien esta variable se puede leer como cualquier otra, para escribir en ella, al tratarse de memoria flash, hay que seguir un procedimiento especial que comentaremos más adelante. Además, también hay que destacar que el atributo __section__ no se puede emplear para variables locales.

Por otra parte, si recordáis, en el tutorial de la interrupción externa se comentó que es recomendable minimizar el número de operaciones a realizar dentro del callback de la interrupción. Por ello, para este caso utilizaremos un flag que declararemos e inicializaremos en main.c, también dentro de USER CODE BEGIN PV, como:

Modificar el valor de este flag será lo único que haremos dentro del callback de la interrupción, que quedará del siguiente modo. Recordamos que este callback se encuentra en el fichero gpio.c.

Es importante destacar que para poder emplear la variable swap_flag en este otro fichero, hay que declararla en gpio.c, dentro de  USER CODE BEGIN 0, como extern.

Para este ejemplo, todo lo demás lo programamos dentro de la función main(). Queda en la mano del lector reorganizar este código en las funciones que considere oportunas para lograr un código de mayor calidad. Del mismo modo, queda pendiente el tratamiento de errores. Para el ejemplo, la función quedaría así:

Como asumimos ciertos conocimientos de programación por parte del lector, en este punto únicamente comentaremos ciertos aspectos relevantes:

  • Antes de escribir en memoria, hay que borrarla mediante la función HAL_FLASHEx_Erase(&EraseInitStruct, &PAGError), definida en el fichero stm32f4xx_hal_flash_ex.c. En la Sección 3.5.4 del Reference Manual RM0383 Rev 2 podéis encontrar más información al respecto.
  • La estructura EraseInitStruct se utiliza para configurar la operación de borrado de la memoria. En este caso, utilizamos siempre la misma configuración y por eso sólo se rellena una vez, pero esto no tiene por qué ser así. Podéis leer más sobre sus distintos campos en la cabecera de su definición, FLASH_EraseInitTypeDef, en el fichero stm32f4xx_hal_flash_ex.h.
  • Antes de realizar cualquier operación de borrado o escritura de la flash, es necesario desbloquearla con la función HAL_FLASH_Unlock(). Del mismo modo, al concluir dichas operaciones, hay que volver a bloquearla con la función HAL_FLASH_Lock().
  • Para escribir en memoria flash utilizamos la función HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, (uint32_t)&current_delay, (uint32_t)data), definida en el fichero stm32f4xx_hal_flash.c.
    • El primer argumento que le pasamos es una macro definida en stm32f4xx_hal_flash.h que indica que haremos una escritura de una palabra, es decir, un dato de 32 bits. En ese fichero podéis ver qué otras opciones permite este microcontrolador.
    • El segundo argumento que le pasamos es la dirección de la variable donde queremos guardar el dato.
    • El tercer argumento que le pasamos es el dato a guardar que, en este caso, debe coincidir con el tamaño de palabra.

Por último, para poder confirmar que la escritura se ha realizado correctamente, durante su ejecución en Debug, podemos monitorizar las distintas posiciones de memoria desde la pestaña Memory del entorno Eclipse. En este caso vemos como la variable current_delay se encuentra al principio de la sección .user_data_flash, en la dirección 0x0806 0000. 

memory
Figura 2. Herramienta de Eclipse para monitorizar la memoria del MCU.

Además, como esta memoria es no volátil, podría suceder, dependiendo de la configuración del Debugger, que al reprogramar el MCU no se borrase la flash de usuario. Para hacerlo manualmente, podemos usar la herramienta Erase chip del siguiente modo.

La herramienta Erase chip permite borrar toda la memoria del MCU por completo.
Figura 3. La herramienta Erase chip permite borrar toda la memoria del MCU por completo.

Hasta aquí la publicación de hoy. Esperemos que os haya parecido interesante y os animéis a profundizar en las distintas líneas que se quedan abiertas. En la siguiente parte, comentaremos más aspectos importantes a tener en cuenta al trabajar con la memoria flash, por ejemplo, el almacenamiento de múltiples datos en ella.

VIII Reunión del Foro de Interoperabilidad en Salud

foto

Los pasados 9 y 10 de Mayo tuvo lugar en A Coruña la VIII Reunión del Foro de Interoperabilidad en Salud organizado por la Sociedad Española de Informática de la Salud sobre el tema Interoperabilidad, Internet de las cosas y Salud Integrada en la que el B105 Electronic Systems Lab participó en la sesión Innovación e Investigación con la ponencia Retos y oportunidades de IoT en el campo de la salud bajo un punto de vista tecnológico.

En esta ponencia se pasa revista a las tecnologías que está desarrollando el Grupo de Investigación B105 Electronic Systems Lab de la Universidad Politécnica de Madrid en el campo de sistemas empotrados, radio cognitiva y nubes de sensores aplicados al campo de la salud.

En enfoque realizado se basa en dos pilares, la investigación, entendida como la inversión de dinero para obtener conocimiento y la innovación, entendida como la aplicación de ese conocimiento para obtener fondos con los que financiar la investigación. Esta estructura permite la definición de un círculo virtuoso en el que la investigación se financia en base a la innovación y la innovación utiliza el conocimiento de la investigación.

Las tecnologías tratadas son las siguientes:

  • Sensores, tanto directos (electrodos y sensores biométricos) como indirectos (temperatura, humedad y temperatura, inclinómetros y magnetómetros, acelerómetros, posición, etc.) en el campo de la innovación. Tanto en innovación como en investigación se pasa revista a la creación de sensores virtuales mediante la fusión de sensores reales con parámetros tales como espacio, tiempo, confianza, reputación, etc.
  • Medio de comunicación, se exponen algunas de las tecnologías en las que se está investigando, como redes neuronales inalámbricas y redes cuerpo humano versus redes aire.
  • Actuadores, principalmente mencionando los trabajos tanto en investigación como innovación en el campo de la estimulación nerviosa eléctrica transcutánea como interfaz electrotáctil y su posible aplicación al tacto remoto.

Finalmente, se pasa revista a un conjunto de aplicaciones de ejemplo desarrolladas bajo el modelo de innovación como un sistema de detección de fatiga de conductores mediante cámara, otro mediante monitorización del EEG con técnicas de machine learning, un detector de barreras arquitectónicas basado en realidad aumentada o una pulsera inteligente con su aplicación al móvil asociado para monitorizar las condiciones de vida de personas necesidades especiales.

Aprende Electrónica con la placa de desarrollo STM32F411-DISCOVERY

discovery

“Me lo contaron y lo olvidé; lo ví y lo entendí; lo hice y lo aprendí.”

Confucio

En el B105 tenemos la convicción de que la mejor manera para aprender algo es haciéndolo. Además, actualmente existen en el mercado multitud de placas de desarrollo muy económicas, por lo que ya no hay escusa para no ponerse manos a la obra. 

Por ello, arrancamos esta serie de publicaciones con el objetivo de guiar el aprendizaje del uso de sistemas empotrados. Para ello, hemos escogido la placa de desarrollo STM32F411-DISCOVERY de STMicroelectronics, que tiene un precio inferior a 15€ y el software necesario para desarrollar con ella es gratuito. Aun así, aunque el método variará, los conceptos o fundamentos que esperamos transmitiros con estas publicaciones son aplicables a cualquier plataforma basada en un microcontrolador.

Sin alargarnos mucho más, os dejamos una lista de tutoriales y ejemplos, que irá creciendo con el tiempo, en la que tendréis los enlaces a las distintas publicaciones de esta serie.

  1. STM32F4: Primeros pasos con el entorno de desarrollo
  2. STM32F4: Interrupción externa
  3. STM32F4: Configurar el PWM con timers
  4. STM32F4: Consideraciones para el uso de la memoria flash (Parte I) 

¡Suerte y ánimo!

The Twelve of B105: Wireless Neural Networks

apr'18

Un mes más aquí llega la entrega de …
theTwelveOfB105En este nuevo post hemos decidido introducir una temática que llevamos unos años tratando, la cual nos sirve a modo de introducción en el tema de la Bioingeniería. Comenzaremos abarcando aspectos relacionados con la actividad cerebral.

Hemos realizado un estudio en el que hemos tratado el diseño de técnicas para redes neuronales artificiales, y que también está basado en Redes de Sensores Inalámbricas. Dicho estudio tiene el objetivo de obtener, transmitir y generar señales neuronales como lo hace el cuerpo humano. Hay que ser especialmente cuidadoso con estas redes debido a que van a formar parte del cuerpo humano. Se debe prestar especial atención a la absorción de energía o al daño térmico que se puede generar debido al contacto constante entre el sensor y la piel. Por lo tanto, la potencia radiada debe estar limitada en este tipo de redes.

Se busca implementar un sistema no invasivo, en el cual se obtenga la información neuronal de la médula espinal, se procese localmente y se transmita un impulso al nodo receptor, colocado en una extremidad. Dicho nodo generaría un impulso eléctrico para la estimulación artificial del tejido nervioso. Esto permite que el cerebro se comunique con cualquier parte del cuerpo a pesar de los nervios disfuncionales. Un ejemplo aplicado en primates es el que puede verse en la imagen. El diseño del sistema tendrá en cuenta el bajo costo y el tamaño reducido, de cara a su implementación práctica sobre las personas.

primate

Básicamente, la neurona genera un potencial de acción o “pico” cada vez que propaga información. En este contexto, este estudio apunta a detectar un pico en la señal de una neurona y transmitir a otro nodo la existencia de esa señal. Una vez que el receptor recibe los datos, genera una estimulación eléctrica en otra parte del cuerpo humano.

Se puede separar este proyecto en tres partes diferenciadas:

  1. El módulo de adquisición para obtener la información neuronal, que debe tener una sensibilidad muy alta, ya que la señal obtenida en la superficie de la piel tiene una amplitud muy pequeña y gran cantidad de ruido.
  2. La transmisión del impulso está influenciada por la frecuencia, la distancia entre el transmisor y el receptor, la permitividad relativa de las capas del cuerpo humano o la línea de visión.
  3. La generación del impulso eléctrico depende de la forma de onda utilizada, del material de los electrodos o de la intensidad. En este punto, parámetros como la sincronización entre nodos son fundamentales para saber que el pulso que se ha recibido se corresponde con el impulso que se ha enviado.

Por lo tanto, la tesis propuesta supone un gran avance en el tratamiento de las lesiones de la médula espinal y en los sistemas neuronales no intrusivos en general.

En este link  os dejamos las temáticas de los meses anteriores. Podéis seguirnos a través de las redes sociales (@elb105) para conocer más sobre nosotros. Y todo lo que queráis saber no dudéis en consultarnos.

¡Os esperamos!

The Twelve of B105: Energy Efficiency

mar18

¿Ávidos por conocer más sobre nuestro trabajo? No esperéis más, aquí llega una nueva entrega de…

theTwelveOfB105En esta ocasión nos espera un nueva pero como siempre atractiva temática: IoT aplicado a la eficiencia energética. En este campo abordaremos dos de nuestros proyectos, RS y SONRISAS, gracias a los cuales hemos podido observar y poner nuestro grano de arena en el sector de la domótica.

En el primer proyecto, la red de sensores y actuadores permite optimizar el consumo energético del hogar, infiriendo a raíz de las medidas de temperatura, luminosidad, presencia, etc., parámetros de uso y confort de los ocupantes. El sistema se compone de dos nodos especializados, Prometheus y Boucherot, y para las comunicaciones emplea el protocolo SimpliciTi sobre bandas libres ISM.

Por otro lado, con SONRISAS abordamos la eficiencia energética como uno de los campos con potencial para impulsar el mercado de IoT. Los diseños de bombilla, enchufe y termostato inteligente desarrollados en esta ocasión, implementados en FreeRTOS sobre procesadores STM32Lx, permitirían realizar mediciones de consumo, ajustar la temperatura e iluminación, desconectar o alimentar dispositivos de forma remota, etc. Por otro lado el despliegue, con un sistema de comunicaciones interno a 868 MHz, ofrece un simple acceso vía WiFi e interfaces de usuario disponibles para las plataformas más usuales (ordenador, telefono móvil, etc.)

g3701

Antes de despedirnos, recordad que podéis consultar aquí otras temáticas abordadas en meses anteriores, e información de nuestro día a día a través de las redes sociales. Y por supuesto, si hay algo de vuestro interés, no dudéis en acercaros. ¡Os esperamos!

¡Nos vemos en breve!

A Modular-Reconfigurable Presentation System Design and Implementation Based on LEDs

1

This project “A modular-reconfigurable presentation system design and implementation based on LEDs” consists of a LED screen design and development at hardware and software level, features cited in the name of this project.

In order to approach its design, we have started making an art state investigation, through which some similar projects to this one have been looked into.

Next, we carried out a hardware design and implementation. During this stage two hardware versions were developed.

Then, the software design and development have taken place. A first software stage is executed by the PC and the other stage is executed by the microcontroller. During this phase of the project we have developed many block versions which made the software architecture up.

Later, different hardware and software level tests were performed.

Finally, some full system tests were also carried out.

The project has been developed in seven phases as shown as per below chart.

2

As said before, the presentation system is made up of a hardware and software structure. The hardware structure is constituted by some elements, from which It is emphasized the relevant LED screen and the development board that includes a microcontroller. The software structure has been coded at PC and within a microcontroller too. This main project aim has been to desing a modular system presentation and resettting based on LEDs.

The main objective is broken down into four purposes

  • Draw up a modular and reconfigurable LED screen.
  • Develop a microcontroller software to allow using the LED screen.
  • Develop a software by PC to display a photo on the LED screen.
  • Develop a software by PC to display a video on the LED screen.

It is relevant to clarify that every pixel of this screen is encoded by 24 bits. These bits are G7, G6, G5, G4, G3, G2, G1, G0, R7, R6, R5, R4, R3, R2, R1, R0, B7, B6, B5, B4, B3, B2, B1, B0 as shown as per below chart.

3

The hardware architecture is a set of physical blocks through which this system is based on. In the basis of the system outcome and the hardware requirement some hardware architecture blocks have been defined.  The hardware architecture that makes up the bits is described as per below.

  • PC: It executes processor-transmitter software blocks.
  • USB-serial converter: It Carries GRB bits forward to microcontroller.
  • Microcontroller: It executes receiver-presentation software blocks.
  • Logic level converter: It goes the amplitude up from the PWM to the microcontroller pins GPIO output, from 3.3 [V] to 5 [V].
  • LED screen: It is made up of LED modules. Each module has 25 LEDs. For LED modules manufacturing purposes some LEDs SMD 5050 have been chosen, these LEDs mix an integrated circuit enclosed in. This circuit incorporates a signal amplifier and depending on the manufacturer also a sequential logic block. This way, the signal is empowered through each LED and 24 bits data is addressed to, from which 8 bits are related to sub LED G, 8 are linked up  to sub LED R and 8 bits are connected to sub LED B. So that, color and bright are separately controlled for every LED.
  • Power supply: It is setup into a star topology. Supplies 23 [A] to the system.

By means of next chart, hadware arquitecture is shown as per below.

4

The LED screen is composed by four module rows of LEDs, each module row is assigned by a data line as per below.

5

For the LEDs screen, it has been decided to use several parallel data lines, due to it aims to overcome a LEDs handicap. This handicap consists of when broadcasting a 30 [frames/s] – streaming video. It does not allow to connect more than 1024 LEDs into serial architecture. Essentially because of timing  purposes. Which are exposed by means of this reasoning: If the rate to broadcast this video is 30 [frames/s], this indicates every 0.033 [s] a frame to display on LEDs is loaded. Tframe = 0.033 [s].

On the other hand, Tbit=1,25 [µs] which is a value forced by the LEDs.

As discussed earlier in this report, 24 bits are related to every single pixel, immediately after sending all bits towards the LEDs, a time must be saved for a 50 [µs] reset. This way, sending period expression, it is as it follows:
Tsend = ( 1.25 [µs/bit] x 24 [bits/pixel] x 1024 [pixels] ) + Treset = 0.03077[s]

Checking out on, Tsend < Tframe.

That is, this limitation resides in central premise that, sending time cannot be greater than frame time, whether more than 1024 LEDs are connected in cascade architecture, it is need a time greater than frame time, therefore it breaks that premise.

For the case in which the rate to broadcast this video is 60 [frames/s], could be linked into  cascade connecting factors up to 512 LEDs.

Therefore, there is an inversely proportional relationship between the video rate broadcast and the number of LEDs to be connected in cascade.

The software architecture is composed by two phases, one developed to PC and another to microcontroller.

In the PC phase, processor and transmitter blocks have been processor defined. This stage consists about reproducing a video signal and executing some processor and transmitter blocks for each frame from the video signal.

In the microcontroller phase, it is been defined both receiver and presentation blocks. In this stage continuously some bytes are received through UART and are shown on the screen.

The next diagram shows the software architecture.

6a

Now we describe the software blocks functions

  • Processor block: This block extracts the pixels from each frame and it organises them according to the data line of LED screen. Then, it moves these GRB bits to the corresponding bit of data line and then it stores those GRB bits in an array.
  • Transmitter block: This block is in charge of transmitting in serial the array obtained in the processor block.
  • Receiver block: This block receives in serial the bytes of array transmitted by the transmitter block. That array contains sorted pixels according to line mapping data on the LEDs screen.
  • Presentation block: This block carries the symbols “1” or “0” to GPIOs MCU. Those symbols are generated as from extracted pixels from each frame. It should be clarified that GPIOD pines within microcontroller are linked up to the LEDs screen.

The symbols are illustrated below.

7

Consequently, it is graphically represented by the way different blocks interact one another.

8

For a video composed by n frames, first the processor block is run for all the pixels within frame 1, then transmitter block sends GRB bits associated to frame 1 towards MCU. After that, receiver block is run for frame 1 and while presentation block shows GRB frame 1 bits on the screen, also GRB bits are received from frame 2.

This way, successively software blocks are run for video n frames.

This system has been tested projecting a video composed by 462 frames, this video is reproduced at 29.97[frames/s] speed. Next link illustrates that test.

Poster about Methodology for implementation of Synchronization Strategies for Wireless Sensor Networks

TitlePosterFrta

On the occasion of the II edition of the Symposium “Tell us your thesis” organized by the Universidad Politécnica de Madrid I created a poster summary of my thesis.

Both the thesis and the poster are entitled “Methodology for implementation of Synchronization Strategies for Wireless Sensor Networks“.

In the poster I intend to explain the process that every researcher and/or developer must carry out to add synchronization tasks to his Wireless Sensor Network.

180216 Methodology for implementation of Synchronizatoin WSN
Methodology for implementation of Synchronizatoin WSN

First of all it is needed to know what is the objective of the user application in which we want to add temporary synchronization.

Based on the application we will have some requirements to fulfill. That is, each application will have different requirements regarding timing, maximum permissible error regarding temporal precision or accuracy, network topology, message distribution method, battery consumption and life time objectives, hardware resources of different nature and different price, etc.

Since there are many options and possible ways, a methodology is needed that helps the researcher and/or developer to obtain a solution, in order to achieve a time synchronization in their wireless sensor networks, which is adapted to the needs of the application.

The development of this methodology is the objective of this doctoral thesis.

Download the poster with full resolution [PDF 18 MB]

STM32F4: Configurar el PWM con Timers

pwm-duty

Un timer no es más que un contador. Es como un reloj que se usa para medir eventos temporales. Se configura a través de unos registros especiales y se puede elegir, entre otras cosas, su modo de funcionamiento.

En el ejemplo de hoy vamos a trabajar con la placa de desarrollo 32F411-DISCOVERY y nuestro objetivo va a ser aprender a configurar el TIM4 en modo PWM para controlar la intensidad de luz del led Naranja que viene integrado en la placa.

Esta placa está basada en el microcontrolador STM32F411 el cual dispone de hasta 11 Timers, de los cuales 6 pueden ser de 16 bits, y 2 de 32 bits, cada uno con hasta 4 canales de IC/OC/PWM o contador de pulsos. Además de 2 timers watchdog y un Systick Timer.

A través del software CubeMX activaremos el PWM Generation CH2 del TIM4 en la pestaña Pinout. Además de que asociaremos el pin PD13 la función alternativa de TIM4_CH2 (Channe2 PWM Generation CH2).

timers1

Con esto habremos conseguido dos cosas: por un lado configurar el canal 2 del Timer4 en modo PWM, y por otro lado asociar la salida del PWM al pin PD13, que es donde se encuentra el led naranja.

Tras esto pasamos a la pestaña Configuration y ahí configuramos el control del TIM4. Dentro de la pestaña de Parameter Settings hay 3 parámetros numéricos que debemos entender para configurarlos correctamente.

Prescaler (PSC – 16 bits value).

Con este valor podemos fijar la frecuencia del reloj asociado al Timer dividiendo la frecuencia del reloj de sistema.

Counter Period (AutoReload Register – 16 bits value).

Será el valor en el cual nuestro Timer saltará y nos avisará de alguna forma, ya sea reiniciándose o lanzando una interrupcion, etc.

Pulse (16 bits value).

Con este valor podemos fijar el ciclo de trabajo de nuestro PWM.

  • FreqTimer = FreqClock / (Prescaler + 1)
  • Prescaler = (FreqClock / FreqTimer) – 1
  • FreqPWM = FreqTimer / (CounterPeriod + 1)
  • Period = (FreqTimer / FreqPWM) – 1
  • Pulse = ((Period + 1) * DutyCicle) / 100 – 1
Queremos llevar a cabo dos ejemplos, por un lado queremos ver parpadear el led a varios ciclos de trabajo diferentes, y por otro lado queremos configurar un dimmer del led.
 

Ejemplo 1. Parpadeo del led.

Para el parpadeo del led queremos un periodo de trabajo lento para que nos de tiempo a ver esa conmutación entre encendido y apagado del led. Es por ello que hemos fijado el la Frecuencia del PWM a 1Hz. Luego, para hacer el resto de operaciones más fáciles hemos fijado la FreqTimer a 10 Khz. Con estos datos y usando las ecuaciones anteriores obtenemos:

  • APB2 timer clocks = 96 Mhz
  • Objetivo de PWM Freq = 1 Hz
  • Prescaler = 9599
  • Period = 9999

Para poder ver el cambio de parpadeo del led usaremos estos tres valores de Pulse (% Duty cicle). Estos cambios se podrían hacer en tiempo de ejecución.

  • Pulse: 99 (1%), 4999 (50%), 9899 (99%)

Ejemplo 2. Dimmer del led.

En este caso queremos que el periodo de trabajo sera muy pequeño para que las transiciones sean fluidas para el ojo humano. Es por ello que en este ejemplo hemos fijado la Frecuencia del PWM a 10 Khz. Luego, para hacer el resto de operaciones más fáciles hemos fijado la FreqTimer a 2 Mhz. Con estos datos y usando las ecuaciones anteriores obtenemos:

timers2

  • APB2 timer clocks = 96 Mhz
  • Objetivo de PWM Freq = 10 Khz
  • Prescaler = 47
  • Period = 199

Para poder ver un dimmer en el led recorreremos todos los valores posible de Pulse (% Duty cicle). Este cambio de valor hay que hacerlo en tiempo de ejecución.

  • Pulse: 0 (0%)-199 (100%)

Ejecución de los ejemplos

Una vez hemos generado la plantilla de código con CubeMX es momento de continuar en Eclipse.

Ahora debemos tener en cuenta que para que el PWM se ponga en funcionamiento tenemos que llamar a la función 

Y para poder hacer cambios en el valor de Pulse en tiempo de ejecución debemos llamar a la macro 

STM32F4: Interrupción externa

IMG_20180307_173310_HDR

En el ejemplo de hoy veremos como asociar la generación de una interrupción externa al botón de usuario que hay en la placa de desarrollo 32F411-DISCOVERY. Después vincularemos a la atención de esa interrupción el toggle del led rojo.

Empezaremos configurando CubeMX, donde ya por defecto nos han puesto el GPIO PA0 configurado como GPIO_EXTI0 que indica que ese pin está configurado como interrupción externa. 

Para ello en la pestaña Configuration, dentro de la configuración de GPIO seleccionamos el pin PA0-WKUP y lo configuramos en modo External Interrupt Mode with Rising edge trigger detection, No pull-up and no pull-down.

Ahora debemos activar dicha interrupción bajo la pestaña Configuration, en la configuración de NVIC, debemos activar la línea EXTI line0 interrupt

Activando estas opciones en CubeMX nos generará el código correspondiente a la inicialización del sistema y activará la interrupción asociada a la linea 0, que en nuestra placa está vinculada al botón de usuario.

Si abrimos el fichero main.c y pinchamos sobre la definición de la función MX_GPIO_Init() podemos ver dos líneas al final del método que fijan la prioridad y activan la interrupción.

Si abrimos el fichero stm32f4xx_it.c podemos ver como ha aparecido una función para la gestión de la interrupción EXTI line0. Si pulsamos sobre la definición de HAL_GPIO_EXTI_IRQHandler(), nos lleva a otro método que limpia el flag de interrupción asociado al GPIO que ha generado la interrupción y llama a su callback asociado HAL_GPIO_EXTI_Callback(). Si vamos a la definición de esta última función vemos que está definida como tipo __weak y en un comentario nos dicen que debe ser implementada en espacio de usuario.

Como nosotros somos muy obedientes copiamos la definición de la función y nos lo llevamos al fichero gpio.c donde dentro del USER CODE 2 pegamos:

A este callback acudirá nuestro programa cuando se detecte una pulsación del botón. Ya que es recomendable hacer el mínimo de operaciones dentro del callback de una interrupción, en este callback sólo realizaremos la operación de toggle del led.

Para ello, dentro de este callback haremos la llamada a HAL_GPIO_TogglePin(GPIOD, GPIO_PIN_14). De esta forma cada vez que se pulse el botón de usuario el led rojo de la placa debe conmutar.

Se deja al lector la resolución de varios problemas tales como el sistema antirebotes software que habría que poner asociado a las interrupciones que se generan a través del botón, o el problema asociado a que dentro del callback habrá que distinguir entre los diferentes GPIOs que generen interrupción.

Solo nos falta compilar, y debuguear en Ac6 STM32 C/C++ Application. Y con eso podremos ver conmutar el led rojo de la placa cada vez que pulsamos el botón de usuario.