Descripción general de las características de programación del microcontrolador Qt Creator 4.10 y QBS 1.14

Hola, compañeros programadores, hardware y todos los que simpatizan con ellos. Me gustaría presentar una breve descripción de las capacidades del Qt Creator IDE junto con el sistema de compilación QBS con respecto a la programación de microcontroladores. Para quien este tema es interesante, bienvenido a cat.

Justo el otro día, silenciosa e imperceptiblemente, se lanzó la versión Qt Creator 4.10 , que agregó algunas mejoras para trabajar con microcontroladores (en personas comunes: dispositivos "baremetal"). Esta versión de Qt Creator integra el sistema de compilación QBS 1.14 , que también tiene nuevas mejoras. Algunas de estas mejoras se discutirán a continuación.

Mejoras en Qt Creator


Todas estas mejoras están disponibles solo cuando el complemento BareMetal está activado, que se activa a través del menú "Ayuda -> Acerca de los complementos -> Soporte de dispositivos -> BareMetal".

  1. Ahora se admiten tres nuevos compiladores, cuya información básica se proporciona en la tabla a continuación:
    CompiladorArquitecturas compatibles
    IAR EWBRAZO, AVR, 8051 (MCS51)
    KeilBRAZO, 8051 (MCS51)
    SDCC8051 (MCS51)

    Nota: Vale la pena señalar que los productos de IAR EW y KEIL para diferentes arquitecturas son proporcionados por paquetes separados que deben instalarse de forma independiente. A diferencia, digamos, del compilador SDCC que admite varias arquitecturas a la vez.
  2. Ahora estos nuevos compiladores se detectan automáticamente en la pestaña "Herramientas -> Opciones -> Kits -> Compiladores -> Detección automática".

    Por ejemplo, para mí se ve así:



    Nota: Como puede ver, para C ++ no hay un compilador KEIL para MCS51, lo cual es correcto, porque este compilador solo es compatible con C. Además, el compilador SDCC faltará aquí por la misma razón.
  3. También es posible agregar manualmente estos nuevos compiladores a través del menú "Herramientas -> Opciones -> Kits -> Compiladores -> Agregar":


  4. Para el compilador, su ABI (arquitectura, formato y ancho de palabra) se determinará automáticamente. La información sobre esto se puede ver simplemente haciendo clic en el compilador.

    Por ejemplo, para mi IAR EW y arquitectura 8051 (MCS51), se ve así:



    Nota: En este caso, se seleccionó un compilador que se detectó automáticamente, por lo que los campos ABI están inactivos aquí. Pero al agregar manualmente el compilador, el usuario puede seleccionar el ABI correcto, si por alguna razón se determinó incorrectamente.
  5. Para el compilador, todas sus macros se detectarán automáticamente. Por lo tanto, se resaltarán correctamente en el editor de código.

    Nota: Una excepción son solo las palabras clave de algunos compiladores (por ejemplo, para la arquitectura 8051), que se resaltarán con una advertencia. Pero esa es otra historia.
  6. Para el compilador, los directorios con sus archivos de encabezado se detectarán automáticamente. Por lo tanto, se resaltarán correctamente en el editor de código.
  7. Se implementan los analizadores de errores y advertencias de estos nuevos compiladores, que se muestran en el panel Problemas.

Mejoras en QBS


QBS será una parte integral de esta revisión, por lo que tiene sentido hablar sobre sus mejoras:

  1. Se agregó soporte para estos nuevos compiladores (algunos desde la versión 1.13).
  2. Se implementó la capacidad de detectar automáticamente los compiladores instalados y crear perfiles. ¿Para qué se utiliza la utilidad qbs-setup-toolchains ?

    En mi caso, se ve así:

    c:\Qt-meta\Tools\QtCreator\bin>qbs-setup-toolchains.exe --detect ... Trying to detect IAR toolchains... Profile 'iar-arm' created for 'C:/Program Files (x86)/IAR Systems/Embedded Workbench 8.3/arm/bin/iccarm.exe'. Profile 'iar-mcs51' created for 'C:/Program Files (x86)/IAR Systems/Embedded Workbench 8.0/8051/bin/icc8051.exe'. Profile 'iar-avr' created for 'C:/Program Files (x86)/IAR Systems/Embedded Workbench 8.0/avr/bin/iccavr.exe'. Trying to detect KEIL toolchains... Profile 'keil-mcs51' created for 'C:/Keil_v5/C51/BIN/c51.exe'. Profile 'keil-arm' created for 'C:/Keil_v5/ARM/ARMCC/bin/armcc.exe'. Trying to detect SDCC toolchains... No SDCC toolchains found. ... 

    Para ver lo que se descubrió allí, puede usar la utilidad qbs-config-ui GUI.

    En mi caso, se ve así:



Características de crear un proyecto


Es importante tener una idea y poder completar correctamente las propiedades del proyecto para los módulos cpp y qbs .

