Building with GCC - success!

[wangyeee]

There are a couple of threads discussing compiling the AQ firmware. Somehow the source codes are tricky to build with any compilers other than 2.x version of crossworks. Even the newer version of crossworks doesn't work. So I hook up my M4 with a ST-Link debugger and went through the codes line by line, and tried to find out what stops other compilers working.

I'd like to skip the tedious process of debugging and summarize the followings which crossworks has done for what you've paid for

• CCM RAM in ld script. As it's obviously from the source(such as control.c), AQ makes use of the CCM memory in STM32 processor. However you can't *just* use it. The ld script and startup file need to be revised to use it properly. Crossworks has done it for you perfectly!
• Basic C runtime. AQ employs dynamic memory allocation for data structures like those related to STM32 peripherals. Although I prefer to use static allocation in embedded systems. Nothing/no one should stop anyone from using dynamic allocation, except ST, the MCU manufacturer I haven't find anything related to basic c runtime routine on its website So again, crossworks does this for you. Fortunately, I've found that the ld scripts and syscall implementation of truestudio in StdPeriph would work with some minor changes.

With the findings above, I wrote a makefile from scratch, and have successfully compiled the codes. The binary has been tested on a M4 v2. It works on the ground, but I haven't tested it in the air. One change I've made to the source is in aq_init.c:
AQ_NOTICE("Initialization complete, hello AQ from GCC.\n");
So the mavlink message would tell you the AQ is running on gcc

The source can be found here:
https://github.com/wangyeee/autoquadfc
Basically you can clone and make, all dependencies are in that repo. Please advice if there were any copyright issues doing so.

It's much appreciated if anyone can test it on AQ6 with or without DIMU.

Edit on 27-Mar-2016:
I did successful flight tests today. Flying in manual/PH/DVH and mission mode are working as expected. RTH by radio command and RTH on failsafe are also working.

I've uploaded compiled binaries for M4v2 and AQ6, so that more people can test.

Be sure to do ground test w/o props first, safety is always No.1 priority!!

[chschmid]

Wow, it seems you really understand what you are doing.

Cheers
Christof

[Max]

Hi Ye,

This is great info and work, really appreciated. It has been on my list to test with GCC further -- I went down a path similar to yours but other projects took precedence. I'd like to get away from the CW requirement, which I personally don't use (except the build chain, of course).

There is another fork which does something similar, are you aware of it? https://github.com/multigcs/quadfork

Unfortunately neither Git repo shows the actual changes made, so it is very hard to track, especially with the different folder structures. Is there any way you'd consider doing a proper fork of either Bill's original or my current version and then applying your changes to that? The latter already has re-organized folder structure and many other additions. This way I could integrate your changes into the working version, instead of having a whole different code base to maintain for GCC. I'd also prefer to keep the option of building with either CW or pure GCC tool chains.

Thanks again for taking the time and letting us know, good stuff.

Cheers,
-Max

[wangyeee]

Hi Ye,

This is great info and work, really appreciated. It has been on my list to test with GCC further -- I went down a path similar to yours but other projects took precedence. I'd like to get away from the CW requirement, which I personally don't use (except the build chain, of course).

There is another fork which does something similar, are you aware of it? https://github.com/multigcs/quadfork

Unfortunately neither Git repo shows the actual changes made, so it is very hard to track, especially with the different folder structures. Is there any way you'd consider doing a proper fork of either Bill's original or my current version and then applying your changes to that? The latter already has re-organized folder structure and many other additions. This way I could integrate your changes into the working version, instead of having a whole different code base to maintain for GCC. I'd also prefer to keep the option of building with either CW or pure GCC tool chains.

Thanks again for taking the time and letting us know, good stuff.

Cheers,
-Max

Hi Max,

Actually the changes I made were simple, you may have a look here:
https://github.com/wangyeee/aq_flight_c ... ef141d714b

Regarding the multigcs fork, I haven't heard it before, except for the openfc hw. And thanks for your link, I'll take a look at what they've done

Regards,
Ye

[Max]

Thanks, I'll try this out!

Did you use the latest release of GCC ARM (2015 q4)?

-Max

[wangyeee]

Thanks, I'll try this out!

Did you use the latest release of GCC ARM (2015 q4)?

-Max

No, I'm still using the 4.9 release:
gcc version 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]

Haven't tried the 5.x release yet.

Regards,
Ye

[wangyeee]

Thanks, I'll try this out!

Did you use the latest release of GCC ARM (2015 q4)?

-Max

I've upgraded to latest GCC release. My tests are good, binaries uploaded.

I can open a pr if needed.

[Max]

Thanks Ye, good to know. I haven't forgotten about this at all, just too many projects right now and too little time. A pure-GCC build option is definitely attractive and I think will help the project in general.

Cheers,
-Max

[Max]

Ye, if you felt like working on this some more for integration, what I'd like to see is all the current build options and features preserved for the GCC build.

I think the best way to go would be to create 3 makefiles -- one main Makefile for all the common options and build steps/targets, and then one each specifically for CW and GCC builds which get included in the main one as needed. The latter should only do things which are compiler-specific. The build type (CW/GCC) could perhaps be specified on the Make command-line (with default being CW for now).

A lot of the current build system options/features are used for automated builds and across multiple project files, so they need to stay and be centrally editable (not needing to modify stuff in two places). Being able to include user-defined settings from an external makefile is essential. Auto-incrementing the build number and labeling the bin files with the right version are important, and things like the elf size report are invaluable during development.

Anyway, those would be my next steps once I got time. If you're up for doing some/all of it, that would be great. I'm open to other ideas as well, but the end result must require the least amount of maintenance possible...

Thanks,
-Max

[wangyeee]

Max, I like the idea of one makefile with common options. I'll take a look at the two makefiles and find out everything common between them.

Regards,
Ye