Closed Nicogene closed 1 year ago
ok @Nicogene, I have an idea of how to measure it. i will write some code which we should test on the prototype.
the idea is to log time before and after in a non intrusive way, measure an histogram and the print it now and then on trace port or on usart.
or ... we just could look at something like what I measured for demo013 just yesterday. https://github.com/icub-tech-iit/ventilator-FI5/blob/code/tests/boards/stm32f7disco/demo013/instructions/assets/prcv.10ms.timeHMI.jpg
the botton labeled <No Address> (6)
is teh scheduling of the thread HMI
Hi @Nicogene,
I have just committed https://github.com/icub-tech-iit/ventilator-FI5/commit/60d6132725f326fbb301fe5b09cae18b0754a8eb. it gives support for printing every 5 seconds on teh trace port the statistics (histogram between 30 and 80 ms) of the duration of the execution of EwProcess()
. And also, if required, the print of each duration time.
We can test it next time we work on the prototype.
Where it is printed out?
Where it is printed out?
so far on the trace port which is captured by u-Vision and displayed by the Debug (printf) Viewer
.
You enable the display as shown by the following picture (of another project as I don't have the ventilator board w/ me).
Remember: you must define macro HMI_PRINTS in file tests/boards/stm32f7disco/demo013/code/iit/app_tHMI.cpp
(or in the whole project).
We noticed that at the end of the graph the draw of the points seems to slow down. The plot is done in this way:
My hyposthesis is that every iteration
CoordList
become bigger and bigger and theGraph.Coordinates = CoordList;
copy become more and more expensive. Unfortunately @vtikha and me tried to reduced the number of point plotted, and to plot in a more efficient way, but also checking online it seems to be the only way it work. (For example see https://ask.embedded-wizard.de/2931/how-to-avoid-drawing-a-graph-outside-of-the-window)However, before proceeding with a deep refactoring in order to optimize it, I would measure the time that every iteration the gui takes for plotting the data, in order to see if it actually slows down or it was just an impression.
In this sense we failed to do it inside Embedded Wizard, it would be way simpler to do
tic-toc
before and after the callEwProcess()
inside the firmware. For this we may have the need of help of @marcoaccame .