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!

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.

STM32F4: Primeros pasos con el entorno de desarrollo

IMG_20180307_120229_HDR

En el tutorial que vamos a llevar a cabo hoy veremos como instalar todas las herramientas de desarrollo para poner en marcha la placa de desarrollo 32F411-DISCOVERY. Una vez tengamos todas las herramientas instaladas procederemos a compilar y ejecutar un programa que haga parpadear un led.

Unos de los entornos de desarrollo integrado (IDE) que nosotros usamos en el B105 es eclipse. Para trabajar y poder compilar de forma cruzada para los STM32 existe una versión de eclipse que contiene todos los plugins y librerias necesarias para trabajar con dispositivos de STM llamada System Workbench for STM32 (SW4STM32). Es una herramienta gratuita que debéis descargar e instalar en vuestro ordenador. Para poder descargarla tendréis que registraros en la web. Es posible, que si no lo tenéis instalado todavía, tengáis que instalar Java en vuestro ordenador.

eclpse

 

Ahora procedemos a descargar e instalar el software STM32CubeMX que nos es más que un generador de código de inicialización para los microcontroladores y plataformas de desarrollo de ST. Con este software podremos crear el código inicial con las capas de abstracción hardware con las que queremos inicializar nuestra plataforma.

cubmxAl instalar SW4STM32 y CubeMX se nos deberían instalar los drivers correspondientes para poder usar el programador integrado en la placa Discovery para el STM-Link v2 o v2.1.

Proyecto Toggle Led

Abrimos CubeMX y creamos un nuevo proyecto. En la pestaña Board Selector elegimos nuestra placa STM32F411E-DISCO.

cubemx1

 

A través de este software se pueden activar y desactivar los periféricos y los middlewares disponibles en el microcontrolador STM32F411. Además se pueden asociar los periféricos y funciones a los pines, o asignar funciones alternativas a un pin tales como: GPIO de salida, entrada, de interrupción, analógico, de PWM, etc.

Antes de configurar nada del microcontrolador vamos a configurar el programa para que nos genere el código con la estructura correcta. Para ellos entraremos en Project Settings, pondremos un nombre a nuestro proyecto en Project Name, por ejemplo Toggle Led. En Toolchain/IDE seleccionaremos SW4STM32 y desactivamos el Generate Under Root.

Bajo la pestaña Code Generator seleccionamos Copy only the necessary library files, Generate peripheral initialization as a pair of ‘.c/.h’, Keep user code when re-generating y Delete previously generated files when not re-generated. Aceptamos la configuración.

Ahora nos fijaremos en el pin PD12, que está asociado al led verde. Comprobamos que está en modo GPIO_Output. Y ahora simplemente confiamos que el resto de configuraciones por defecto son correctas.

Generamos el código pulsando sobre Project -> Generate Code. El programa comenzará a generar todo el código y al finalizar, en el cuadro emergente pulsaremos sobre abrir proyecto. Esto nos debe abrir e incluir el proyecto en SW4STM32 (Eclipse).

Podemos ver como tenemos una estructura de directorios y ficheros que nos ha generado CubeMX con todos los drivers y librerias necesarias para nuestro sencillo proyecto. Si abrimos el main.c podemos ver que hay muchas líneas que dicen USER CODE BEGIN/END.

eclipse2

 

Es muy importante que todo el código que escribamos lo hagamos centro del bloque BEGIN/END. De lo contrario, cuando volvamos a generar código CubeMX lo sobreescribirá y no lo conservará.

En la inicialización vemos que se hace la llamada a MX_GPIO_Init(), con eclipse si mantenemos pulsado la tecla Ctrl mientras hacemos click sobre las función, nos abrirá su definición. Y la leemos un poco podemos ver una sección donde se define la funcionalidad del LD4_Pin asociado al puerto GPIOD y pin GPIO_PIN_12 que en nuestro caso es el GPIO asociado al Led Verde.

Si ahora accedemos a la definición de HAL_GPIO_Init() nos abrirá el fichero stm32f4xx_hal_gpio.c donde podemos ver todas las funciones de la HAL que nos ha generado CubeMX, entre ellas las de Read, Write y Toggle de un GPIO.

En nuestro caso, dentro del while(1) del main() haremos uso de HAL_GPIO_TogglePin(GPIOD, GPIO_PIN_12) para hacer parpadear el led. Para que podamos visualizarlo tendremos que poner un HAL_Delay(500).

