Enhancement of WPM feature

[drashna]

Types of Changes

• Core
• Enhancement/optimization
• Documentation

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).
  And additional code cleanup

[brickbots]

Thanks for these great updates!

[tzarc]

Sorry about that, GitHub decided to delete the develop branch from upstream when we merged it, despite being told otherwise. Reopened.

[stale]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[firetech]

@drashna Since this patch, pressing multiple (counted) keys simultaneously makes the WPM skyrocket, often even overflowing the uint8_t it's stored in. As far as I've been able to test, I can't seem to reproduce that with the last version of wpm.c before this.

The reason seems to be that, previously, the old calculation of latest_wpm was stored in a uint8_t before being added to current_wpm, but now that calculation is entirely inline. Adding a uint8_t cast to that part inside the new calculation restores the old behaviour. I.e.

current_wpm += ((uint8_t)(60000 / timer_elapsed(wpm_timer) / WPM_ESTIMATED_WORD_SIZE) - current_wpm) * wpm_smoothing;

Not sure if the potential overflow there was intentional or not...

That said, I'm not entirely sure which of the algorithms is the most correct, but I never really found either of them to be far off other measurements, except for this difference.

Edit: This might be a better solution, clamping the value instead of just relying on a random-ish value after uint8_t overflow:

uint16_t latest_wpm = 60000 / timer_elapsed(wpm_timer) / WPM_ESTIMATED_WORD_SIZE;
if (latest_wpm > UINT8_MAX) {
    latest_wpm = UINT8_MAX;
}
current_wpm += (latest_wpm - current_wpm) * wpm_smoothing;