User Manual

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.

Max QSPI does similarly for the extra flash storage on M4 “Express” boards.

Very few

Arduino sketches access this

storage at all, let alone in a bandwidth-constrained context, so this will benefit next to nobody. Additionally, due to the

way clock dividers are selected, this will only provide some benefit when certain “CPU Speed” settings are active. Our

PyPortal Animated GIF Display (https://adafru.it/EkO) runs marginally better with it, if using the QSPI flash.

Enabling the Buck Converter on some M4 Boards

If you want to reduce power draw, some of our boards have an inductor so you can use the 1.8V buck converter

instead of the built in linear regulator. If the board does have an inductor (see the schematic) you can add the line

SUPC->VREG.bit.SEL = 1; to your code to switch to it. Note it will make ADC/DAC reads a bit noisier so we don't use it

by default. You'll save ~4mA (https://adafru.it/F0H).