Solo nos falta compilar, y debuguear en Ac6 STM32 C/C++ Application. Y con eso podremos ver parpadear nuestro led verde cada 0.5 segundos en nuestra plataforma de desarrollo.

The Twelve of B105: B105 Radar

feb18

Termina febrero y eso significa una nueva entrega de…

theTwelveOfB105

Esta vez nos hemos centrado en la tecnología radar, con la que llevamos ya varios años trabajando. En la actualidad, dentro del proyecto All-in-One, hemos desarrollado varios prototipos de sensores de bajo coste basados en radar.

Nuestro primer prototipo fue la placa RALPH, que nos permitió validar el diseño y desarrollar el grueso del software de procesado para la detección de la velocidad de los vehículos y su conteo. Incluso tuvimos estudiantes que se atrevieron a meterle mano a esta plataforma y mejorar algunos aspectos de la misma.

En una segunda aproximación, se llevó a cabo un esfuerzo importante para optimizar RALPH al máximo en tamaño, coste y utilización de recursos. Así fue como vio la luz ISHTAR, nuestro nodo sensor radar que, por cierto, utiliza YetiOS como soporte para todo el software. Esta plataforma ha sido probada y validada múltiples veces en entornos reales.

YetiRadar

 

 

Nuevamente nos despedimos con la esperanza de que nuestros twelve os entusiasmen tanto como a nosotros, y que os permitan conocer mejor todo lo que hacemos por si os interesa uniros y participar de ello. Pincha aquí si quieres ver otros meses.

Si encuentras interesante toda esta información, no dudes en seguirnos en las redes sociales para mantenerte informado.

¡Hasta el mes que viene!

Concedidos todos los Trabajos Fin de Titulación

sold out stamp

Como siempre en el B105 apostamos fuerte por la docencia de calidad. Este año, una vez más, habéis confiado en nosotros y hemos cubierto TODAS las plazas de Trabajo Fin de Titulación ofertadas. Esperamos que cumpláis vuestras expectativas y recordad “Research to learn, learn to teach, teach to push society forward”.

Este curso somos:

Alumno – Tutor

Victor Garvin – Franscisco Tirado
Rosa Pita – Roberto Rodríguez
Óscar Iglesias – Ramiro Utrilla
Jaime Soler – José Martín
Javier Pomeda – Roberto Rodríguez
Javier González – Guillermo Jara
Iván Duque – Alvaro Araujo
Hector Carretero – Francisco Tirado
Carlos del Valle – Guillermo Jara
Ainhoa Seisdedos – Francisco Tirado
Agustín Riscos – Alba Rozas
Adrián Sánchez – Roberto Rodríguez
Ildefonso Áspera – Francisco Tirado/Roberto Rodríguez
David Gil – Alba Rozas
Raquel García – Guillermo Jara
Sezgin Ibramov – José Martín
Denica Dimitrova – Guillermo Jara
Yanqing Wang – Ramiro Utrilla

Alda Martín (Cátedra BQ) – Alvaro Araujo/Ramiro Utrilla
Guillermo Ojeda – Alvaro Araujo
Fernando Martínez – Alvaro Araujo
Jose Antonio Moral – Alvaro Araujo
Agoney Moreno (Cátedra Kairos) – Octavio Nieto-Taladriz

Gracias a todos por vuestro esfuerzo!

 

 

 

B105 Radar Sensor Developments: Software

Radar Interface

 

The radar platform developed in B105 Electronic Systems Lab contains a microcontroller which process the I and Q signals adapted from the radar transceiver in order to obtain targets information -speed and distance-. The microcontroller used is a low-power STM32L496 that has a DSP module and enough RAM to perform processing tasks. It runs at 48 MHz and has low-power mode, which allows using our platform in battery-powered Wireless Sensor Networks applications.

The software developed in the microcontroller uses the YetiOS operating system which has also been developed in B105 Electronic Systems Lab and is based on well-known FreeRTOS. The architecture of the radar processing module is composed by two tasks:

  • Acquisition and Generation Task. This task is responsible of taking samples from the ADC and generating signals using the DAC synchronously. Both acquisition and generation is done using DMA, so other tasks -such as processing one- could run while taking samples.
  • Processing Task. This task provides the processed information -speed and distance of targets- to the final user. The acquired signal is filtered so the information in undesired frequency bands is eliminated. Besides, a Fast Fourier Transform (FFT) is performed in order to obtain the signals in the frequency domain. Then an OS-CFAR algorithm is applied to select the frequency peaks corresponding to targets, and the targets are selected based on signal levels and SNR ratio.

