building o_c in catalina

[twhiston]

How can o_c be built when using Catalina? Seems like arduino-1.8.1 doesnt work due to the 32-bit toolchain and more recent versions of the IDE or teensyduino fail wth compilation errors (as expected from the build instructions). Is it actually possible to build with a current version of OSX? Thanks!

[patrickdowling]

Catalina is such a PITA. Unfortunately I don't think there's an easy solution. I'm not sure when it started failing entirely though. My last info was that with newer versions the code would at least compile, but there were side effects like the display corruption.

[timchurches]

The only solution is to use a pre-Catalina version of macOS with ArduinoIDE 1.8.1 as required by the o_C code. I have kept an old MacBook Air that can’t be upgraded to Catalina for that purpose.

The latest versions of ArduinoIDE work fine on Catalina, but they can’t be used to compile the o_C code to a binary that runs without crashing.

Tim C

On Thu, 13 Feb 2020 at 18:12, Patrick Dowling notifications@github.com wrote:

Catalina is such a PITA. Unfortunately I don't think there's an easy solution. I'm not sure when it started failing entirely though. My last info was that with newer versions the code would at least compile, but there were side effects like the display corruption.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mxmxmx/O_C/issues/99?email_source=notifications&email_token=AAV2AYP4EPIW6DJNW3UZJ4DRCTXF7A5CNFSM4KUD2PK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELTVDRY#issuecomment-585585095, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAV2AYPHJA4QH544756ACBLRCTXF7ANCNFSM4KUD2PKQ .

[wraybowling]

I've been fighting with this as well. I think perhaps we could resolve it by using PlatformIO instead of the Arduino IDE. I'm just starting to learn about it however, so help would be appreciated.

[wraybowling]

Do we understand why the screen will not work when compiled with the newer version of Arduino/GCC? The root of the problem could be that the code simply needs to be refactored to meet newer standards, and those shouldn't be brushed under the rug because OSX is just the first in line of what will eventually be many toolchains that will phase out support for Arduino 1.x

Issue #92 touches on this, and I'm not the only one that wants to get to the root of the problem. It's just going to get worse. I do not recommend keeping an entire old operating system just to flash firmware on one Eurorack module. Be realistic.

[patrickdowling]

The screen stops working because of a timing issue. That has two parts, and the issue exists in all versions. The first is that the apps use too much CPU time, and the second is the handling when that occurs. It's exacerbated with newer gcc versions because the optimizations and generated code are different -- the code seems to be smaller, but runs slower, which triggers the overrun more often.

I assume you mean #98? The branch I posted there fixes the glitches by handling the second part. I don't think anyone's going to optimize all the applications...

Platformio just brings a different set of problems.

[timchurches]

@wraybowling you need to understand that maintaining o&C code so that it works with updated build chains etc takes considerable time and effort, for which there has to be some rewards. In the case of o&c, the various micro versions of the module destroyed the modest but useful revenue stream from PCB sales and contributions from third-party builders, and the fork of the code by the Hemisphere guy meant that most o&c owners seem to be running his code. Thus there isn't much motivation for any of the original o&c code authors to spend time and effort on the original o&c code base, just so it will compile on later toolchains running on the latest version of macOS.

[timchurches]

You can always run a linux VM under Catalina to host the older 32-bit Arduino toolchain required by o&c. That's a workable solution that involves a lot less effort by us.

[patrickdowling]

It's also not uncommon to freeze the toolchain version as "known good" and you're on your own with any other. Issues aren't always as immediately visually apparent as display glitches so an upgrade requires a full test. Which is definitely not fun, especially with constant, moving target upgrades. As @timchurches says, maintaining the code isn't free.

The branch I mentioned does seem to compile fine with the latest Arduinoteensy though.

[wraybowling]

For the moment, a linux VM seems to be the quickest viable solution. I'm just trying to get you all to think about how challenging this repo will be to maintain if these limitations aren't laid out clearly in the build instructions. I for one prefer trying to modernize, so if I come across a better solution, I'll come back and let you know. Hemispheres Suite is affected by this too

[patrickdowling]

