building o_c in catalina about o_c HOT 20 OPEN

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.

from o_c.

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.

from o_c.

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.

from o_c.

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.

from o_c.

from o_c.

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.

from o_c.

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.

from o_c.

@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.

from o_c.

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.

from o_c.

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

from o_c.

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.

from o_c.

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.

from o_c.

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 😃

from o_c.

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

from o_c.

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 😄

from o_c.

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.

from o_c.

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 😉

from o_c.

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 .

from o_c.

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

from o_c.

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 :)

from o_c.