Overview of the possibilities of Qt Creator 4.10 and QBS 1.14 for programming microcontrollers

Hello, fellow programmers, hardware and all who sympathize with them. I would like to present a short overview of the capabilities of the Qt Creator IDE in conjunction with the QBS build system regarding microcontroller programming. To whom this topic is interesting, welcome to cat.



Just the other day, quietly and imperceptibly, the Qt Creator 4.10 release was released, which added some improvements for working with microcontrollers (in common people - “baremetal” devices). This release of Qt Creator integrates the QBS 1.14 build system, which also has new improvements. Some of these improvements will be discussed below.

Improvements in Qt Creator

All these improvements are available only when the BareMetal plugin is enabled, which is activated through the menu "Help -> About Plugins -> Device Support -> BareMetal".

1. Three new compilers are now supported, the basic information about which is given in the table below:
   
   

   Compiler	Supported Architectures
   IAR EW	ARM, AVR, 8051 (MCS51)
   Keil	ARM, 8051 (MCS51)
   SDCC	8051 (MCS51)

   
   
   Note: It is worth noting that the products from IAR EW and KEIL for different architectures are provided by separate packages that must be installed independently. In difference, say, from the SDCC compiler which supports several architectures at once.
   
   
2. Now these new compilers are automatically detected on the tab "Tools -> Options -> Kits -> Compilers -> Auto-detected".
   
   
   
   For example, for me it looks like this:
   
   
   
   
   
   
   
   Note: As you can see, for C ++ there is no KEIL compiler for MCS51, which is correct, because this compiler only supports C. Also, the SDCC compiler will be missing here for the same reason.
   
   
3. It is also possible to manually add these new compilers through the menu "Tools -> Options -> Kits -> Compilers -> Add":
   
   
   
   
   
   
4. For the compiler, its ABI (architecture, format and word width) will be automatically determined. Information on this can be viewed simply by clicking on the compiler.
   
   
   
   For example, for IAR EW and architecture 8051 (MCS51), it looks like this:
   
   
   
   
   
   
   
   Note: In this case, a compiler was selected that was automatically detected, so the ABI fields are inactive here. But when manually adding the compiler, the user can select the correct ABI, if for some reason it was determined incorrectly.
   
   
5. For the compiler, all its macros will be automatically detected. Thus, they will be correctly highlighted in the code editor.
   
   
   
   Note: The exception is only the keywords of some compilers (for example, for the 8051 architecture), which will be highlighted with a warning. But that is another story.
   
   
6. For the compiler, directories with its header files will be automatically detected. Thus, they will be correctly highlighted in the code editor.
   
   
7. The parsers for errors and warnings of these new compilers are implemented, which are displayed in the Issues panel.
   
   

Improvements in QBS

QBS will be an integral part of this review, so it makes sense to talk about its improvements:

1. Added support for these new compilers (some of them starting from version 1.13).
2. Implemented the ability to automatically detect installed compilers and create profiles. What is the qbs-setup-toolchains utility used for.
   
   
   
   In my case, it looks like this:
   
   
   
   

   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. ...
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   To see what was discovered there, you can use the qbs-config-ui GUI utility.
   
   
   
   In my case, it looks like this:
   
   
   
   
   
   

Features of creating a project

It is important to have an idea and be able to correctly fill in the project properties for the cpp and qbs modules .



Let us dwell on the most important of them and consider them in more detail:

• qbs.toolchain - this property is automatically populated when generating a profile for the selected compiler. The table below shows the possible values ​​for this property:
  
  
  
  

  Toolchain name	Property value
  IAR EW	iar
  Keil	keil
  SDCC	sdcc

  
  
  
• qbs.architecture - this property is automatically populated when generating a profile for the selected compiler. The table below shows the possible values ​​for this property:
  
  
  
  

  Architecture name	Property value
  ARM	arm
  AVR	avr
  8051 (MCS51)	mcs51

  
  
  
• cpp.cLanguageVersion - this property allows you to set the version of the standard used for the C language . Possible uses are shown in the table below:
  
  
  
  

  Toolchain name	Possible options	Default
  IAR EW	c89	The latest version, depending on the version of the toolchain.
  Keil	c99 (ARM only)	The latest version, depending on the version of the toolchain.
  SDCC	c89, c99, c11	The latest version, depending on the version of the toolchain.

  
  
  Note: It is important to note that the IAR EW and KEIL toolchains do not provide options for choosing a standard version. By default, they use the latest version implemented in a specific version of the compiler (either c99 or c11, you need to look in the release-notes for the compiler). Usually you can only select the old version of the c89 standard.
  
  
• cpp.cxxLanguageVersion - this property allows you to set the version of the standard used for the C ++ language . Possible uses are shown in the table below:
  
  
  
  

  Toolchain name	Possible options	Default
  IAR EW	No	The latest version, depending on the version of the toolchain
  Keil	c ++ 03, c ++ 11 (only for ARM)	c ++ 03 (only for ARM)
  SDCC	Not supported	Not supported

  
  
  
• cpp.entryPoint is the name of the point in the move in the program used for linking. Its necessity is determined by the used runtime. For example, if you use the IAR EW runtime (that is, link to its libraries and use its linker scripts), then the point name will be "__program_start". Those. it is entirely up to the developer.
  
  
• cpp.driverFlags are common flags that will be passed to the compiler and assembler. In some cases, they will also be transferred to the linker (this depends on the type of toolchain). These flags can be flags indicating the type of processor, coprocessor, etc.
  
  
  
  For example, for the IAR EW compiler for the AVR architecture, these could be:
  
  
  
  

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

  
  
  
• cpp.driverLinkerFlags are flags that will be passed to the linker without changes, unlike cpp.linkerFlags , which can be automatically additionally wrapped with some keywords. For IAR EW and KEIL compilers, it is preferable to use cpp.driverLinkerFlags , because these compilers always use a separate linker executable for linking. For the SDCC compiler, it is preferable to use cpp.linkerFlags , as the commands of this compiler are somewhat similar to the GCC compiler.
  
  
• cpp.commonCompilerFlags are common flags that will be passed to both the C compiler and the C ++ compiler.
  
  
  
  For example, for the IAR EW compiler, this could be a flag to enable specific extensions of this compiler:
  
  
  
  

   cpp.commonCompilerFlags: ["-e"]
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  
• cpp.cFlags are flags that will only be passed to the C compiler.
  
  
• cpp.xxFlags are flags that will only be passed to the C ++ compiler.
  
  
• cpp.staticLibraries is a list of libraries with which you need to link the application. I note that cpp.dynamicLibraries are not supported in these compilers (as I know), so it makes sense to use only cpp.staticLibraries .
  
  
• cpp.assemblerFlags - these flags will be passed only to assembler.
  
  

To specify script files for the linker, there is a special tag “linkerscript”, which you must use, for example:

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Note: The reason is that different compilers have different naming options for these files. For the same GCC, it can be files with the extensions * .ld, * .x, * .xn, * .xbn, etc. (what can we say about other compilers ...). Therefore, it was decided not to bother tagging all possible file extensions for specific compilers, but simply to use the linkerscript tag for its intended purpose and situation.



To see how it all works, QBS provides a set of simple examples that only “jerk” a leg and blink an LED.

What's with debugging

Unfortunately, the debugging situation is deplorable. Products (IDEs) IAR EW and KEIL use their debuggers, but since Since these products are proprietary, it is not possible to get somewhere a description of the operation of the protocols of these debuggers. The only option is to try reverse engineering the plugins for Eclipse (for example, IAR EW provides these plugins), but this requires serious motivation.



But I can be a little happy if I say that for the ARM architecture you can use the GDB debugger. At least it worked for me for IAR EW (but something didn’t work out with KEIL, maybe some additional flags should be indicated to the linker there).

What's next

Here I’m a little spoiler, I’ll say that in the next versions (I don’t know which ones), the STM8 and MSP430 architectures should be added, as well as in QBS generators will be implemented in native IAR EW and KEIL projects (which will make it possible, for example, to debug projects).



On this note, I end my story, thank you all who will pay attention to this review.