En un post anterior mencioné algunas alternativas interesantes a Raspberry Pi.
Pero en el mercado existen muchísimas más alternativas que puedes usar y constantemente se están lanzando más al mercado.
Por ello en este post voy a analizar 3 alternativas más a Raspberry Pi.
ODROID-C4
En el anterior artículo uno de los modelos que analicé fue el Odroid-XU4. Esta placa tenía basicamente dos problemas:
a) El número de puertos USB
b) Necesidad de un ventilador
Dentro de la gama de tarjetas ODROID tenemos la placa ODROID-C4. Esta tarjeta no tienen ningúno de los problemas de su hermana.
Como puedes ver en la tabla de características esta placa está equipada con 4 puertos USB3.0.
También dispone de un conector eMMC donde se pueden conectar memorias de entre 8 y 64GB.
Ah, y una cosa muy curiosa que tiene este modelo es que incluye un receptor Infrarrojo. El cual puede servirte para manejar tu TV o estudiar el protocolo que usan tu mando y tu TV para comunicarse.
UP-CHT01
Cuando revisé las características de esta placa dos cosas me llamaron mucho la atención.
a) The SoC era un Intel (Intel® Atom™ x5-Z8350 Processor)
b) Lleva integrada una FPGA.
Los precios varían entre 109€ para el modelo de 1GB RAM/16GB eMMC y los 199€ para la versión con 4GB de RAM y 32GB de memoria eMMC. Además trae un conector que permite conectar un disco duro SSD adicional.
BEAGLEBONE BLACK
Soy consciente de que esta tarejta no es exactamente un «nuevo lanzamiento» y que lleva a la venta ya unos años.
Como puedes ver en la tabla de características no hay nada que sobresalga.
Entonces te puedes estar preguntando, «¿Porqué la incluyes en la lista?»
La razón es que esta placa es la mejor documentada del mercado.
Si por ejemplo quieres iniciarte en el desarrollo de drivers de Linux o hacer hacking del Kernel de Linux la extensa documentación que ofrece esta placa te ayudará mucho.
Por este motivo en muchos cursos de desarrollo de drivers utilizan esta placa.
CONTINUARÁ…?
En este artículo hemos visto tres alternativas muy interesantes a la Raspberry Pi.
Lo sé, has oído hablar del Arduino. Incluso has usado algunas placas y las has programado para hacer un pequeño proyecto.
Pero en este post, quiero dar una mirada diferente al Arduino.
No como un aficionado. Sino como un ingeniero con algunos conocimientos de sistemas embebidos.
Así que sin más preámbulos, ¡comencemos!
¿Es hardware? Por supuesto. Arduino es una serie de placas como Arduino nano, Arduino UNO, etc.
Todas tienen diferentes características pero una cosa en común. Todas se programan de la misma manera.
Y algo clave (que veremos más adelante) es que son de código abierto.
Es decir, tienes los diagramas de cableado y la lista de componentes disponibles.
Así que si quisieras, podrías hacer una placa igual o modificarla a tu gusto.
¿Pero, eso es todo?
No.
¿Es un software? Sí, señor. En realidad, la clave para que todas las placas Arduino (y compatibles) se programen de la misma manera es el SW que utilizan.
Todos los que desarrollamos en Arduino usamos las funciones digitalWrite y similares sin pensarlo demasiado.
Pero, ¿qué ocurre cuando llamamos a esa función?
Pues aquí está el secreto.
En cada placa, dependiendo del microcontrolador (Atmel, ARM, Espressif) las operaciones que se realizan entre bambalinas serán diferentes.
¿Y sabes dónde se define todo eso?
Dentro del core de Arduino.
El fabricante de la placa desarrolla el core de Arduino. Ya sea Arduino o, en el caso de una placa compatible, el fabricante correspondiente.
Pero como el HW es de código abierto, la «plataforma» también lo es, por lo que está perfectamente especificado cómo tiene que ser este core.
Así que si quieres hacer una placa con un microcontrolador raro/nuevo/lo que sea, puedes hacer esa placa compatible con Arduino.
¿Y eso es todo?
¡No querido!
¿Es un IDE? Exactamente. Porque puedes tener una gran placa y un gran núcleo, pero falta una cosa más.
Tu código
El código que escribes para controlar la temperatura de tu casa o la humedad de tus plantas.
Tu código tiene que ser compilado junto con el núcleo. Y, el «binario» resultante hay que grabarlo en la placa.
Todas esas cosas las hace el IDE de Arduino.
Pero, pero, pero. Igual que podemos usar placas Arduino compatibles o podemos crear nuestro propio Arduino Core para nuestra placa personalizada…
…podemos usar otros IDEs para compilar y flashear placas Arduino.
Una alternativa interesante al uso de Arduino IDE es el uso de Platform.io junto con VS Code.
(Si quieres saber más sobre VS Code aquí tienes un artículo que escribí hace tiempo hablando de las maravillas de VS Code. Eso si, está en inglés. Aunque como mi inglés no es para tirar cohetes seguro que no te cuesta mucho leerlo)
¿Es un programador? Es probable que, si eres joven, no lo hayas experimentado, pero en el pasado, flashear un microcontrolador era una tarea muy difícil.
Casi siempre necesitabas un programador específico para tu microcontrolador.
Y o bien tenías el dinero para comprar uno (y no eran precisamente baratos) o tenías que montar una versión casera tu mismo.
Los chicos de Arduino sabían que esto era una mierda. Así que decidieron hacerlo más fácil.
Así que equiparon sus placas con una cosa llamada «bootloader».
Que simplemente es un pequeño programa que se encarga de hacer dos cosas.
Iniciar un programa que se encuentra en una determinada dirección de memoria
Escuchar el puerto serie y esperar a que alguien le envíe un nuevo programa.
Y esto es lo que ocurre cuando quieres grabar una placa Arduino
Haces clic en el botón «flash», el IDE envía tu nuevo programa a través del puerto serie. El bootloader recibe los datos y los almacena en la memoria flash.
Imagen de ElectronicWings.com
Y cuando el MCU se reinicia, el nuevo programa se ejecuta.
¿Y eso es todo?
…últimas palabras sobre Arduino Como hemos dicho, tanto el HW, como el SW y el entorno de programación son de código abierto.
Y eso, amigo mío, aparte del buen diseño, ha sido la clave de su éxito.
¿Quieres hacer una placa compatible? No hay problema, usa sus esquemas, modifícalos a tu gusto y listo.
¿Quieres hacer tus propias librerías?. No hay problema, escribe tu propio código y ya está.
¿Quieres que tu placa sea compatible con Arduino? Entonces creas el core de Arduino siguiendo las instrucciones y voilà.
En pocas palabras, Arduino ha cubierto todas las partes de un sistema embebido (HW, SW de bajo nivel, Tooling y Flashing) para proporcionar a los aficionados y estudiantes una experiencia sin fisuras en la que sólo tienes que ocuparte de lo que realmente quieres hacer y olvidarte de todo lo demás.
Pero, también te da la libertad de modificar algunas de las partes (HW, SW o IDE) a tu gusto ampliando el espectro de personas que pueden utilizar la plataforma.
Espero que hayas disfrutado de este artículo y que a partir de ahora veas la plataforma Arduino bajo una nueva luz.
Estás cansado de escuchar Internet de las Cosas, IoT, y sus miles de eufemismos y derivados.
En las noticias, en la prensa, en anuncios de Youtube y hasta tu abuela te dice que le ha puesto un dispositivo IoT a su perro Max.
Y lo mismo alguna vez te has preguntado de que va esto del IoT o has googleado un poco y no te has enterado de una hijueputa mierda.
Pues estas de suerte.
En este post, te voy a contar que es esto del IoT y cuales son los 3 componentes fundamentales de un sistema IoT.
Una cosa es una cosa y seis media docena
Bueno, pues como no podía ser de otra forma si hablamos del «Internet de las cosas» es empezar hablando de «cosas».
¿Y que son esas cosas?
Redoble de timbales…
¡Microcontroladores!
Esos microcontroladores que siempre han estado en tu tele o en tu lavadora o en tu nevera o en tu estación meteorologica.
Pero resulta que esos microcontroladores, ahora gracias a los avances en comunicaciones tienen conectividad inalambrica.
WiFi, Bluetooth, ZigBee, LoRa, SigFox, NB-IoT, etc, etc, etc.
Le podemos dar muchas vueltas. Y meternos en muchos detalles, pero la diferencia entre un microcontrolador como los que se usaban para cacharrear hace 10 años y un flamante dispositivo IoT es la conectividad inalámbrica.
Los ríos desembocan en el mar
Vale, entonces el dispositivo IoT tiene conectividad inalámbrica.
¿Y a donde se conecta?
Pues mira, depende.
Algunos, sobre todo los que tienen conectividad directa con internet mediante WiFi o GPRS se conectarán con «la nube» como veremos en la siguiente sección.
Pero la mayoría, que tienen conectividad inalámbrica con protocolos que no permiten la conexión directa con la nube se conectarán con un intermediario.
Un cacharro que se encargará de recibir sus mensajes y mandarlos a la nube.
Estos cacharros, se llaman «Gateways» o puertas de enlace para los que no se manejen con la lengua de Shakespeare.
Y como su nombre indica se encargan de enlazar dos mundos.
Los mundos de los dispositivos IoT (Que hablan Bluetooth, Zigbee, LoRa o Sigfox) por un lado y la nube (que no deja de ser una máquina a la que te conectas por un socket).
Vivir en las nubes
Y para completar esta santa trinidad de los sistemas IoT nos falta hablar del destino final de todos esos datos que un día cogieron su petate, salieron del dispositivo IoT y pasaron por el gateway con rumbo… la nube.
Supongo que te lo estarías oliendo, pero por concretar un poco la cosa.
La operativa básica de un dispositivo IoT es medir alguna magnitud (temperatura, humedad, número de coches por hora en una calle o el índice de cuñadismo).
El caso es que esos datos de uno a muchos dispositivos IoT acaban llegando a la nube.
Y allí en primera instancia se hacen dos cosas con ellos.
Representarlos gráficamente y almacenarlos.
Luego en una segunda derivada y sobre todo si tenemos muchos dispositivos IoT mandando muchos datos es extraer información de ellos.
Puede ser mediante el tan manido «Data Science» o quizás entrenando con esos datos un modelo de Machine Learning que nos permita predecir cosas.
Todo esto de manejar grandes volúmenes de datos la gente lo llama «Big Data».
Resumen final
El mundo del «Internet de las cosas» puede ser confuso por la gran cantidad de palabras de moda (IoT, Cloud, Big Data).
Pero hemos visto que básicamente podemos entender un sistema IoT como un conjunto de dispositivos que generan datos, estos se enrutan a través de una puerta de enlace que consigue que lleguen a la nube donde son almacenados y procesados para poder extraer información útil de ellos.
En el los dos posts anteriores hemos preparado las herramientas que vamos a necesitar para conseguir hacer parpadear un LED.
Si acabas de incorporarte sin haber leido los posts anteriores y estas pensando «¿Pero cuantos posts necesita este fulano para enceder un puñetero LED?» Te recomiendo que empieces desde el principio. AQUI
HORA DE PISAR TECLAS
Y ahora que ya tenemos todos los «papeles» e información necesaria vamos a empezar a ver código.
Pero antes, una cosa más.
SETUP
Te voy a contar el setup que voy a utilizar para escribir y compilar todo nuestro código.
SO: *Linux Mint 19.2 Tina
IDE: Visual Studio Code (He vivido toda mi vida odiando a Microsoft, pero joder, este IDE es la hostia)
Compilador: arm-none-eabi-gcc-10.3.1 (GNU Arm Embedded Toolchain 10.3-2021.10) 10.3.1 20210824
*Nota 1: Uso Linux porque soy así, me gusta. Estoy casi seguro (no al 100% porque no pienso probarlo) que podrías instalar todas estas herramientas en Windows y obtener el mismo resultado. Puede que si usas el WLS(Windows Linux Subsystem) puedas replicar todos los pasos que voy a realizar como si estuvieras en una máquina Linux nativa (pero tampoco lo voy a hacer).
**Nota 2: El debugger SEGGER EDU es solo de uso educativo. Es decir, para cacharrear en casa o usarlo en centros educativos. Si usas este debugger (que vale 60€ en lugar de los 400€ de la versión comercial) para hacer cosas profesionales (es decir, cobrando por ellas), aparte de hacer llorar al niño jesus, puedes meterte en problemas legales. Avisado quedas!!
UN POQUITO DE ATAJO
En algún momento de esta serie de post te he dicho que ibamos a hacer parpadear un LED desde cero.
Pues soy un sucio mentiroso. No va ha ser desde cero, cero.
Voy a utilizar el SDK que provee el fabricante de nuestro SoC.
¿Que es un SDK?
Pues es una serie de librerias y código fuente que nos entrega el fabricante para que a nosotros los desarrolladores nos resulte más sencillo usar su SoC. Esto no lo hace porque sean como la madre Teresa de Calculta. Es un tema de pasta. Si usar su SoC es más sencillo que usar el de otra marca, pues nosotros, que lo que queremos es acabar nuestro curro rápido para irnos a beber cerveza compraremos sus microcontroladores.
¿Que incluye este SDK y en general cualquier SDK?
Pues ficheros de inicialización de muy bajo nivel (ensamblador), librerias y drivers de los diferentes periféricos que integra el SoC, ejemplos de uso de las diferentes funcionalidades que tiene el SoC, soporte para placas comerciales que la marca vende (una vez más poniendonos facil que nos dejemos la pasta en sus productos)
Entonces, partiendo del SW que hay en el SDK y apoyandome en el esquemático y el manual de referencia voy a adaptar el código de ejemplo de una placa similar a la nuestra (y con similar me refiero a que lleva el mismo SoC nRF52840).
Pero para purgar mi pecado de ser un mentiroso, voy a explicar lo que hacen cada uno de los ficheros que vamos a compilar y lo voy a enlazar con la información del manual y del esquemático. De tal forma que veas el proceso completo de como se hace el SW y como finalmente se ejecuta hasta que veamos el LED parpadear.
ENTENDIENDO EL SDK
Estructura carpetas SDK
Como puedes ver la estructura tiene bastantes carpetas. Pero para no perdernos por el camino, vamos a ir a la carpeta «examples» y desde allí vamos a empezar.
Dentro de la carpeta tenemos varias subcarpetas con exemplo de diferentes funcionalidades que tiene nuestro SoC (Bluetooth, cryptografía, NFC, etc)
Nos vamos a fijar en la carpeta peripherals que a su vez tiene más carpetas con ejemplos de como usar la memoria flash, el I2C, etc.
En ella tenemos una carpeta con un nombre bastante revelador. «Blinky».
Dentro veremos otras cuantas carpetas que corresponden a ejemplos para ser usados en varias de las tarjetas de desarrollo oficiales de Nordic Semiconductor.
En concreto nos interesa la carpeta pca10056. ¿Porque? pues porque esa tarjeta tiene el mismo SoC que nuestra Argon.
¿Y que vamos a hacer a continuación? Facil, lo que cualquier programador haría. Copiar la carpeta renombrandola como «particle_argon».
Yo la he llamado así en un alarde de originalidad, pero seguro que tu eres más imaginativo y le pones algún nombre loco como «ArgonKit», «ArgonBoard» o yo que se. !Que se note que somos gente que vivimos al límite!
CREANDO LOS FICHEROS DE NUESTRA PLACA
Bueno, pues ahora que tenemos nuestra carpeta para nuestra placa «inspirada» en otra similar, vamos a ir cambiando todas las cosas especificas de nuestra placa para llegara tener un impresionante y bonito LED parpadeante.
main.c
Empezamos por el main.
En ese archivo vamos a escribir la funcionalidad básica que queremos.
a) Configurar el pin al que está conectado el LED que queremos hacer parpadear com salida
b) Poner a 0 ese pin
b) Entrar en un bucle donde conmutamos el led cada 250ms
Inicialmente el ejemplo encendia y apagaba todos los leds de la placa en sucesión.
En nuestro caso, como solo queremos hacer parpadear uno, vamos a modificar el main para dejarlo así.
boards.h
En este fichero podemos ver dos partes importantes:
a) Las directivas de compilación condicional (lineas 46-93) que permiten incluir el header correspondiente a nuestra placa en función del define que esté habilitado. En nuestro caso al estar definido el define «BOARD_PARTICLE_ARGON» en el archivo Makefile el fichero que se utilizará será el «particle_argon.h» cuyo contenido vemos a continuación
b) Una serie de funciones genericas para utilizar nuestra placa. Dentro del fichero boards.c pueden verse la implementacion de cada una de estas funciones, aunque debido a lo minimalista de nuestro main no utilizamos ninguna de ellas.
particle_argon.h
En este archivo se definen las patillas asociadas a cada funcionalidad dentro de nuestra placa.
¿Os acordais del esquemático que conseguimos en el primer post?
Pues vamos a empezar a utilizarlo aquí.
Como puedes ver los pines donde están conectados los 3 LEDs RGB son los pines 13, 14 y 15 del puerto 0 y el LED de usuario al pin 12 del Puerto 1.
Pues bien, partiendo del fichero de configuración de la placa pca10056.h vemos que los LEDS se definen utilizando una macro que se llama NRF_GPIO_PIN_MAP la cual recibe dos parámetros. El número de puerto y el número de pin.
Esta claro que lo que tenemos que hacer el nuestro fichero particle_argon.h es definir los 4 leds que tiene nuestra placa de forma análoga. Y para ello utilizamos la información del esquemático.
Y antes de que te lo preguntes, vamos a ver que hace exactamente esa misteriosa macro NRF_GPIO_PIN_MAP(port, pin) y vamos a relacionarlo con el manual de referencia del SoC
Lo que hace es desplazar 5 posiciones a la izquierda el valor del campo «port» y luego hace una mascara del valor del campo pin y el valor hexadecimal «0x1F»
Basicamente está haciendo lo siguiente
port = 0b00000001 << 5
0b00100000
pin = 0b00001100 &
0b000FFFFF
value = 00100000 |
00001100
______________________________
00101100
Este valor es el que codifica el puerto y el número de pin
Ese valor es el que vamos a pasar a la función nrf_gpio_cfg_output que internamente llama a la función nrf_gpio_cfg
En esta función pasan dos cosas
a) Se obtiene la dirección de memoria donde están los registros para configurar esa patilla de ese puerto en concreto
b) Se setean los campos de ese registro para configurar la patilla como salida
Si vemos el apartado 6.9.2.10 podemos ver que sinifica cada uno de los 32 bits que conforman el registro.
*En el «code snippet» que ves encima están unificadas todas las funciones y defines relevantes para configurar el pin del LED correctamente. En el código real los valores están repartidos en 3 ficheros. nrf_gpio.h, nrfx.h y nrf52840_bitfields.h
Como vemos el puntero a la estructura NRF_GPIO_Type se le asigna la dirección 0x50000300 (linea 46 del code snippet)
Si miramos el manual vemos que en esa dirección tenemos los registros para manejar el puerto GPIO 1.
Y si comparamos la estructura NRF_GPIO_Type con los registros que aparecen en el manual de referencia vemos que coinciden.
Esta operación es muy común en sistemas embebidos y es definir una estructura que «mapea» una serie de registros en nuestro SoC.
Después definimos un puntero a ese tipo de estructura y le asignamos el valor de la dirección de memoria donde comienzan esos registros.
De esta forma cuando accedemos a cada uno de esos campos en nuestro puntero estamos escribiendo/leyendo en esos registros.
Makefile
El archivo Makefile contiene unas cuantas consas importantes que comentar.
En primer lugar los ficheros fuente que se van a compilar
Son solo 3. En el ejemplo de base habia unos cuantos más pero me he propuesto hacer algo «minimalista».
a) main.c
Nuestro querido main, que nunca puede faltar en un buen programa en C. Ya sabes lo que hace, porque lo hemos comentado previamente
b) system_nrf52840.c
Que en realidad es el fichero system_nrf52.c puesto que el fichero system_nrf52840.c solo tiene un include a system_nrf52.c.
Esta función basicamente implementa la función SystemInit y es la encargada de las inicializaciones del microcontrolador
– Reloj de sistema
– Configurar algunos perifericos de una forma específica para evitar ciertos fallos de fabricacion del microcontrolador*
c) gcc_startup_nrf52840.S
Este fichero es muy importante, porque es el encargado de realizar las operaciones de más bajo nivel y más especificas de la arquitectura.
Estas son – Definir la tabla de vectores de interrupción
– Definir la dirección de memoria del stack
– Definir la función Reset_Handler que será la encargada de:
– Copiar las variables de la memoria flash a la memoria RAM
– Las variables inicializadas a cero al segmento .bss
– Las variables inicializadas (a un valor distinto de cero) al segmento .data
– Saltar a la función SystemInit de la que hemos hablado hace un momento.
– Saltar a la función _mainCRTStartup que es una función que provee la toolchain dentro del fichero crt0.o** y que realiza las inicializaciones necesarias para tener un entorno de ejecucción para programas en C.
– Saltar a nuestra función main y comenzar a hacer parpadear nuestro LED
*Esto es bastante común y es conocido como «Errata». A veces los microcontroladores no se comportan como dice su manual de referencia. Esto, tarde o temprano es descubierto por algún usuario. La marca lo analiza y pueden pasar dos cosas.
a) Que el error sea simplemente del documento, y se edita una nueva versión del mismo corregido.
b)Puede que por un error de diseño hw el microcontrolador tiene un funcionamiento erroneo que se puede «arreglar» configurandolo de una forma especifica.
**CRT es el acrónimo de C Run Time. El fichero crt0.o, suele lincarse automágicamente por las toolchains y dentro se implementan las operaciones básicas que necesita un «main» de C para funcionar correctamente. Que resumiendo mucho son: Setear las variables no inicializadas (e inicializadas con valor cero) a cero y setear las variables que han sido seteadas con cualquier otro valor con su valor asignado. Y tras esas inicializaciones saltar a la funcion main.
OTROS ARCHIVOS IMPORTANTES
Y para terminar el recorrido por los archivos «oscuros» y «tenebrosos» llegamos al fichero blinky_gcc_nrf52.ld que es el fichero que utilizará nuestro linkador para formar nuestro binario.
Internamente el fichero blinky_gcc_nrf52.ld llama al fichero nrf_common.ld
Sin entrar en demasiados detalles, porque la sintaxis de los ficheros de lincado daría para una serie completa de posts, estos ficheros le dicen al linkador en que direcciones de memoria y en que orden colocar todos los objetos generados durante la compilación (ficheros .o)
GRABANDO NUESTRO BINARIO
Dentro de nuestro directorio _build vemos que se generan varios archivos al compilar.
A destacar
a) particle_argon.out -> fichero de salida en formato elf -> podemos desemsamblarlo para ver las operaciones que realiza en enesamblador
b) particle_argon.hex -> Fichero binario en formato hex (Para más info sobre el formato hex AQUI)
c) particle_argon.bin -> Fichero binario en formato binario (valga la redundancia) Este fichero grabado tal cual en nuestra memoria flash contiene todas las instrucciones en código máquina a ejecutar por nuestro SoC.
Para grabar nuestra tarjeta vamos a utilizar el debugger JFlash-EDU junto con el software JFlashLite
J-Flash Lite
Los pasos son realmente sencillos
a) Elegir el fichero a grabar
b) Borrar la tarjeta para asegurarnos de que grabamos correctamente
c) Pulsar en program
Si todo ha salido bién, deberíamos estar viendo a nuestro LED parpadear
Para muestra un botón
CODIGO EJEMPLO
El código que he utilizado puedes encontrarlo en mi repositorio de github
Ha sido un camino largo y tortuoso, que espero te haya gustado y en el que hayas aprendido algunas cosas sobre el oscuro pero apasionante mundo del desarrollo de firmware.
El próximo post no se de que será, pero intentaré que sea un poco mejor y sobre todo con menos faltas de otrografía.
En el anterior post de esta serie (si no lo has leído, ES AQUI) te desvelé la tarjeta que vamos a utilizar y nos hicimos con dos cosas importantes para alcanzar nuestro objetivo: El esquema electrónico de la placa y el manual del *microcontrolador.
*NOTA IMPORTANTE: A lo largo de la serie posiblemente utilice los términos «Microcontrolador», «SoC» (system on chip), «CPU» o «Chip» indistintamente. SE QUE TECNICAMENTE NO ES LO MISMO pero seguro que me perdonas.
Ahora es momento de hablar sobre las herramientas que necesitamos para llegar al «ambicioso» objetivo de hacer parpadear un LED.
Salvo que hables «maquina» necesitas un compilador
Puede que esto que te voy a decir ahora te sorprenda, pero…
Las CPUs basicamente ejecutan instrucciones que leen de una memoria.
¿Que instrucciones? pues simple y llanamente las que el fabricante de esa CPU ha introducido en su diseño.
En el caso concreto del SoC nRF52840, la CPU que tiene dentro es un ARM Cortex-M4F**.
Arquitectura SoC nRF52840
**Nota aclaratoria: El fabricante del SoC (Nordic Semiconductor) ha incluido dentro de su diseño una CPU de marca ARM. Aunque no lo sepas ARM no fabrica ni un solo semiconductor.
¿Pero si todos los móviles y otros muchos dispositivos llevan CPUs ARM, quien los fabrica?
Pues bien, ARM solo diseña CPUs. Y luego cobra una licencia a los fabricantes de semiconductores por usar sus diseños.
En este caso Nordic Semiconductor estará pagando unos royalties para poder incluir dentro de su chip esa CPU.
Vale y después de este paréntesis, continuamos…
Como la CPU es ARM, las instrucciones que puede ejecutar esa CPU estarán especificadas por el fabricante (ARM).
En el caso concreto del ARM Cortex-M4F las instrucciones disponibles están descritas AQUI.
Si has echado un vistazo al enlace igual no has entendido nada.
Pero aquí estoy yo para explicártelo.
Para programar una CPU puedes hacer 3 cosas
a) Escribir las instrucciones en código máquina. Técnicamente se podría, pero sería básicamente como «ver matrix» porque tendrías que escribir codigos binarios en un fichero con todas las instrucciones de tu programa. DESCARTADO!!
b) Escribir las instrucciones en ensamblador. El ensamblador es un lenguaje más «amigable» para un humano (aunque no mucho) y facilita la tarea (todas las instrucciones que aparecen en el enlace de arriba son en ensamblador).
Eso si, tienes que tener en cuenta que para traducir ese código ensamblador en código máquina necesitas un traductor (AKA: Compilador)
c) Escribir tu programa en un lenguaje de alto nivel como C/C++ o «the new kid on the block» Rust. Obviamente para obtener código máquina a partir de este programa escrito en alguno de estos lenguajes también necesitas un compilador.
Y tras estos prolegómenos vamos a lo importante.
¿QUE COMPILADOR ELEGIMOS?
Para saber eso necesitamos dos datos
a) que CPU vamos a usar
En nuestro caso un ARM Cortex-M4F
b) Para que tipo de sistema vamos a generar código
Aquí hay dos opciones. Bare-Metal (Sin sistema operativo) o sobre un sistema operativo (tipicamente linux).
En nuestro caso, la opción será bare-metal porque no vamos a tener sistema operativo.
Si accedemos a la página de ARM donde están sus *toolchains AQUI veremos dos opciones de toolchain. Y la que obviamente la que nos interesa es la siguiente:
*Toolchain es el término que se emplea para referirse al compilador y a otras herramientas necesarias para generar nuestros binarios y también para analizarlos y depurarlos.
COMO GRABAMOS EL CÓDIGO
Vale, ya tenemos la toolchain que nos permitirá compilar nuestro código (cuando tengamos algo de código) en un fichero (también conocido como binario).
Pero, ¿Como grabo ese binario en mi tarjeta?
La primera opción es utilizando un debugger que se conectará a nuestro SoC usando el puerto JTAG y nos permitirá escribir en la memoria flash del dispositivo.
Debugger Segger
Vale, se lo que estas pensando. Que tu no tienes un trasto de esos.
Pues la segunda opción es grabar la memoria flash a través del puerto USB de la tarjeta.
IMPORTANTE: Para que puedas hacer eso, tu tarjeta tiene que tener pregrabado un bootloader.
Y antes de que me preguntes, te cuento lo que es un bootloader.
Un bootloader es un pequeño programa que se graba al inicio de la memoria flash, de tal modo que siempre lo primero que se ejecuta al arrancar el chip es ese programa.
¿Y que hace ese programa? Pues basicamente 2 cosas
a) Escuchar en el puerto USB por si hay una petición para escribir una nueva aplicación y si es así recibir los datos e irlos grabando en la zona de memoria flash permitida
b) Si no hay peticion para grabar datos saltar a la dirección de memoria donde está la aplicación y ejecutarla.
Particionado de la memoria flash con bootloader pregrabado
Si miras en la tabla de arriba aparte del bootloader y la aplicación hay algunas cosas más.
Te las cuento muy por encima:
MBR (Master boot Record): En realidad esto es lo primero que se ejecuta al encender nuestra placa y se encarga de hacer algunas inicializaciones y salta al bootloader.
SoftDevice: El stack de Bluetooth y algunas cosas más que nuestros amigos de Nordic nos da ya compiladas (pero sin código fuente).
Bootloader settings & MBR parameter storage: Zonas donde se almacenan datos de configuración para el MBR y el bootloader.
No voy a comentar mucho más porque entraremos en más detalles en siguientes posts.
RESUMIENDO
En la primera entrega nos hicimos con algunos documentos que necesitaremos para llevar a cabo nuestra misión.
En esta segunda entrega hemos visto que compilador utilizaremos y como grabaremos nuestra aplicación en nuestra tarjeta.
…Y EN EL PROXIMO POST?
En el próximo post entraremos a ver el SDK del microcontrolador, como tunearlo para nuestra placa específica (usando el esquemático y el manual de referencia) y alguna cosa más que aún no he decidido…
Este es el primero de una serie de posts que voy a dedicar a entender como se pasa de una tarjeta electrónica «vacia» a tener un dispositivo con un software mínimo que nos permita hacer tareas alucinantes como… encender un LED
Prólogo
Antes de meternos en harina tienes que saber unas cuantas cosas.
Lo primero, que la tarjeta que voy a utilizar es la Argon kit de la firma Particle.
Argon Kit con sus accesorios: Bread board, antena WiFi, cable USB, LEDs y resistencias.
Las características más destacables de esta placa son:
20 patillas de GPIO que pueden configurarse como PWM, I2C, SPI, UART
JTAG
Connector SWD para usar In-Circuit Debuggers
LED
1 x LED RBC conectado a 3 de las salidas GPIO 1 x LED monocolor azul conectado a otra salida GPIO
Carga
Conector para batería LiPo
USB
Conector USB para alimentación / UART y grabación de Firmware mediante el bootloader.
Botones
Reset y Mode
Especificaciones de la Argon Kit
¿Por qué esta placa?
Pues por dos motivos. Primero que es una placa que tenía en casa. Ya sabes, de esas que compras en una preventa mientras te prometes que no le pasará lo mismo que a las 15 anteriores…
…eso fue en noviembre de 2018
El segundo motivo es porque el MCU (SoC o como quieras llamarlo) principal de esta placa es de la marca Nordic Semiconductor en concreto de la familia nRF528xx.
Es una familia muy extendida desde hace 3-4 años en el mercado y NO HE TRABAJADO NUNCA CON ELLA.
Espera, ¿que?. ¿Y como se supone que vas a enseñarnos a hacer algo útil?
Una cosa que quiero demostrar con este tutorial es que teniendo claros unos conceptos básicos, puedes enfrentarte con cualquier Microcontrolador/Microprocesador/SoC (o el nombre molón que le pongan a la siguiente generación semiconductores) y salir victorioso.
Consiguiendo el mapa del tesoro
En esto de los sistemas embebidos, puesto que vas a meter en terrenos inexplorados lo primero que tenemos que conseguir es documentación.
¿Documentación sobre que? Pues sobre dos cosas
a) Esquema electrónico (o esquemático)
Lo que nos permitirá saber como está conectado todo.
Extracto del esquematico de la placa Argon Kit
Por ejemplo, en el extracto del esquemático del Argon Kit vemos que el LED RGB está conectado a 3 patillas que se llaman P0.13(Rojo), P0.14(Verde) y P0.15(Azul).
Que son esas patillas y que significan los nombres que tienen, lo veremos más adelante.
Si quieres ver el esquemático del Argon Kit. PINCHA AQUÍ
b) Manual de referencia
En este manual, que habitualmente tiene cientos de páginas el fabricante cuenta con pelos y señales todas las interioridades del chip en cuestión.
Secuencia de arranque, mapa de memoria, configuración de los periféricos, cuanta memoria flash tiene, cuanta memoria RAM, como se accede a ella, etc.
Además suele tener entremezclada información sobre características puramente electrónicas. Voltajes de operación, corrientes máximas, esquemas de conexión básicos, consideraciones a la hora de hacer un PCB para este chip, etc.
Si quieres ver el manual del nRF52840. PINCHA AQUÍ
!551 páginas de indómita e indigesta información!
Separando en grano de la paja
Como comentaba hace un momento, en el manual de referencia se mezclan datos de dos tipos que interesan a diferentes personas.
Por un lado información eléctrica/electrónica que interesa al diseñador de PCB o Ingeniero Electrónico que vaya a diseñar una placa con este SoC.
Y por otro lado información que necesita alguien que como nosotros quiera ejecutar algún SW en ese SoC.
Una de las cosas más importantes a la hora de desarrollar SW embebido para una tarjeta es saber extraer la información de este tipo de manuales y saber como aplicarla en nuestro software.
A lo largo de la serie veremos ejemplos concretos sobre como configurar diferentes periféricos del SoC en nuestro SW a partir de la información extraída del manual de referencia.
En el próximo capítulo…
En este primer capítulo hemos hecho las presentaciones y dado algunas pinceladas de cosas a tener en cuenta a la hora de convertir un ladrillo en algo útil.
En la segunda parte del post hablaremos de las herramientas SW que utilizaremos para dar vida a nuestro ladrillo.
Pero por hoy es suficiente, que no quiero provocar derrames cerebrales masivos nada más empezar.
Y ahora vamos cuales son los puntos fuertes de esta tarjeta.
SoC (Media docena de cores, nada menos)
Lo primero, su procesador. El SoC de la firma RockChip tiene 6 cores de los cuales 2 son A72 y 4 son A53.
Esto de mezclar núcleos diferentes se denomina «heterogeneous computing» y como su nombre indica (oh sorpresa) consiste en mezclar nucleos de diferente topología en un mismo chip.
A este tipo de configuraciones ARM las denomina big.LITTLE*.
Pueden ser una alternativa muy interesante en caso de querer experimentar con hypervisores bare-metal o pruebas de concepto de sistemas críticos como entornos de automoción o aviónica donde tenemos aplicaciones de diferente «criticidad» corriendo dentro del mismo SoC aisladas unas de otras.
Aplicaciones de diferente criticidad corriendo aisladas en diferentes cores
Memoria eMMC
Si recuerdas (y si no lo recuerdas, léelo aquí) la raspberry pi usa tarjetas microSD para almacenar todos sus ficheros.
Orange Pi también tiene un lector de tarjetas micro SD pero, opcionalmente (pagando más obviamente) puede llevar un módulo eMMC de 16GB como sistema de almacenamiento.
Alguna pega tenía que tener…
Para ser justos y que no me tachen de parcial, también hay que comentar algunas cosas de la Orange Pi que son mejorables.
Puertos USB
Orange Pi tiene un puerto USB menos que su homologa la Raspberry Pi. Puede parecer una nimiedad, pero en estos tiempos donde una gran cantidad de periféricos son USB, ese USB de menos puede darnos dolores de cabeza.
Precio
Pues si, las características HW de esta tarjeta son impresionantes, pero el precio no es demasiado ajustado. La versión con módulo eMMC supera los 140€ y eso es una cantidad de dinero que pare un hobbista puede ser algo elevada.
*La primera generación de SoC heterogeneos se denominó Big.LITTLE pero posteriormente ARM lanzó una evolución de esta tecnología que denominó DynamiIQ.
ROCK64PRO
ROCK64PRO
En primer lugar, vamos a ver las características de esta tarjeta.
Esta tarjeta es muy similar a la Orange Pi. Tiene basicamente el mismo SoC y el mismo número de puertos por lo que no voy a comentar mucho por ese lado.
Memoria hasta 64GB
Lo que si cabe destacar es que tiene 3 tamaños diferentes de memoria eMMC, 16GB, 32GB y 64GB.
Precio
Algo a destacar de esta tarjeta es el precio.
La versión sin memoria eMMC cuesta 79$, 95$ con eMMC de 16GB, 101$ con 32GB y 115$ con 64GB. Unos precios bastante más bajos que la Orange Pi con unas características casi calcadas.
Conector PCIe
Otro elemento muy a tener en cuenta es la ranura PCIe «open-ended» que nos permitiría conectar tarjetas PCIe convencionales. De hecho uno de los accesorios que vende Pine es un adaptador PCIe-M.2 (por solo 5,99$) que nos permitiría conectar un disco de estado sólido de última generación.
Alguna pega tenía que tener…
En el apartado de cosas menos buenas, la ROCK64PRO presenta el mismo problema que su prima-hermana la Orange Pi. Se echa de menos tener algún USB más.
ODROID-XU4
Y en tercer lugar, vamos a ver que nos ofrece la ODROID-XU4.
ODROID-XU4
CPU
Samsung Exynos5422 Cortex™-A15 2Ghz and Cortex™-A7 Octa core CPUs
RAM
2GB
USB
2xUSB3.0 1xUSB3.0 1xUSB-C
Almacenamiento
tarjeta microSD * Modulo 8GB/16GB/32GB/64GB eMMC
Salida video
1xHDMI
PCIe
No
*Modulo eMMC es opcional
SoC (8 cores, no hay más preguntas su señoria)
El SoC que monta esta odroid-XU4 es una auténtica bestia (ya se que el adjetivo «bestia» está muy manido, pero es tarde, estoy cansado y suspendía lenguaje en el instituto).
En este caso el SoC es de la firma Samsung (especialista en hacer moviles que explotan) y tiene 4 cores A15 y 4 cores A7.
Precio
Una cosa muy a destacar de esta tarjeta es el precio. Solo 59$. Una calidad/precio brutal.
Alguna pega tenía que tener…
En el apartado de cosas malas, la ODROID tiene un par.
Ventilador
Un ventilador siempre es algo indeseable en una SBC. Hace ruido y en caso de fallar puede provocar un sobrecalentamiento de la CPU y producirse daños.
RAM
A diferencia de las otras dos tarjetas comparadas la ODROID tiene solo 2GB. Que para una tarjeta de este calibre se queda un poco escasa.
ASÍ SON LAS COSAS Y ASI SE LAS HEMOS CONTADO
Como has podido comprobar, en el mercado existen muchas alternativas a la raspberry pi y en este post hemos analizado 3 de ellas para que puedas elegir una tarjeta que se ajuste a tus necesidades.
Salvo que hayas estado metido en una cueva los últimos 10 años seguramente sabrás que es una Raspberry Pi.
Podría repetir las «ventajas» que ya habrás leído 10 trillones de veces.
Que si es open source, que si es muy barata, tiene una gran comunidad detrás, etc, etc, etc.
Pero el objetivo de este post es justamente el contrario.
!Vamos a airear las miserias de este miniordenador!
Porque hasta el príncipe azul más apuesto se tira pedos.
Software no tan libre
¿Como, ahora vas a decir que el software de la Raspberry Pi no es libre?
¡Explícate maldito hereje!
Sin entrar en detalles innecesarios el corazón de la Raspberry Pi lo forman dos componentes: La GPU y la CPU (bueno, es un System-on-Chip o SoC, pero eso, otro día te lo cuento)
Cuando arrancas tu raspberry Pi pasan unas cuantas cosas hasta que tu flamante Raspbian está operativo.
Se pueden resumir en 5 pasos.
1.La GPU ejecuta el código de arranque almacenado en su memoria ROM, el cual lee el fichero bootcode.bin de la tarjeta SD y lo carga en la memoria caché L2.
Este código de que hay en la ROM es open source?… Negativo!!!
2. Se ejecuta el código del fichero bootcode.bin el cual habilita la memoria SDRAM y carga el fichero loader.bin.
El fichero bootcode.bin ? Nop, tampoco es open source…
3. El fichero loader.bin lee el fichero start.elf de la tarjeta SD.
Lo has adivinado verdad? El fichero loader.bin , tampoco es open source.
4. El fichero start.elf se encarga de cargar el fichero kernel.img.
¿Y start.elf ? No quiero ser repetitivo, pero… no.
5. Se ejecuta el fichero kernel.img
El fichero kernel.img … Si, este sí!!
Este fichero es el resultado de compilar un Kernel de Linux, el cual podemos obtener si problemas del repositorio de GitHub de Raspberry Pi.
Resumiendo…
5 binarios ejecutados desde que alimentas tu Raspberry Pi
4 Propietarios
1 Open source
Está claro que una vez arrancas tu Raspberry todo el ecosistema Raspbian, todas las aplicaciones, librerías, etc. son open source y quizás por eso nunca te has planteado otra cosa.
Pero si alguna vez necesitas/quieres cacharrear con una GPU o con la secuencia de arranque en un miniordenador, quizás Raspberry Pi no es tu mejor opción.
Sistema de almacenamiento
Este desde mi punto de vista es una de las partes más débiles del diseño hardware de la raspberry Pi.
Como sabrás, todos los ficheros que necesita la raspberry Pi para funcionar se almacenan en una tarjeta micro SD (SD en las versiones más antiguas).
Estos dispositivos de almacenamiento, son bastante lentos comparados con otros como una memoria USB, un disco SSD o una memoria Flash integrada en la placa.
Además, si alguna vez has hecho un uso intensivo de tu raspberry Pi, descargando torrents (suponiendo que seas un carca como yo) o haciendo streaming de video sabrás que las tarjetas SD tienen costumbre de corromperse.
En mi trabajo, he trabajado con unas cuantas tarjetas electrónicas utilizadas en sistemas críticos (sistemas de gestión de energía, trenes, autobuses) los cuales suelen funcionar incluso años sin reiniciarse y te puedo decir que nunca he usado tarjetas SD.
Y antes de que alguien me diga. ¡Oye, pero la raspberry pi 4 permite arranque desde memorias USB!
Si, lo sé. Pero esto es algo que todavía es experimental y debido a la baja corriente que entregan los puertos USB de la raspberry pi hay memorias que no funcionan correctamente y a veces es necesario alimentaciones externas o inventos muy turbios.
¿Como ordenador de escritorio? Ni lo sueñes
Si has usado una Raspberry Pi con un entorno completo de escritorio habrás comprobado lo frustrante que es.
El sistema de ventanas es horrible. La velocidad es regulera siendo muy benévolo.
Definitivamente el reclamo comercial de «Un PC de escritorio por 40€» es completamente falso.
Si quieres un miniordenador para hacer tareas básicas, hay en el mercado verdaderos minordenadores por menos de 200€ que cumplirán mucho mejor tus expectativas en cuanto a rendimiento y estética.
Ultimas palabras
Como has visto, en la raspberry pi no es oro todo lo que reluce y hay ciertos usos para los que este dispositivo no es la mejor elección.
En próximos posts hablaré de otros miniordenadores quizás menos conocidos pero que pueden utilizarse para cosas donde la raspberry pi flaquea.
Ya se que no suena bonito, pero deja que te cuente mi historia.
Llevo más de 10 años casado con mi querida pareja «la señora empresa».
Ella es buena y me aporta estabilidad.
Hacemos cosas de matrimonios.
Dormimos 8 horas en la misma cama, nos vamos de vacaciones, tenemos sexo una vez a final de mes. A veces, incluso dos veces.
Tenemos una casa bonita con «open concept». Tiene grandes cristaleras y es muy luminosa.
Pero después de tantos años, la monotonía empezó a incomodarme y me picó el gusanillo de ver que había por ahí fuera.
Y aquí estoy hoy, en busca de relaciones esporádicas que me permitan saber si lo que quiero es simplemente divertirme un poco o si tengo que divorciarme de «la señora empresa».
