proteus none for cortex gcc embedded arm eabi

gcc - for - install arm none eabi gdb



¿Puedo mezclar el brazo con el elfo brazo? (3)

No. Un ABI es la magia que hace que los binarios sean compatibles. La interfaz binaria de aplicaciones determina varias convenciones sobre cómo comunicarse con otras bibliotecas / aplicaciones. Por ejemplo, un ABI definirá la convención de llamadas, que hace suposiciones implícitas sobre cosas como qué registros se usan para pasar argumentos a las funciones de C y cómo tratar con los argumentos en exceso.

No conozco las diferencias exactas entre EABI y ABI, pero puedes encontrar algunas al leer EABI. La página de Debian menciona que la convención syscall es diferente, junto con algunos cambios de alineación.

Dado lo anterior, por supuesto, no se pueden mezclar los objetos de elfo de brazo y brazo-eabi.

La respuesta anterior se da en el supuesto de que hable con el código del gestor de arranque en su aplicación principal. Dado que la interfaz puede ser muy simple (solo una llamada a función con dos parámetros), es posible que funcione. Sería un experimento interesante de probar. Sin embargo, no está ** garantizado ** para funcionar.

Tenga en cuenta que no tiene que usar EABI. Puede generar una cadena de herramientas de brazo-elf con gcc 4.6 tan bien como con versiones anteriores. Como está utilizando una cadena de herramientas binaria en Windows, puede tener más desafíos. Sugeriría investigar crosstool-ng , que funciona bastante bien en Linux, y puede funcionar bien en cygwin para construir la cadena de herramientas adecuada.

Tengo un producto que el gestor de arranque y la aplicación se compilan utilizando un compilador (gnuarm GCC 4.1.1) que genera "arm-elf".

El gestor de arranque y la aplicación están segregados en diferentes áreas de memoria FLASH en el script del enlazador.

La aplicación tiene una función que le permite llamar al gestor de arranque (como una simple función c con 2 parámetros).

Necesito poder actualizar los productos existentes en todo el mundo, y puedo hacerlo de forma segura utilizando siempre el mismo compilador.

Ahora me gustaría poder compilar esta aplicación de producto utilizando una nueva versión de GCC que genera arm-eabi.

Todo estará bien para los nuevos productos, donde la aplicación y el gestor de arranque se compilan utilizando la misma cadena de herramientas, pero ¿qué sucede con los productos existentes? Si flasheo una nueva aplicación, compilada con GCC 4.6.x y arm-none-eabi, ¿mi aplicación podrá llamar a la función del gestor de arranque desde el gestor de arranque del brazo-elfo antiguo?

Además, no directamente relacionado con la pregunta anterior, ¿puedo mezclar archivos de objetos compilados con el elfo armado en un binario compilado con arm-eabi?

EDITAR:

Creo que es bueno dejar en claro que estoy construyendo para un ARM7 bare metal, si hace alguna diferencia ...

Siempre existe la opción de realizar la llamada al gestor de arranque en ensamblado en línea, en cuyo caso puede cumplir con cualquier estándar de llamada que necesite :).

Sin embargo, además del problema de portabilidad que presenta, este enfoque también hará dos suposiciones sobre su gestor de arranque y su aplicación:

  • puede detectar en su aplicación que un dispositivo en particular tiene un gestor de arranque creado con su cadena de herramientas no EABI, ya que solo puede llamar al gestor de arranque de tipo antiguo utilizando el código ensamblador.
  • los dos parámetros que mencionó se usan como datos primitivos en su gestor de arranque. Si el gestor de arranque los utiliza, por ejemplo, como punteros a estructuras, entonces podría enfrentar problemas con una alineación incorrecta, relleno y demás.