summaryrefslogtreecommitdiff
path: root/doc/MemoryAnalysis.md
diff options
context:
space:
mode:
authormabuch <marcel.buechler@gmail.com>2021-10-15 18:03:10 +0200
committermabuch <marcel.buechler@gmail.com>2021-10-15 18:03:10 +0200
commit1d76d9170e367b4d1f97f9a5e43bd6801724dfd3 (patch)
tree192eb148d87c8bd38aab144d5f384056bd5e5566 /doc/MemoryAnalysis.md
parent69ef5bfc8d053b49a81f60740acc09302d11ce9c (diff)
Replaced "JF002" in github URLs with "InfiniTimeOrg"
Diffstat (limited to 'doc/MemoryAnalysis.md')
-rw-r--r--doc/MemoryAnalysis.md18
1 files changed, 9 insertions, 9 deletions
diff --git a/doc/MemoryAnalysis.md b/doc/MemoryAnalysis.md
index 3251c98d..7304e3f3 100644
--- a/doc/MemoryAnalysis.md
+++ b/doc/MemoryAnalysis.md
@@ -6,7 +6,7 @@ The PineTime is equipped with the following memories:
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).
+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/InfiniTimeOrg/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.
@@ -38,7 +38,7 @@ In this analysis, I used [Linkermapviz](https://github.com/PromyLOPh/linkermapvi
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...
+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/InfiniTimeOrg/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...
@@ -69,8 +69,8 @@ This way, you can easily check what needs to be optimized : we should find a way
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
+ - Analysis with linkermapviz : https://github.com/InfiniTimeOrg/InfiniTime/issues/313#issuecomment-842338620
+ - Analysis with Puncover : https://github.com/InfiniTimeOrg/InfiniTime/issues/313#issuecomment-847311392
## RAM
RAM memory contains all the data that can be modified at run-time: variables, stack, heap...
@@ -93,7 +93,7 @@ int main() {
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.
### 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).
+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/InfiniTimeOrg/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:
@@ -197,10 +197,10 @@ On the following dump, the maximum stack usage is 520 bytes (0xFFFF - 0xFDF8):
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
+ - https://github.com/InfiniTimeOrg/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`...).
+The heap is declared in the [linker script](https://github.com/InfiniTimeOrg/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:
@@ -239,7 +239,7 @@ Using this technique, I was able to trace all malloc calls at boot (boot -> digi
- hr task = 304
#### Links
- - https://github.com/JF002/InfiniTime/issues/313#issuecomment-851035625
+ - https://github.com/InfiniTimeOrg/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/
@@ -263,7 +263,7 @@ 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
+ - https://github.com/InfiniTimeOrg/InfiniTime/issues/313#issuecomment-850890064
## FreeRTOS heap and task stack