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

Correct spelling issue in documentation (#509) 

* Correct spelling issue
This commit is contained in:
Grant 2021-07-25 10:58:55 -05:00 committed by GitHub
parent 1ae22f45f9
commit 6222b7c223
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
7 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/PinetimeStubWithNrf52DK.md
View File

@ -1,7 +1,7 @@
# Build a stub for PineTime using NRF52-DK # 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. [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 * 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. * 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 | | 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. 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.

4
doc/ble.md
View File

@ -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. **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 ## 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. 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.

2
doc/branches.md
View File

@ -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/). 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: 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. - **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. 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.

2
doc/buildAndProgram.md
View File

@ -163,7 +163,7 @@ J-Link>g
``` ```
#### JLink RTT #### 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) - Program the MCU with the code (see above)
- Start JLinkExe - Start JLinkExe

2
doc/contribute.md
View File

@ -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. 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. 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.