/*                                             -*- mode:C++; fill-column:100 -*- */
/**

\page AdvancedExamples Advanced Examples

\section AdvancedPacketHandling Advanced packet handling

In the usual flow of SFB affairs, packets are input from any of the four faces and are reacted to,
and output packets are sent out to any of the four faces, from packet handlers, Alarm handlers, or
the loop() method.  But sometimes more fine-grained control over packet handling is needed, and the
core software provides more advanced mechanisms for that purpose.

 - \subpage trigger.cpp "Reacting to conscious packets"

 - \subpage hallucination.cpp "Creating packets in memory"

\section QLED Controlling the built-in LEDs without delays

For debugging, display, or just fun, we often want to blink the onboard LEDs in response to events.
The 'good old-fashioned way' to blink an LED is (1) Turn it on, then (2) Delay for a while, then (3)
turn it off, but if we do that -- step (2) specifically -- inside a packet (or alarm) handler, we
can run into trouble.  Since only \e one \e handler \e runs \e at \e a \e time, \b all handler
functions (packet or alarm) need to be relatively quick, to give the other handlers a chance.  But
calling #delay() is the \e opposite of being quick.

The #QLED object (an instance of #SFBQLED) provides a way to schedule LED 'on' and 'off' 'events'
without calling #delay().

 - \subpage qled1.cpp "Blink LEDs from a packet handler without blocking"



\section AdvancedEeprom Advanced EEPROM usage

In the basic tutorials, \ref BasicEeprom 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.

 - \subpage eeprom3.cpp "Waiting for EEPROM writes to finish"

 - \subpage eeprom4.cpp "Use a checksum to validate/initialize EEPROM"

\section TimerSketches Using hardware timers

As an advanced technique, if you need more accurate timing than the \c Alarms system provides, you
can use a \e hardware \e timer.  There are three hardware timers specifically reserved for sketch
use, named \c Timer1, \c Timer2, and \c Timer3.  In addition, there is a fourth timer (named \c
Timer4, naturally) also available, but that hardware is shared with the hardware PWM (Pulse Width
Modulation, see \ref PWMSketches) system, so a single sketch cannot use both hardware PWM and \c
Timer4.

Hardware timers are a more advanced topic, primarily because (unlike with \c Alarms) the 'handler'
functions you write are executed with \e interrupts \e disabled, meaning that while your handler is
running, \e nothing \e 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!

 - \subpage timer1.cpp "Blink an LED using a hardware timer"

 - \subpage timer2.cpp "Configure a twelve hour clock"

 - \subpage timer3.cpp "Red light Green light"

 - \subpage timer4.cpp "A whiter shade of blinky"

\section PWMSketches Using the hardware PWM module

--TO COME--

\section PowerSketches Controlling power

--TO COME--

*/
