El botón de encendido en los dispositivos actuales

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.

Certificación y pruebas del proyecto Demotherm

La pasada semana se realizó en las instalaciones de Therman (Gijón) la certificación del proyecto Demotherm ante el CDTI (Centro para el Desarrollo Tecnológico Industrial). Durante esta visita no sólo se realizó la justificación del proyecto, sino que se aprovechó para realizar más pruebas con el robot desarrollado conjuntamente entre Therman, el Grupo de Ingeniería de los Procesos de Fabricación de la Universidad de Oviedo y el B105 Electronic Systems Lab de la Universidad Politécnica de Madrid. 

IMG_0954

Estas pruebas se realizaron con todos los elementos del robot ya integrados (parte mecánica, hardware y software de control y bomba de agua) para evaluar el desempeño en la aplicación final para la que se ha diseñado. Además de las pruebas de corte de hormigón, se aprovechó para comprobar algunos parámetros de funcionamiento, como es la fuerza que ha de ejercer el robot contra las paredes para no caerse. Esto permite establecer los umbrales seguros de funcionamiento que habrá de mantener el robot durante su funcionamiento en los escenarios de uso. 

IMG_0871

De discos duros externos, economía de escala y conectores

Tradicionalmente los discos duros externos solían consistir en un disco duro de tipo interno junto con una controladora SATA-USB conectada al disco que le provee de conectividad y alimentación. Sin embargo, desde hace unos años, varios fabricantes OEM de discos duros han empezado a ofrecer discos duros externos (típicamente de 2,5″) que prescinden de esta controladora separada.

En su lugar, dado que realizan la fabricación del disco duro, han personalizado la placa controladora que llevan todos los discos duros. En lugar de exponer la señal SATA a través del conector habitual, han colocado en la misma placa el chip conversor SATA a USB, por lo que sólo necesitan el conector USB externo (que típicamente es microUSB, ya sea 2.0 o la versión extendida 3.0). Esto supone para el cliente que el disco es más compacto, ya que las dimensiones exteriores de la caja sólo han de incluir el saliente del conector USB. De cara al fabricante, se produce un ahorro en el BOM, ya que los conectores SATA tienen cierto coste, además de evitar otra placa con su proceso de fabricación, soldadura y testeo. Todo esto hace que, a la escala a la que se fabrican, les salga rentable el desarrollo y validación de la placa.

Sin embargo, los conectores siempre han sido propensos a daños mecánicos, tanto por el uso normal, cómo por caidas, o golpes. En los modelos antiguos, era posible abrir la carcasa y conectar el disco directamente a un PC o a otra controladora SATA a USB para recuperar los datos, o bien colocar el disco en otra carcasa. En cambio, en los modelos que llevan toda la electrónica en la controladora del disco, esto no es posible. En estos casos, quedan menos alternativas posibles:

  • Buscar el fallo en la placa (y tratar de solucionarlo). Salvo que se trate de un conector roto o alguna soldadura saltada, es complicado.
  • Encontrar las líneas SATA entre en el controlador del disco duro y el conversor SATA-USB. Normalmente estas se pueden identificar debido al rutado como par diferencial, y suelen llevar pads de test asociados a los que se puede cablear un conector SATA de datos. En este caso, se ha de buscar la forma de desacoplar el conversor USB, ya sea cortando las pistas o quitando resistencias serie si se hallan presentes.
  • Sustituir la placa controladora. En la mayoría de discos actuales, incluye una memoria flash que configura el funcionamiento del disco. Para que se puedan recuperar los datos, se habrá de sustituir la memoria de la antigua a la de reemplazo.
LRM_EXPORT_20171215_174643
Memoria flash de una controladora de disco duro.

Reemplazando el firmware ST-Link por J-Link en las placas de desarrollo de ST

A la hora de iniciarse en el desarrollo de STM32, las placas de desarrollo Nucleo y Discovery de ST son bastante baratas, e incluyen un debugger en la propia placa (ST-Link) bastante aceptable en términos de velocidad y funcionalidad. Para la mayoría de proyectos es más que suficiente, sin embargo, existen en el mercado programadores externos más avanzados. Estos se suelen distinguir en cuanto a velocidad, soporte técnico, interfaces de comunicación, o herramientas añadidas (seguimiento de trazas, análisis de memoria, etc.).

