Menu
Programación

Programación

Cómo programar ensamblador ARM de forma libre SIN MORIR EN EL INTENTO

Cómo programar ensamblador ARM de forma libre SIN MORIR EN EL INTENTO

¡Buenas noches, tardes o mañanas a todos los que nos leeis!

Soy Pedro Javier (@pedro-javierf) y hoy me estreno en el blog de LibreLabUCM. Finalmente, vamos a ver cómo poder programar para la asignatura de Fundamentos de los Computadores (aka FC 1) en ensamblador de ARM, desde Linux.

Cómo muchos sabréis, en la FDI se nos provee de unas herramientas anticuadas, desfasadas, y solo funcionales en WIndows de 32 bits!. Vamos a ver como poder programar con un ensamblador (y linker) moderno para ARM y desde nuestra distro favorita.

El proceso se resume en 4 sencillos pasos:

  • 1. Instalar las toolchains
  • 2. Instalar Eclipse
  • 3. Crear un proyecto, ¡que compila!
  • 4. Notas y avisos finales

1. Instalar Las Toolchains

Nos dirigimos a la siguiente URL

Y descargamos la última versión disponible. En este caso yo usaré la siguiente, a fecha de 2019.

gnu-mcu-eclipse-arm-none-eabi-gcc-8.2.1-1.3-20190202-1016-centos64.tgz

NOTA: Las toolchains se compilan en centos, de ahí el nombre, pero funcionan en cualquier distro.

Una vez descargado, preferiblemente la versión de 64 bits, ejecutamos los siguientes comandos:

sudo mv archivo.tgz /opt/  --> Movemos el archivo comprimido a la carpeta /opt/ (programas externos que se instalan en linux)

cd /opt/

sudo tar -xvzf archivo.tgz  --> Desempaquetamos el archivo

Debemos tener finalmente una carpeta llamada gnu-mcu-eclipse en opt. La ruta quedaría de la siguiente forma: /opt/gnu-mcu-eclipse.

Vamos a probar si las toolchains funcionan. Podemos ejecutar el siguiente comando en la terminal: 

/opt/gnu-mcu-eclipse/arm-none-eabi-gcc/8.2.1-1.3-20190202-1016/bin/arm-none-eabi-gcc --version

NOTA: Los números de versión del comando cambiarán. Es decir, en vez de 8.2.1-1.3-20190202vosotros tendréis un número diferente. 

Si el resultado del comando anterior es:

arm-none-eabi-gcc (GNU MCU Eclipse ARM Embedded GCC, 64-bit)

Vamos por el buen camino!

Es muy importante que la carpeta que tengamos finalmente en /opt/ se llame gnu-mcu-eclipse y nada más. De esta forma, en el paso posterior, eclipse podrá detectarla automaticamente.

2. Instalar Eclipse

A continuación instalaremos una versión especial de eclipse, con los plugins para ARM, que detectará automaticamente las toolchains que hemos instalado anteriormente.

Nos dirigimos a la siguiente URL

Y descargamos el archivo comprimido tar. En mi caso: 20190101-2023-gnumcueclipse-4.5.1-2018-12-R-linux.gtk.x86_64.tar.gz

De nuevo, lo moveremos a /opt/ , donde habíamos instalado las toolchains.

sudo mv archivo2.tgz /opt/  --> Movemos el archivo comprimido a la carpeta /opt/ 

cd /opt/

sudo tar -xvzf archivo2.tgz  --> Desempaquetamos el archivo

Debemos obtener una carpeta llamada eclipse.

Dentro de esta carpeta, se encuentra el binario eclipse, que podremos ejecutar con ./ eclipse

 

3. Crear un proyecto, ¡que compila!

Para crear proyectos y compilar fácilmente, haremos lo siguiente.

New > Project > C Project    y Hacemos click en Next.

Después nos servirá

Empty Project > ARM Cross GCC  e Introducimos el nombre de nuestro proyecto. Por ejemplo HelloWorld.

Hacemos click en next hasta llegar a la siguiente pestaña.

Como podéis ver, si hemos instalado las toolchains correctamente en el paso anterior, se nos mostrará el PATH de las toolchains automáticamente. Hacemos click en Finish, y listo!

A continuación, crearemos un archivo de código ensamblador. Hay que usar la extensión *.s , no *.asm.

File > New > Source File 

De nombre pondremos: main.s

