Reflex packet handling), but it also possible to do 'good old-fashioned' a-byte-at-a-time serial input. This section illustrates that 'legacy serial' support.
loop()function, you create "reflexes" for your sketch, saying "Whenever this type of packet arrives, call that function to handle it." Reflex packet handling is the SFB's 'native tongue' -- it is what SFB's use, by default, to talk to each other, and it underlies the 'code flow protocol' that allows SFB's to download sketches from host computers and each other.
Using the packet system in your sketch can feel quite strange at first, because the sketch never actually reads any input. What is really happening is that the core software is collecting input bytes that arrive from the outside world, and storing them in memory. The sketch isn't bothered unless a complete line of text -- a complete 'packet' -- is available, and the sketch has expressed an interest in packets of that type.
Consider these examples:
Traditional serial communications may feel too low-level and rickety, like trying to build a house out of toothpicks, well, perhaps Reflex packet handling may feel too uncertain and out-of-control, like trying to sip tea on a racing horse. "Conscious packet handling" falls somewhere in between -- it works with whole packets, not a byte at a time, but avoids all the automatic baud rate negotiation and background packet handling.
(See Advanced packet handling for more examples.)
Alarmssystem to make that easy. You write an 'alarm handler' function, and create and set an alarm, and when the alarm goes off your alarm handler gets called.
Alarms can be used for one-shot or repeating events, they can be canceled, or reset for a different time, before or after they have gone off, and dozens of them are available for sketch use. Alarms provide resolution down to the millisecond, but they don't guarantee perfect accuracy: An alarm handler may be called right on the millisecond for which it was scheduled, but it may run one or more milliseconds later, depending on how busy the system is.
If the no-less-than-millisecond resolution or possible delays of Alarms are a problem for your timing application, see Using hardware timers for an alternative!setup() function will run again, and whatever needs to be initialized will get initialized.
But often, there is information that one would like to preserve for the future, power-losses, reboots, or whatever notwithstanding. It might be nice to know how many times the board had been rebooted, just to make up an example (see getBootBlockBootCount).
Enter the EEPROM. EEPROM stands for 'Electrically Erasable Programmable Read-Only Memory', which is an extremely long-winded way of saying 'persistent storage', like a hard drive.
Note that these basic examples only change the processor speed during their
setup() function. As an advanced technique, it is possible to change processor speed 'on the fly', but there are some significant limitations and warnings you should be aware of before you try. See Changing the processor speed on the fly for more information.