scott/InfiniTime
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases 1 Wiki Activity

Improved documentation readability

Browse source 
Removed extra space in contribute.md and cleaned up MemoryAnalysis.md phrasing and confusing punctuation.
This commit is contained in:
Eli Weiss 2021-11-29 21:51:35 -06:00 committed by JF
parent 1832a6c231
commit f66fcdd3ca
2 changed files with 10 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
doc/MemoryAnalysis.md
View file

@ -32,13 +32,13 @@ In this analysis, I used [Linkermapviz](https://github.com/PromyLOPh/linkermapvi
### Linkermapviz
[Linkermapviz](https://github.com/PromyLOPh/linkermapviz) parses the MAP file and displays its content in a graphical way into an HTML page:
[Linkermapviz](https://github.com/PromyLOPh/linkermapviz) parses the MAP file and displays its content on an HTML page as a graphic:
![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,...
Using this tool, you can compare the relative size of symbols. This can be helpful for checking memory usage at a glance.
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...
Also, as Linkermapviz is written in Python, you can easily modify and adapt it to your firmware or export data in another format. For example, [here it is modified to parse the contents of the MAP file and export it in a CSV file](https://github.com/InfiniTimeOrg/InfiniTime/issues/313#issuecomment-842338620). This file could later be opened in LibreOffice Calc where sort/filter functionality could be used 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...
@ -46,8 +46,8 @@ Also, as Linkermapviz is written in Python, you can easily modify it to adapt it
Puncover is really easy to install:
- clone the repo and cd into the cloned directory
- setup a venv
- Clone the repo and cd into the cloned directory
- Setup a venv
- `python -m virtualenv venv`
- `source venv/bin/activate`
- Install : `pip install .`
@ -60,13 +60,13 @@ Puncover is really easy to install:
- 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.
Using the MAP file and tools, we can easily see what symbols are using most of the flash memory. In this case, with no surprise, fonts and graphics are the largest use of flash memory.
![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.
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.
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/InfiniTimeOrg/InfiniTime/issues/313#issuecomment-842338620
@ -210,7 +210,7 @@ NRF_LOG_INFO("heap : %d", m.uordblks);
```
#### 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.
According to my experimentation, InfiniTime uses ~6000bytes of heap most of the time. Except when the Navigation app is launched, where the heap usage exceeds 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:

2
doc/contribute.md
View file

@ -46,7 +46,7 @@ Other contributors can post comments about the pull request, maybe ask for more
Once the pull request is reviewed and accepted, it'll be merged into **develop** and will be released in the next version of the firmware.
## Why all these rules?
## Why all these rules?
Reviewing pull requests is a **very time consuming task**. Everything you do to make reviewing easier will **get your PR merged faster**.