Detengámonos en los más importantes y consideremos con más detalle:

  • qbs.toolchain : esta propiedad se rellena automáticamente al generar un perfil para el compilador seleccionado. La siguiente tabla muestra los valores posibles para esta propiedad:

    Nombre de la cadena de herramientasValor de la propiedad
    IAR EWiar
    Keilkeil
    SDCCsdcc

  • qbs.architecture : esta propiedad se rellena automáticamente al generar un perfil para el compilador seleccionado. La siguiente tabla muestra los valores posibles para esta propiedad:

    Nombre de la arquitecturaValor de la propiedad
    BRAZObrazo
    AVRavr
    8051 (MCS51)mcs51

  • cpp.cLanguageVersion : esta propiedad le permite establecer la versión del estándar utilizado para el lenguaje C. Los posibles usos se muestran en la tabla a continuación:

    Nombre de la cadena de herramientasPosibles opcionesPor defecto
    IAR EWc89La última versión, dependiendo de la versión de la cadena de herramientas.
    Keilc99 (solo ARM)La última versión, dependiendo de la versión de la cadena de herramientas.
    SDCCc89, c99, c11La última versión, dependiendo de la versión de la cadena de herramientas.

    Nota: Es importante tener en cuenta que las cadenas de herramientas IAR EW y KEIL no ofrecen la posibilidad de seleccionar una versión estándar. Por defecto, utilizan la última versión implementada en una versión específica del compilador (ya sea c99 o c11, debe buscar en las notas de la versión del compilador). Por lo general, solo puede seleccionar la versión anterior del estándar c89.
  • cpp.cxxLanguageVersion : esta propiedad le permite establecer la versión del estándar utilizado para el lenguaje C ++ . Los posibles usos se muestran en la tabla a continuación:

    Nombre de la cadena de herramientasPosibles opcionesPor defecto
    IAR EWNoLa última versión, dependiendo de la versión de la cadena de herramientas.
    Keilc ++ 03, c ++ 11 (solo para ARM)c ++ 03 (solo para ARM)
    SDCCNo compatibleNo compatible

  • cpp.entryPoint es el nombre del punto en el movimiento en el programa utilizado para vincular. Su necesidad está determinada por el tiempo de ejecución utilizado. Por ejemplo, si usa el tiempo de ejecución IAR EW (es decir, enlace a sus bibliotecas y usa sus scripts de enlace), en este caso el nombre del punto será "__program_start". Es decir depende completamente del desarrollador.
  • cpp.driverFlags son banderas comunes que se pasarán al compilador y al ensamblador. En algunos casos, también se transferirán al vinculador (esto depende del tipo de cadena de herramientas). Estas banderas pueden ser banderas que indican el tipo de procesador, coprocesador, etc.

    Por ejemplo, para el compilador IAR EW para la arquitectura AVR, estos podrían ser:

     cpp.driverFlags: ["--cpu=can128", "-ms"] 

  • cpp.driverLinkerFlags son marcas que se pasarán al enlazador sin cambios, a diferencia de cpp.linkerFlags , que se pueden ajustar automáticamente con algunas palabras clave. Para los compiladores IAR EW y KEIL, es preferible usar cpp.driverLinkerFlags , como estos compiladores siempre usan un ejecutable de vinculador separado para vincular. Para el compilador SDCC, es preferible usar cpp.linkerFlags , como Los comandos de este compilador son algo similares al compilador GCC.
  • cpp.commonCompilerFlags son banderas comunes que se pasarán tanto al compilador de C como al compilador de C ++.

    Por ejemplo, para el compilador IAR EW, esto podría ser un indicador para habilitar extensiones específicas de este compilador:

     cpp.commonCompilerFlags: ["-e"] 

  • cpp.cFlags son banderas que solo se pasarán al compilador de C.
  • cpp.xxFlags son banderas que solo se pasarán al compilador de C ++.
  • cpp.staticLibraries es una lista de bibliotecas con las que necesita vincular la aplicación. Observo que cpp.dynamicLibraries no son compatibles con estos compiladores (como sé), por lo que tiene sentido usar solo cpp.staticLibraries .
  • cpp.assemblerFlags : estas banderas se pasarán solo al ensamblador.

Para especificar archivos de script para el vinculador, hay una etiqueta especial "linkerscript", que debe usar, por ejemplo:

 Group { name: "Linker Scripts" fileTags: ["linkerscript"] files: ["cfg3soim.xcl", "cfgcan128.xcl"] } 

Nota: La razón es que para diferentes compiladores hay diferentes opciones para nombrar estos archivos. Para el mismo GCC, pueden ser archivos con las extensiones * .ld, * .x, * .xn, * .xbn, etc. (qué podemos decir sobre otros compiladores ...). Por lo tanto, se decidió no molestar a etiquetar todas las extensiones de archivo posibles para compiladores específicos, sino simplemente usar la etiqueta linkerscript para su propósito y situación previstos.

Para ver cómo funciona todo, QBS proporciona un conjunto de ejemplos simples que solo "sacuden" una pierna y parpadean un LED.

¿Qué pasa con la depuración?


Desafortunadamente, la situación de depuración es deplorable. Los productos (IDE) IAR EW y KEIL usan sus depuradores, pero desde Dado que estos productos son propietarios, no es posible obtener en alguna parte una descripción del funcionamiento de los protocolos de estos depuradores. La única opción es probar la ingeniería inversa de los complementos para Eclipse (por ejemplo, IAR EW proporciona estos complementos), pero esto requiere una seria motivación.

Pero puedo estar un poco feliz si digo que para la arquitectura ARM puedes usar el depurador GDB. Al menos funcionó para mí para IAR EW (pero, algo no funcionó con KEIL, tal vez algunas banderas adicionales deberían indicarse al enlazador allí).

Que sigue


Aquí estoy un poco spoiler, diré que en las próximas versiones (no sé cuáles), se deben agregar las arquitecturas STM8 y MSP430, así como en los generadores QBS se implementarán en proyectos IAR EW y KEIL nativos (lo que hará posible, por ejemplo, depurar proyectos).

En esta nota, termino mi historia, gracias a todos los que prestarán atención a esta revisión.

Source: https://habr.com/ru/post/467323/


All Articles