 |
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 GPIOs can be done by this flag.
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. These flags are placed in the beginning of the linker command line. Prefix -Wl, is required for each separate parameter added here, or the parameters can be in a comma-separated list after a single -Wl,.
Example:
Adding compiler-provided libraries can be done by extending this list. The libraries are added to the end of the linker command line, so they are usable from precompiled libraries (see LIBS) as well.
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:
Wirepas Mesh wireless updates, or Over-The-Air-Programming ("OTAP"), use a file format called a "scratchpad". A scratchpad file contains one or more compressed and encrypted files, each of which have a specific target area ID that the file is meant for.
A tool called genscratchpad.py is used to generate scratchpad files. It reads Intel HEX files as inputs, compresses and encrypts them according to a specified .ini file, and writes out the resulting scratchpad file. Scratchpad files have a suffix of .otap.
genscratchpad.py is normally called automatically as part of an application build (Makefile), but it can also be called manually, or from user-provided scripts. Various special scratchpad files can be created this way, for advanced OTAP use.
Scratchpad files are compressed and encrypted for use with a specific Wirepas Mesh network. When a device reeives new scratchpad contents, the bootloader authenticates the scratchpad and decrypts it. Aauthentication and encryption keys used to generate a scratchpad must match the ones stored in the bootloader, or the scratchpad will not be processed further.
The list of keys stored in bootloader can be configured in the custom_bootloader_keys.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.
The bootloader has a number of preconfigured memory areas. When it processes a scratchpad, the area IDs of files within are compared to the areas known by the bootloader, and processed when matching files are found.
By default, each application uses the same <mcu>_app.ini file in the mcu/ folder, but the .ini file can be copied to the application folder and modified as needed. The new .ini file can then be specified in the application config.mk file, as follows:
The scratchpad generated from an application build uses a key called default from the custom_bootloader_keys.ini file. Another key can be used instead, by adding the –keyname option to the invocation of genscratchpad.py in user scripts.
The secure storage library uses 32-bit tags instead of filenames for efficiency. To achieve this, it employs a character encoding scheme called SQUOZE, which can store up to six characters in a 32-bit integer. The available character set consists of 40 symbols:
In addition, a space character is supported, but it cannot appear as the first character in the name.
Any listed names are converted to integers. If a single name is given, the tool converts and prints the result without extra text, making this mode suitable for use in scripts. When multiple names are given, both the names and their converted values are printed, separated by newlines.
The command-line flag -u or –unsquoze converts integers back to names.
The command-line flag -d or –decimal displays all values in decimal instead of hexadecimal. Values on the command line may be provided in either format, with 0x indicating a hexadecimal value.
Convert a single name to uint32:
Convert multiple names:
Convert uint32 values back to names, with decimal output: