Timers

[droogmic]

Based on #8, appears to work as required. It is however, very messy, I am just happy I got it working. I am not totally up to speed with recent embedded rust developments and roadmap, nor am I very experienced with rust, so a skim read and advice if there is a better standard to follow would be appreciated.

Changes:

• Refactored so all logic sits in timers.rs
• Added TIMER1, TIMER2, RTC0 and RTC1
• Examples to test this can be found in https://github.com/droogmic/microbit/tree/examples/tests

Consider / TODO:

• [x] Duplicate start method
• [x] Commented out features
• [x] Move things to a time.rs file
• [x] hal::timer::Periodic marker trait flag, doesn't apply as for the nrf51 this can be changed at runtime, how is this usually handled?
• [ ] A robust testing strategy is probably needed; some tests are provided in microbit which are a good start for manual verification, but ideally these would be run as tests not examples; also briefly discussed in #10
• [x] Compare with other examples, e.g. stm32f* hal crates
• [x] What should be the API for shortcuts
• [x] How should the similar feature set between TIMER and RTC be combined to a unified API

[droogmic]

I think this is ready for an initial review, I have qualified the functionality of all 5 peripherals on my device. I can rebase on request I can run rustfmt on request

[droogmic]

Fixes following discussion with @therealprof.

Still some open issues, but a lot is down to shortcomings in embedded-hal

[droogmic]

Don't merge this, I think there is a major flaw with this as is. If DelayMs and Timer are implemented on the same struct, then they can currently both be used at the same time. Obviously this currently breaks everything... e.g. start an asynchronous countdown, use a delay on the same struct, then waiting for the countdown (hint: the countdown will block forever as the timer is now stopped) 2 options:

1. Macro everything to have a full duplicate implementation of everything in Delay and Timer, with the exception of the embedded-hal traits, which will be only in one or the other
2. (Possibly, I need to think further if it is possible) take a performance penalty (might need to do more computations and store a u32 in the struct) but enable more functionality: use the second comparison registers and events on the nrf51's timers and rtcs to enable compliant functionality

Thoughts?

[therealprof]

@droogmic Just from reading the code I'm not sure how conflicting use would be possible. Is this due to Delay being a type alias for a Timer? If so this could be solved by using a type state, i.e. have some general timer initialisation code and then two different types implementing either HAL functionality.

[droogmic]

@droogmic Just from reading the code I'm not sure how conflicting use would be possible. Is this due to Delay being a type alias for a Timer? If so this could be solved by using a type state, i.e. have some general timer initialisation code and then two different types implementing either HAL functionality.

Ah yeah, that would be option 1, don't actually need macros. That is the simplest and probably the best, as testing for interactions will be painful

[droogmic]

@therealprof And yes, because of the alias you can make a Delay item with both DelayMs and Timer traits implemented

[droogmic]

@therealprof I am not sure if this is what you meant

using a type state

[therealprof]

@droogmic I don't have the time right now to look into your update but typestate programming is something like this: https://github.com/therealprof/stm32f042-hal/blob/master/src/gpio.rs

Basically what you had previously but with empty structs for the different possibilities (e.g. Countdown or Delay), functions to move the generic timer into those states and then only impl the traits on the timers which are in that specific state.

[droogmic]

@therealprof Thanks, I'll try that and get back to you.

[droogmic]

@therealprof I have made an attempt, but I am not really happy with the result...

[droogmic]

@therealprof bump, a quick look to see if this is what you meant would be appreciated.

[droogmic]

@therealprof See https://github.com/therealprof/microbit/pull/11 for a demo.

Not sure type state is the way to go anymore, as the moment the struct specializes most of the methods should probably be removed. I think having 3 different structs would be simpler, where Delay and Countdown structs container a single Timer struct.

[therealprof]

@droogmic Actually I was hoping that instead of Timer<Generic, TIMERx> we would have something like Timer<TIMERx<Generic>>, potentially even without the additional Timer though I'm not sure whether that would work register-wise.