... | @@ -9,23 +9,30 @@ Chances are that you need a unique node ID for each target device. One way to ge |
... | @@ -9,23 +9,30 @@ Chances are that you need a unique node ID for each target device. One way to ge |
|
// must be global (variable will be placed into the .data section)
|
|
// must be global (variable will be placed into the .data section)
|
|
volatile uint16_t FLOCKLAB_NODE_ID = 0xbeef; // any value is ok, will be overwritten by FlockLab
|
|
volatile uint16_t FLOCKLAB_NODE_ID = 0xbeef; // any value is ok, will be overwritten by FlockLab
|
|
```
|
|
```
|
|
FlockLab will then automatically change (by binary patching) this value to the target ID (if specified, otherwise the observer ID is used) before uploading the image to the targets.
|
|
FlockLab will then automatically change this value to the target ID (if specified, otherwise the observer ID is used) before uploading the image to the targets.
|
|
Note that some compilers might still remove the symbol `FLOCKLAB_NODE_ID`. To make sure is included in the final binary, you can use `objdump` to display the symbol table:
|
|
You can use `objdump` to check whether the symbol is included in the binary:
|
|
```
|
|
```
|
|
objdump -t [elf_file] | grep FLOCKLAB_NODE_ID
|
|
objdump -t [elf_file] | grep FLOCKLAB_NODE_ID
|
|
```
|
|
```
|
|
If you want to assign a specific node ID to each target, you can do this by using the `targetIds` field in the [XML configuration file](Man/XmlConfig#target-configuration).
|
|
If you want to assign a specific node ID to each target, you can do this by using the `targetIds` field in the [XML configuration file](Man/XmlConfig#target-configuration).
|
|
Note that assigning node IDs is only supported if you submit your target images in the file format ELF. For Intel hex files, binary patching is currently not supported.
|
|
Note that assigning node IDs is only supported if you submit your target images in the file format ELF. For Intel hex files, binary patching is currently not supported.
|
|
|
|
|
|
Note that depending on your compiler, the data section in the ELF may be empty, and thus binary patching will fail (this is e.g. the case if you use the SEGGER compiler for the platform nRF5). As a workaround, you need to place the variable into the read-only memory section by making it constant:
|
|
Depending on the compiler you use, the data section in the ELF may be empty, and thus binary patching will fail (this is e.g. the case if you use the SEGGER compiler for the platform nRF5). As a workaround, you need to place the variable into the read-only memory section by making it constant. To avoid constant propagation and ensure the symbol is included in the binary file, `FLOCKLAB_NODE_ID` should be placed into a separate C file and declared as `extern` in all files where you want to access it:
|
|
|
|
```
|
|
|
|
// add this to a separate C file (constant will be placed into the .rodata section)
|
|
|
|
const uint16_t FLOCKLAB_NODE_ID = 0xbeef;
|
|
|
|
|
|
|
|
// in your code, declare the constant with the keyword extern:
|
|
|
|
extern const uint16_t FLOCKLAB_NODE_ID;
|
|
|
|
```
|
|
|
|
As an alternative to placing the constant into a separate C file, you can define it anywhere in your code (global scope) and access its value by dereferencing the address:
|
|
```
|
|
```
|
|
// must be global (constant will be placed into the .rodata section)
|
|
// must be global (constant will be placed into the .rodata section)
|
|
const uint16_t FLOCKLAB_NODE_ID = 0xbeef;
|
|
const uint16_t FLOCKLAB_NODE_ID = 0xbeef;
|
|
|
|
|
|
// somewhere in the code (note: conversion to volatile avoids constant propagation)
|
|
// access the node ID (conversion to volatile avoids constant propagation)
|
|
node_id = *(volatile const uint16_t*)&FLOCKLAB_NODE_ID;
|
|
node_id = *(volatile const uint16_t*)&FLOCKLAB_NODE_ID;
|
|
```
|
|
```
|
|
Alternatively, you can place the constant `FLOCKLAB_NODE_ID` into a separate C file and declare it as `extern` in your code.
|
|
|
|
|
|
|
|
<br />
|
|
<br />
|
|
|
|
|
... | | ... | |