delay() is the opposite of being quick.
Using the EEPROM illustrated the primary functions used for accessing the EEPROM. Here we touch on one additional function -- eepromWait() -- and look at an advanced mechanism for initializing EEPROM data.
Alarmssystem provides, you can use a hardware timer. There are three hardware timers specifically reserved for sketch use, named
Timer3. In addition, there is a fourth timer (named
Timer4, naturally) also available, but that hardware is shared with the hardware PWM (Pulse Width Modulation, see Using the hardware PWM module) system, so a single sketch cannot use both hardware PWM and
Hardware timers are a more advanced topic, primarily because (unlike with
Alarms) the 'handler' functions you write are executed with interrupts disabled, meaning that while your handler is running, nothing else is happening -- no input is being read, no output is being shipped, the millis() clock isn't ticking, and so on. So you need to keep your timer handler functions relatively short and simple as much as possible.
But, that said, don't be afraid! Sometimes a hardware timer is just the right tool for the job!
Ticker, and a higher-level object called Profile.
The Ticker assigns microseconds to one of several broad categories (see SFBTickerCategories) like 'packet handler' or 'alarm handler', which are just what you would expect, or 'background processing', which includes time spent in the
loop() functions as well as whatever isn't categorized somewhere else. Also, there are three categories (e.g., TICKER_SKETCH0) reserved for whatever execution-time-counting needs you may have.
Ticker, an instance of SFBTicker, is built into the core software; its primary limitation is that its microsecond-based counters overflow after about an hour, just like micros().
The Profile operates with millisecond resolution, so it can count well over a month of time without overflowing, using the same set of SFBTickerCategories. It gathers data from Ticker and uses an alarm to reset Ticker regularly to keep it from overflowing (so if Profile is active, results returned from SFBTicker::getUsec(u32) may be somewhat hard to interpret -- use SFBProfile::getMsec(u32) instead).
Configuring the processor speed only demonstrated changing the processor speed in the setup() function. It is possible to change the Processor speed at any point(s) during a single sketch execution, but the sketch writer should be aware of some limitations and warnings before they try to do so. See SFBProcessor::setCode() for the details.
facePrintf and packetScanf, have an extension called 'custom Z handlers', which enable you to define your own CustomPrintfHandler (which see, for details) and/or CustomPacketScanfHandler, and then handle formats involving mixtures of traditional formats and your custom format.