Page Comparison

You've compiled your shiny new app and installed it on a mote, and it works!  Congratulations. You're not done yet however.  Congratulations!  You still have some work to do though...

Stress testing is an important step in making sure that your application behaves reasonable reasonably when the network or the device gets busy.   Most applications have been written so that unexpected events result in an ASSERT(), and thus a mote reset.  This is good for catching problems, but is not always a good strategy in a real setting - rebooting and rejoining is expensive, both in the energy to search for a network, and lost opportunity to send or forward data. Recoverable errors therefore should be handled gracefully. Unusual errors like a task failing to start, or a device failing to open are reasonable things reasons to ASSERT() on.

Tips

• Join a network: Most samples are written to explain a concept without having the mote join a network. Always test your application with the mote joined to a network - this can catch race conditions between the stack and app that might otherwise be missed.
• Test response codes: Your code should always look at responses to OCSDK functions - some non-zero (!= DN_ERR_NONE or DN_API_RC_OK) responses provide actionable information that can be used instead of asserting, e.g. if a device is already open, or the mote is in a state where the command is not valid.
• Get busy: By default the embedded manager can handle data published every 9s in a 100-mote network - normally you should be using services if you intend to publish faster than that.  Try publishing every 5s to see what your application does in the event of a packet being rejected by the stack.  You can also add a dummy higher-priority task that keeps your other tasks waiting to check for thread priority problems.
• Check your buffers:  If you have the possibility of variable size messages or device commands, make sure you test with the maximum message sizes to avoid buffer overruns.
• Watch your tasks: the mshow stacks CLI command is available to check stack memory usage. If you're getting close to 100% on one of your application's tasks, you should increase its allocation in app_task_cfg.h.

...