RFC: Introducing a common interface for counters.

[Ben-PH]

Initially intended as a Clock rfc, my thoughts evolved while writing. Though this could be returned to a simple Clock RFC, a clock interface is nothing more than

1. Reading a generic integer value that increments 1 at a time. For a clock, this is an oscilation count
2. A specification of a measurement assosciated with each increment. For a clock, this is a duration of time

There are many situations where these two principals are used, and they are distinct only in the what they are reading (u32, u64, u8, etc), and what they are measuring (1/80_000_000 seconds per count? 1 milimeter per count? 100 milliradians per count?).

I chose to generalise, so as to entrench the idea that this RFC aims to bring in something that incurs no restrictions on reverse dependencies, and portability limitation defined only by the inherent nature of clocks and other counters.

I anticipate a Counter trait emerging, with other more specific expressions of counting to emerge, such as a Clock: Counter and PulseCount: Counter traits, in such a way that the extensions add additional constraints (e.g. you're counting something that can be a measurement of time). The RFC file goes into detail.

A list of reasonable expectations proposed by @jamesmunns

• [ ] A timer/counter will need to be shared - there are relatively few of them on many chips
• [x] Users will want high precision in some cases, 1k-1M are very reasonable number
• [ ] Some timers have a limited range - 16/24/32 bit are common, but many chips only have 16/24
• [ ] Programs will be expected for months to years at a time
• [ ] Some users want to use the lowest possible power design they can
• [ ] Not all chips have atomics, and may need to use critical sections
• [ ] Users may have other interrupts, some of which may have higher priority than your timer/counter interrupt
• [ ] Users may want to use a global timer inside of other interrupts