La estandarización en una sola plataforma para microcontroladores encabeza la lista de los deseos en el sector, pero incluso con un núcleo común los diseñadores deberán afrontar problemas de portabilidad de periféricos y de firmware.

Los periféricos son fundamentales para la migración
Muchos diseños empiezan especificando las funciones que proporcionará el sistema y cómo accederán a ellas los usuarios.
Esto determinará los circuitos necesarios y los periféricos que sea necesario integrar en el microcontrolador para controlarlos. Si, por ejemplo, el diseñador quiere incluir un interface hombre-máquina (Human Machine Interface, HMI) industrial, el microcontrolador habrá de ofrecer soporte a un LCD y a algunos botones o a una pantalla táctil; un interface de comunicación con la máquina; LED y un avisador acústico u otro componente de audio. Por tanto, el microcontrolador habrá de integrar un controlador CAN para comunicación; un convertidor A/D para la pantalla táctil y un temporizador PWM para el avisador acústico. Cuanto mayor sea la funcionalidad del periférico, menos circuitería externa se necesitará, lo cual puede reducir la cantidad de código que debe escribir el diseñador. Por tanto, con un avisador acústico resulta más sencillo ajustar un PWM para lograr el mismo resultado.

Lo habitual es que el diseñador quiera conocer dos datos fundamentales sobre el núcleo: ¿es lo suficientemente rápido como para ejecutar todas las tareas de software necesarias para ofrecer soporte a todas las funciones que ofrece el producto final? y ¿realiza todas estas tareas de manera eficiente? Si la respuesta a ambas preguntas es afirmativa, entonces la mayoría de diseñadores no estarán muy preocupados por el tipo de núcleo que se está utilizando.

Más relevante es la cantidad de software y firmware ya existente y que pueda migrarse de un núcleo a otro para ofrecer soporte a los periféricos. Como la mayor parte del código del microcontrolador de 32 bit está escrito en C, gran parte de él se puede recompilar para cualquier núcleo. No obstante, cada fabricante de microcontroladores dispondrá de funciones de periféricos y de modelos de programación exclusivamente para sus propios productos, con independencia del núcleo utilizado. Esto es lo que convierte en un reto la portabilidad del código.

Portabilidad de firmware
Cada fabricante de microcontroladores suministra una biblioteca de firmware que contiene el código para configurar y ejecutar los periféricos integrados en su microcontrolador. Sin embargo, cada fabricante implementa también estos periféricos de una manera distinta y cada periférico puede tener funciones distintas. Esto significa que la portabilidad de una aplicación de uno a otro microcontrolador no es una tarea sencilla.

ARM ha afrontado esta cuestión definiendo una capa de abstracción de firmware estándar denominada Cortex™ Microcontroller Software Interface Standard (CMSIS) que ha sido adoptada por todos los fabricantes de microcontroladores que utilizan los núcleos Cortex-M y se utiliza en sus bibliotecas de firmware. No obstante, este estándar no afronta la dificultad que tiene la portabilidad de periféricos ni ha establecido una denominación estándar para variables o funciones. Como resultado de ello apenas reduce el esfuerzo y el trabajo necesarios para la portabilidad de una aplicación entre diferentes suministradores de microcontroladores ARM.

Proyectos de portabilidad
Si bien los proveedores de microcontroladores pueden utilizar el mismo núcleo ARM, no les interesa simplificar la portabilidad al microcontrolador de otro suministrador. El reto de hacer que un diseño sea portátil pasa, por tanto, al ingeniero de diseño. Para simplificar la portabilidad, el diseñador podría implementar una capa de abstracción para crear un interface de programación estándar entre el microcontrolador y el hardware del periférico y el código de aplicación. Existen, por lo menos, dos maneras de llevarlo a cabo:

-    Se puede desarrollar una capa de compensación o de cobertura para la traducción entre la biblioteca del periférico del fabricante de microcontrolador y el código de aplicación. Si bien ésta es probablemente la solución más eficiente en el tiempo, añadirá más código en las rutas de comandos y datos.
-    Definir una función estándar y un método de denominación de variables y aplicarla a cada biblioteca de periférico. Si bien esto evita añadir código, puede consumir mucho tiempo, especialmente para periféricos complejos.

La portabilidad debe formar parte del proceso de desarrollo desde las primeras etapas. Además del firmware/software, está la cuestión de la compatibilidad entre patillas, que generalmente implica un nuevo trazado de la placa de circuito impreso al pasar de un suministrador de microcontroladores a otro. Es posible que también haya que cambiar componentes externos como condensadores y reguladores.

Portabilidad en el mundo real
Una portabilidad sencilla entre microcontroladores de 32 bit de diferentes suministradores parece seguir estando en la lista de deseos en el sector hasta que se hayan resuelto los problemas de portabilidad de periféricos y de bibliotecas de firmware. Hasta entonces, los diseñadores deben asumir la responsabilidad para la portabilidad de sus diseños. Una de las formas de mitigarlo consiste en escoger un microcontrolador que facilite la migración a otros microcontroladores pertenecientes a la gama de productos del mismo fabricante.

Por ejemplo, Microchip ha simplificado recientemente su gama de compiladores C con el paquete MPLAB® XC, que ofrece un compilador para cada una de sus arquitecturas de 8, 16 y 32 bit, y ofrece soporte a cada microcontrolador PIC® y controlador de señal digital (DSC) dsPIC®. Esto se suma a su compatibilidad entre arquitecturas para conservar la inversión en desarrollo de código y compatibilidad entre patillas de varios paquetes para simplificar el trazado de la placa de circuito impreso que sirve para una sustitución directa.

Por tanto, mientras los diseñadores siguen a la espera de un núcleo estándar que se complete con periféricos y firmware estándar, al menos pueden realizar diseños preparados para el futuro evaluando la relación costes/beneficios de la migración con el catálogo de un solo fabricante al iniciar cada proyecto.

Más información o presupuesto