 |
Wirepas SDK
|
|
Wirepas SDK
|
Applications exist in source/ subfolders, named after application name. Note that not all applications exist for every processor architecture.
Applications are categorized into two categories:
Example and unitary applications are:
| Application name | Description | Notes |
|---|---|---|
| battery_voltage_read_app | Battery voltage reading demo app | |
| ble_scanner | How to receive BLE beacons | Only 2.4GHz devices |
| control_node | To be used with control_router, switch in lighting example | |
| control_router | To be used with control_node, lighting fixture | |
| custom_app | Simple data transmission and reception | |
| evaluation_app | Wirepas Massive discovery application | |
| inventory_app_router | Inventory application using directed-advertiser for headnodes | |
| inventory_app_tag | Inventory application using directed-advertiser for advertisers | |
| low_latency_app | Low-latency mode demonstration app | |
| minimal_app | Minimal app that just starts the stack | |
| ruuvi_evk | Send sensor data | Only Ruuvitag |
| aes | Test software AES library | |
| app_persistent | App persistent feature demo | |
| appconfig | Receiving application configuration | |
| basic_interrupt | How to use interrupt service | Only Nordic nRF52xx |
| ble_tx | How to transmit BLE beacons | Only 2.4GHz devices |
| blink | Very simple blink/hello world application | |
| diradv | Direct Advertiser demo app | |
| local_provisioning | Local provisioning demo app | |
| nfc | NFC peripheral usage | Only Nordic nRF52xx |
| provisioning_joining_node | Using provisioning for a joining node | |
| provisioning_proxy | Using provisioning for a proxy node | |
| scheduler | How to use Application scheduler | |
| shared_data | How to use shared_data.h | |
| tinycbor | use of the tiny cbor library |
Production apps are following:
| Application name | Description | Notes |
|---|---|---|
| dualmcu_app | Implementation of dual-MCU API interface, used most commonly in sinks | |
| positioning_app | Application to acquire network data for the positioning use case | Only Nordic nRF52xx |
This page contains following sections:
This file is present in all applications. Application init function and its application callback functions should be implemented here as defined in the app.h file.
config.mk file is used to configure application compilation. Here, the contents of that file have been described. Only fields that are common to all applications are described here! Some applications may have own, application-specific fields which are out of the scope of this documentation. For example, content of the file could be following:
This page contains following sections:
Wirepas network supports Over The Air (OTAP) updates of devices on the network.
A network can contain heterogenous devices (different types of sensors, for example), so various different kinds of applications can coexist simultaneously in a network.
Even when upgrading a subset of nodes in the network (just nodes with a specific type of sensor, for example), all nodes will receive the update image. This is to ensure that all nodes on the network receive the update image, due to the multi-hop nature of the network. Consequently, it is crucial for a node to know if the received image, called a scratchpad, contains any updates for the node in question. This is the purpose of the application area ID.
More information about Over The Air Protocol can be found in [1].
Each new application must define its own app_specific_area_id in its config.mk file. It is a random 24-bit field that must have its most significant bit set to 1 (MSB to 0 is reserved for Wirepas):
This specific area ID will be used in two different places:
config.mk.*.otap images generated from this application build will be only accepted by nodes flashed with a bootloader matching this area ID.The app_specific_area_id is only part of the scratchpad area id existing on the device. The whole scratchpad area id is composed on 4 bytes, as following:
| byte # | content |
|---|---|
| MSB byte 0 | app_specific_area_id MSB byte 0 |
| byte 1 | app_specific area id byte 1 |
| byte 2 | app_specific area id LSB byte 2 |
| byte 3 LSB | hardware magic (see app_lib_system_hardware_magic_e) |
For example, if app_specific_area_id has value of 0x83744C and used hardware is Nordic nRF52 (i.e. app_lib_system_hardware_magic_e is APP_LIB_SYSTEM_HARDWARE_MAGIC_NRF52832_SP_2), the resulted area id stored in the devices is:
To summarize, in order to have unique scratchpad image on the device, the image must have*
app_specific_area_id ORIf, however, same application is built on different board (but having same processor architecture), it will result same area id and otap mechanism cannot disinguish the images from others.
app_area_id to avoid mismatch between its applications.Following definitions:
define the version of the application software. It is different from stack software and is application- specific. This information can be used to pinpoint which version of the application is running on the device.
This configuration defines the boards which application supports. Configuration is optional.
Example:
Application specific makefile contains application-specific build recipes. Here, the common features are documented:
This page contains following sections:
Enabling of uart_print.h app debug prints can be done with this configuration.
Example:
Using of app scheduler can be done by using this flag.
Example:
Introducing custom compilation flags for compilation can be done by extending this list.
Example:
Using of HAL for buttons can be done by this flag.
Example:
Using of HAL for hardware delay can be done by this flag.
Example:
Using of HAL for I2C interface can be done by this flag.
Example:
Using of HAL for led driving can be done by this flag.
Example:
Using of HAL for persistent memory can be done by this flag.
-DUSE_PERSISTENT_MEMORY by using CLAGS option.Example:
Using of HAL for SPI interface can be done by this flag.
Example:
Using of HAL for UART interface can be done by this flag.
Example:
There is also related flag UART_USE_DMA that can be used to enable DMA functionality.
Example:
Extending to to include folders for include search paths can be done by extending this list.
Example:
Introducing custom linker flags for ld can be done by extending this list.
Example:
Introducing of precompiled libraries (.a files) for compilation can be done by extending this list.
Example:
Using of provisioning library can be done by using this flag.
Example:
Using of provisioning library (for the existing node) can be done by using this flag.
Example:
Using of shared data library can be done by using this flag.
Example:
Introducing of new source files can be done by extending this list.
Example:
Software AES library can be enabled by using this configuration.
Example:
This folder contains various tools, mainly implemented in Python, used during build process of the application.
This page contains following sections:
This tool, used by the Makefile, allows the scratchpad binary generation for the OTAP update. It uses the ini file in the same directory
All scratchpad images received Over The Air are compressed and encrypted.
The bootloader authenticates the image and decrypts it, so authentication and encryption keys used to generate a scratchpad must match the ones stored in the bootloader.
The list of keys stored in bootloader can be configured at the end of tools/scratchpad_<mcu>.ini file. The bootloader can contain several keys and will decrypt a received scratchpad, if it can be authenticated with any of the listed keys.
By default, each application uses the same .ini file stored in tools/scratchpad_<mcu>.ini but it can be copied to the application folder and modified as needed. The new .ini file can be specified from the application as following:
The scratchpad generated from an application build use the key named default from the .ini file. It can be changed by adding the –keyname option to the invocation of genscratchpad.py script from makefile.