Hm, the quickest solution seems to be to use the branch; eventually I suppose that should make its way into master. There's no need to modernize anything, and in the mean time these build instructions at least are pretty explicit about what's required.

It's not like these things haven't been thought about. The number of people building their own firmware is small, the end user benefit marginal, it's a lot of time vs. little reward, and time is limited. Unless something in that equation changes, modernization probably isn't going to be a priority. Ultimately one outcome might be that it has run its course. Another would be an injection of resources.

If someone wants to modernize instead, have at it. I have a (private) branch with a refactoring of the IO and app framework that'd be a good start, but can't currently justify spending time on reviewing and rewriting all the apps.

[timchurches]

Far more interesting would be porting the o&C code to run on the Teensy 4, which is a drop-in replacement for the Teensy 3.2, in theory. I n practice, the SPI libraries and/or hardware support on the T4 seemed slower than on the T3.2, and that was a showstopper when tried last year. Might be worth revisiting. The T4 would need to be throttled to run at a much slower clock speed, which it can, with power consumption about the same as the T3.2.

[patrickdowling]

Yes, if one were to spend any significant amount of time on the code, something like that would be far more interesting. OTOH I already have a stm32f4 accelerated o_C 😃

[wraybowling]

Huh. I thought the Teensy 4 pin layout was different. Definitely worth investigating.

[patrickdowling]

I thought the Teensy 4 pin layout was different.

It is, but IIRC it's compatible enough for o_C (the internal DAC isn't required, and the ADCs might be worse?). So it's mostly a matter of writing new drivers since the timing around the SPI/DMA is critical. That will always be a hard limit, so "more horsepower" doesn't automatically translate into "better" or "more useful" but that's a separate issue 😄

[catkins]

Would it be feasible to create a Docker image with the correct versions of the toolchain installed to build the firmware? It could equally be used to automatically create the artifacts on release using Github actions or the like.

[patrickdowling]

Interesting. Not sure if there's any benefit for end users though, now that my branch seems to work on newer Teensyduinos (assuming that makes it upstream at some point). And frequent releases aren't really much of an issue right now 😉

[catkins]

I got most of the way through dockerizing the toolchain, but turns out that the Teensyduino installer needs an X11 session as it pops up an installer 🤦

The docker container doesn't have access to to one, and fails. I lost steam after that, but I'm sure it is possible to automate albeit fiddly. Apparently proper headless installation was added in Teensyduino 1.43. https://www.pjrc.com/teensyduino-1-43-released/

FROM ubuntu:focal

# install dependencies
RUN apt-get -qq update && apt-get -qq -y install \
    curl \
    jq \
    libxext6 \
    libfontconfig \
    libxft2 \
    x11-xserver-utils

RUN mkdir -p /arduino
WORKDIR /arduino

# install arduino-cli
RUN curl -fsSL https://raw.githubusercontent.com/arduino/arduino-cli/master/install.sh | sh
ENV PATH=/arduino/bin:$PATH
RUN arduino-cli core list
RUN arduino-cli core install arduino:avr

# install teensyduino
RUN curl -qq https://www.pjrc.com/teensy/td_135/TeensyduinoInstall.linux64 > TeensyduinoInstall.linux64
RUN chmod +x TeensyduinoInstall.linux64
RUN export ARDUINO_TOOLS=$(arduino-cli config dump --format json | jq -r '.directories.data') \
  && /arduino/TeensyduinoInstall.linux64 --dir=$ARDUINO_TOOLS/packages/hardware

# add o_c source code to image
ADD . /o_c_REV
WORKDIR /o_c_REV

# compile artifact
RUN arduino-cli compile .

[catkins]

All I wanted was to recompile with the boring app names haha! Ahwell.

[patrickdowling]

Thanks. As mentioned above you should probably be ok with newer Teensyduino versions and the code in this branch.

Heh, all I wanted was to see how interleaving the screen/DAC updates would work out, here we are now :)

[w-winter]

Running Catalina here, was able to build with Arduino IDE 1.8.1 running on a Windows VM. Copied the hex file generated on the VM to my host machine and used the latest Mac-friendly version of Teensy Loader on OSX to program the board with the hex.