From 6222b7c22307b114fef0ddd2148472dbebbc5174 Mon Sep 17 00:00:00 2001 From: Grant Date: Sun, 25 Jul 2021 10:58:55 -0500 Subject: [PATCH] Correct spelling issue in documentation (#509) * Correct spelling issue --- doc/PinetimeStubWithNrf52DK.md | 4 ++-- doc/ble.md | 4 ++-- doc/branches.md | 2 +- doc/buildAndProgram.md | 2 +- doc/buildWithDocker.md | 2 +- doc/contribute.md | 2 +- doc/filesInReleaseNotes.md | 2 +- 7 files changed, 9 insertions(+), 9 deletions(-) diff --git a/doc/PinetimeStubWithNrf52DK.md b/doc/PinetimeStubWithNrf52DK.md index 52131251..c4857921 100644 --- a/doc/PinetimeStubWithNrf52DK.md +++ b/doc/PinetimeStubWithNrf52DK.md @@ -1,7 +1,7 @@ # Build a stub for PineTime using NRF52-DK [NRF52-DK](https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF52-DK) is the official developpment kit for NRF52832 SoC from Nordic Semiconductor. -It can be very useful for PineTime developpment: +It can be very useful for PineTime development: * You can use it embedded JLink SWD programmer/debugger to program and debug you code on the PineTime * As it's based on the same SoC than the PineTime, you can program it to actually run the same code than the PineTime. @@ -47,4 +47,4 @@ You also need to enable the I/O expander to disconnect pins from buttons and led | --------- | --------- | | DETECT | GND | -Now, you should be able to program the SoC on the NRF52-DK board, and use it as if it was running on the pintime. \ No newline at end of file +Now, you should be able to program the SoC on the NRF52-DK board, and use it as if it was running on the PineTime. \ No newline at end of file diff --git a/doc/ble.md b/doc/ble.md index fdf1a5b6..518b99c8 100644 --- a/doc/ble.md +++ b/doc/ble.md @@ -5,9 +5,9 @@ This page describes the BLE implementation and API built in this firmware. **Note** : I'm a beginner in BLE related technologies and the information of this document reflect my current knowledge and understanding of the BLE stack. These informations might be erroneous or incomplete. Feel free to submit a PR if you think you can improve these. ## BLE Connection -When starting the firmware start a BLE advertising : it send small messages that can be received by any *central* device in range. This allows the device to announce its presence to other devices. +When starting the firmware start a BLE advertising : it sends small messages that can be received by any *central* device in range. This allows the device to announce its presence to other devices. -A companion application (running on a PC, RasberryPi, smartphone) which received this avertising packet can request a connection to the device. This connection procedure allows the 2 devices to negociate communication parameters, security keys,... +A companion application (running on a PC, RaspberryPi, smartphone) which received this avertising packet can request a connection to the device. This connection procedure allows the 2 devices to negotiate communication parameters, security keys,... When the connection is established, the pinetime will try to discover services running on the companion application. For now **CTS** (**C**urrent **T**ime **S**ervice) and **ANS** (**A**lert **N**otification **S**ervice) are supported. diff --git a/doc/branches.md b/doc/branches.md index 0fb8316d..ef280f40 100644 --- a/doc/branches.md +++ b/doc/branches.md @@ -2,7 +2,7 @@ The branching model of this project is based on the workflow named [Git flow](https://nvie.com/posts/a-successful-git-branching-model/). It is based on 2 main branches: - - **master** : this branch is always ready to be reployed. It means that at any time, we should be able to build the branch and release a new version of the application. + - **master** : this branch is always ready to be deployed. It means that at any time, we should be able to build the branch and release a new version of the application. - **develop** : this branch contains the latest development that will be integrated in the next release once it's considered as stable. New features should be implemented in **feature branches** created from **develop**. When the feature is ready, a pull-request is created and it'll be merge into **develop** when it is succesfully reviewed and accepted. diff --git a/doc/buildAndProgram.md b/doc/buildAndProgram.md index 5fe593ae..87b6dd9a 100644 --- a/doc/buildAndProgram.md +++ b/doc/buildAndProgram.md @@ -163,7 +163,7 @@ J-Link>g ``` #### JLink RTT -RTT is a feature from Segger's JLink devices that allows bidirectionnal communication between the debugger and the target. This feature can be used to get the logs from the embedded software on the development computer. +RTT is a feature from Segger's JLink devices that allows bidirectional communication between the debugger and the target. This feature can be used to get the logs from the embedded software on the development computer. - Program the MCU with the code (see above) - Start JLinkExe diff --git a/doc/buildWithDocker.md b/doc/buildWithDocker.md index 17fb53d9..2e4ecbb6 100644 --- a/doc/buildWithDocker.md +++ b/doc/buildWithDocker.md @@ -13,7 +13,7 @@ Based on Ubuntu 18.04 with the following build dependencies: 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. -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 **/build/output**: +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 **/build/output**: ```bash cd # e.g. cd ./work/Pinetime diff --git a/doc/contribute.md b/doc/contribute.md index 09d20774..9f4c2154 100644 --- a/doc/contribute.md +++ b/doc/contribute.md @@ -48,7 +48,7 @@ When reviewing PR, the author and contributors will first look at the **descript Then, reviewing **a few files that were modified for a single purpose** is a lot more easier than to review 30 files modified for many reasons (bug fix, UI improvements, typos in doc,...), even if all these changes make sense. Also, it's possible that we agree on some modification but not on some other, and we won't be able to merge the PR because of the changes that are not accepted. -We do our best to keep the code as consistent as possible, and that mean we pay attention to the **formatting** of the code. If the code formatting is not consistent with our code base, we'll ask you to review it, which will take more time. +We do our best to keep the code as consistent as possible, and that means we pay attention to the **formatting** of the code. If the code formatting is not consistent with our code base, we'll ask you to review it, which will take more time. The last step of the review consists in **testing** the modification. If it doesn't work out of the box, we'll ask your to review your code and to ensure that it works as expected. diff --git a/doc/filesInReleaseNotes.md b/doc/filesInReleaseNotes.md index 78c20b51..1a37fefb 100644 --- a/doc/filesInReleaseNotes.md +++ b/doc/filesInReleaseNotes.md @@ -18,7 +18,7 @@ This firmware is standalone, meaning that it does not need a bootloader to actua **This firmware must be flashed at address 0x00 in the main flash memory** ### Bootloader -The bootloader is maintained by [lupyuen](https://github.com/lupyuen) and is a binary version of [this release](https://github.com/lupyuen/pinetime-rust-mynewt/releases/tag/v5.0.4). +The bootloader is maintained by [lupyuen](https://github.com/lupyuen) and is a binary version of [this release](https://github.com/lupyuen/pinetime-rust-mynewt/releases/tag/v5.0.4). - **bootloader.hex** : Firmware in Intel HEX file format.