Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32


Compiler Documentation

The compiler appears to be rejecting this directive:

  1. pragma message( ” ... ” )


I know this is compiler specific and therefore it may not be implemented on other compilers than Microsoft’s. But I need to know what the equivalent of this is for the ARM Compiler for MCU that Ac6 uses. I have trouble finding this documentation. Where is documentation for available compiler directives for ARM Compiler for MCU?

Hi,

what does it mean “rejecting the pragma directive”

For example, with this source code...

int main(void)
{
 #pragma message "Fix it!!!"
	for(;;);
}


... the compiler output is

make all
'Building file: ../src/main.c'
'Invoking: MCU GCC Compiler' ...
../src/main.c:19:9: note: #pragma message: Fix it!!!
 #pragma message "Fix it!!!"
         ^
'Finished building: ../src/main.c'


Is it not what you expect?

Regards,
Stefano


What is the meaning of the caret symbol below the first letter of the “message” token? This caret looks to me to be an error indicator. The message token is not included as valid for #pragma in the “ARM Compiler toolchain Compiler Reference”:
http://infocenter.arm.com/help/topic/com.arm.doc.dui0491i/DUI0491I_arm_compiler_reference.pdfQuestion
which I found after starting this thread.

When I used “#pragma message ...” these did not appear in the output under the Console tab in the expected order. This is another indication to me that this is an error message, and not a message directive the compiler was executing.

I ended up doing what I needed to do with the #warn directive. These gave me the expected results and were useful in finding the source of the compiler errors I was seeking.