Correct spelling issue in documentation (#509)
* Correct spelling issue
This commit is contained in:
parent
1ae22f45f9
commit
6222b7c223
|
@ -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.
|
|
@ -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,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.
|
||||||
|
|
|
@ -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
|
||||||
|
|
|
@ -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.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue
Block a user