/**
  \example qled1.cpp 

   <b>Rule of Thumb: Don't call #delay() inside packet or alarm
   handlers.</b>

   The most common reason people are tempted to violate that rule is
   to blink an LED to indicate that some packet or time of interest
   has arrived.

   The #QLED object, illustrated in this example, provides a way to do
   that sort of blinking, without violating that rule.

   Here's the reason that rule exists:

   The traditional easy way to blink an LED is to do it from loop():
   \code
     void loop() {
       ledOn(BODY_RGB_RED_PIN);
       delay(2000);             // 2seconds of red on
       ledOff(BODY_RGB_RED_PIN);
       delay(1000);             // 1second of red off
     }
  \endcode

   That 'delay()-based' programming style works well in the loop()
   function, because loop() is a special case: When you call #delay()
   from inside the loop() function, a process called 'dispatching'
   takes place.  \e Dispatching is calling packet handlers for whom
   matching patckets have arrived, and alarm handlers whose time has
   arrived.

   When #delay(u32 ms) is called from inside #loop(), dispatching is
   performed (repeatedly), until the \c ms delay time you specified
   has been used up.  Dispatching is also performed briefly \e in \e
   between successive calls to #loop().

   So why should you care?  Because of the 'Dispatching Rule': \b No
   \b Dispatching \b While \b Dispatching.  When are packet handlers
   called?  During dispatching.  When are alarm handlers called?
   During dispatching.  That means \e dispatching \e is \e already \e
   in \e progress when a packet or alarm handler is running.  So if a
   packet or alarm handler calls #delay(), no \e other packet or alarm
   handlers can be called during that delay, because dispatching is
   already going and calling another handler would violate the
   Dispatching Rule.

   So, if #delay(u32) is called from a packet or alarm handler, that
   delay time is basically wasted.  Although low-level I/O and timer
   interrupts still occur, until that current handler returns,
   allowing dispatching to continue, any arrived packets will be
   buffered or discarded, depending on whether room is available, and
   any alarm handlers that should have been triggered will be delayed.
   And that's the reason for the:

   <b>Rule of Thumb: Don't call #delay() inside packet or alarm
   handlers.</b>

   If you were calling #delay(u32) just to blink a built-in LED, the
   #QLED object provides an alternative.  It's pretty easy to use: To
   get started, just call \c QLED.begin() in your \c setup() method,
   and then you can call \c QLED.on(ledPin, msOn) and \c
   QLED.off(ledPin,msOff) to schedule 'on' and 'off' events (lasting
   \c msOn and \c msOff milliseconds, respectively) for the given \c
   ledPin (which must be one of the built-in LEDs: You cannot use
   #QLED to blink external data pins.)

   In this sketch, when a 'p' packet arrives, the packet handler
   blinks the face LED corresponding to the source of the packet.  In
   addition, the handler either tries to send the packet on to a
   neighbor, or 'eats' the packet itself, with a long red blink when
   that happens.

 */
