Timer additions: raw access to prescaler and auto-reload

[Windfisch]

I frequently use timers for precise measurements, and unfortunately, start_countdown performs intransparent calculations which can introduce rounding errors.

This PR adds the capability to set and read the raw prescaler and auto-reload values, also we can now read the timer's count; this is useful when ARR is set to 0xFFFF, i.e. the timer is just "free-running".

[Windfisch]

Hm, seems like it fails to build with cargo check --features=stm32f100,rt but works with cargo check --features=stm32f100,rt.

I don't understand why it gives me this error for stm32f100, but not for f103.

error[E0133]: call to unsafe function is unsafe and requires unsafe function or block
   --> src/timer.rs:366:44
    |
366 |                       self.tim.arr.write(|w| w.arr().bits(arr) );
    |                                              ^^^^^^^^^^^^^^^^^ call to unsafe function

I could just wrap around an unsafe, but I'd prefer discussing this first. Is this a bug in the stm32 crate or am I missing something? Please help.

[TheZoq2]

I think there are some inconsistencies between the different f1 variants which causes that unsafe thingy, we can probably add an unsafe block and accept the warning it will throw on the other versions

[TheZoq2]

Thanks for the PR and sorry for the review delay. I added a few notes which would be nice if they are addressed

[Windfisch]

Just to give a update, I've seen your suggestions and will implement them later this week. Thanks for the help :)

[Windfisch]

I've implemented your requested changes and merged with the current master. Hopefully everything is fine now :)

[burrbull]

merged with the current master

Don't merge master in PRs, you make commit history non-linear. Rebase only.

[Windfisch]

Thanks for the hint, I've updated my PR.

It may be helpful to state "rebase over merge" somewhere in a contibutor's guidelines document, or just under the "Contributing" header of the README, since it is not an obvious thing to do; other projects prefer it the other way round. Or is there such a document which I failed to find?

[TheZoq2]

Great work! Adding a CONTRIBUTING document stating rebasing is prefered is a pretty good idea. Though I assume that tends to almost always be the case when working on PRs, and the debate is more often about wether or not to do the final "merge" as a rebase or true merge.