depending how it’s written. If you encounter such code or libraries, set the CPU speed to the default 120
MHz and re-upload.
Optimize
There’s usually more than one way to solve a problem, some more resource-intensive than others. Since
Arduino got its start on resource-limited AVR microcontrollers, the C++ compiler has always aimed for the
smallest compiled program size. The “Optimize” menu gives some choices for the compiler to take
different and often faster approaches, at the expense of slightly larger program size…with the huge flash
memory capacity of M4 devices, that’s rarely a problem now.
The “Small” setting will compile your code like it always has in the past, aiming for the smallest compiled
program size.
The “Fast” setting invokes various speed optimizations. The resulting program should produce the same
results, is slightly larger, and usually (but not always) noticably faster. It’s worth a shot!
“Here be dragons” invokes some more intensive optimizations…code will be larger still, faster still, but
there’s a possibility these optimizations could cause unexpected behaviors.
Some code may not work the
same as before.
Hence the name. Maybe you’ll discover treasure here, or maybe you’ll sail right off the
edge of the world.
Most code and libraries will continue to function regardless of the optimizer settings. If you do encounter
problems, dial it back one notch and re-upload .
Cache
This option allows a small collection of instructions and data to be accessed more quickly than from flash
memory, boosting performance. It’s enabled by default and should work fine with all code and libraries. But
if you encounter some esoteric situation, the cache can be disabled, then recompile and upload.
Max SPI and Max QSPI
These should probably be left at their defaults. They’re present mostly for our own experiments and can
cause serious headaches.
Max SPI determines the clock source for the M4’s SPI peripherals. Under normal circumstances this allows
transfers up to 24 MHz, and should usually be left at that setting. But…if you’re using write-only SPI devices
(such as TFT or OLED displays), this option lets you drive them faster (we’ve successfully used 60 MHz
with some TFT screens). The caveat is, if using
any
read/write devices (such as an SD card),
this will not
work at all…
SPI reads
absolutely
max out at the default 24 MHz setting, and anything else will fail. Write =
OK. Read = FAIL. This is true
even if your code is using a lower bitrate setting…
just having the different
clock source prevents SPI reads.