...
The
| Include Page | ||||
|---|---|---|---|---|
|
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.