search

am32-firmware / AM32

GNU General Public License v3.0
244 stars 82 forks source link

Standardization of the AM32 compiler version and compiler flags across Keil, Windows CLI & Linux CLI #45

Open ianrmurphy opened 1 month ago

ianrmurphy commented 1 month ago

My understanding is that AM32 can currently be built using at least 4 compiler variants (tested on 'main'):

Ref. the Keil IDE, if I download and install that, by default I get compiler version '6.22' installed. The 'multi project build' compiles most targets but fails on 'G431_test' which expects '6.19'. The other projects are set to 'Use default compiler version 6'. Thus, it seems the actual compiler used by the Keil IDE will depend upon when the IDE was installed.

During the day I am sometimes developing Safety-Related embedded software. When doing this we standardize both the compiler toolchain and the compiler flags. Sometime this is an audited requirement to maintain a Functional Safety Certification (e.g. IEC6108) from the target ECU supplier.

While AM32 is not 'Safety Related' software per se, nobody wants a compiler-induced regression to affect arming behaviour or smoke motors. Thus I feel it's worth a discussion on how to move forward from here, especially given the situation with BLHeli32 and the likely migration to AM32 of a lot of speedo targets.

I understand the root of the project began with the Keil IDE and this is the preferred environment for the key developers. Thus us 'new guys' need to be respectful of this and work to ensure this environment is maintained.

But, for Continuous Integration / Cloud builds etc. a CLI 'makefile' solution is also required. Probably on Linux.

Thus, I propose to support the following 2 initiatives:

  1. Work towards a 'makefile' solution targeting the Keil compiler.
    • As a sub-task, ensuring a known version of this compiler and standardized flags are adopted.
  2. Work toward reconfiguring the Keil IDE to target Andrew's Windows toolchain compiler instead, using the 'makefile' (like Eclipse can)
    • As a sub-task, determining if the output of Andrew's Windows and Linux toolchains are binary identical.

Of course, this all needs debating and reviewing and discussing and a consensus forming. Either here, on the Discord, or if you prefer to DM me that's good too.

Thanks, Ian

AlkaMotors commented 1 month ago

We actually went the other way. I used to use makefiles and moved to Keil for easier building and debugging and a few other reasons. The code is open source but that does not mean I want or need any contributed code in the project. Often code is added and the submitter puts the testing (the much harder part of the work) back on the devs. As of today I have a setup where I can compile error free.. debug and easily edit targets. If any "improvement" slows down this workflow then it just makes my job harder.

ianrmurphy commented 1 month ago

If any "improvement" slows down this workflow then it just makes my job harder.

Hopefully we can work to make your job easier not harder. E.g. facilitating automated testing.

Are you OK with a makefile process that uses the same Keil compiler you use in the IDE? That would not affect the existing workflow.

ianrmurphy commented 1 month ago

So, Keil uses a licensed version of CLANG, not gcc. Depending what's commented out in the makefile I can get either:

Fatal error: L3921U: Option '--library' not available with your license. Finished: 0 information, 0 warning, 0 error and 1 fatal error messages.

Or:

Error: L6218E: Undefined symbol _sidata (referred from startup_stm32f051k6tx-a62754.o). Error: L6218E: Undefined symbol _sdata (referred from startup_stm32f051k6tx-a62754.o). Error: L6218E: Undefined symbol _edata (referred from startup_stm32f051k6tx-a62754.o). Error: L6218E: Undefined symbol _sbss (referred from startup_stm32f051k6tx-a62754.o). Error: L6218E: Undefined symbol _ebss (referred from startup_stm32f051k6tx-a62754.o). Error: L6218E: Undefined symbol __libc_init_array (referred from startup_stm32f051k6tx-a62754.o). Error: L6218E: Undefined symbol _estack (referred from startup_stm32f051k6tx-a62754.o). Finished: 0 information, 0 warning and 7 error messages.

AlkaMotors commented 1 month ago

I realize I sounded a bit negative above. I am definitely open to a different system. I just spend a lot of time everyday working with the current system. Right now the workload is very high so it's difficult to switch gears. I am going to do one more release on the current build method for all the newly added targets and then I am going to give Andrew's vscode build a go.

ianrmurphy commented 1 month ago

I am going to do one more release on the current build method for all the newly added targets and then I am going to give Andrew's vscode build a go.

The vscode integration should offer s similar debugging experience to Keil, Andrew has done a good job configuring it. It's also cross platform Linux & Windows.

ATM Windows lacks a command line build, unless you use WSL. Mainly because it requires a 'make.exe' in the path. You can expressly call the 'make.exe' in Andrew's 'tools/windows/make/bin' folder if you don't mind typing that out. Since CI / Cloud builds likely will use Linux maybe that doesn't matter.

So, the only remaining issue is whether you are happy with the switch from Keil ARMCLANG to arm-none-eabi-gcc? As I expressed above, I feel a standard compiler + flags setup is a good QC step.

tridge commented 1 month ago

@ianrmurphy I think the main impediment to us switching to vscode/make build is that there is a particular target varient of the F421 that doesn't boot with the gcc toolchain build. I'm waiting on receiving an example board that has the issue then I hope to fix it. Once that is fixed I'm hopeful that @AlkaMotors will find the vscode experience good enough that we use vscode going fwd for windows users, and on linux users can either use vscode or command line. Command line on windows isn't actually hard (see the CI job that builds on windows), you just need make.exe in your path