diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/NavigationService.md | 10 | ||||
| -rw-r--r-- | doc/buildAndProgram.md | 1 | ||||
| -rw-r--r-- | doc/buildWithVScode.md | 52 | ||||
| -rw-r--r-- | doc/contribute.md | 71 | ||||
| -rw-r--r-- | doc/gettingStarted/ota-gadgetbridge-nrfconnect.md | 8 | ||||
| -rw-r--r-- | doc/ui/example.png | bin | 0 -> 10642 bytes | |||
| -rw-r--r-- | doc/ui_guidelines.md | 16 | ||||
| -rw-r--r-- | doc/versioning.md | 2 |
8 files changed, 129 insertions, 31 deletions
diff --git a/doc/NavigationService.md b/doc/NavigationService.md index d0899817..fd81d0bf 100644 --- a/doc/NavigationService.md +++ b/doc/NavigationService.md @@ -9,19 +9,19 @@ manDist (string) - Manouvre Distance, the distance to the upcoming change progress (uint8) - Percent complete of total route, value 0-100 ## Service -The service UUID is c7e60001-78fc-48fe-8e23-433b3a1942d0 +The service UUID is 00010000-78fc-48fe-8e23-433b3a1942d0 ## Characteristics -## Flags (UUID c7e60002-78fc-48fe-8e23-433b3a1942d0) +## Flags (UUID 00010001-78fc-48fe-8e23-433b3a1942d0) All included icons are from pure-maps, which provides the actual routing from the client. The icon names ultimately come from the mapbox project "direction-icons", See https://github.com/rinigus/pure-maps/tree/master/qml/icons/navigation See the end of this document for the full lsit of supported icon names. -## Narrative (UUID c7e60003-78fc-48fe-8e23-433b3a1942d0) +## Narrative (UUID 00010002-78fc-48fe-8e23-433b3a1942d0) This is a client supplied string describing the upcoming instruction such as "At the roundabout take the first exit". -## Man Dist (UUID c7e60004-78fc-48fe-8e23-433b3a1942d0) +## Man Dist (UUID 00010003-78fc-48fe-8e23-433b3a1942d0) This is a short string describing the distance to the upcoming instruction such as "50 m". -## Progress (UUID c7e60001=5-78fc-48fe-8e23-433b3a1942d0) +## Progress (UUID 00010004-78fc-48fe-8e23-433b3a1942d0) The percent complete in a uint8. The watch displays this as an overall progress in a progress bar. ## Full icon list diff --git a/doc/buildAndProgram.md b/doc/buildAndProgram.md index 87b6dd9a..e97bb30d 100644 --- a/doc/buildAndProgram.md +++ b/doc/buildAndProgram.md @@ -28,6 +28,7 @@ CMake configures the project according to variables you specify the command line **GDB_CLIENT_BIN_PATH**|Path to arm-none-eabi-gdb executable. Used only if `USE_GDB_CLIENT` is 1.|`-DGDB_CLIENT_BIN_PATH=/home/jf/nrf52/gcc-arm-none-eabi-9-2019-q4-major/bin/arm-none-eabi-gdb` **GDB_CLIENT_TARGET_REMOTE**|Target remote connection string. Used only if `USE_GDB_CLIENT` is 1.|`-DGDB_CLIENT_TARGET_REMOTE=/dev/ttyACM0` **BUILD_DFU (\*\*)**|Build DFU files while building (needs [adafruit-nrfutil](https://github.com/adafruit/Adafruit_nRF52_nrfutil)).|`-DBUILD_DFU=1` +**WATCH_COLMI_P8**|Use pin configuration for Colmi P8 watch|`-DWATCH_COLMI_P8=1` ####(**) Note about **CMAKE_BUILD_TYPE**: By default, this variable is set to *Release*. It compiles the code with size and speed optimizations. We use this value for all the binaries we publish when we [release](https://github.com/JF002/InfiniTime/releases) new versions of InfiniTime. diff --git a/doc/buildWithVScode.md b/doc/buildWithVScode.md new file mode 100644 index 00000000..23c97145 --- /dev/null +++ b/doc/buildWithVScode.md @@ -0,0 +1,52 @@ +# Build and Develop the project using VS Code + +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. + + + diff --git a/doc/contribute.md b/doc/contribute.md index 9f4c2154..b84d6c9c 100644 --- a/doc/contribute.md +++ b/doc/contribute.md @@ -1,68 +1,89 @@ # How to contribute? + ## Report bugs -You use your Pinetime and find a bug in the firmware? [Create an issue on Github](https://github.com/JF002/InfiniTime/issues) explaining the bug, how to reproduce it, the version of the firmware you use... + +Have you found a bug in the firmware? [Create an issue on Github](https://github.com/JF002/InfiniTime/issues) explaining the bug, how to reproduce it, the version of the firmware you use... + ## Write and improve documentation + Documentation might be incomplete, or not clear enough, and it is always possible to improve it with better wording, pictures, photo, video,... As the documentation is part of the source code, you can submit your improvements to the documentation by submitting a pull request (see below). + ## Fix bugs, add functionalities and improve the code + You want to fix a bug, add a cool new functionality or improve the code? See *How to submit a pull request below*. + ## Spread the word -The Pinetime is a cool open source project that deserves to be known. Talk about it around you, on social networks, on your blog,... and let people know that we are working on an open-source firmware for a smartwatch! -# How to submit a pull request ? +The Pinetime is a cool open source project that deserves to be known. Talk about it around you, on social networks, on your blog,... and let people know that we are working on an open source firmware for a smartwatch! + +# How to submit a pull request? ## TL;DR - - Create a branch from develop; - - Work on a single subject in this branch. Create multiple branches/pulls-requests if you want to work on multiple subjects (bugs, features,...); - - Test your modifications on the actual hardware; - - Check the code formatting against our coding conventions and [clang-format](../.clang-format) and [clang-tidy](../.clang-tidy); - - Clean your code and remove files that are not needed; - - Write documentation related to your new feature is applicable; - - Create the pull-request and write a great description about it : what does your PR do, why, how,... Add pictures and video if possible; - - Wait for someone to review your PR and take part in the review process; + + - Create a branch from develop + - Work on a single subject in this branch. Create multiple branches/pulls-requests if you want to work on multiple subjects (bugs, features,...) + - Test your modifications on the actual hardware + - Check the code formatting against our coding conventions and [clang-format](../.clang-format) and [clang-tidy](../.clang-tidy) + - Clean your code and remove files that are not needed + - Write documentation related to your new feature if applicable + - Create a pull request and write a great description about it: what does your PR do, why, how,... Add pictures and video if possible + - Wait for someone to review your PR and take part in the review process - Your PR will eventually be merged :) -Your contribution is more than welcome! +Your contributions are more than welcome! -If you want to fix a bug, add a functionality or improve the code, you'll first need to create a branch from the **develop** branch (see [this page about the branching model](./branches.md)). This branch is called a feature branch, and you should choose a name that explains what you are working on (ex: "add-doc-about-contributions"). In this branch, **focus on only one topic, bug or feature**. For example, if you created this branch to work on the UI of a specific application, do not commit modifications about the SPI driver. If you want to work on multiple topics, create one branch per topic. +If you want to fix a bug, add functionality or improve the code, you'll first need to create a branch from the **develop** branch (see [this page about the branching model](./branches.md)). This branch is called a feature branch, and you should choose a name that explains what you are working on (ex: "add-doc-about-contributions"). In this branch, **focus on only one topic, bug or feature**. For example, if you created this branch to work on the UI of a specific application, do not commit modifications about the SPI driver. If you want to work on multiple topics, create one branch for each topic. When your feature branch is ready, **make sure it actually works** and **do not forget to write documentation** about it if it's relevant. -I **strongly discourage to create a PR containing modifications that haven't been tested**. If, for any reason, you cannot test your modifications but want to publish them anyway, **please mention it in the description**. This way, other contributors might be willing to test it and provide feedback about your code. +**Creating a pull request containing modifications that haven't been tested is strongly discouraged.** If, for any reason, you cannot test your modifications but want to publish them anyway, **please mention it in the description**. This way, other contributors might be willing to test it and provide feedback about your code. Also, before submitting your PR, check the coding style of your code against the **coding conventions** detailed below. This project also provides [clang-format](../.clang-format) and [clang-tidy](../.clang-tidy) configuration files. You can use them to ensure correct formatting of your code. -Do not forget to check the files you are going to commit and remove those who are not necessary (config files from your IDE, for example). Remove old comments, commented code,... +Don't forget to check the files you are going to commit and remove those which aren't necessary (config files from your IDE, for example). Remove old comments, commented code,... -Then, you can submit a pull-request for review. Try to **describe your pull request as much as possible**: what did you do in this branch, how does it work, how is it designed, are there any limitations,... This will help the contributors to understand and review your code easily. You can add pictures and video to the description so that contributors will have a quick overview of your work. +Then, you can submit a pull request for review. Try to **describe your pull request as much as possible**: what did you do in this branch, how does it work, how it is designed, are there any limitations,... This will help the contributors to understand and review your code easily. You can add pictures and video to the description so that contributors will have a quick overview of your work. Other contributors can post comments about the pull request, maybe ask for more info or adjustments in the code. -Once the pull request is reviewed and accepted, it'll be merge in **develop** and will be released in the next release version of the firmware. +Once the pull request is reviewed and accepted, it'll be merged into **develop** and will be released in the next version of the firmware. ## Why all these rules? -Reviewing pull-requests is a **very time consuming task** for the creator of this project ([JF002](https://github.com/JF002)) and for other contributors who take the time to review them. Every little thing you do to make their lives easier will **increase the chances your PR will be merge quickly**. -When reviewing PR, the author and contributors will first look at the **description**. If it's easy to understand what the PR does, why the modification is needed or interesting and how it's done, a good part of the work is already done : we understand the PR and its context. +Reviewing pull requests is a **very time consuming task** for the creator of this project ([JF002](https://github.com/JF002)) and for other contributors who take the time to review them. Everything you do to make reviewing easier will **get your PR merged faster**. -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. +When reviewing PRs, the author and contributors will first look at the **description**. If it's easy to understand what the PR does, why the modification is needed or interesting and how it's done, a good part of the work is already done : we understand the PR and its context. -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. +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, so we won't be able to merge the PR because of the changes that are not accepted. -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. +We do our best to keep the code as consistent as possible. If the formatting of the code in your PR is not consistent with our code base, we'll ask you to review it, which will take more time. -It's totally normal for a PR to need some more work even after it was created, that's why we review them. But every round trip takes time, and it's good practice to try to reduce them as much as possible by following those simple rules. +The last step of the review consists of **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. + +It's totally normal for a PR to need some more work even after it was created, that's why we review them. But every round trip takes time, so it's good practice to try to reduce them as much as possible by following those simple rules. # Coding convention + ## Language -The language of this project is **C++**, and all new code must be written in C++. (Modern) C++ provides a lot of useful tools and functionalities that are beneficial for embedded software development like `constexpr`, `template` and anything that provides zero-cost abstraction. -It's OK to include C code if this code comes from another library like FreeRTOS, NimBLE, LVGL or the NRF-SDK. +The language of this project is **C++**, and all new code must be written in C++. (Modern) C++ provides a lot of useful tools and functionalities that are beneficial for embedded software development like `constexpr`, `template` and anything that provides zero-cost abstraction. + +C code is accepted if it comes from another library like FreeRTOS, NimBLE, LVGL or the NRF-SDK. ## Coding style + The most important rule to follow is to try to keep the code as easy to read and maintain as possible. +Using an autoformatter is highly recommended, but make sure it's configured properly. + +There are preconfigured autoformatter rules for: + + * CLion (IntelliJ) in .idea/codeStyles/Project.xml + +If there are no preconfigured rules for your IDE, you can use one of the existing ones to configure your IDE. + - **Indentation** : 2 spaces, no tabulation - **Opening brace** at the end of the line - **Naming** : Choose self-describing variable name diff --git a/doc/gettingStarted/ota-gadgetbridge-nrfconnect.md b/doc/gettingStarted/ota-gadgetbridge-nrfconnect.md index 1187a9b7..ffc27ed8 100644 --- a/doc/gettingStarted/ota-gadgetbridge-nrfconnect.md +++ b/doc/gettingStarted/ota-gadgetbridge-nrfconnect.md @@ -47,6 +47,8 @@ Read carefully the warning and tap **Install**: Wait for the transfer to finish. Your PineTime should reset and reboot with the new version of InfiniTime! +Don't forget to **validate** your firmware. In the InfiniTime go to the settings (swipe right, select gear icon) and Firmware option and click **validate**. Otherwise after reboot the previous firmware will be used. +  ### Using NRFConnect @@ -64,6 +66,8 @@ Select **Distribution packet (ZIP)**: Browse to the DFU file you downloaded previously, the DFU transfer will start automatically. When the transfer is finished, your PineTime will reset and restart on the new version of InfiniTime! +Don't forget to **validate** your firmware. In the InfiniTime go to the settings (swipe right, select gear icon) and Firmware option and click **validate**. Otherwise after reboot the previous firmware will be used. +  ## How to flash InfiniTime using the SWD interface @@ -88,6 +92,10 @@ If you are using OpenOCD with a STLinkV2, you can find more info [on this page]( ### Using Gadgetbridge Good news! Gadgetbridge **automatically** synchronizes the time when connecting to your PineTime! +### Using any Chromium-based web browser +You can use it from your PC, Mac, Android. Browsers now have BLE support. +https://hubmartin.github.io/WebBLEWatch/ + ### Using NRFConnect You must enable the **CTS** *GATT server* into NRFConnect so that InfiniTime can synchronize the time with your smartphone. diff --git a/doc/ui/example.png b/doc/ui/example.png Binary files differnew file mode 100644 index 00000000..2f6cb789 --- /dev/null +++ b/doc/ui/example.png diff --git a/doc/ui_guidelines.md b/doc/ui_guidelines.md new file mode 100644 index 00000000..c267b79b --- /dev/null +++ b/doc/ui_guidelines.md @@ -0,0 +1,16 @@ +# UI design guidelines + +- Align objects all the way to the edge or corner +- Buttons should generally be at least 50px high +- Buttons should generally be on the bottom edge +- Make interactable objects **big** +- Recommendations for inner padding, aka distance between buttons: + - When aligning 4 objects: 4px, e.g. Settings + - When aligning 3 objects: 6px, e.g. App list + - When aligning 2 objects: 10px, e.g. Quick settings +- When using a page indicator, leave 8px for it on the right side + - It is acceptable to leave 8px on the left side as well to center the content +- Top bar takes at least 20px + padding + - Top bar right icons move 8px to the left when using a page indicator + + diff --git a/doc/versioning.md b/doc/versioning.md index b08af714..48e05043 100644 --- a/doc/versioning.md +++ b/doc/versioning.md @@ -3,4 +3,4 @@ The versioning of this project is based on [Semantic versionning](https://semver - The **patch** is incremented when we fix a bug on a **released** version (most of the time using a **hotfix** branch). - The **minor** is incremented when we release a new version with new features. It corresponds to a merge of **develop** into **master**. - - The **major** should be incremented when a breaking change is made to the application. We still have to define what is a breaking change in the context of this project. For now, I suggest that it stays **0** until we have a fully functionning firmware suited for the final user.
\ No newline at end of file + - The **major** should be incremented when a breaking change is made to the application. We still have to define what is a breaking change in the context of this project. For now, I suggest that it stays **0** until we have a fully functioning firmware suited for the final user.
\ No newline at end of file |
