Compilation on MacOS and Linux

[jmechnich]

I am looking into building the firmware on Linux and/or MacOS (on an M1 Mac).

As a first step I am trying to reproduce creating an identical SysEx file for release v2022, unfortunately, without much success.
I am able to build all relevant files but size and contents are quite different to the release (and I am a bit wary of screwing up my working P600).

@image-et-son could you give a few details on your build environment?
On Linux, I am using avr-gcc 5.4.0 (package gcc-avr 1:5.4.0+Atmel3.6.2-1+b1 on Debian Bullseye).
On MacOS, I have avr-gcc 9.4.0 via Homebrew from https://github.com/osx-cross/homebrew-avr/.

I have updated the fw2syx script to use python3 and would be happy to make a PR if that is ok.

[image-et-son]

Hi Jörg,

first, as long as you're happy to transfer the hex to the Teensy using USB and the Teensy loader app, then I need not worry don't worry about messing up your P600. It's quite safe if you can flash it completely.

Then: initially it took me 2-3 weeks to get a working compliation environment running and to migrate from the old gcc version which GliGli last used. The changes in gcc version over time are hard to understand, for me at least. I managed to compile it on my Mac once but I don't remember what version that was. I ended up using the following setup:

• Virtual Machine (Virtual Box running on Windows) with Linux Fedora 35 installed
• avr-binutils, version: 2.37
• avr-gcc, version: 11.1.0
• avr-libc, version: 2.0.0

Advantage: you get some great developer tool on Linux :-)

You can never expect the binary to be the same of different gcc versions and compilation environments, I have found. But different versions may work equally well. And - as said above - it is next to impossible to understand the differences.

Please create a PR for the script. Great that you updated it!

[jmechnich]

Thanks for your reply!

I have worked with the ARM-based Teensys before, so I would be comfortable to flash them using USB...just trying to keep my life easy (for now). :)

"CrossPack for AVR" for the Mac which is mentioned in the README seems hopelessly outdated (and does not work at all on M1). Once I have figured out a working environment for MacOS I will submit an update.

[jmechnich]

I was able to build a working firmware by using avr-gcc@11 from homebrew on MacOS 12.6 (M1 Macbook Air).
Edit: build was broken at the time of writing, workaround: osx-cross/homebrew-avr#280

Here a short list of my experiences: 😄

• gcc-avr 1:5.4.0+Atmel3.6.2-1+b1 on Debian Bullseye: 230 SysEx messages, not working (blank display, no sound)
• Homebrew AVR GCC 9.4.0 on MacOS: 256 SysEx messages, starts but synth freezes after a few keyboard presses
• Homebrew AVR GCC 10.3.0_1 on MacOS: 253 SysEx messages, working normally
• Homebrew AVR GCC 11.3.0 on MacOS: 251 SysEx messages, working normally

I did not bother to test GCC 5 and 8 on MacOS which are available as well.
Maybe I am going to try building a newer version of gcc on Debian following those instructions and try again.

The good news is that it was always possible to reflash via MIDI.

[image-et-son]

Hi there, good news!

I think it would be good to document all compilation environments that work, especially to one working method for each platform. I have already added my solution to the compilation guide (although not very detailled). Every "new" contributor who uses a new environment should add that.

[jmechnich]

A modern and sort of platform-independent solution could be one using docker/podman (e.g. using one of the readily available images on Docker Hub, e.g. https://hub.docker.com/r/lpodkalicki/avr-toolchain). When I find the time I will start documenting and place a PR.

[jmechnich]

I have submitted PR #206 in order to take care of this matter.
As I don't have a machine running Windows at home, I was not able to optimize the build instruction for this particular OS.
It should be easily possible to apply the Docker-related instructions if one uses WSL, for Docker Desktop or compilation inside the host system directly the instructions are likely a bit more convoluted.

I could easily add a build.sh script as well in order to take care of everything in one command for convenience sake.

[image-et-son]

Hi Jörg, while many people around me at work are using Docker, frankly, I have never used it. Can you point me in the right direction what this will do for the project. How would I use it?

[jmechnich]

Hi Felix,

inside the file BUILD.md that I supplied with PR #206, you can see how it works approximately.

The general advantage is to create a well-defined containerized build environment to be used

• on all platforms supporting Docker
• independent of the configuration of those platforms

By the way, "Docker" is a commercial product...podman is the open equivalent that e.g. I am using on MacOS (but obviously comes from Linux platforms). Basically you can use it as a drop-in replacement by setting alias docker=podman.

In comparison to using a VM, you can more easily integrate it into the host environment (like here: just mount the source tree into the container and run the compilation, with the output being produced in situ), and it is easier to distribute (i.e. you write a Dockerfile with a few lines of text to define the image, in contrast to actually creating a VM image and offering it for download).

On Linux, all of this is pretty straightforward: install the docker/podman package and follow the instructions in BUILD.md. On MacOS it is slightly more complicated but well-documented (you have to use packages from Homebrew). On Windows, it is pretty easy if you are using the Windows Subsystem for Linux (WSL) because it is simply a Linux VM well integrated into Windows. You could also run it directly on Windows but that would be a bit cumbersome.

In any case, all changes in #206 are independent of how compilation has been handled so far. It is just another option (but slightly more modern).

I encourage you to try it out 😃

Edit:
As a slightly more specific example, I was able to build identical firmware files on Debian Bullseye x86_64 and MacOS 12.6 ARM64 by copy-pasting and running the same 1-2 lines of shell commands.

Edit2:
Using Docker, it should be easily possible to trigger a firmware build using Github Actions with each push, tag and/or release.