diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/MemoryAnalysis.md | 299 | ||||
| -rw-r--r-- | doc/PinetimeStubWithNrf52DK.md | 4 | ||||
| -rw-r--r-- | doc/ble.md | 4 | ||||
| -rw-r--r-- | doc/branches.md | 2 | ||||
| -rw-r--r-- | doc/buildAndProgram.md | 4 | ||||
| -rw-r--r-- | doc/buildWithDocker.md | 2 | ||||
| -rw-r--r-- | doc/companionapps/Amazfish.md | 3 | ||||
| -rw-r--r-- | doc/companionapps/Gadgetbridge.md | 2 | ||||
| -rw-r--r-- | doc/contribute.md | 2 | ||||
| -rw-r--r-- | doc/filesInReleaseNotes.md | 14 | ||||
| -rw-r--r-- | doc/gettingStarted/gettingStarted-1.0.md | 31 | ||||
| -rw-r--r-- | doc/memoryAnalysis/linkermapviz.png | bin | 0 -> 55661 bytes | |||
| -rw-r--r-- | doc/memoryAnalysis/mapfile.png | bin | 0 -> 111302 bytes | |||
| -rw-r--r-- | doc/memoryAnalysis/puncover-all-symbols.png | bin | 0 -> 78193 bytes | |||
| -rw-r--r-- | doc/memoryAnalysis/puncover.png | bin | 0 -> 217193 bytes |
15 files changed, 293 insertions, 74 deletions
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. + + + +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: + + + +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 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. + + + +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 <NRFSDK>/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/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 @@ -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 afd526e0..87b6dd9a 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. @@ -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 7a2f3727..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. Outputs will be written to **<project_root>/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 **<project_root>/build/output**: ```bash cd <project_root> # e.g. cd ./work/Pinetime 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 + 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: 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 f48a0c10..1a37fefb 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,... @@ -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. @@ -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: 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 :  - -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).  ## 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). - diff --git a/doc/memoryAnalysis/linkermapviz.png b/doc/memoryAnalysis/linkermapviz.png Binary files differnew file mode 100644 index 00000000..8edfc8f9 --- /dev/null +++ b/doc/memoryAnalysis/linkermapviz.png diff --git a/doc/memoryAnalysis/mapfile.png b/doc/memoryAnalysis/mapfile.png Binary files differnew file mode 100644 index 00000000..0badd104 --- /dev/null +++ b/doc/memoryAnalysis/mapfile.png diff --git a/doc/memoryAnalysis/puncover-all-symbols.png b/doc/memoryAnalysis/puncover-all-symbols.png Binary files differnew file mode 100644 index 00000000..6a984248 --- /dev/null +++ b/doc/memoryAnalysis/puncover-all-symbols.png diff --git a/doc/memoryAnalysis/puncover.png b/doc/memoryAnalysis/puncover.png Binary files differnew file mode 100644 index 00000000..b32e1784 --- /dev/null +++ b/doc/memoryAnalysis/puncover.png |
