search

mxmxmx / O_C

display w/ dac
472 stars 122 forks source link

Meta-Q: Display going weird under certain circumstances #94

Closed Triscus closed 5 years ago

Triscus commented 5 years ago

While using Meta-Q under certain circumstances the display is going weird.

Sometimes it is mirrored or the sections are in the wrong order (e. g. the title bar is at the bottom, the rest of the screen is above.) more often the display is offset to the bottom, the upper half of the screen is black.

I noticed the behavior on one of my modules while using the trigger inputs on both channels or when they share the same trigger input.

Tested it on a second module but it didn't show this behavior at first. Now I set the latency setting to 2ms on this module and the display is going weird too (using both trigger inputs).

The display is OK, I changed it when the issue came up the first time.

I'm using v1.3.6 with the uO_C Hardware.

IMG_20191008_215616

IMG_20191008_215627

patrickdowling commented 5 years ago

Are you using a pre-compiled .hex? While it might be related to the latest changes that type of display corruption has been reported when compiling using any version of arduino/teensyduino higher than (IIRC) 1.8.1/1.35. It seems independent of the actual app that's running.

There seems to be some kind of timing issue or interaction with the libraries that's hard to diagnose and I've never been able to reproduce it.

Triscus commented 5 years ago

At first I used self-complied v1.3.6a from the dev136 branch (Arduino 1.8.8 and Teensyduino 1.4.5 on Windows 10) but I was able to reproduce the behaviour with the latest v1.3.6 pre-compiled release.

timchurches commented 5 years ago

I think Max mentioned that he was now using the latest version of Arduino/Teensyduino to compile the hex for releases and no issues had been encountered. But seems like that may not be the case. As Patrick says, it is very non-deterministic, and seems to happen randomly. Try compiling with Arduino 1.8.1 and Teensyduino 1.35 as Patrick suggests. On past experience, that will solve the problem. Hopefully the latest code still fits when compiled like that.

mxmxmx commented 5 years ago

mmh, yeah, i was secretly hoping that issue had disappeared. i've now replaced the hex compiled with the older gcc: https://github.com/mxmxmx/O_C/releases/tag/1.3.6 ...

had to disable a bunch of preset scales to make it compile; not sure how they compile the "VOR" branch (in as much that won't compile without disabling even more scales)

timchurches commented 5 years ago

Just BTW, the earlier versions of Arduino such as v1.8.1 as required by o_C don’t run under macOS 10.15 (Catalina), so think twice before upgrading. I didn’t. Luckily I also have an ancient MacBook Air running macOS 10.13...

mxmxmx commented 5 years ago

ah, good to know ... (i haven't yet).

@Triscus can you let us know if that was it? thanks

patrickdowling commented 5 years ago

Yeah, it'd be good to know if it goes away again with 1.8.1. I'm kind of torn on the issue... I'd really like to know what's causing it, but the turn-around times and clunky tooling mean there's a lot of inertia to overcome.

Arduino isn't the only victim of 10.15, it's also older versions of avr-gcc and other compilers.

Triscus commented 5 years ago

The latest per-compiled version works. I was able to reproduce the issue with an older version right away.

I also compiled the latest version with Arduino 1.8.1 and Teensyduino 1.3.5 . The Optimization Option in Arduino needed to be 'Smallest Code' as the code was about 500 Bytes too large when set to 'Faster'. I ran it for a couple of minutes and it seems to work.

mxmxmx commented 5 years ago

ok, thanks for trying ...

re optimization, this branch does/should compile with "faster" (-O2); i haven't pulled this over into the master branch (but you can simply use the pre-release hex, that's the same thing). interesting to know though that it seems to worked with -Os ...