Feature Summary

The  allows the development of applications which can do a combination of the following:

• Drive the  protocol stack:
  • Automatically connect to a  network
  • Manage services and data flows
  • Send data to one or more computers on the Internet
  • Receive data from computers on the Internet
  • Develop very low power, multithreaded applications with full uC/OS-II support
  • Scan for available networks and choose a network dynamically
  • Put the device into low power sleep such that it can only be awoken via a non-maskable interrupt (NMI) such as the RESETn pin
• Interact with on-chip sensors and external devices (see Devices for a complete list):
  • On-chip sensors include:
    • Temperature
    • Supply voltage (“battery”)
    • Charge accounting - Measure the total energy used by the network stack and user application
  • Interfaces for external sensors include:
    • General Purpose Input-Output (GPIO) pins: Set digital outputs, including multiple IOs simultaneously, and respond to level-triggered digital inputs
    • Analog-to-Digital Converter (ADC) inputs: Take 10-bit ADC readings with variable gain and offset
    • Serial Peripheral Interface (SPI) Master: Supports triggering repeated DMA transfers at a configurable rate. The SDK allows the user to specify clock phase and polarity, as well as set bit order and slave select pin (up to 3 slave devices), more with external logic. 
    • Inter-Integrated Circuit (I2C) Master:  Including setting the clock frequency. 
    • 1-Wire Master
• Access miscellaneous on-chip services:
  • Random number generator:  E.g. to seed a Pseudo-Random Bit Sequence generator
  • Network time: Retrieve network time to timestamp data or schedule synchronous (network wide) activity
  • AES 128 data encryption: Encrypt/decrypt arbitrary payloads
  • File system: Create/read/write files in the wear-leveled filesystem
  • Universal Asynchronous Receiver/Transmitter (UART): HDLC encoded serial port for interacting with other devices
  • Command Line Interface (CLI): Serial port for human interaction with the networking stack and the user application

Important System Limitations

The  is intended to allow a systems integrator to build a complete system without the need for an external microprocessor, reducing system cost and power use. A wide range of applications are well suited for this platform, however some restrictions apply and should be carefully considered. The following is a general guideline for some of these system limitations:

• The UART protocol is HDLC which is implemented in hardware and cannot be turned off. A "raw" UART mode was added in OCSDK 1.2.0 that does not use HDLC encoding. 
• The SDK currently only exposes single point sampling of the onboard ADC.  It is not possible to obtain periodic samples with a consistent period above ~ 100 Hz. Also note that the the network stack activity (including radio activity) is prioritized above the user application and will pre-empt ADC sampling activities. It is possible to temporarily pause radio activity to prioritize sampling, but the frequency and duration must be low enough to not interfere with network operation.
• High-speed I2C or SPI arbitrary transactions is limited. While there is support for automatically clocked repeated SPI transfers, arbitrary exchanges of data (via a dn_ioctl()) can only be called at the OS level and thus are limited to 100 Hz-1kHz, depending upon radio activity.  I2C uses a 5-byte FIFO that must be managed by the application.
• High-speed I/O sampling frequency is limited. The re-arming of a level trigger can take 10’s of ms due to interrupt priorities when a mote is using the radio, which limits the effective sampling rate to < 1 kHz, perhaps <100 Hz when a mote has a busy communications schedule.
• The PWM output isn’t currently exposed in the SDK. PWM support was added with OCSDK 1.2.0
• It is not possible to timestamp data or schedule activity more accurately than a few ms due to OS latency and timer granularity (1 ms). It isn’t possible to time events more accurately, and results will depend on radio activity.
• Raw access to the radio is not supported as only a payload interface is provided to the application.
• There is no support for reading networking stack information, e.g. the slotframe & link information or list of neighbors.  The networking part of the system is designed as a turn-key solution and the application need only send and receive data.
• There is no control available to the application for an external PA/LNA. These pins are controlled by the network stack software.
• The number of tasks and mutexes is limited, and there are 10 user priorities available. 
• It is strongly encouraged to limit application memory use to 32 kBytes of code space and 12 kBytes of RAM (16 KB may be used with stack 1.3.2.1 or earlier, but limiting your application to 12 KB ensures that you will be able to use later stacks with additional features). The system will not prevent going over these recommendations, however doing so may limit the ability of these devices to be reprogrammed over the air in the future using SmartMesh IP's OTAP (Over The Air Programming) capability.
• Caution should be used if using the flash file system as a datalogger. The built in flash should not be written more than 20,000 times to guarantee lifetime use.  If not carefully implemented, this could lead to early failure.
• The application cannot dynamically allocate memory.  While malloc() is present in the compiler, it cannot be used.
• The compiler to be used for development is IAR EWARM >= version 6.4. No other compilers are supported.
• Carefully consider applications that drop off the network for long periods of time to “save power.” While this can certainly be done at the device, without a network to set time, devices may drift sufficiently such that the time spent listening for the network could erase any savings spent by staying off the network.