Categorías
Hardware

El ladrillo que se convierte en un LED que brilla (parte 3)

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

Debugger: Segger J-Link EDU**

SW Debugger: JLink 7.6.0 (paquete debian aquí)

Nordic SDK: nRF5_SDK_17.1.0

*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

AQUI

DESPEDIDA Y CIERRE

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.

Categorías
Hardware

El ladrillo que se convierte en un LED que brilla (parte 2)

En capítulos anteriores…

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.

Alta Velocidad j-link JLink V8 USB ARM JTAG Depurador del emulador j-link V8 emulador
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…

Categorías
Hardware

El ladrillo que se convierte en un LED que brilla. (Parte 1)

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

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, IoT Starter Kit – Particle Retail
Argon Kit con sus accesorios:
Bread board, antena WiFi, cable USB, LEDs y resistencias.

Las características más destacables de esta placa son:

MCU PrincipalNordic Semiconductor nRF52840 SoC
ARM Cortex-M4F 32-bit processor @ 64MHz
1MB flash, 256KB RAM
MCU SecundarioEspressif ESP32-D0WD 2.4G Wi-Fi coprocessor
SPI-Flash4MB
I/O20 patillas de GPIO que pueden configurarse como PWM, I2C, SPI, UART
JTAGConnector SWD para usar In-Circuit Debuggers
LED1 x LED RBC conectado a 3 de las salidas GPIO
1 x LED monocolor azul conectado a otra salida GPIO
CargaConector para batería LiPo
USBConector USB para alimentación / UART y grabación de Firmware mediante el bootloader.
BotonesReset 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.

Categorías
Hardware

3 alternativas a raspberry pi

En el anterior post hablé sobre algunos puntos débiles de la archiconocida (dios, siempre he querido usar esta palabra) Raspberry Pi.

Y como uno no puede pasarse la vida quejándose sin buscar soluciones…

…en este post vamos a ver 3 alternativas muy interesantes a la raspberry pi.

Orange Pi

Para empezar no puedo resistirme a hablar sobre el nombre así que aquí va un…

<MOMENTO PEDANTE>

Raspberry pi es un juego de palabras.

Si lo pronuncias bien en inglés (y seguro que tu lo harás porque tienes nivel medio-alto 😉) suena como «raspberry pie» es decir, tarta de frambuesas.

Vale, y la gente come tarta de frambuesas.

Pero, ¿tarta de naranja? Joder, no me puedo imaginar algo más repugnante.

Vale y hasta aquí el…

</MOMENTO PEDANTE>

La declaración de intenciones de este SBC es claro. Ser un clon o sustitutivo de la raspberry pi.

Para ello copia su tamaño y las diferentes conexiones incluido el header de 40 pin cuyo pinout es prácticamente idéntico entre las dos.

Pero para tener claro que es lo que ofrece la Orange Pi vamos a una tabla con sus características principales.

CPURockchip RK3399 Hexa-Core (2xCortex-A72 + 4xCortex-A53)
RAM4GB
USB1xUSB2.0
2xUSB3.0
1xUSB-C
Almacenamientotarjeta microSD
*Modulo 16GB eMMC
Salida video1xHDMI
1xDP
PCIeConector 24pin
*El módulo es opcional

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.

CPURockchip RK3399 Hexa-Core (2xCortex-A72 + 4xCortex-A53)
RAM4GB
USB2xUSB2.0
1xUSB3.0
1xUSB-C
Almacenamientotarjeta microSD
*Modulo 16GB/32GB/64GB eMMC
Salida video1xHDMI
1xDP (USB-C)
PCIeConector «open-ended» 4x
*Los módulos se venden por separado.

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
CPUSamsung Exynos5422 Cortex™-A15 2Ghz and Cortex™-A7 Octa core CPUs
RAM2GB
USB2xUSB3.0
1xUSB3.0
1xUSB-C
Almacenamientotarjeta microSD
* Modulo 8GB/16GB/32GB/64GB eMMC
Salida video1xHDMI
PCIeNo
*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.

Categorías
Hardware

3 razones para repudiar tu Raspberry Pi

Photo by Vishnu Mohanan on Unsplash

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.