Buena parte de mi éxito en el diseño se lo debo a mi formación universitaria. Y no es por los experimentos de laboratorio en los que descubrimos que podíamos quemar un condensador accidentalmente, sino porque aprendimos que la Ley de Murphy puede atacar cuando uno menos se lo espera. Como me pasaba mucho tiempo entre jugar Warcraft y procurar entregar a tiempo los deberes que tenía, necesitaba desesperadamente que mi ordenador funcionase perfectamente en todo momento.
En aquel entonces, los ordenadores tenían unas capacidades muy limitadas y no era raro toparse con la “Pantalla Azul de la Muerte” de Windows de vez en cuando. Si bien es frustrante que te interrumpan en una partida de Warcraft, perder archivos que costaron horas y horas de trabajo a causa de un fallo en el ordenador era algo que me llenaba de pánico. Como diseñador, es posible que usted experimente un pánico similar si su microcontrolador causa un fallo en el campo.
En un sistema embebido, un fallo en el microcontrolador (MCU) podría tener unas repercusiones mucho más graves que simplemente no entregar los deberes a tiempo. Los MCU suelen ser la base de aplicaciones como máquinas de pago, dispositivos médicos y sistemas de seguridad. Estos sistemas requieren de una alta estabilidad y suelen presentar un muy bajo nivel de tolerancia para su tasa de fallos.
Una unidad de microcontrolador con fallos puede producir un alto total en las operaciones. Esto puede incomodar a los usuarios o presentar riesgos de seguridad funcionales en aplicaciones críticas. Es extremadamente importante contar con un mecanismo de seguridad. Para los clientes, unos sistemas inestables afectan negativamente la capacidad de operación y pueden causar pérdidas económicas. Para los diseñadores, el tener cientos de productos fallando constantemente en el campo es un duro golpe para nuestro orgullo y puede afectar a nuestra reputación.
Un sistema embebido requiere de un esfuerzo combinado por parte del diseñador del hardware y el programador del firmware. Algunos fallos en el diseño pueden pasar desapercibidos durante la fase de desarrollo, pero emergen cuando los equipos ya están implementados. Cuando esto sucede: ¿Quién debe asumir la mayor parte de la responsabilidad?
Antes de comenzar a buscar culpables, demos un vistazo a las posibles causas de que un mecanismo falle.
La pila de memoria de un microcontrolador es un área de su RAM interna que está designada para uso temporal. El tamaño de la pila de memoria es limitado y varía para los diferentes MCU. Cuando el programador del firmware asigna una variable más grande que el tamaño de la pila, puede ocurrir un desbordamiento de pila (también conocido por el término en inglés: Stack Overflow) durante la operación, causando que el firmware genere un fallo en el hardware.
En la programación del firmware de una MCU, se usan comúnmente los punteros para indicar la dirección de una variable o las funciones del programa. La declaración y uso de los punteros exige al programador del firmware que respete la estricta sintaxis definida por el lenguaje de programación, que suele ser C. Introducir un puntero ilegal por error puede causar que la MCU intente procesar variables o funciones en direcciones que están fuera de su rango válido. Esto podría hacer que la MCU se cuelgue.
Este factor se suele pasar por alto: una MCU necesita de una fuente de alimentación estable para funcionar de manera también estable. La MCU podría presentar fallos si su fuente de alimentación sufre de constantes interrupciones por interferencias externas. Una caída en la tensión de operación podría hacer que la MCU se comportase erráticamente o se congele por completo.
El no corregir la interferencia eléctrica, especialmente la producida por relés y motores podría hacer que su MCU se cuelgue. En uno de mis primeros proyectos, en el que tenía que controlar un motor DC sencillo, mi MCU fallaba cada vez que trataba de operar el motor en reversa. El problema se corrigió incrementando su nivel de aislamiento eléctrico usando un amplificador operativo.
Ocasionalmente, los fallos en la unidad de microcontrolador pueden no tener nada que ver en absoluto con el ingeniero de hardware ni con el de firmware. Unas uniones de soldadura de baja calidad en los pines de la MCU pueden producir comportamientos impredecibles en la MCU. Si solo están fallando unos pocos sistemas embebidos, es posible que quiera indagar un poco en la calidad del proceso de su fabricante.
En lugar de dedicarse a buscar culpables, tanto los ingenieros de hardware como de firmware deben hacer lo que les corresponde para diseñar un sistema embebido que sea confiable. Observar una buena ética de programación y planificar la asignación de memoria por anticipado son buenas prácticas a seguir. Para los programadores, mantener las cosas lo más sencillas posible puede ser la mejor elección para evitar errores en el código.
Los diseñadores de hardware deben tener presente el entorno en que se utilizará este hardware y prepararse para todas las posibilidades. Esto implica el observar las buenas prácticas básicas de diseño y la utilización plena de las herramientas de su software de PCB para poner a prueba el diseño. Cuando necesite acceder a una herramienta de disposición de PCB que incluya todo lo necesario para crear placas de circuitos de alta calidad y de fácil fabricación, la mejor es CircuitMaker. Además de un software de diseño de PCB fácil de usar, todos los usuarios de CircuitMaker tienen acceso a un espacio personal de trabajo en la plataforma Altium 365. Usted podrá cargar y almacenar sus datos de diseño en la nube. Además, podrá ver fácilmente sus proyectos desde su navegador web en una plataforma segura.
Comience a usar CircuitMaker hoy mismo y no se pierda el nuevo CircuitMaker Pro, de Altium.