Finalente, y este paso solo tendremos que hacerlo una sola vez (es una configuración general para todos los proyectos) tendremos que hacer que eclipse reconozca los archivos .s como archivos de código.

Project Properties > C/C++ General > File Types > Use project settings > New >
E introducimos lo siguiente:
Pattern: *.s,
Type: Assembly Source File y hacemos click en OK.

Listo! eclipse compila y está listo. Os dejo un código de prueba para que comprobeis que funciona:

.global main
.global _exit
.equ ONE, 0x01
.dataMYVAR: 
.word 0x02
.bss
RES: 
.space 4
.text
main:
MOV R0, #ONE
LDR R1, =MYVAR
LDR R2, [R1]
ADD R3, R0, R2
LDR R4, =RES
STR R3, [R4]
END:
B ._exit:
exit:
.end



Haremos click sobre el icono del martillo. Si todo transcurre sin problemas, todo ha ido de forma correcta.

4. Notas y avisos finales

Si habréis leido el (simple) código anterior, habréis notado algo: hay un par de declaraciones globales nuevas: 

.global main

.global _exit

En resumen. Los ARM que se utilizan en la FDI son muy muy antiguos (2006 aprox) y no eran muy estrictos a la hora de como debía estar formateado el código. El punto de entrada (donde el código empieza) siempre ha sido start pero en este caso o he renombrado a main, que es lo que espera por defecto las toolchains de GNU. Aunque seguro seguro que hay una forma de que empieze en start, pronto investigaré sobre ello. De momento, lo dejamos así. También he añadido una "label" nueva, llamada :_exit, que al igual que :end, apunta al final del programa. De igual manera es necesaria por las herramientas de GNU, pero no afecta al programa como podréis comprobar.

Esto es todo! pronto aprenderemos a debuggear los programas creados ;)

Un saludo!

pedro-javierf

Leer más

Cómo migrar de GitHub a GitLab

Gitlab wallpaper

¿Debería migrar a GitLab?

Recientemente se han dado ciertos cambios en GitHub que no han sido muy bien recibidos por la comunidad (como su adquisición por Microsoft).

Sea como sea, GitHub es una plataforma privativa, y existen excelentes alternativas libres como GitLab.

En esta entrada del blog explicaremos cómo migrar de GitHub a GitLab de la forma más simple y efectiva.

Recientemente hemos montado nuestro propios servidor con GitLab, así que ese será el que usemos en estos ejemplos (pero estos mismos pasos se aplican igual en cualquier otro).

GitLab además ofrece muchísimas características que lo hacen único y que ayudan mucho a la hora de usar git en un proyecto.

 Nuestra recomendación desde LibreLabUCM es, sin duda alguna, que uses GitLab siempre que sea posible.

Estamos seguros de que no te va a desilusionar, y de que una vez lo pruebes las alternativas como GitHub se te quedarán cortas.

Creando una cuenta

Nos dirigimos a https://gitlab.com/users/sign_in o, en nuestro caso, a https://gitlab.librelabucm.org/users/sign_in , y procedemos a crearnos una cuenta.

Podemos elegir la opción de registrarse usando otra cuenta de terceros.

Una vez creada la cuenta podemos editar nuestro perfil para personalizarlo a nuestro gusto.

Importante mirar la privacidad de nuestro email, y la cuenta de email con la que se harán los commits.

Configurar nuestras claves SSH

Las claves SSH tienen muchísima utilidad, git es sólo una de sus muchas aplicaciones.

Normalmente los pares de claves SSH se usar para realizar un proceso de autenticación seguro.

Recomiendo tener un par de claves (una pública y una privada) en cada uno de nuestros dispositivos.

¿No tienes claves SSH? ¿Estás algo perdido en esto de las claves SSH?

Aquí tenemos un artículo que explica en más detalle qué son, como se crean y cómo se usan.

¿Ya tienes tus claves SSH listas? ¡Genial! Vamos a configurarlas en GitLab.

Iremos a los ajustes de nuestra cuenta, a la sección "SSH Keys" o "Claves SSH". Veremos un área de texto grande en el que tendremos que poner nuestra clave pública.

Para obtener lo que tenemos que poner aquí podemos ejecutar el siguiente comando:

cat ~/.ssh/id_rsa.pub

Es muy importante que el archivo seleccionado terminé en .pub ya que este es la clave pública.

