¿Por qué ARM? - Cika Electrónica SRL

Capítulo 3
¿Por qué ARM?
alharma o alf arma
(Del ár. alharmal )
1. f. Planta de la familia de las
Rutáceas, de unos cuatro
decímetros de altura, ramosa, con
hojas laciniadas y flores blancas,
muy olorosa, y cuyas semillas
sirven de condimento en Oriente,
y también se comen tostadas.
3.1.
¿Por qué 32-bits?
Como enunciáramos al abrir el libro, el mundo de los microprocesadores y microcontroladores ha ido evolucionando rápida y vertiginosamente,
adquiriendo características cada vez más complejas.
Desde un punto de vista constructivo, los sistemas microprocesados evolucionan siguiendo los requerimientos de su entorno de operación. En un
análisis simple, la demanda hacia sistemas de mayor ancho de palabra, como
por ejemplo 32-bits, radica en las siguientes causas, y seguramente muchas
otras más:
la necesidad de interfaces sumamente simples para usuarios con poca
alfabetización tecnológica: nadie quiere aprender a programar en assembler para poder hablar por teléfono. Estas interfaces requieren
extracto del libro “Desarrollo con Microcontroladores ARMCortex-M3”
113
3. ¿Por qué ARM?
una cantidad de código y datos mayor, que a su vez requiere de mayor
velocidad para su manejo en el mismo tiempo.
la avidez de los usuarios por consumir dibujitos y colores, como desprendimiento de la anterior. Ante dos interfaces equivalentes en todo
excepto la presencia del color, la que los tiene es más linda, y aunque
requiere más del doble de memoria y ancho de banda, es preferida.
la necesidad de procesar datos con mayor precisión. En muchos casos,
no se dispone de o no se quiere invertir en el tiempo necesario para
hacerlo en micros de 8-bits, y/o en lenguajes de bajo nivel.
la necesidad de llevar los productos al mercado en un tiempo más
corto, mueve a la utilización de lenguajes de programación de más
alto nivel; esto a su vez favorece el empleo de procesadores con más
capacidad de memoria, dado que este esquema suele utilizar mayor
cantidad de memoria en comparación a los lenguajes de bajo nivel.
la disponibilidad de sistemas operativos, multitarea, operación en tiempo real, sistemas de archivos y demás, hace más atractivos los entornos
en los cuales es más fácil hacer más cosas con menor intervención del
programador, y aún con menores conocimientos. Esto provoca una
potenciación mutua en cuanto se favorece a los micros más poderosos
y se da mayor soporte a éstos.
la migración de usuarios y programadores de computadoras al mundo
de los sistemas dedicados, hace que éstos quieran aplicar sus modelos y costumbres, con la consecuente necesidad del crecimiento de la
disponibilidad de recursos para poder satisfacerlos.
etc.
Si tuviera que elegir a ciegas entre un micro de 8-bits y uno de 32-bits, mi
elección no sería para nada fácil. La razón principal es que mi cerebro está
fuertemente condicionado por mi profesión y mi experiencia de muchos años
de desarrollo de electrónica general, hardware, y firmware en assembler
en micros de 8- y 16-bits, con lo cual me veo inmediatamente polarizado a
pensar la forma de hacer todo con ellos. No obstante, algunas aplicaciones
más comunes requieren el manejo de complejas interfaces gráficas, lo cual
no sólo es harto complicado hasta para el más obsesivo, sino que requiere
de una capacidad de memoria y velocidad de procesamiento muy difícil de
114
extracto del libro “Desarrollo con Microcontroladores ARMCortex-M3”
3.1. ¿Por qué 32-bits?
obtener en este ámbito. Mi decisión, entonces, estará basada en la complejidad del proyecto, el tiempo de desarrollo disponible, y el costo; tanto en
valor monetario como en energía de operación.
¿Pero qué opina aquél que ve el mundo no desde el hardware sino desde
el software? Seguramente alguien acostumbrado a disponer de un sistema
operativo, un API, la posibilidad de desarrollar en un lenguaje de alto
nivel, y una vasta cantidad de memoria valora mucho estos conceptos, y
prefiere desarrollar sobre un gran sistema de 32-bits, antes que perder el
pelo incrementando registros de 8-bits.
La respuesta al interrogante es más o menos obvia en ambos extremos.
Ante un controlador temporizado de muy bajo costo, con un botón,
un relé, y tal vez un LED que parpadea; siendo más barato que un
par de circuitos integrados de lógica, nadie dudaría en utilizar un
microcontrolador de 8-bits.1
Ante una aplicación con pantalla color sensible al tacto y una compleja
interfaz de usuario, pocos dudarían en emplear un hardware basado
en un procesador de aplicación, y hasta preferentemente desarrollar
sobre un sistema operativo que provea un API para resolver la parte
gráfica.
La duda parece cernirse sobre la franja media; sobre el sistema que es más
complejo que un simple control temporizado pero no requiere hacer malabares con un display color. Sin embargo, la economía nos provee de algunas
soluciones de compromiso:
El costo de un microcontrolador de 32-bits de gama baja a media es
menor que el de un micro de 8-bits de gama media a alta.
Un sistema con más recursos, que permita reducir el tiempo de desarrollo de firmware/software, tendrá un costo de desarrollo menor, al
utilizar menos tiempo de programador.2
Y si incluimos algunos detalles técnicos en la balanza:
1 Bueno, tal vez sí encontremos alguien que justifique hasta el utilizar una granja
de servidores en pos de muchas “features”. Convengamos en que se trata de una tarea
elemental sin demasiadas ambiciones.
2 El tiempo del programador está considerado uno de los costos de desarrollo más
altos, sino el más alto, en todo sistema que lo requiera. La disminución de este tiempo sin
tomar las medidas adecuadas aumenta considerablemente la probabilidad de existencia
de defectos (bugs) presentes en el código, muchos de los cuales pasan la inspección y
quedan como defectos latentes, pudiendo manifestarse luego en bochornosas y/o costosas
situaciones.
extracto del libro “Desarrollo con Microcontroladores ARMCortex-M3”
115
3. ¿Por qué ARM?
La cantidad de memoria de programa empleada para resolver aritmética de 16- y 32-bits en un micro de 32-bits con un set de instrucciones
comprimido como Thumb es igual o menor que la necesaria para resolver la misma tarea con un micro de 8- o incluso 16-bits.
La complejidad del código en assembler sigue las mismas pautas, y
un micro ortogonal de 32-bits con un set de instrucciones eficiente
permite que un compilador genere código más compacto.
Un microcontrolador de 32-bits no requiere el diseño de un hardware
complejo como un procesador de aplicación, siendo bastante similar
(si no igual) al de cualquier sistema microcontrolado.
Es decir, es altamente probable que más allá de los 16KB de código, un
micro de 32-bits sea más económico y eficiente para resolver la misma tarea
que uno de 8-bits.
En conclusión, cualquiera sea nuestra extracción, seguramente habrá
algunas razones más o menos importantes para que una u otra opción tenga
más o menos peso; hemos analizado los detalles básicos como para ayudarnos
a tomar una decisión y fijar ciertas pautas.
3.2.
¿Por qué ARM?
Muy bien, ya hemos detectado algunas de las situaciones en las cuales la
balanza se inclina para el lado de los 32-bits. ¿Por qué no, entonces, emplear
una PC industrial o cualquier otra cosa de 32- o más bits?
Si bien al gerente de tecnología y al programador en C++ pueden interesarle poco el hecho de que el procesador tenga una alta ortogonalidad, una
pipeline y un set de instrucciones altamente eficientes, ejecución condicional, pueda resolver el algoritmo de m.c.d. con menos instrucciones assembler
que líneas de código C del programa fuente, y sea capaz de armar el cubo
mágico en una sola instrucción; creemos que coincidirá en que:
un procesador con la relación MIPS/MHz que tiene ARM implica que
con un clock mucho más bajo puede realizar la misma tarea, con el
consecuente ahorro de energía, que se traduce al menos en un retorno
económico (menor gasto de dinero en energía eléctrica, ya sea en la
cuenta de la empresa prestataria o el reemplazo de baterías) y uno
ecológico (menor derroche de energía).
un procesador que puede aprovechar código tan compacto como ARM,
requerirá de menos memoria de código para realizar la tarea necesaria,
116
extracto del libro “Desarrollo con Microcontroladores ARMCortex-M3”
3.2. ¿Por qué ARM?
con el consecuente ahorro en el costo de las memorias y por ende
también en consumo eléctrico.
un procesador con la potencia y simpleza del set de instrucciones de
ARM, hace que los compiladores de lenguajes de alto nivel generen
código más compacto, reforzando el punto anterior.
un procesador simple presenta una relación performance/costo elevada.
el procesador, en su versión con MMU, soporta los sistemas operativos
más comunes, como Linux y Windows Embedded Compact.
Además, los sistemas dedicados suelen caracterizarse por:
un bajo consumo de potencia, la velocidad de operación se acomoda
a los requerimientos energéticos del sistema
un hardware minimalista, por una parte por una razón de costo, por
otra para mantener bajos niveles de consumo eléctrico
el empleo de procesadores con manejo óptimo de los recursos, y una
respuesta rápida ante interrupciones
Las características fundamentales de la arquitectura ARM, que la distinguen frente a otras como las vistas en el capítulo sobre micros, son:
una pipeline compacta, simple y eficiente, que logra una ejecución
sostenida a alta velocidad
un set de instrucciones simple y altamente eficiente, compacto y ortogonal, que hace que los compiladores de lenguajes de alto nivel generen
a su vez código más compacto, respecto a otros procesadores
set de instrucciones reducido que permite optimizar el uso de memoria
de código y performance
una excelente relación MIPS/MHz que logra una alta velocidad de
ejecución con un mínimo consumo
una arquitectura simple concebida en 32-bits, con características optimizadas para una respuesta rápida ante excepciones
instrucciones de un ciclo, minimizando la latencia
bajo costo en relación a su performance
extracto del libro “Desarrollo con Microcontroladores ARMCortex-M3”
117
3. ¿Por qué ARM?
En síntesis, si bien, como sabemos, es posible implementar cualquier sistema
con cualquier herramienta (costará más o menos y rendirá más o menos);
cuando la herramienta es óptima la relación costo/beneficio es mayor. Bajo
estas condiciones, consideramos que ante un requerimiento de mayor capacidad de memoria y procesamiento, una arquitectura como ARM es una
herramienta óptima, más cerca del mundo de los sistemas dedicados.
3.2.1.
¿... y en microcontroladores?
Bien..., lo visto en la sección anterior más o menos nos muestra dónde se
inclina la balanza para el lado “procesadores para sistemas dedicados” versus
“procesadores para computadoras de escritorio”. Pero si vamos al ambiente
de microcontroladores, hay otras opciones, y algunas también basadas en
procesadores con un altísimo rendimiento. Entonces, ¿por qué ARM en este
entorno?
En el capítulo anterior hemos visto mayormente hardware, y un pantallazo de las arquitecturas ARM sin entrar demasiado en detalles sobre las
arquitecturas específicas para microcontroladores. En capítulos siguientes
veremos que las arquitecturas ARM permiten que no sea difícil desarrollar
sino hasta más fácil, haciendo que elegir 32-bits por costo y por las razones
dadas en la sección anterior no se transformen en un dolor crónico a la hora
de plasmarlo en un proyecto. Esto limita tal vez el abanico de opciones,
pero no termina de definir por qué ARM y no un fabricante cualquiera con
similares características.
Pues bien, tal vez la diferencia fundamental en este aspecto es que ARM
nos permite cierta libertad en la elección de los demás elementos de nuestro
entorno. En la sección 8.1 en la página 205, veremos una herramienta de
desarrollo que en realidad es algo mucho más profundo, que se denomina
CMSIS. Este concepto nos permite obtener:
Independencia del fabricante del hardware
Independencia del proveedor del compilador
◦ Posibilidad de utilizar herramientas gratuitas y hasta open source
Independencia del proveedor del RTOS (en caso de utilizarlo)
3.2.1.1.
Independencia del fabricante del hardware
El core del procesador es ARM, y accedemos a él mediante funciones
standard definidas en CMSIS. Cada fabricante desarrolla los periféricos que
118
extracto del libro “Desarrollo con Microcontroladores ARMCortex-M3”
3.2. ¿Por qué ARM?
incorporará en su microcontrolador como guste, pero la interfaz de control
sigue ciertas pautas comunes. De este modo, es posible cambiar de fabricante
del microcontrolador realizando un mínimo trabajo de transporte de uno a
otro.
En un mundo ideal, CMSIS define una capa intermedia de abstracción que permite que la aplicación esté desacoplada del hardware lo
suficiente como para permitir el transporte, pero sin que esto afecte
la performance. Mayormente la abstracción se realiza mediante directivas del compilador
En el mundo real, gran parte de esto todavía es vaporware 3 , y existe
un trabajo de transporte, si bien está bastante minimizado por esta
estructura común. Dado que todo lo relacionado al core, incluyendo
el timer del sistema y las excepciones e interrupciones de los periféricos, se controla mediante CMSIS, el trabajo de transporte específico
asciende sólo a lo estrictamente relacionado con la operación de los
periféricos
De utilizarse un RTOS, éste se optimiza para el procesador, no para
el microcontrolador, y utiliza los recursos del core, por lo que no es
necesario portarlo. (ver además 3.2.1.2)
A la hora de elegir un microcontrolador, disponemos entonces no sólo de
todas las opciones de un fabricante en particular, sino de todo un abanico
de fabricantes, con jugadores de la calidad de Fujitsu, Toshiba, y otros no
tan conocidos (pero no por ello de menor calidad) como Holtek o Energy
Micro; más allá de los tradicionales gigantes como NXP, Freescale,
Texas Instruments, ST, Atmel, entre otros. La lista es muy extensa.
3.2.1.2.
Independencia del proveedor del compilador
Si bien Keil es una empresa del grupo ARM, existen otras opciones
como IAR Systems, e incluso gratuitas. Nos ocuparemos de esto en la
sección 8.2 en la página 210.
Pero no es solamente elegir otro compilador u otro entorno de desarrollo.
Al utilizar CMSIS, la forma de interactuar con el compilador a través del
código es la misma; todas las directivas y llamados a funciones intrínsecas
3 Este término se utiliza para referirse a productos tecnológicos que no existen al
momento de su lanzamiento. En algunos casos se trata de maniobras de marketing para
ganar posicionamiento, observar la respuesta y la posible demanda antes de siquiera
definir el producto; en otros casos se utilizan los datos obtenidos de la respuesta de los
usuarios potenciales para ajustar parámetros de desarrollo antes del lanzamiento “real”.
extracto del libro “Desarrollo con Microcontroladores ARMCortex-M3”
119
3. ¿Por qué ARM?
para aprovechar las ventajas del procesador, se realizan a través de la capa
de abstracción de CMSIS. Esta capa se conforma mediante directivas del
pre-procesador, por lo que no genera impacto en el código, es simplemente
una especie de “lenguaje intermedio” mediante el cual nos comunicamos de
igual forma con un compilador Keil que con un compilador IAR, usando
directivas e intrínsecas CMSIS, que a su vez se trasladan al momento de
compilación a directivas Keil o directivas IAR. Lo mismo ocurre para un
entorno gratuito como GNU o CooCox. Lo único que debemos tener presente es la configuración del compilador para utilizar CMSIS, y el empleo
de la estructura que éste requiere.
Todo esto significa que podemos utilizar cualquier herramienta profesional que deseemos, con el microcontrolador que deseemos4 . Si bien algunos
fabricantes proveen además un entorno propio, al cual embellecen y tornan
más atractivo para su solución en particular, siempre tenemos una opción
genérica y es la intención de este libro que la usemos y la aprovechemos.
3.2.1.3.
Independencia del proveedor del RTOS
Finalmente, la tercera edición de CMSIS introdujo un esquema de abstracción para unificar la forma de acceder a las funciones básicas de un
RTOS. De este modo,es posible portar una aplicación de un RTOS a otro
prácticamente sin modificaciones, dado que las funciones básicas se llaman
a través de CMSIS. Una vez más, podemos utilizar cualquier herramienta
profesional que deseemos, con el microcontrolador de nuestra elección; independientemente de las sugerencias de cualquier fabricante o proveedor en
particular.
4 dentro de ciertos límites, en algunos raros casos el microcontrolador no está soportado por alguna herramienta.
120
extracto del libro “Desarrollo con Microcontroladores ARMCortex-M3”