systick: Refactoring.

[dpc]

This change rewrites systick module a bit to use new ioreg macro, changes systick::setup a bit to eliminate "boolean trap", exposes tenms() to the user, so the user can read and manipulate it.

[bharrisau]

Or

match reg::SYSTICK.calib.tenms() {
  0 => None,
  val => Some(val)
}

[bharrisau]

Nice, I like using enums this way.

[farcaller]

I feel that "fallback" is a bit misleading concept. I want to set the systick clock to the exact time value that I know.

There are two cases: either platform has the value for 10ms or not. It's also a bit more complicated as that reference value is only supported on reference clock, so in the end it's up to PT to initialise the systick clocking correctly (i.e. we don't even need to care about pre-defined constant).

I'm fine if "calibrated" source goes away in that case. Systick is kind of reserved for zinc/os internals (scheduler), so it's not really that of user-facing api.

[bgamari]

bikeshed: perhaps ten_ms would be a tad more readable?

[bharrisau]

Does it even need to be public?

[dpc]

Depends. For standalone applications (not using any rust-provided scheduler), it might be useful to check if there's any calibrated value. Is there any cost having it public?

[bgamari]

A couple of notes above but otherwise LGTM.

[dpc]

I feel that leaving ten_ms public, to let user potentially discover calibrated value if it wants it, and killing CalibrationMode is simplest solution that does not sacrifice simplicity.

I'll fix using your comments and push today/tomorrow. Thanks.

[bgamari]

@dpc I agree. systick::setup(systick::tenms().or(fallback)) seems much clearer to me than yet another type.

[dpc]

r?

[bharrisau]

Looks good to me. Thanks for your good work.

[bharrisau]

@hacknbot: merge