Entre estos programadores, unos de los más conocidos son los J-Link de Segger. Estos programadores tienen un precio algo elevado (salvo la versión EDU, que no permite uso comercial). Sin embargo, cuando se usan para debuggear micros STM32 en las placas de desarrollo, ofrecen un firmware que sustituye el presente en el debugger de estas placas y que aporta la mayoría de funciones de sus programadores. 

jtrace
Programador J-Trace de Segger.

Sobre el ST-Link, aporta sólo algo más de velocidad, pero tiene mucho mejor soporte software. Esto es especialmente interesante cuando se programan algunas versiones de los Cortex M7 (r0p0 y r0p1, como el STM32F746ZG), ya que tiene implementado algunos workarounds que facilitan el debugging de estos cores (info). Por otro lado, cuando se desarrolla sobre FreeRTOS, funciona bastante mejor el soporte de thread awareness en el depurador que el que proporciona OpenOCD. 

Para ponerlo en marcha:

  1. Reemplazar el firmware del ST-Link. En la página de Segger, se puede descargar la herramienta que permite cambiar y restaurar el firmware del ST-Link. En caso de restaurarlo, es conveniente actualizarlo mediante las herramientas de ST a la ´última versión.
  2. Instalar el paquete software de Segger.
  3. Para añadir el soporte a System Workbench:
    1. Añadir el repositorio que aparece aquí a Eclipse e instalar GNU MCU C/C++ J-Link debugging, mediante Help->Install New Software.
    2. En las opciones de Eclipse, en la categoría MCU, ajustar las rutas al paquete software, tanto en la categoría global como workspace (capturas aquí).
  4. Para añadir la configuración de depuración al proyecto:
    1. Crear una nueva en la categoría GDB SEGGER J-Link debugging. En la pestaña Debugger hay que hacer unos cambios:
      1. En Device name añadir el nombre del micro (p.e. STM32F746ZG).
      2. A la hora de depurar, si saltase un fallo al ejecutar gdb –version, buscar manualmente el ejecutable en el cuadro de GDB Client Setup, por el de la toolchain. Un path de ejemplo puede ser C:\Ac6\SystemWorkbench\plugins\fr.ac6.mcu.externaltools.arm-none.win32_1.15.0.201708311556\tools\compiler\bin\arm-none-eabi-gdb.exe
        gdbconf
    2. Lanzarla manualmente (a veces System Workbench tiende a ejecutar la de ST-Link al pulsar F11 o el icono).

debugConf

Como apuntes adicionales, si se usa freeRTOS se puede cargar el plugin de thread awareness añadiendo “-rtos GDBServer/RTOSPlugin_FreeRTOS” al campo  Other options:  en la pestaña Debugger, sección J-Link GDB Server Setup.

thread awareness
Soporte thread awareness en Eclipse.

A WSN-Based Intrusion Alarm System to Improve Safety in Road Work Zones

Title: A WSN-Based Intrusion Alarm System to Improve Safety in Road Work Zones
Authors: Jose Martin, Alba Rozas, and Alvaro Araujo
Published in: Journal of Sensors
Date of Publication: Jun 2016
Digital Object Identifier : 10.1155/2016/7048141
Web: https://www.hindawi.com/journals/js/2016/7048141/

Road traffic accidents are one of the main causes of death and disability worldwide. Workers responsible for maintaining and repairing roadways are especially prone to suffer these events, given their exceptional exposure to traffic. Since these actuations usually coexist with regular traffic, an errant driver can easily intrude the work area and provoke a collision. Some authors have proposed mechanisms aimed at detecting breaches in the work zone perimeter and alerting workers, which are collectively called intrusion alarm systems. However, they have several limitations and have not yet fulfilled the necessities of these scenarios. In this paper, we propose a new intrusion alarm system based on a Wireless Sensor Network (WSN). Our system is comprised of two main elements: vehicle detectors that form a virtual barrier and detect perimeter breaches by means of an ultrasonic beam and individual warning devices that transmit alerts to the workers. All these elements have a wireless communication interface and form a network that covers the whole work area. This network is in charge of transmitting and routing the alarms and coordinates the behavior of the system. We have tested our solution under real conditions with satisfactory results.