Implement frame rate monitor

[davidcutting42]

From #66

[Asbelos]

This is really there to check we are not overloading the cpu and slowing loop calls down.
Initially i think just flipping a pin each time loop is called would be enough for soneone with an oscilloscope to monitor loop speed.

[grbba]

Which loop would you measure ? there are many loops at the end all trying to play nice with each other but still you may get fluctuations in the 'frame-rate'. Giving the fact that 99% of all users may not have an Ozilloscope isn't that more a feature for development ? What would be the use case i.e. why as a user I would/do need it ?

[Asbelos]

Not really a user thing... more for developers to check they have not introduced a problem delay in the loop.On 22 Nov 2020 20:37, Gregor Baues <[email protected]> wrote: Which loop would you measure ? there are many loops at the end all trying to play nice with each other but still you may get fluctuations in the 'frame-rate'. Giving the fact that 99% of all users may not have an Ozilloscope isn't that more a feature for development ? What would be the use case i.e. why as a user I would/do need it ? —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

[Asbelos]

Interestingly, the main track sentResetsSincePacket counter can be used to detect loop speed issues as this indicates that the reminder code is not being called often enough to keep the waveform busy. (Assuming at least 1 loco in reminders)

[Asbelos]

Interestingly... once there is at least one loco in the reminders table, then the existing idle/reset counter for the main track will only increase if fhe main loop is too slow to keep the waveform supplied with reminder packets. Being able to display this value would be useful and easy.

[Neil-McK]

I believe that the loop time monitor in CS may fulfil the original request here. It is enabled by #define IO_LOOPTIMES in the config.h and, when enabled, it outputs something similar to the following every 5 seconds:
<* Loop Total:102us (264us max) HAL:30us (104us max) *> (basic system)
<* Loop Total:292us (2376us max) HAL:70us (688us max) *> (system with lots of devices and automation installed)
The loop total is the time taken for the CommandStation's main loop() function to execute (including all sub-loops). If any of the CS functions is taking too long at the loop() level then this figure will be high. Typically, Serial I/O and WiFi operations give increased figures. The HAL figures relate to the IODevice::loop() function on its own, and indicate whether the problem might arise from a HAL device (user-written or otherwise).