will/InfiniTime
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Typos for days

Browse Source
This commit is contained in:
Tim Keller 2021-07-26 15:43:48 +00:00
parent e9248b225e
commit 7f2ee62aed
2 changed files with 18 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
.devcontainer/README.md
View File

@ -1,11 +1,11 @@
# VScode devcontainer # VS Code Dev Container
This is a docker-based interactive development environment using VSCode and Docker Devcontainers removing the need to install any tools locally* This is a docker-based interactive development environment using VS Code and Docker Dev Containers removing the need to install any tools locally*
## Requirements ## Requirements
- VScode - VS Code
- [Remote - Containers](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) extension - [Remote - Containers](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) extension
- Docker - Docker
- OpenOCD - For debugging - OpenOCD - For debugging
@ -14,24 +14,24 @@ This is a docker-based interactive development environment using VSCode and Dock
### Code editing, and building. ### Code editing, and building.
1. Clone InifiniTime and update submodules 1. Clone InfiniTime and update submodules
2. Launch VSCode 2. Launch VS Code
3. Open InifiTime directory, 3. Open InfiniTime directory,
4. Allow VSCode to open folder with devcontainer. 4. Allow VS Code to open folder with devcontainer.
After this the environment will be built if you do not currently have a container setup, it will install all the necessary tools and extra VSCode extensions. After this the environment will be built if you do not currently have a container setup, it will install all the necessary tools and extra VSCode extensions.
In order to build InfiniTime we need to run the initial submodule init and Cmake commands. In order to build InfiniTime we need to run the initial submodule init and CMake commands.
#### Manually #### Manually
You can use the VSCode terminal to run the CMake commands as outlined in the [build instructions](blob/develop/doc/buildAndProgram.md) You can use the VS Code terminal to run the CMake commands as outlined in the [build instructions](blob/develop/doc/buildAndProgram.md)
#### Script #### Script
The dev enviroment comes with some scripts to make this easier, They are located in /opt/. The dev environment comes with some scripts to make this easier, They are located in /opt/.
There are also VSCode tasks provided should you desire to use those. There are also VS Code tasks provided should you desire to use those.
The task "update submodules" will update the git submodules The task "update submodules" will update the git submodules
@ -41,20 +41,20 @@ The task "update submodules" will update the git submodules
You can use the build.sh script located in /opt/ You can use the build.sh script located in /opt/
CMake is also configured and controlls for the CMake plugin are available in VSCode CMake is also configured and controls for the CMake plugin are available in VS Code
### Debugging ### Debugging
Docker on windows does not support passing USB devices to the underlying WSL2 subsystem, To get around this we use openocd in server mode running on the host. Docker on windows does not support passing USB devices to the underlying WSL2 subsystem, To get around this we use OpenOCD in server mode running on the host.
`openocd -f <yourinterface> -f <nrf52.cfg target file>` `openocd -f <yourinterface> -f <nrf52.cfg target file>`
This will launch openocd in server mode and attach it to the MCU. This will launch OpenOCD in server mode and attach it to the MCU.
The default launch.json file expects openocd to be listening on port 3333, edit if needed The default launch.json file expects OpenOCD to be listening on port 3333, edit if needed
## Current Issues ## Current Issues
Currently WSL2 Has some real performance issues with IO on a windows host. Accessing files on the virtualized filesystem is much faster. Using VSCodes "clone in container" feature of the Remote - Containers will get around this. After the container is built you will need to update the submodules and follow the build isntructions like normal Currently WSL2 Has some real performance issues with IO on a windows host. Accessing files on the virtualized filesystem is much faster. Using VS Codes "clone in container" feature of the Remote - Containers will get around this. After the container is built you will need to update the submodules and follow the build instructions like normal

4
doc/buildWithVScode.md
View File

@ -1,6 +1,6 @@
# Build and Develop the project using VS Code # Build and Develop the project using VS Code
The .VSCode folder contains configuration files for developing InfiniTime with VS Code. Effort was made to have these rely on Environment variables instead of hardcoded paths. 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 ## Environment Setup
@ -22,7 +22,7 @@ We leverage a few VS Code extensions for ease of development.
#### Optional Extensions #### Optional Extensions
[Cortex-Debug](https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug) - ARM Cortex-M GDB Debugger support for VSCode [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. Cortex-Debug is only required for interactive debugging using VS Codes built in GDB support.