Added some explanation about the serial debugging.

[tinyos-2.x.git] / tos / lib / mac / tkn154 / TKN154_MAC.h

diff --git a/tos/lib/mac/tkn154/TKN154_MAC.h b/tos/lib/mac/tkn154/TKN154_MAC.h
index 965e4c7534e98f1cb391a1067c1c56f894b81358..20d4e982c4f4c8295ad62c20757697fada13245d 100644 (file)
--- a/tos/lib/mac/tkn154/TKN154_MAC.h
+++ b/tos/lib/mac/tkn154/TKN154_MAC.h
@@ -291,29 +291,35 @@ token_requested_t rcombine(token_requested_t r1, token_requested_t r2)
   /****************************************************************** 
    * ATTENTION! Debugging over serial is a lot of overhead. To
    * keep it simple, here are the rules you have to follow when
-   * using the dbg_serial() command:
+   * using the dbg_serial() macro:
    *
    * - dbg_serial() is used like dbg(), i.e. you pass it at least
    *   two strings, the first one describing the component/file,
    *   the second is a format string (like in printf())
    * - following the second string, there may be zero up to 
-   *   two parameters -- these must be (cast to) uint32_t! 
+   *   two parameters -- these must be (cast to) uint32_t and
+   *   the format specifier must be "%lu", e.g.
+   *   dbg_serial("MyComponentP", "Value: %lu\n", (uint32_t) val);
    * - both strings must be constants (pointers always valid)
    * - no data is sent over serial, unless dbg_serial_flush() is
    *   called; try to call it when the system is idle or at least
-   *   when no time-critical operations are pending
-   * - on the PC use the printf java client to display the text
-   *   (see tinyos-2.x/apps/tests/TestPrintf/README.txt)
+   *   when no time-critical operations are pending; on TelosB
+   *   you can also press the user button to trigger a flush
+   * - on the PC use the printf java client to display the debug
+   *   output (see tinyos-2.x/apps/tests/TestPrintf/README.txt);
+   *   the output format is component:line-in-source-code:text
    *
    * The ASSERT(X) macro is used to test for errors. If X evaluates 
    * to zero, then 3 leds start blinking simulataneously (about 2Hz)
-   * and the node *continuously* outputs over serial the filename+line
+   * and the node *continuously* outputs over serial the filename/line
    * where the (first) ASSERT has failed. This means, even if your
    * TelosB was not attached to your PC while the ASSERT failed you
-   * can still pull the information out later.
+   * can typically still pull the information out later.
    *
-   * All dbg_serial() and ASSERT() statements are removed, if
-   * TKN154_DEBUG is not defined (which is the default).
+   * When TKN154_DEBUG is not defined (which is the default), then
+   * dbg_serial() maps to dbg(), i.e. is completely removed unless 
+   * the platform is TOSSIM, and in the ASSERT(X) statement X is 
+   * evaluated/executed, but the result is ignored.
    **/
 
   /* -> functions are defined in DebugP.nc */
@@ -324,7 +330,8 @@ token_requested_t rcombine(token_requested_t r1, token_requested_t r2)
   #define dbg_serial(m, ...) tkn154_dbg_serial(m, __LINE__,__VA_ARGS__)
   #define dbg_serial_flush() tkn154_dbg_serial_flush()
 #else
-  #define ASSERT(X) if ((X)==0){}
+  // Note: in an ASSERT(X) the X must always be evaluated/executed!
+  #define ASSERT(X) while(!(X)){ break;}
   #define dbg_serial(m, ...) dbg(m, __VA_ARGS__)
   #define dbg_serial_flush()
 #endif