Hi @GianfrancoIU1JSU
Thanks for the PR, we will review it, as a first comment, it seems not complete and probably generate warnings.
Check should be done if the value is higher than an UINT32_MAX.
GetOverflow should also be updated to return a uint64_t.
Examples and codes using them should be also updated.

Hi @fpistm

it seems not complete and probably generate warnings.

in teory the only place where a it can trigger a warning is on the return value of the
getOverflow() since in already made code is used with uint32_t
this is a narrowing conversion and could generate a warning but i could not get it,
even with -Wall build flag.
warning a side for existing code doesn't pose a issue since they are using values that fit in uint32_t

Check should be done if the value is higher than an UINT32_MAX.

Check should be done if value - 1 > UINT32_MAX,
the point of the modification is to allow the value to be 0x100000000
which will became UINT32_MAX after the -1

GetOverflow should also be updated to return a uint64_t.

I've already done that in this PR be7e127

Examples and codes using them should be also updated.

this modification does not break existing code.
some examples could be added demonstrating usage of 32 bit timers like:

• long period measurements
• long period wave form generation

if you agree I can make the corrections and remake the PR
and in a separate PR I can build a coulple of new examples

Hi @GianfrancoIU1JSU
Unfortunately, we remembered that the HardwareTimer library uses all timer like 16 bits timer. See

https://github.com/stm32duino/Arduino_Core_STM32/wiki/HardwareTimer-library#1-introduction

For genericity purpose, HardwareTimer library uses all timers like a 16bits timer (even if some may be wider).

So even if this PR allow you to use max 32 bits values, it is not enough to support properly 32 bits timers as some side effects can occurs.