El archivo "id_rsa" que no termina en ".pub" es la clave privada que NO debemos compartir con nadie ni subir a ninguna web.

Ahora que ya hemos configurado nuestra clave pública en GitLab comprobemos si ya tenemos acceso.

Para ello intentaremos conectarnos por SSH al servidor usando el usuario git:

ssh Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.

Para el servidor de LibreLabUCM (al que se accede por el puerto 8022): 

ssh Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo. -p 8022

En cualquier caso deberíamos ver un mensaje Ok en el que se nos informa de que GitLab no permite acceso a la terminal.

Si nos da un error de autenticación, o si nos pide que escribamos una contraseña, entonces no hemos configurado la clave SSH correctamente y tendremos que revisarlo.

Configurar nuestra clave GPG

Tras seguir los pasos indicados en el tutorial de GPG para crear una clave GPG podemos exportarla con el siguiente comando:

gpg --armor --export IDENTIFICADOR

Y luego podemos importarla a nuestra de GitLab en https://gitlab.com/profile/gpg_keys o en https://gitlab.librelabucm.org/profile/gpg_keys

Usar el importador de GitLab para migrar los repositorios

Una vez se tiene cuenta en GitLab podemos usar su importador automático para importar repositorios de otros servidores.

Recomiendo usar este método super que sea posible, no solo por ser el más fácil, también por que GitLab importará Pull Requests, issues, y otros datos relacionados con el repositorio.

Para ello haremos clic en el icono "+" de crear nuevo repositorio, seleccionaremos la pestaña "Importar", y elegiremos de donde queremos importar (en nuestro caso, de GitHub).

Tras dar permiso a GitLab para que acceda a nuestra cuenta de GitHub veremos la lista con todos nuestros repositorios, y simplemente tendremos que hacer clic en el botón importar de aquellos que queramos.

Configurar los repositorios locales para trabajar en GitLab

Lo más probable es que tengas en tu ordenador algún repositorio con el que estuvieses trabajando en GitHub. Tendremos que configurarlo para continiar trabajando en GitLab.

Para ello, en una terminal con en la que se esté trabajando en la carpeta del repositorio (moviendose por las carpetas con el comando "cd") ejecutaremos:

git remote -v

Para ver cuál es el servidor remoto con el que estamos trabajando (GitHub o GitLab). Para cambiar el remote, copiaremos la dirección del repositorio en GitLab (puede ser la url HTTPS, o SSH si tenemos la clave configurada), y ejecutaremos el siguiente comando:

git remote set-url origin [nuevo repositorio]

Tras ejecutar este comando probemos:

git remote -v
git fetch

Para comprobar que tenemos todo bien configurado.

Trabajar con múltiples remotes

Es posible configurar varios repositorios remotos. De esta forma podremos hacer pull de algunos o todos, y luego hacer push a algunos o todos. 

No es común trabajar con varios repositorios remotos, pero en algunas situaciones puede ser útil, y una de estas situaciones es la de migrar un repositorio, pero querer mantener nuestro repositorio antiguo actualizado.

Dado que esto es ligeramente más complejo no lo explicaremos en este tutorial, pero próximamente se hará un tutorial de Git Avanzado en el que explicaremos cómo configurar y usar múltiples repositorios remotos.

Nuestra instancia de GitLab

Tras más de 3 años pensando en migrar nuestra organización de GitHub a GitLab por fin realizamos la migración.

Sin embargo decidimos migrar a nuestra propia instancia de GitLab. Esta instancia es pública: cualquiera peude crearse una cuenta y usarla sin ningún problema.

Actualmente esta es la situación de nuestra instancia:

  • Soporte para 1000 usuarios (estimación)
  • Soporte para git por SSH en el puerto 8022
  • Speed Index: 500ms
  • 50 proyectos por usuario (con planes de aumentarlo)
  • Archivos de hasta 1MB (con planes de aumentarlo)
  • Previews en navegador habilitados (Web IDE)
  • Versión 11.9.1-CE (última versión de Comunity Edition, a fecha de publicación) 100% Open Source

 

 

 

Leer más
email: librelab@ucm.es
Facultad de Informática de la UCM
Calle del Profesor José García Santesmases 9, Despacho 120
28040, Madrid
×
Probando acceso a TOR... Web disponible en TOR! ;) La web está disponible en TOR, pero el navegador no tiene acceso a TOR