We have tested the complete radar system in real scenarios and we can process each 128 samples signal in 15 ms. That means that our radar sensor provides distance and speed information with a rate higher to 60 samples per second.

Finally, we have developed an user interface which allows us testing different configuration and the behaviour of the radar sensor on different scenarios.

 

Radar SW

B105 Radar Sensor Developments: Hardware

YetiRadar

 

Low-cost radar transceivers such as RFbeam ones allows using radar sensors in several applications where cost is an important constraint. However they need a hardware platform to work properly. Therefore, in B105 Electronic Systems Lab we have designed and implemented a hardware platform that allows obtaining using radar sensors in Doppler operating mode and FMCW operating mode.

The platform developed is low-sized and resource-constraint which allows using it in Wireless Sensor Networks applications in battery powered nodes. The hardware modules of the designed system are described below:

  • Power Source. Probably one of the most importan parts of the system as it must provide power to the radar transceiver and to the analog adaptation modules. The power source must provide 12 V, 5 V and 3.3 V for proper radar operation, and these sources must be highly noiseless to enchance radar performance.
  • Radar Transceiver. The main component of the radar sensor is the transceiver which sends and receive radar signals. K-LC5 and K-LC6 radar transceivers from RFbeam may be used, providing I and Q IF signals, and a VCO pin for FMCW operation.
  • Signal Adaptation Module. Signal adaptation is necessary to process radar I and Q signals and obtain information from them. An amplification stage, a low-pass filter and a high-pass filter are used in this module. Besides, a single-ended to differential stage is also used to improve signal acquisition.
  • Signal Acquisition. An ADC is used to digitalize the analog signals so they can be processed. The ADC used can be sigma-delta or SAR, with the higher resolution possible (12 to 16 bits), and with speeds from 10 KHz to 1 MHz. In our platform, the acquisition is done by the main microcontroller.
  • Signal Generation.  A DAC is used to generate the signals to modulate the radar transceiver through its VCO pin. Besides, an adaptation stage is implemented to provide adequated modulation signals to the radar transceivers. The DAC used in our platform is integrated in the main microcontroller.
  • Processing Unit. A microcontroller is needed to process the acquired signals and obtain information from them. In our design a low-power STM32L496 microcontroller is used.

Radar HW

 

B105 Radar Sensor Developments

radar-153679_960_720

 

Radar technology is a well-known field used since 1940s. This technology has been traditionally applied in military and aerospace fields while it has not been highly exploited in civil applications. However, in the last years, radar transceivers cost-reduction and miniaturization have allowed its application in other fields such as traffic and vehicular safety.

These low-cost radar sensors uses the Doppler effect to obtain information about obstacles or targets in its range. The radar transmits a signal and the frequency shift of the returned signal provides the velocity of the moving targets. There are two main operating modes for these radar sensors:

  • Unmodulated Doppler radar. This operating mode is the most commonly used. The hardware and processing software needed is quite simple which allows using these sensors in size-constraint and resource-contraint devices. However, they only provide velocity information of moving objects in its range. That means that static objects are missed, the distance of the objects cannot be obtained, and two objects moving at the same velocity will be detected as one.
  • Frequency Modulated Continuous Wave (FMCW) radar. This operating mode is used to obtain the distance of static and moving objects. The radar signal is frequency modulated -usually with a frequency ramp- to allow obtaining distances and velocities from the returning signal frequency shift. Thereby, it is necessary to generate a signal to realize the frequency modulation which increases the hardware complexity. Besides, the software processing is harder as there are much more information to process and there are more noise sources from unwanted environment targets.

In B105 Electronic Systems Lab we have developed a full radar system that can operate in both modes and includes all the hardware and the software necessary. This radar system is being used for traffic safety and traffic monitoring applications in several research projects.

El botón de encendido en los dispositivos actuales

always_on_device

Hasta hace no mucho, todos los aparatos que nos rodean, ya sean alimentados por baterías o desde la corriente eléctrica, disponían de un botón de encendido con dos posiciones que desconectaba el aparato completamente de la fuente de alimentación. Las únicas excepciones eran los aparatos que siempre debían estar conectados (despertadores, etc.). Algunos de estos lo implementaron de una forma más o menos disimulada en la interfaz (p.e. el temporizador de un horno), pero en otros aparatos, como televisiones, siempre suponía levantarse a pulsar el botón para encenderla.

