Building with GCC - success!

[mikewhy]

[wangyeee]

Haven't tried Docker before. TOOLCHAIN_ROOT was mainly used for Windows users who haven't add cross compiler to PATH env var. It can also be used to test new version of compilers. The makefile itself should have no problems compiling on a Mac, although I've only tested it on Windows and Debian Linux.

[mikewhy]

Docker is like a virtual machine but much more lightweight and built for this type of thing. Now you don't need to install gcc-arm-none-eabi-docker on Windows / Debian / Ubuntu / Mac, or worry about paths on different systems. Just "docker run --volume "$PWD":/source mikewhy/gcc-arm-none-eabi make" works on any platform.

[Max]

Hi Mike, welcome to the forums.

I see from some of your repos that you seem to like Docker. Could you explain what benefit it would have for AQ firmware (or software) projects? I went to their site but it's all marketing-speak.

"Docker provides an integrated technology suite that enables development and IT operations teams to build, ship, and run distributed applications anywhere."

Just based on that description, I don't see what it has to do with something like firmware, which isn't distributed (in the multi-server sense) and obviously needs very specific hardware to run. I also looked at their pricing -- 'Request quote."

So, what's the big deal with Docker, why are low/no budget open-source projects even interested in this? I'm genuinely curious.

Thanks!
-Max

[mikewhy]

It's open source, so I'm not sure where you saw information on pricing. This page might be better: https://www.docker.com/what-docker

"Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in."

In this case, the "application" is gcc-arm-none-eabi and make. We leave out the source code since Docker allows you to mount a folder inside the container (--volume "${PWD}:/source" means "make $PWD available at /source in the container").

It's mainly used in infrastructure, so the container you use in development is the same you use for testing on a build server and for running on a completely different server in production. If you've ever used "virtualenv" for python, it's like that but for absolutely any language, and you only run "pip install" once, not once per machine.

For users of the firmware it doesn't do anything. For building of the firmware, it means instructions are much simpler for newcomers and consistent across all machines. Like I've said, no more "go read this tutorial to install $SOFTWARE_STACK for your OS and hope everything works. Oh and if you're on Windows, probably muck around with your PATH and change these variables in the Makefile". Want to get automated builds of aq_flight_control firmware to push to Github Releases or your own site? You're already set up.

[Max]

Thanks for the explanation Mike. The pricing page is right off their front page, big buttons under the text I quoted earlier.

So who would maintain this magical "container" which is all set up with a build system for the firmware on any OS? Ensuring the correct GCC version, libraries, or whatever.

I'm not sure I understand why someone who doesn't know how to compile code (or follow instructions) would even need to build their own flight controller firmware...? There's lots of room for error even given a perfectly working toolchain. And the consequences can be ugly.

Cheers,
-Max

[mikewhy]

[Max]

[rput]

Just reading along here, but anything that can simplify the compiling process would be great. After several ignored requests on the forum to update the number of waypoints, we decided to try and compile ourselves. After several frustrating weeks eventually it worked, but I couldn't help but think it should be easier.

Having a working gcc build is great and should help. Not sure about docker, but if it can simplify things then I can only applaud the effort.

[Max]

So, you felt qualified to go make changes in key structures of the firmware (are you aware of all the possible implications?) but getting the build set up took weeks? I'm just not sure I agree with "it should be easier," sorry. Also for $200 one could just buy a ready-to-go IDE and compiler, no frustration required.

Hopefully the instructions have improved since last time you tried it. https://github.com/mpaperno/aq_flight_c ... e-firmware

The compiler is not just some piece of software that you use and forget. It becomes part of the final firmware, both figuratively (because it decides key factors about how it is built) and literally (code libraries from the toolchain get included in the final product). This stuff really matters.

What I think would really help beginners get going would be a full IDE environment all set up for the firmware and ground tools. A good IDE is almost as important as the compiler (more so for a beginner, IMHO), and would go a long way to help understand the firmware overall (code insight, instance search, language references, etc). A GCC build would make this possible.

Cheers,
-Max