…But only when I flash the board with the optimization set as “fastest” in Arduino. If I reflash the exact same config, but set optimization as “smallest code” then everything works just fine.
It’s a very noticeable pause between the out.wav, and then the hum begins, and that’s it, no lag anywhere else that I can detect. Tried 2 different boards, 2 different SD cards, dozens of fonts and it’s consistent.
ProffieOS 7.14
Also it doesn’t even seem to matter if you actually have an OLED screen, just that you enable it in the config.
Not a big deal really, but I was wondering if anyone could explain why this happens?
Also, for anyone that has a saber with an externally mounted OLED screen and a removable chassis (like the new Sabertrio models)…You apparently have 5 seconds from flipping the kill switch to seat your chassis in the saber or your OLED times out … It took me awhile to figure this out lol.
I am very confused, like I walked into a room half way through a conversation, context is required. there’s a few things I would suggest, the first is connecting the saber to the pc using the micro usb and opening arduino ide and turn on serial monitor.
this should show you the output you can then test the if there’s any dead air on the wav files or if it is lagging.
p.s. if this is a continuation of an older topic I would reference it.
I’m not an expert but the different optimization levels are in reference to the manner in which the compiler compiles the code and the smallest code is best because it is trying to make the code as efficient as possible where as Fastest is trying to compile without any optimization and as fast as it can. hence why smallest code is best, not to mention we only have 262144 bytes of memory so it makes sense to have it smallest code. p.s. if Profezzorn the inventor of the proffieboard says use that option he’s got reasons.
It’s not supposed to.
The question is; is this a bug in ProffieOS, or a bug in the compiler?
What version of the arduino-proffieboard plugin are you using?
No, “Fastest” means that it uses -O3, which tries as hard as possible to make the compiled code run fast, but in doing so it usually makes the code much larger.