rei-forks
/
InfiniTime
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Add doc : build the project with command line, docker and vscode.

This commit is contained in:
JF002 2022-03-02 21:20:16 +01:00
parent b4cbec3b45
commit 144721a86d
1 changed files with 215 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

215
docs/build-flash-and-debug/index.md
View File

@ -3,6 +3,221 @@
## Versioning
## Files included in the release notes
## Build the project
### Dependencies
To build this project, you'll need:
- A cross-compiler : [ARM-GCC (9-2020-q2-update)](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads/9-2020-q2-update)
- The NRF52 SDK 15.3.0 : [nRF-SDK v15.3.0](https://developer.nordicsemi.com/nRF5_SDK/nRF5_SDK_v15.x.x/nRF5_SDK_15.3.0_59ac345.zip)
- The Python 3 modules `cbor`, `intelhex`, `click` and `cryptography` modules for the `mcuboot` tool (see [requirements.txt](../tools/mcuboot/requirements.txt))
- To keep the system clean, you can install python modules into a python virtual environment (`venv`)
```
python -m venv .venv
source .venv/bin/activate
python -m pip install wheel
python -m pip install -r tools/mcuboot/requirements.txt
```
- A reasonably recent version of CMake (I use 3.16.5)
Note that you do not need to install those dependencies on your system if you use Docker to build the project.
### Using the command line
#### Build steps
##### Clone the repo
Clone the repo and update the submodules:
```
git clone https://github.com/InfiniTimeOrg/InfiniTime.git
cd InfiniTime
git submodule update --init
mkdir build
cd build
```
##### Generate the project with CMake
Run CMake to generate the project. Here's the default command line
```
cmake -DARM_NONE_EABI_TOOLCHAIN_PATH=/path/to/the/toolchain -DNRF5_SDK_PATH=/path/to/the/sdk ..
```
You can specify a few more options:
- `-DCMAKE_BUILD_TYPE` : specify the build type (`Release` or `Debug`). The `Release` mode is selected by default. It enables various optimizations from the compiler to reduce the binary size and increase perfromances. `Debug` mode does not enable those optimizations. It makes the binary easier to debug but it'll run slower and the binary file will be bigger.
- `-DBUILD_DFU` : enables (`1`) or disables (`0`) the generation of the DFU file (needed for this OTA udate). Note that this option needs [adafruit-nrfutil](https://github.com/adafruit/Adafruit_nRF52_nrfutil) installed on your system.
#### Build
Run make to build the project:
```
make -j
```
This command will build all the targets of the project (see below). You can also specify a specific target you want to build:
```
make -j pinetime-mcuboot-app
```
Here's the list of CMake targets:
- pinetime-app
- pinetime-mcuboot-app
- pinetime-recovery
- pinetime-mcuboot-recovery
- pinetime-recovery-loader
- pinetime-mcuboot-recovery-loader
Binary files are generated in the `src/` subfolder.
These files are named with various extensions:
- **.bin** files are binary files corresponding to the firmware. These files are intended to be ran by the MCU of the PineTime.
- **.hex** files are binary files formatted in the [Intel HEX format](https://en.wikipedia.org/wiki/Intel_HEX).
- **.map** files contains the [memory mapping generated by the compiler](https://en.wikipedia.org/wiki/MAP_(file_format)). Useful to understand the memory usage and mapping of the firmware.
- **.out** files are intended to be used by a debugger (GDB) to debug the firmware running on the PineTime
You'll find various files named according to their respective `cmake target`:
- **pinetime-app** : The standalone version of the firmware. This firmware must be flashed at offset 0x00 and runs without the bootloader. You can use this binary to debug (using a SWD debugger) the firmware faster and more easily as it doesn't rely on the bootloader.
- **pinetime-mcuboot-app** : The firmware with support for the bootloader. The file `pinetime-mcuboot-app-x.y.z.bin` must be converted into an *MCUBoot* image for the bootloader to be able to run it. This image is named pinetime-mcuboot-app-image-x-y-z.bin and it can be flashed at offset **0x8000**. A DFU file for the OTA update is also generated (if the option BUILD_DFU was enabled during `cmake` generation) : pinetime-mcuboot-app-dfu-x.y.z.zip.
- **pinetime-recovery** is the recovery firmware (standalone).
- **pinetime-mcuboot-recovery** is the bootloader variant of the recovery firmware. The MCUBoot image (pinetime-mcuboot-recovery-image) and the DFU file (pinetime-mcboot-recovery-dfu) are also generated.
- **pinetime-recovery-loader** is a firmware that updates the bootloader of the PineTime. Use this firmware with caution as it erases and overwrites the bootloader of your PineTime. There's no fallback in case of issue during this operation. The MCUBoot image and DFU file are also generated.
Most of the time, you'll only need the file `pinetime-mcuboot-app-image` to update the firmware using a SWD debugger or the file `pinetime=-mcuboot-app-dfu` to update it over the air using a BLE device.
See below for more info on flashing and upgrading your firmware on your PineTime.
### Using docker
A [Docker image (Dockerfile)](../docker) containing all the build environment is available for X86_64 and AMD64 architectures. These images make the build of the firmware and the generation of the DFU file for OTA quite easy, as well as preventing clashes with any other toolchains or development environments you may have installed.
Based on Ubuntu 18.04 with the following build dependencies:
* ARM GCC Toolchain
* nRF SDK
* MCUBoot
* adafruit-nrfutil
#### Run a container to build the project
The `infinitime-build` image contains all the dependencies you need. The default `CMD` will compile sources found in `/sources`, so you need only mount your code.
Before continuing, make sure you first build the image as indicated in the [Build the image](#build-the-image) section, or check the [Using the image from Docker Hub](#using-the-image-from-docker-hub) section if you prefer to use a pre-made image.
This example will build the firmware, generate the MCUBoot image and generate the DFU file. For cloning the repo, see [these instructions](../doc/buildAndProgram.md#clone-the-repo). Outputs will be written to **<project_root>/build/output**:
```bash
cd <project_root> # e.g. cd ./work/Pinetime
docker run --rm -it -v $(pwd):/sources infinitime-build
```
If you only want to build a single CMake target, you can pass it in as the first parameter to the build script. This means calling the script explicitly as it will override the `CMD`. Here's an example For `pinetime-app`:
```bash
docker run --rm -it -v $(pwd):/sources infinitime-build /opt/build.sh pinetime-app
```
The image is built using 1000:1000 for the user id and group id. If this is different to your user or group ids (run `id -u` and `id -g` to find out what your id values are if you are unsure), you will need to override them via the `--user` parameter in order to prevent permission errors with the output files (and the cmake build cache).
Running with this image is the same as above, you just specify the ids to `docker run`:
```bash
docker run --rm -it -v $(pwd):/sources --user $(id -u):$(id -g) infinitime-build
```
Or you can specify your user id and group id (by number, not by name) directly:
```bash
docker run --rm -it -v $(pwd):/sources --user 1234:1234 infinitime-build
```
#### Using the image from Docker Hub
**NOTE** : This image is provided by a contributor and might not be up-to-date.
The image is available via Docker Hub for both the amd64 and arm64v8 architectures at [pfeerick/infinitime-build](https://hub.docker.com/r/pfeerick/infinitime-build).
It can be pulled (downloaded) using the following command:
```bash
docker pull pfeerick/infinitime-build
```
The default `latest` tag *should* automatically identify the correct image architecture, but if for some reason Docker does not, you can specify it manually:
* For AMD64 (x86_64) systems: `docker pull pfeerick/infinitime-build:amd64`
* For ARM64v8 (ARM64/aarch64) systems: `docker pull pfeerick/infinitime-build:arm64v8`
#### Build the image
You can build the image yourself if you like!
The following commands must be run from the root of the project. This operation will take some time but, when done, a new image named *infinitime-build* is available.
```bash
docker image build -t infinitime-build ./docker
```
The `PUID` and `PGID` build arguments are used to set the user and group ids used in the container, meaning you will not need to specify it later unless they change for some reason. Specifying them is not mandatory, as this can be over-ridden at build time via the `--user` flag, but doing so will make the command you need to run later a bit shorter. In the below examples, they are set to your current user id and group id automatically. You can specify them manually, but they must be specified by number, not by name.
```bash
docker image build -t infinitime-build --build-arg PUID=$(id -u) --build-arg PGID=$(id -g) ./docker
```
### Using VSCode
The .VS Code folder contains configuration files for developing InfiniTime with VS Code. Effort was made to have these rely on Environment variables instead of hardcoded paths.
#### Environment Setup
To support as many setups as possible the VS Code configuration files expect there to be certain environment variables to be set.
Variable | Description | Example
----------|-------------|--------
**ARM_NONE_EABI_TOOLCHAIN_PATH**|path to the toolchain directory|`export ARM_NONE_EABI_TOOLCHAIN_PATH=/opt/gcc-arm-none-eabi-9-2020-q2-update`
**NRF5_SDK_PATH**|path to the NRF52 SDK|`export NRF5_SDK_PATH=/opt/nRF5_SDK_15.3.0_59ac345`
#### VS Code Extensions
We leverage a few VS Code extensions for ease of development.
###### Required Extensions
- [C/C++](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools) - C/C++ IntelliSense, debugging, and code browsing.
- [CMake Tools](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools) - Extended CMake support in Visual Studio Code
###### Optional Extensions
[Cortex-Debug](https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug) - ARM Cortex-M GDB Debugger support for VS Code
Cortex-Debug is only required for interactive debugging using VS Codes built in GDB support.
#### VS Code/Docker DevContainer
The .devcontainer folder contains the configuration and scripts for using a Docker dev container for building InfiniTime
Using the [Remote-Containers](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) extension is recommended. It will handle configuring the Docker virtual machine and setting everything up.
More documentation is available in the [readme in .devcontainer](.devcontainer/readme.md)
##### DevContainer on Ubuntu
To use the DevContainer configuration on Ubuntu based systems two changes need to be made:
1. Modify the file ``.devcontainer/devcontainer.json`` and add the argument ``"--net=host"`` to the ``"runArgs"`` parameter making the line look like this:
`` "runArgs": [ "--cap-add=SYS_PTRACE", "--security-opt", "seccomp=unconfined", "--net=host"],
``
2. Modify the file ``.vscode/launch.json`` and change the argument of ``"gdbTarget"`` to ``"127.0.0.1:3333"``, making the line look like:
``"gdbTarget": "127.0.0.1:3333",``
3. To start debugging launch openocd on your host system with the appropriate configuration, for example with a stlink-v2 the command is:
``openocd -f interface/stlink.cfg -f target/nrf52.cfg``. This launches openocd with the default ports ``3333``, ``4444`` and ``6666``.
4. In VsCode go to the Debug pane on the left of the screen and select the configuration ``Debug - Openocd docker Remote`` and hit the play button on the left.
## Build the documentation
### Setup
The documentation is written in Makrdown (.md) files and generated using the Sphinx documentation generator.