From 346d20db52823eeed01d81cee4f413b753fbec9e Mon Sep 17 00:00:00 2001 From: JF002 Date: Sat, 12 Jun 2021 11:02:54 +0200 Subject: Rewrite MemoryAnalysis.md with up to date information. (#411) Rewrite MemoryAnalysis.md with up to date information. --- doc/MemoryAnalysis.md | 299 ++++++++++++++++++++++++---- doc/memoryAnalysis/linkermapviz.png | Bin 0 -> 55661 bytes doc/memoryAnalysis/mapfile.png | Bin 0 -> 111302 bytes doc/memoryAnalysis/puncover-all-symbols.png | Bin 0 -> 78193 bytes doc/memoryAnalysis/puncover.png | Bin 0 -> 217193 bytes 5 files changed, 255 insertions(+), 44 deletions(-) create mode 100644 doc/memoryAnalysis/linkermapviz.png create mode 100644 doc/memoryAnalysis/mapfile.png create mode 100644 doc/memoryAnalysis/puncover-all-symbols.png create mode 100644 doc/memoryAnalysis/puncover.png (limited to 'doc') diff --git a/doc/MemoryAnalysis.md b/doc/MemoryAnalysis.md index 95bd611c..3251c98d 100644 --- a/doc/MemoryAnalysis.md +++ b/doc/MemoryAnalysis.md @@ -1,78 +1,289 @@ # Memory analysis -## FreeRTOS heap and task stack -FreeRTOS statically allocate its own heap buffer in a global variable named `ucHeap`. This is an array of *uint8_t*. Its size is specified by the definition `configTOTAL_HEAP_SIZE` in *FreeRTOSConfig.h* -FreeRTOS uses this buffer to allocate memory for tasks stack and all the RTOS object created during runtime (timers, mutexes,...). +The PineTime is equipped with the following memories: + - The internal RAM : **64KB** + - The internal Flash : **512KB** + - The external (SPI) Flash : **4MB** -The function `xPortGetFreeHeapSize()` returns the amount of memory available in this *ucHeap* buffer. If this value reaches 0, FreeRTOS runs out of memory. +Note that the NRF52832 cannot execute code stored in the external flash : we need to store the whole firmware in the internal flash memory, and use the external one to store graphicals assets, fonts... + +This document describes how the RAM and Flash memories are used in InfiniTime and how to analyze and monitor their usage. It was written in the context of [this memory analysis effort](https://github.com/JF002/InfiniTime/issues/313). + +## Code sections +A binary is composed of multiple sections. Most of the time, these sections are : .text, .rodata, .data and .bss but more sections can be defined in the linker script. + +Here is a small description of these sections and where they end up in memory: + + - **TEXT** = code (FLASH) + - **RODATA** = constants (FLASH) + - **DATA** = initialized variables (FLASH + RAM) + - **BSS** = uninitialized variables (RAM) + + +## Internal FLASH +The internal flash memory stores the whole firmware: code, variable that are not default-initialized, constants... + +The content of the flash memory can be easily analyzed thanks to the MAP file generated by the compiler. This file lists all the symbols from the program along with their size and location (section and addresses) in RAM and FLASH. + +![Map file](./memoryAnalysis/mapfile.png) + +As you can see on the picture above, this file contains a lot of information and is not easily readable by a human being. Fortunately, you can easily find tools that parse and display the content of the MAP file in a more understandable way. + +In this analysis, I used [Linkermapviz](https://github.com/PromyLOPh/linkermapviz). + +### Linkermapviz + +[Linkermapviz](https://github.com/PromyLOPh/linkermapviz) parses the MAP file and displays its content in a graphical way into an HTML page: + +![linkermapviz](./memoryAnalysis/linkermapviz.png) + +Using this tool, you can easily see the size of each symbol relative to the other one, and check what is using most of the space,... + +Also, as Linkermapviz is written in Python, you can easily modify it to adapt it to your firmware, export data in another format,... For example, [I modified it to parse the contents of the MAP file and export it in a CSV file](https://github.com/JF002/InfiniTime/issues/313#issuecomment-842338620). I could later on open this file in LibreOffice Calc and use sort/filter functionality to search for specific symbols in specific files... + +### Puncover +[Puncover](https://github.com/HBehrens/puncover) is another useful tools that analyses the binary file generated by the compiler (the .out file that contains all debug information). It provides valuable information about the symbols (data and code): name, position, size, max stack of each functions, callers, callees... +![Puncover](./memoryAnalysis/puncover.png) + +Puncover is really easy to install: + - clone the repo and cd into the cloned directory + - setup a venv + - `python -m virtualenv venv` + - `source venv/bin/activate` + - Install : `pip install .` + - Run : `puncover --gcc_tools_base=/path/to/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi- --elf_file /path/to/build/directory/src/pinetime-app-1.1.0.out --src_root /path/to/sources --build_dir /path/to/build/directory` + - Replace + * `/path/to/gcc-arm-none-eabi-9-2020-q2-update/bin` with the path to your gcc-arm-none-eabi toolchain + * `/path/to/build/directory/src/pinetime-app-1.1.0.out` with the path to the binary generated by GCC (.out file) + * `/path/to/sources` with the path to the root folder of the sources (checkout directory) + * `/path/to/build/directory` with the path to the build directory + - Launch a browser at http://localhost:5000/ + +### Analysis +Using the MAP file and tools, we can easily see what symbols are using most of the FLASH memory space. In this case, with no surprise, fonts and graphics are the biggest flash space consumer. + +![Puncover](./memoryAnalysis/puncover-all-symbols.png) + +This way, you can easily check what needs to be optimized : we should find a way to store big static data (like fonts and graphics) in the external flash memory, for example. + +It's always a good idea to check the flash memory space when working on the project : this way, you can easily check that your developments are using a reasonable amount of space. + +### Links + - Analysis with linkermapviz : https://github.com/JF002/InfiniTime/issues/313#issuecomment-842338620 + - Analysis with Puncover : https://github.com/JF002/InfiniTime/issues/313#issuecomment-847311392 + +## RAM +RAM memory contains all the data that can be modified at run-time: variables, stack, heap... + +### Data +RAM memory can be *statically* allocated, meaning that the size and position of the data are known at compile-time: + +You can easily analyze the memory used by variables declared in the global scope using the MAP. You'll find them in the .BSS or .DATA sections. Linkermapviz and Puncover can be used to analyze their memory usage. + +Variables declared in the scope of a function will be allocated on the stack. It means that the stack usage will vary according to the state of the program, and cannot be easily analyzed at compile time. ``` -NRF_LOG_INFO("Free heap : %d", xPortGetFreeHeapSize()); +uint8_t buffer[1024] + +int main() { + int a; +} ``` +#### Analysis +In Infinitime 1.1, the biggest buffers are the buffers allocated for LVGL (14KB) and the one for FreeRTOS (16KB). Nimble also allocated 9KB of RAM. -The function `uxTaskGetSystemState()` fetches some information about the running tasks like its name and the minimum amount of stack space that has remained for the task since the task was created: +### Stack +The stack will be used for everything except tasks, which have their own stack allocated by FreeRTOS. The stack is 8192B and is allocated in the [linker script](https://github.com/JF002/InfiniTime/blob/develop/nrf_common.ld#L148). +An easy way to monitor its usage is by filling the section with a known pattern at boot time, then use the firmware and dump the memory. You can then check the maximum stack usage by checking the address from the beginning of the stack that were overwritten. + +#### Fill the stack section by a known pattern: +Edit /modules/nrfx/mdk/gcc_startup_nrf52.S and add the following code after the copy of the data from read only memory to RAM at around line 243: ``` -TaskStatus_t tasksStatus[10] -auto nb = uxTaskGetSystemState(tasksStatus, 10, NULL); -for (int i = 0; i < nb; i++) { - NRF_LOG_INFO("Task [%s] - %d", tasksStatus[i].pcTaskName, tasksStatus[i].usStackHighWaterMark); -``` +/* Loop to copy data from read only memory to RAM. + * The ranges of copy from/to are specified by following symbols: + * __etext: LMA of start of the section to copy from. Usually end of text + * __data_start__: VMA of start of the section to copy to. + * __bss_start__: VMA of end of the section to copy to. Normally __data_end__ is used, but by using __bss_start__ + * the user can add their own initialized data section before BSS section with the INTERT AFTER command. + * + * All addresses must be aligned to 4 bytes boundary. + */ + ldr r1, =__etext + ldr r2, =__data_start__ + ldr r3, =__bss_start__ + + subs r3, r3, r2 + ble .L_loop1_done +.L_loop1: + subs r3, r3, #4 + ldr r0, [r1,r3] + str r0, [r2,r3] + bgt .L_loop1 -## Global heap -Heap is used for **dynamic memory allocation (malloc() / new)**. NRF SDK defaults the heap size to 8KB. The size of the heap can be specified by defining `__HEAP_SIZE=8192` in *src/CMakeLists.txt*: +.L_loop1_done: + +/* Add this code to fill the stack section with 0xFFEEDDBB */ +ldr r0, =__StackLimit + ldr r1, =8192 +ldr r2, =0xFFEEDDBB +.L_fill: +str r2, [r0] +adds r0, 4 +subs r1, 4 +bne .L_fill +/* -- */ +``` + +#### Dump RAM memory and check usage +Dumping the content of the ram is easy using JLink debugger and `nrfjprog`: + +``` +nrfjprog --readram ram.bin ``` -add_definitions(-D__HEAP_SIZE=8192) -``` -You can trace the dynamic memory allocation by using the flag `--wrap` of the linker. When this flag is enabled, the linker will replace the calls to a specific function by a call to __wrap_the_function(). For example, if you specify `-Wl,-wrap,malloc` in the linker flags, the linker will replace all calls to `void* malloc(size_t)` by calls to `void* __wrap_malloc(size_t)`. This is a function you'll have to define in your code. In this function, you can call `__real_malloc()` to call the actual `malloc()' function. +You can then display the file using objdump: -This technic allows you to wrap all calls to malloc() with you own code. +``` +hexdump ram.bin -v | less +``` -In *src/CMakeLists.txt*: +The stack is positionned at the end of the RAM -> 0xFFFF. Its size is 8192 bytes, so the end of the stack is at 0xE000. +On the following dump, the maximum stack usage is 520 bytes (0xFFFF - 0xFDF8): ``` -set_target_properties(${EXECUTABLE_NAME} PROPERTIES - ... - LINK_FLAGS "-Wl,-wrap,malloc ..." - ... - ) +000fdb0 ddbb ffee ddbb ffee ddbb ffee ddbb ffee +000fdc0 ddbb ffee ddbb ffee ddbb ffee ddbb ffee +000fdd0 ddbb ffee ddbb ffee ddbb ffee ddbb ffee +000fde0 ddbb ffee ddbb ffee ddbb ffee ddbb ffee +000fdf0 ddbb ffee ddbb ffee ffff ffff c24b 0003 +000fe00 ffff ffff ffff ffff ffff ffff 0000 0000 +000fe10 0018 0000 0000 0000 0000 0000 fe58 2000 +000fe20 0000 0000 0000 00ff ddbb 00ff 0018 0000 +000fe30 929c 2000 0000 0000 0018 0000 0000 0000 +000fe40 92c4 2000 0458 2000 0000 0000 80e7 0003 +000fe50 0000 0000 8cd9 0003 ddbb ffee ddbb ffee +000fe60 00dc 2000 92c4 2000 0005 0000 929c 2000 +000fe70 007f 0000 feb0 2000 92c4 2000 feb8 2000 +000fe80 ddbb ffee 0005 0000 929c 2000 0000 0000 +000fe90 aca0 2000 0000 0000 0028 0000 418b 0005 +000fea0 02f4 2000 001f 0000 0000 0000 0013 0000 +000feb0 b5a8 2000 2199 0005 b5a8 2000 2201 0005 +000fec0 b5a8 2000 001e 0000 0000 0000 0013 0000 +000fed0 b5b0 2000 0fe0 0006 b5a8 2000 0000 0000 +000fee0 0013 0000 2319 0005 0013 0000 0000 0000 +000fef0 0000 0000 3b1c 2000 3b1c 2000 d0e3 0000 +000ff00 4b70 2000 54ac 2000 4b70 2000 ffff ffff +000ff10 0000 0000 1379 0003 6578 2000 0d75 0003 +000ff20 6578 2000 ffff ffff 0000 0000 1379 0003 +000ff30 000c 0000 cfeb 0002 39a1 2000 a824 2000 +000ff40 0015 0000 cfeb 0002 39a1 2000 a824 2000 +000ff50 39a1 2000 0015 0000 001b 0000 b4b9 0002 +000ff60 0000 0000 a9f4 2000 4b70 2000 0d75 0003 +000ff70 4b70 2000 ffff ffff 0000 0000 1379 0003 +000ff80 ed00 e000 a820 2000 1000 4001 7fc0 2000 +000ff90 7f64 2000 75a7 0001 a884 2000 7b04 2000 +000ffa0 a8c0 2000 0000 0000 0000 0000 0000 0000 +000ffb0 7fc0 2000 7f64 2000 8024 2000 a5a5 a5a5 +000ffc0 ed00 e000 3fd5 0001 0000 0000 72c0 2000 +000ffd0 0000 0000 72e4 2000 3f65 0001 7f64 2000 +000ffe0 0000 2001 0000 0000 ef30 e000 0010 0000 +000fff0 7fc0 2000 4217 0001 3f0a 0001 0000 6100 +``` + +#### Analysis +According to my experimentations, we don't use the stack that much, and 8192 bytes is probably way too big for InfiniTime! + +#### Links + - https://github.com/JF002/InfiniTime/issues/313#issuecomment-851035070 +### Heap +The heap is declared in the [linker script](https://github.com/JF002/InfiniTime/blob/develop/nrf_common.ld#L136) and its current size is 8192 bytes. The heap is used for dynamic memory allocation(`malloc()`, `new`...). + +Heap monitoring is not easy, but it seems that we can use the following code to know the current usage of the heap: + +``` +auto m = mallinfo(); +NRF_LOG_INFO("heap : %d", m.uordblks); ``` -In *main.cpp*: +#### Analysis +According to my experimentation, InfiniTime uses ~6000bytes of heap most of the time. Except when the Navigation app is launched, where the heap usage increases to... more than 9500 bytes (meaning that the heap overflows and could potentially corrupt the stack!!!). This is a bug that should be fixed in #362. + +To know exactly what's consuming heap memory, you can `wrap` functions like `malloc()` into your own functions. In this wrapper, you can add logging code or put breakpoints: + +- Add ` -Wl,-wrap,malloc` to the cmake variable `LINK_FLAGS` of the target you want to debug (pinetime-app, most probably) +- Add the following code in `main.cpp` ``` -uint32_t totalMalloc = 0; extern "C" { - extern void* __real_malloc(size_t s); - void *__wrap_malloc(size_t s) { - totalMalloc += s; - return __real_malloc(s); - } +void *__real_malloc (size_t); +void* __wrap_malloc(size_t size) { + return __real_malloc(size); } +} +``` +Now, your function `__wrap_malloc()` will be called instead of `malloc()`. You can call the actual malloc from the stdlib by calling `__real_malloc()`. + +Using this technique, I was able to trace all malloc calls at boot (boot -> digital watchface): + +- system task = 3464 bytes (SystemTask could potentially be declared as a global variable to avoid heap allocation here) +- string music = 31 (maybe we should not use std::string when not needed, as it does heap allocation) +- ble_att_svr_start = 1720 +- ble gatts start = 40 + 88 +- ble ll task = 24 +- display app = 104 +- digital clock = 96 + 152 +- hr task = 304 + +#### Links + - https://github.com/JF002/InfiniTime/issues/313#issuecomment-851035625 + - https://www.embedded.com/mastering-stack-and-heap-for-system-reliability-part-1-calculating-stack-size/ + - https://www.embedded.com/mastering-stack-and-heap-for-system-reliability-part-2-properly-allocating-stacks/ + - https://www.embedded.com/mastering-stack-and-heap-for-system-reliability-part-3-avoiding-heap-errors/ + +## LVGL +I did a deep analysis of the usage of the buffer dedicated for lvgl (managed by lv_mem). +This buffer is used by lvgl to allocated memory for drivers (display/touch), screens, themes, and all widgets created by the apps. + +The usage of this buffer can be monitored using this code : + ``` -This function sums all the memory that is allocated during the runtime. You can monitor or log this value. You can also place breakpoints in this function to determine where the dynamic memory allocation occurs in your code. +lv_mem_monitor_t mon; +lv_mem_monitor(&mon); +NRF_LOG_INFO("\t Free %d / %d -- max %d", mon.free_size, mon.total_size, mon.max_used); +``` + +The most interesting metric is `mon.max_used` which specifies the maximum number of bytes that were used from this buffer since the initialization of lvgl. +According to my measurements, initializing the theme, display/touch driver and screens cost **4752** bytes! +Then, initializing the digital clock face costs **1541 bytes**. +For example a simple lv_label needs **~140 bytes** of memory. + +I tried to monitor this max value while going through all the apps of InfiniTime 1.1 : the max value I've seen is **5660 bytes**. It means that we could probably **reduce the size of the buffer from 14KB to 6 - 10 KB** (we have to take the fragmentation of the memory into account). +### Links + - https://github.com/JF002/InfiniTime/issues/313#issuecomment-850890064 + + +## FreeRTOS heap and task stack +FreeRTOS statically allocate its own heap buffer in a global variable named `ucHeap`. This is an array of *uint8_t*. Its size is specified by the definition `configTOTAL_HEAP_SIZE` in *FreeRTOSConfig.h* +FreeRTOS uses this buffer to allocate memory for tasks stack and all the RTOS object created during runtime (timers, mutexes...). +The function `xPortGetFreeHeapSize()` returns the amount of memory available in this *ucHeap* buffer. If this value reaches 0, FreeRTOS runs out of memory. -# Global stack -The stack is used to allocate memory used by functions : **parameters and local variables**. NRF SDK defaults the heap size to 8KB. The size of the heap can be specified by defining `__STACK_SIZE=8192` in *src/CMakeLists.txt*: - ``` -add_definitions(-D__STACK_SIZE=8192) -``` +NRF_LOG_INFO("Free heap : %d", xPortGetFreeHeapSize()); +``` -*NOTE*: FreeRTOS uses its own stack buffer. Thus, the global stack is only used for main() and IRQ handlers. It should be possible to reduce its size to a much lower value. -**NOTE**: [?] How to track the global stack usage? +The function `uxTaskGetSystemState()` fetches some information about the running tasks like its name and the minimum amount of stack space that has remained for the task since the task was created: -#LittleVGL buffer -*TODO* +``` +TaskStatus_t tasksStatus[10] +auto nb = uxTaskGetSystemState(tasksStatus, 10, NULL); +for (int i = 0; i < nb; i++) { + NRF_LOG_INFO("Task [%s] - %d", tasksStatus[i].pcTaskName, tasksStatus[i].usStackHighWaterMark); +``` -#NimBLE buffers -*TODO* -#Tools - - https://github.com/eliotstock/memory : display the memory usage (FLASH/RAM) using the .map file from GCC. diff --git a/doc/memoryAnalysis/linkermapviz.png b/doc/memoryAnalysis/linkermapviz.png new file mode 100644 index 00000000..8edfc8f9 Binary files /dev/null and b/doc/memoryAnalysis/linkermapviz.png differ diff --git a/doc/memoryAnalysis/mapfile.png b/doc/memoryAnalysis/mapfile.png new file mode 100644 index 00000000..0badd104 Binary files /dev/null and b/doc/memoryAnalysis/mapfile.png differ diff --git a/doc/memoryAnalysis/puncover-all-symbols.png b/doc/memoryAnalysis/puncover-all-symbols.png new file mode 100644 index 00000000..6a984248 Binary files /dev/null and b/doc/memoryAnalysis/puncover-all-symbols.png differ diff --git a/doc/memoryAnalysis/puncover.png b/doc/memoryAnalysis/puncover.png new file mode 100644 index 00000000..b32e1784 Binary files /dev/null and b/doc/memoryAnalysis/puncover.png differ -- cgit v1.2.3-70-g09d2 From 8fb543f4c3174372f2f373b342a20d394cb58597 Mon Sep 17 00:00:00 2001 From: Joel Bradshaw Date: Sat, 12 Jun 2021 02:05:57 -0700 Subject: Add note about getting GadgetBridge from F-Droid (#358) * Add note about getting GadgetBridge from F-Droid Hopefully this is useful and will save folks some frustration * Add note that GadgetBridge should be downloaded via F-Droid There's an "unofficial" version on the Play Store that is outdated and doesn't have PineTime support * Fix typo * Add starting version, reword a bit Initial support version is a little fuzzy, 0.47 states it's "not yet usable" but changelog doesn't specify when we've crossed the "usable" threshold. --- README.md | 2 +- doc/companionapps/Gadgetbridge.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/README.md b/README.md index 396d7462..755f1905 100644 --- a/README.md +++ b/README.md @@ -62,7 +62,7 @@ As of now, here is the list of achievements of this project: * Firmware validation * System information - Supported by 3 companion apps (development is in progress): - * [Gadgetbridge](https://codeberg.org/Freeyourgadget/Gadgetbridge/) (on Android) + * [Gadgetbridge](https://codeberg.org/Freeyourgadget/Gadgetbridge/) (on Android via F-Droid) * [Amazfish](https://openrepos.net/content/piggz/amazfish) (on SailfishOS and Linux) * [Siglo](https://github.com/alexr4535/siglo) (on Linux) * **[Experimental]** [WebBLEWatch](https://hubmartin.github.io/WebBLEWatch/) Synchronize time directly from your web browser. [video](https://youtu.be/IakiuhVDdrY) diff --git a/doc/companionapps/Gadgetbridge.md b/doc/companionapps/Gadgetbridge.md index 1a25069c..974e2828 100644 --- a/doc/companionapps/Gadgetbridge.md +++ b/doc/companionapps/Gadgetbridge.md @@ -1,7 +1,7 @@ # Integration with Gadgetbridge [Gadgetbridge](https://gadgetbridge.org/) is an Android application that supports many smartwatches and fitness trackers. -The integration of InfiniTime (previously Pinetime-JF) is now merged into the master branch (https://codeberg.org/Freeyourgadget/Gadgetbridge/). +The integration of InfiniTime (previously Pinetime-JF) is now merged into the master branch (https://codeberg.org/Freeyourgadget/Gadgetbridge/) and initial support is available [starting with version 0.47](https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/master/CHANGELOG.md). Note that the official version is only available on F-Droid (as of May 2021), and the unofficial fork available on the Play Store is outdated and does not support Infinitime. ## Features The following features are implemented: -- cgit v1.2.3-70-g09d2 From 2c7ad783fc0d37c534050321a13759a28f9b83f0 Mon Sep 17 00:00:00 2001 From: Itai Nelken <70802936+Itai-Nelken@users.noreply.github.com> Date: Sat, 12 Jun 2021 12:06:46 +0300 Subject: Improvements to /doc/filesInReleaseNotes.md (#357) * Update filesInReleaseNotes.md --- doc/filesInReleaseNotes.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'doc') diff --git a/doc/filesInReleaseNotes.md b/doc/filesInReleaseNotes.md index f48a0c10..78c20b51 100644 --- a/doc/filesInReleaseNotes.md +++ b/doc/filesInReleaseNotes.md @@ -1,16 +1,16 @@ # Using the releases -For each new *stable* version of Pinetime, a [release note](https://github.com/JF002/InfiniTime/releases) is created. It contains a description of the main changes in the release and some files you can use to flash the firmware in your Pinetime. +For each new *stable* version of IniniTime, a [release note](https://github.com/JF002/InfiniTime/releases) is created. It contains a description of the main changes in the release and some files you can use to flash the firmware to your Pinetime. This page describes the files from the release notes and how to use them. -**NOTE :** the files included in different could be different. This page describes the release note of [version 0.7.1](https://github.com/JF002/InfiniTime/releases/tag/0.7.1), which is the version that'll probably be pre-programmed at the factory for the next batch of Pinetime devkits. +**NOTE :** the files included in different Releases could be different. This page describes the release notes of [version 0.7.1](https://github.com/JF002/InfiniTime/releases/tag/0.7.1), which is the version that is pre-programmed for the last batches of pinetimes but will be replaced with [1.0.0](https://github.com/jF002/infiniTime/releases/tag/1.0.0) around june 2021. -## Files included in the release note +## Files included in the release notes ### Standalone firmware -This firmware is standalone, meaning that it does not need a bootloader to actually run. It is intended to be flash at offset 0, meaning it will erase any bootloader that might be present in memory. +This firmware is standalone, meaning that it does not need a bootloader to actually run. It is intended to be flashed at offset 0, meaning it will erase any bootloader that might be present in memory. - - **pinetime-app.out** : Output file of GCC containing debug symbols, useful is you want to debug the firmware using GDB. + - **pinetime-app.out** : Output file of GCC containing debug symbols, useful if you want to debug the firmware using GDB. - **pinetime-app.hex** : Firmware in Intel HEX file format. Easier to use because it contains the offset in memory where it must be flashed, you don't need to specify it. - **pintime-app.bin** : Firmware in binary format. When programming it, you have to specify the offset (0x00) in memory where it must be flashed. - **pinetime-app.map** : Map file containing all the symbols, addresses in memory,... @@ -38,7 +38,7 @@ This firmware is a small utility firmware that writes the boot graphic in the ex ### Firmware with bootloader This firmware is intended to be used with our [MCUBoot-based bootloader](../bootloader/README.md). - - **pinetime-mcuboot-app-image.hex** : Firmware wrapped into an MCUBoot image. This is **the** file that must be flashed **@ 0x8000** into flash memory. If the [bootloader](../bootloader/README.md) has been successfully programmed, it should run this firmware after the next reset. + - **pinetime-mcuboot-app-image.hex**: Firmware wrapped into an MCUBoot image. This is **the** file that must be flashed at **0x8000** into the flash memory. If the [bootloader](../bootloader/README.md) has been successfully programmed, it should run this firmware after the next reset. The following files are not directly usable by the bootloader: -- cgit v1.2.3-70-g09d2 From 44d7c6d00f3ec919c6f70d32d084c26539aa58aa Mon Sep 17 00:00:00 2001 From: Roxxor91 Date: Sat, 12 Jun 2021 11:15:39 +0200 Subject: Update Amazfish.md (#386) Add Navigation feature. --- doc/companionapps/Amazfish.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/companionapps/Amazfish.md b/doc/companionapps/Amazfish.md index eb9daa04..90ad20c2 100644 --- a/doc/companionapps/Amazfish.md +++ b/doc/companionapps/Amazfish.md @@ -8,8 +8,9 @@ The following features are implemented: - Time synchronization - Notifications - Music control + - Navigation with Puremaps ## Demo [This video](https://seafile.codingfield.com/f/21c5d023452740279e36/) shows how to connect to the Pinetime and control the playback of the music on the phone. Amazfish and Sailfish OS are running on the [Pinephone](https://www.pine64.org/pinephone/), another awesome device from Pine64. - \ No newline at end of file + -- cgit v1.2.3-70-g09d2 From d4f4ed014cecb600a5fb8541cff1f01bf2c46d54 Mon Sep 17 00:00:00 2001 From: Pekka <85409219+pekkakr@users.noreply.github.com> Date: Sat, 12 Jun 2021 12:16:54 +0300 Subject: Update buildWithDocker.md (#416) Added a link to instructions for cloning the repo. The purpose was mainly to remind of the git submodule update. --- doc/buildWithDocker.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/buildWithDocker.md b/doc/buildWithDocker.md index 7a2f3727..17fb53d9 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. 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 -- cgit v1.2.3-70-g09d2 From 7fee2c25894a3113a580d98c947048152af977d9 Mon Sep 17 00:00:00 2001 From: wilsonjwco <87050999+wilsonjwco@users.noreply.github.com> Date: Sun, 11 Jul 2021 11:47:24 -0600 Subject: Update buildAndProgram.md (#477) Corrected typo in example usage of cmake BUILD_DFU option. Changed from -BUILD_DFU=1 to -DBUILD_DFU=1 --- doc/buildAndProgram.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/buildAndProgram.md b/doc/buildAndProgram.md index afd526e0..5fe593ae 100644 --- a/doc/buildAndProgram.md +++ b/doc/buildAndProgram.md @@ -27,7 +27,7 @@ CMake configures the project according to variables you specify the command line **NRFJPROG**|Path to the NRFJProg executable. Used only if `USE_JLINK` is 1.|`-DNRFJPROG=/opt/nrfjprog/nrfjprog` **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)).|`-BUILD_DFU=1` +**BUILD_DFU (\*\*)**|Build DFU files while building (needs [adafruit-nrfutil](https://github.com/adafruit/Adafruit_nRF52_nrfutil)).|`-DBUILD_DFU=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. -- cgit v1.2.3-70-g09d2 From 7a6ceadb24a57ae041d02f5a73f484f587517e32 Mon Sep 17 00:00:00 2001 From: Riku Isokoski Date: Sun, 25 Jul 2021 18:50:55 +0300 Subject: Update documentation (#467) * Fix and update documentation * Add newlines --- README.md | 44 ++++++++++++++++++++------------ doc/gettingStarted/gettingStarted-1.0.md | 31 +++++++++++++--------- 2 files changed, 46 insertions(+), 29 deletions(-) (limited to 'doc') diff --git a/README.md b/README.md index 4ff21286..d9de4002 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,3 @@ - # PineTime [![Build PineTime Firmware](https://github.com/JF002/InfiniTime/workflows/Build%20PineTime%20Firmware/badge.svg?branch=master)](https://github.com/JF002/InfiniTime/actions) @@ -12,9 +11,10 @@ The **Pinetime** smartwatch is built around the NRF52832 MCU (512KB Flash, 64KB RAM), a 240*240 LCD display driven by the ST7789 controller, an accelerometer, a heart rate sensor, and a vibration motor. # InfiniTime + ![InfiniTime logo](images/infinitime-logo.jpg "InfiniTime Logo") -The goal of this project is to design an open-source firmware for the Pinetime smartwatch : +The goal of this project is to design an open-source firmware for the Pinetime smartwatch : - Code written in **modern C++**; - Build system based on **CMake**; @@ -36,7 +36,7 @@ As of now, here is the list of achievements of this project: - Heart rate measurements - Step counting - Wake-up on wrist rotation - - Quick actions + - Quick actions * Disable vibration on notification * Brightness settings * Flashlight @@ -46,20 +46,22 @@ As of now, here is the list of achievements of this project: * Analog * [PineTimeStyle](https://wiki.pine64.org/wiki/PineTimeStyle) - Multiple 'apps' : - * Music (control the playback of the music on your phone) - * Heart rate (controls the heart rate sensor and display current heartbeat) + * Music (control the playback of music on your phone) + * Heart rate (measure your heart rate) * Navigation (displays navigation instructions coming from the companion app) * Notification (displays the last notification received) * Paddle (single player pong-like game) - * Two (2048 clone game) - * Stopwatch (with all the necessary functions such as play, pause, lap, stop) - * Motion sensor and step counter (displays the number of steps and the state of the motion sensor in real-time) + * Twos (2048 clone game) + * Stopwatch + * Steps (displays the number of steps taken) + * Timer (set a countdown timer that will notify you when it expires) * Metronome (vibrates to a given bpm with a customizable beats per bar) - User settings: * Display timeout * Wake-up condition * Time format (12/24h) * Default watch face + * Daily step goal * Battery status * Firmware validation * System information @@ -70,18 +72,21 @@ As of now, here is the list of achievements of this project: * **[Experimental]** [WebBLEWatch](https://hubmartin.github.io/WebBLEWatch/) Synchronize time directly from your web browser. [video](https://youtu.be/IakiuhVDdrY) - OTA (Over-the-air) update via BLE - [Bootloader](https://github.com/JF002/pinetime-mcuboot-bootloader) based on [MCUBoot](https://juullabs-oss.github.io/mcuboot/) - + ## Documentation ### Getting started + - [Getting started with InfiniTime 1.0 (quick user guide, update bootloader and InfiniTime,...)](doc/gettingStarted/gettingStarted-1.0.md) - [Flash, upgrade (OTA), time synchronization,...](doc/gettingStarted/ota-gadgetbridge-nrfconnect.md) ### Develop + - [Generate the fonts and symbols](src/displayapp/fonts/README.md) - [Creating a stopwatch in Pinetime(article)](https://pankajraghav.com/2021/04/03/PINETIME-STOPCLOCK.html) ### Build, flash and debug + - [Project branches](doc/branches.md) - [Versioning](doc/versioning.md) - [Files included in the release notes](doc/filesInReleaseNotes.md) @@ -94,20 +99,23 @@ As of now, here is the list of achievements of this project: - Using files from the releases ### Contribute + - [How to contribute ?](doc/contribute.md) ### API + - [BLE implementation and API](./doc/ble.md) - + ### Architecture and technical topics + - [Memory analysis](./doc/MemoryAnalysis.md) - + ### Using the firmware + - [Integration with Gadgetbridge](doc/companionapps/Gadgetbridge.md) - [Integration with AmazFish](doc/companionapps/Amazfish.md) - [Firmware update, OTA](doc/companionapps/NrfconnectOTA.md) - - + ## TODO - contribute This project is far from being finished, and there are still a lot of things to do for this project to become a firmware usable by the general public. @@ -121,12 +129,13 @@ Here a quick list out of my head of things to do for this project: - Measure power consumption and improve battery life - Improve documentation, take better pictures and video than mine - Improve the UI - - Create companion app for multiple OSes (Linux, Android, iOS) and platforms (desktop, ARM, mobile). Do not forget the other devices from Pine64 like [the Pinephone](https://www.pine64.org/pinephone/) and the [Pinebook Pro](https://www.pine64.org/pinebook-pro/). + - Create companion app for multiple OSes (Linux, Android, iOS) and platforms (desktop, ARM, mobile). Do not forget the other devices from Pine64 like [the Pinephone](https://www.pine64.org/pinephone/) and the [Pinebook Pro](https://www.pine64.org/pinebook-pro/). - Design a simple CI (preferably self-hosted and easy to reproduce). - + Do not hesitate to clone/fork the code, hack it and create pull-requests. I'll do my best to review and merge them :) ## Licenses + This project is released under the GNU General Public License version 3 or, at your option, any later version. It integrates the following projects: @@ -134,8 +143,9 @@ It integrates the following projects: - UI : **[LittleVGL/LVGL](https://lvgl.io/)** under the MIT license - BLE stack : **[NimBLE](https://github.com/apache/mynewt-nimble)** under the Apache 2.0 license - Font : **[Jetbrains Mono](https://www.jetbrains.com/fr-fr/lp/mono/)** under the Apache 2.0 license - -## Credits + +## Credits + I’m not working alone on this project. First, many people create PR for this projects. Then, there is the whole #pinetime community : a lot of people all around the world who are hacking, searching, experimenting and programming the Pinetime. We exchange our ideas, experiments and code in the chat rooms and forums. Here are some people I would like to highlight: diff --git a/doc/gettingStarted/gettingStarted-1.0.md b/doc/gettingStarted/gettingStarted-1.0.md index 2ac22b97..88ff2072 100644 --- a/doc/gettingStarted/gettingStarted-1.0.md +++ b/doc/gettingStarted/gettingStarted-1.0.md @@ -1,7 +1,9 @@ # Getting started with InfiniTime 1.0 + On April 22 2021, InfiniTime and Pine64 [announced the release of InfiniTime 1.0](https://www.pine64.org/2021/04/22/its-time-infinitime-1-0/) and the availability of PineTime smartwatches as *enthusiast grade end-user product*. This page aims to guide you with your first step with your new PineTime. ## Firmware, InfiniTime, Bootloader, Recovery firmware, OTA, DFU... What is it? + You might have already seen these words by reading the announcement, release notes, or [the wiki guide](https://wiki.pine64.org/wiki/Upgrade_PineTime_to_InfiniTime_1.0.0) and, you may find them misleading if you're not familiar with the project. Basically, a **firmware** is just a software running on the embedded hardware of a device, the PineTime in this case. @@ -13,9 +15,10 @@ Basically, a **firmware** is just a software running on the embedded hardware of **OTA** and **DFU** refer to the update of the firmware over BLE (**B**luetooth **L**ow **E**nergy). **OTA** means **O**ver **T**he **A**ir, this is a functionality that allows the user to update the firmware how their device using a wireless communication like BLE. When we talk about **DFU** (**D**igital **F**irmware **U**pdate), we refer to the file format and protocol used to send the update of the firmware to the watch over-the-air. InfiniTime implement the (legacy) DFU protocol from Nordic Semiconductor (NRF). ## How to check the version of InfiniTime and the bootloader? + Since September 2020, all PineTimes (devkits or sealed) are flashed using the **[first iteration of the bootloader](https://github.com/lupyuen/pinetime-rust-mynewt/releases/tag/v4.1.7)** and **[InfiniTime 0.7.1](https://github.com/JF002/InfiniTime/releases/tag/0.7.1)**. There was no recovery firmware at that time. -The bootloader only runs when the watch starts (from an empty battery, for example) or after a reset (after a succesful OTA or a manual reset - long push on the button). +The bootloader only runs when the watch starts (from an empty battery, for example) or after a reset (after a successful OTA or a manual reset - long push on the button). You can recognize this first iteration of the bootloader with it greenish **PINETIME** logo. @@ -30,14 +33,14 @@ And for version >= 1.0 : ![InfiniTime 1.0 version](version-1.0.jpg) - -PineTime shipped from June 2020 (to be confirmed) will be flashed with the [new version of the bootloader](https://github.com/JF002/pinetime-mcuboot-bootloader/releases/tag/1.0.0), the [recovery firmware](https://github.com/JF002/InfiniTime/releases/tag/0.14.1) and [InfiniTime 1.0](https://github.com/JF002/InfiniTime/releases/tag/1.0.0). +PineTime shipped from June 2021 (to be confirmed) will be flashed with the [new version of the bootloader](https://github.com/JF002/pinetime-mcuboot-bootloader/releases/tag/1.0.0), the [recovery firmware](https://github.com/JF002/InfiniTime/releases/tag/0.14.1) and [InfiniTime 1.0](https://github.com/JF002/InfiniTime/releases/tag/1.0.0). The bootloader is easily recognizable with it white pine cone that is progressively drawn in green. It also displays its own version on the bottom (1.0.0 as of now). ![Bootloader 1.0](bootloader-1.0.jpg) ## How to update your PineTime? + To update your PineTime, you can use one of the compatible companion applications. Here are the main ones: - **[Amazfish](https://github.com/piggz/harbour-amazfish)** (Desktop Linux, mobile Linux, SailfishOS, runs on the PinebookPro and the Pinephone) @@ -45,36 +48,41 @@ To update your PineTime, you can use one of the compatible companion application - **[Siglo](https://github.com/alexr4535/siglo)** (Linux, GTK based) - **NRFConnect** (closed source, Android & iOS). -See [this page](ota-gadgetbridge-nrfconnect.md) for more info about the OTA procedure using Gadgetbrige and NRFCOnnect. +See [this page](ota-gadgetbridge-nrfconnect.md) for more info about the OTA procedure using Gadgetbridge and NRFConnect. ### From InfiniTime 0.7.1 / old bootloader + If your PineTime is currently running InfiniTime 0.7.1 and the old bootloader, we strongly recommend you update them to more recent version (Bootloader 1.0.0 and InfiniTime 1.0.0 as of now). We also recommend you install the recovery firmware once the bootloader is up-do-date. Using the companion app of your choice, you'll need to apply the OTA procedure for these 3 firmwares in this sequence (failing to follow this specific order might temporarily or permanently brick your device): - + 1. Flash the latest version of InfiniTime. The file to upload is named **pinetime-mcuboot-app-dfu-x.y.z.zip**. Here is the link to [InfiniTime 1.0](https://github.com/JF002/InfiniTime/releases/download/1.0.0/pinetime-mcuboot-app-dfu-1.0.0.zip). - 2. Update the bootloader by applying the OTA procedure with the file named [**reloader-mcuboot.zip** from the repo of the bootloader](https://github.com/JF002/pinetime-mcuboot-bootloader/releases/download/1.0.0/reloader-mcuboot.zip). + 2. Update the bootloader by applying the OTA procedure with the file named [**reloader-mcuboot.zip** from the repo of the bootloader](https://github.com/JF002/pinetime-mcuboot-bootloader/releases/download/1.0.0/reloader-mcuboot.zip). 3. Install the recovery firmware by applying the OTA procedure with the file named [**pinetime-mcuboot-recovery-loader-dfu-0.14.1.zip** from the version 0.14.1 of InfiniTime](https://github.com/JF002/InfiniTime/releases/download/0.14.1/pinetime-mcuboot-recovery-loader-dfu-0.14.1.zip). You'll find more info about this process in [this wiki page](https://wiki.pine64.org/wiki/Upgrade_PineTime_to_InfiniTime_1.0.0). You can also see the procedure in video [here](https://video.codingfield.com/videos/watch/831077c5-16f3-47b4-9b2b-c4bbfecc6529) and [here (from Amazfish)](https://video.codingfield.com/videos/watch/f7bffb3d-a6a1-43c4-8f01-f4aeff4adf9e) ### From version > 1.0 + If you are already running the new "1.0.0" bootloader, all you have to do is update your version of InfiniTime when it'll be available. We'll write specific instructions when (if) we release a new version of the bootloader. ### Firmware validation -The bootloader requires a (manual) validation of the firmware. If the watch reset with an updated firmware that was not validated, the bootloader will consider it as non-functionning and will revert to the previous version of the firmware. This is a safety feature to prevent bricking your device with a faulty firmware. + +The bootloader requires a (manual) validation of the firmware. If the watch reset with an updated firmware that was not validated, the bootloader will consider it as non-functioning and will revert to the previous version of the firmware. This is a safety feature to prevent bricking your device with a faulty firmware. You can validate your updated firmware on InfiniTime >= 1.0 by following this simple procedure: - + - From the watchface, swipe **right** to display the *Quick Actions menu* - Open the **Settings** app by tapping the *gear* icon on the bottom right - Swipe down and tap on the entry named **Firmware** - This app shows the version that is currently running. If it's not validated yet, it displays 2 buttons: - **Validate** to validate your firmware - **Reset** to reset the watch and revert to the previously running version of the firmware - + ## InfiniTime 1.0 quick user guide + ### Setting the time + By default, InfiniTime starts on the digital watchface. It'll probably display the epoch time (1 Jan 1970, 00:00). The time will be automatically synchronized once you connect on of the companion app to your PineTime using BLE connectivity. InfiniTime does not provide any way to manually set the time for now. ### Navigation in the menu @@ -90,7 +98,7 @@ By default, InfiniTime starts on the digital watchface. It'll probably display t - Start the **flashlight** app - Enable/disable vibrations on notifications (Do Not Disturb mode) - Enter the **settings** menu - - Settings + - Settings - Display timeout - Wake up event (Tap, wrist rotation) - Time format (12/24H) @@ -104,9 +112,8 @@ By default, InfiniTime starts on the digital watchface. It'll probably display t Most of the time, the bootloader just runs without your intervention (update and load the firmware). However, you can enable 2 functionalities using the push button: - + - Push the button until the pine cone is drawn in **blue** to force the rollback of the previous version of the firmware, even if you've already validated the updated one - Push the button until the pine cone is drawn in **red** to load the recovery firmware. This recovery firmware only provides BLE connectivity and OTA functionality. More info about the bootloader in [its project page](https://github.com/JF002/pinetime-mcuboot-bootloader/blob/master/README.md). - -- cgit v1.2.3-70-g09d2 From 6222b7c22307b114fef0ddd2148472dbebbc5174 Mon Sep 17 00:00:00 2001 From: Grant Date: Sun, 25 Jul 2021 10:58:55 -0500 Subject: 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(-) (limited to 'doc') 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. -- cgit v1.2.3-70-g09d2