Keil/ARM dropped an updated MDK that comes with a version of ARMCLANG: C:Keil_v5ARMARMCLANGbin>armclang –version Product: MDK-ARM Standard Cortex-M only 5.20 Component: ARM Compiler 6.4 Tool: armclang [5c29cb00] Target: unspecified-arm-none-unspecified I would love to use this compiler for my project as it has support for a much more modern version of C++, a lot better static analysis, more warnings, compiles faster, does the dishes and mops the floor, etc. However, it supports a different syntax for inline assembly, and Keil’s docs don’t describe it well. I’m not sure I’m up to the task of porting FreeRTOS myself. I’m willing to try, but if it is going to be extremely hairy I’ll probably have to give up and use the old compiler. My target is a SAM4E16E (Cortex-M4) chip. FreeRTOS is working great for me with the older ARMCC compiler. Is anyone else using this new compiler? Anyone else attempting a port? One possibility that occurred to me: could I build FreeRTOS as a static library, with the old compiler, and drop it into a project built with ARMCLANG? Maybe not, as that won’t help with functions that are really macros. Any suggestions welcome. Thanks, Paul R. Potts

We have used CLANG before, and as it tries to support GCC syntax, had success building and running the FreeRTOS GCC port with it BUT did find we had to make one small modification to the port layer in order for this to work. The issue was related to the use of the attribute((naked)) qualifier, which didn’t work quite as advertised. It is supposed to prevent any compiler prologue or epilogue code being generated, as per GCC’s use of the qualifier. As I recall it removed most of the compiler generated prologue, but left in some stack manipulation code. That was some time ago though, and I believe that issue has since been fixed.

Forgot to mention the static library option – assuming CLANG complies with the ARM EABI, which I would be surprised if it didn’t, then you should be able to mix and match compilers used to build and then subsequently link to static libraries. Again this is something we have done ourselves, but not with CLANG.

Thanks for the suggestions. I am pressing on with it — I have some changes to my portmacro.h that seem to compile. I should be able to test it all pretty soon.

I have good news — my whole project is up and running using armclang! I did have trouble building the FreeRTOS source itself, so I built that as a library with the old compiler. That required setting “Enum Containers always int” and adding the compiler flag “–wchar32” in order to make a library that would link with the armclag-built code. I have not been able to test everything yet but the basic tasks seem to be running with their expected timing, including interrupt handling with yielding from ISRs. So far the only thing tricky I did was to make changes in portmacro.h.

#define portFORCE_INLINE __attribute__((always_inline))

Then using the GCC syntax for assembly, for example, in ulPortRaiseBASEPRI:

__asm( "mrs %[ulReturn_], basepri; msr basepri, %[ulNewBASEPRI_]; dsb; isb" : [ulReturn_] "=r" (ulReturn) : [ulNewBASEPRI_] "r" (ulNewBASEPRI) );

I have not tried attribute ((naked)) or looked at the generated assembly to see if it can be slimmed down. Right now I’m just happy it works so far. I will be testing more so I’ll post updates if I come across anything strange. I would like to get the FreeRTOS sources building with clang but I will have to look into that more later; there were problems with compiler intrinsics and other port-specific things.

I wonder if ARM’s distribution is intended to build ARM compiler syntax. The distribution we used was the ‘vanilla’ one, which was happy with building GCC code (barring the one err mentioned in my previous post).