En el caso de los aparatos alimentados por baterías, estos botones comenzaron a desaparecer antes que en los dispositivos domésticos, siendo sustituidos por un botón que, habitualmente mediante una pulsación larga, encendida o apagaba el dispositivo. Esto permitía ahorrar un botón voluminoso debido al mecanismo de enclavamiento y sólo servía para esta función. Esta forma de encendido tenía un pequeño problema, que no era útil para reiniciar el dispositivo cuando se quedaba bloqueado. Pero tampoco supuso un problema, siempre era accesible abrir la tapa de la batería y quitarla para solucionar el problema.

intBattery
Batería integrada (iPhone X).

Sin embargo, cada vez más dispositivos portátiles no permiten extraer la batería, por lo que se añaden algunas soluciones hardware para poder reiniciar el dispositivo si se queda colgado. Estas requieren, además de los componentes adicionales, una serie de consideraciones en el software que controle el dispositivo. Por otro lado, debido al aumento de funciones que realizan los dispositivos, cada vez tiene menos sentido apagarlos completamente cuando no están en uso. Estos periodos de inactividad son aprovechados por los dispositivos para descargar e instalar actualizaciones, u ofrecer funciones adicionales, como las alarmas en un teléfono móvil. En términos de experiencia de uso también suponen una ventaja, ya que reducen fricción en la interacción con el dispositivo; siempre es más probable que se use el dispositivo si siempre está listo para ser utilizado, sin tiempos de inicio ni carga.

En cuanto al desarrollo del dispositivo, supone un mayor cuidado en algunas areas:

  • Topología de alimentación: en general el dispositivo ha de ser mucho más eficiente energéticamente. En el caso de los dispositivos conectados a la red eléctrica, estos suelen estar regidos por regulaciones como la Energy Star estadounidense o su equivalente europeo, que fija unos consumos máximos en los modos de standby. Por otro lado, elementos como las fuentes de alimentación (incluidos cargadores de móviles y similares) tienen especificaciones parecidas.
    En el caso de dispositivos alimentados por baterías, el mayor problema es la duración de la misma cuando no se está usando. Esto lleva al empleo de reguladores conmutados mucho más eficientes, reducción (dinámica o fija) de las tensiones de alimentación, y la desconexión selectiva de partes del dispositivo (como la pantalla o radio). Otros aspectos que no se suelen considerar por ser despreciable su efecto, como el leakage en los condensadores de alimentación o pullups pueden ser significativos en el consumo en los modos de standby.
  • Control de brownout: si no hay la posibilidad de desconectar la batería, cuando esta no pueda proporcionar suficiente energía para que funcione el sistema, causará que no funcione correctamente pudiendo quedar bloqueado. Para ello se suelen implementar supervisores de alimentación que lo apaguen de forma preventiva, a la par que sólo permitan que se encienda cuando haya disponible energía suficiente para que arranque completamente. Esto es muy habitual en dispositivos alimentados por baterías de litio, ya que si se descargan en exceso sufren deterioro, por lo que estos dispositivos suelen impedir encenderlos cuando la batería está cerca de agotarse.
  • Control hardware de botones: dado que no hay botones de apagado, ni suele ser posible desconectar la batería en los dispositivos portátiles, se suelen implementar mecanismos hardware para poder reiniciar el dispositivo si este se cuelga. Para ello se suelen incluir circuitos de supervisión y reset, que permiten conmutar la señal de reset si una señal externa cumple ciertas características (como una pulsación muy larga en un botón).
  • Ship mode: de nuevo, debido a las baterías integradas, el consumo en standby puede suponer que, desde que se fabrica el dispositivo hasta que llega al cliente, se agote la batería completamente. Esto no solo es una “primera experiencia” de uso negativa, sino que puede suponer que la batería se deteriore. Para ello, muchos controladores de alimentación suelen disponer de un modo llamado ship mode que apaga completamente el dispositivo aislandolo de la batería para evitar este consumo. Para salir de este modo basta que el usuario pulse un botón concreto o lo conecte al cargador.
  • Gestión software de los modos de energía: todo el trabajo en el diseño hardware no es útil si la aplicación del dispositivo no gestiona adecuadamente los modos de inactividad, usando las funciones hardware disponibles (escalado dinámico de la tensión, desconexión de periféricos) y reduciendo las tareas innecesarias durante los periodos de inactividad.

Gran parte de las funciones hardware se suelen concentrar en los PMICs (Power Management IC), estos condensan cargadores de baterías, reguladores, y funciones adicionales como la gestión de botones de reset o monitorización de la carga.

Arquitectura del PMIC bq25121.
Arquitectura del PMIC bq25121.