Implement Observable POC

[usbalbin]

Alternative to #138

@AdinAck is this somewhere close to what you discribed in #138 ?

[usbalbin]

I had to do this since we can not do this the trait impl rules

impl<T: Observable> Into<ObservationToken<T>> for T {
    fn into(self) -> ObservationToken<T> {
        ObservationToken {
            _p: PhantomData
        }
    }
}

do you know if there is a better way?

[AdinAck]

The most recent version of this concept (with a few name changes and being used in a brand new context) is here. The simple solution to this is to implement From rather than Into. This is a good idea in general (save some rare edge cases).

impl<P> From<P> for ObservationToken<P>
where
    P: Observable,
{
    fn from(_: P) -> Self {
        Self { _p: PhantomData }
    }
}

Another option - which eliminates the need for calling .into() to directly pass a peripheral as an observation token - is to create a new trait called ObservationLock which is implemented by all P: Observable and ObservationTokens. Interfaces would thus hold impl ObservationLocks rather than concrete ObservationTokens. This is described in this gist.

The former is a solution I am putting to use right now in proto-hal, the latter I suspect is a better solution, but have not implemented quite yet.

Hope this helps!

[AdinAck]

Maybe the ObservationLock trait is unneeded since the interfaces can accept an Into<ObservationToken<P>>. Clever!

[usbalbin]

If we want the user to be able to destruct the consumer of the ObservationToken how does this affect things?

If the user passed an actual owned peripheral than would it not be best to just not convert it and let the consumer store the peripheral as is until it is destructed?

In that case would ObservationLock make more sense since that better signals what we are doing?

[AdinAck]

Ah yes! That was why ObservationLock was good. Since the peripherals would store an impl ObservationLock, the release() would return back whatever was originally passed in.

[usbalbin]

The former is a solution I am putting to use right now in proto-hal

Very interesting!

[AdinAck]

This looks great! Have you run any integration tests?

[AdinAck]

Every occurrence of P should be P: Observable.

[usbalbin]

Should we even go as far as implementing Deref{Mut} for Observed?

[AdinAck]

Yep, Deref will be a really good QoL feature.

[usbalbin]

This looks great! Have you run any integration tests?

Thanks :) No, no tests at all yet

[usbalbin]

This does not work. Both Channel and EntitlementLock (or rather P i suppose) are from outside this crate. There are also errors about conflicting implementations with the other opamps below.

[AdinAck]

I think the simplest solution is to make a local trait like AdcChannel which requires embedded_hal::adc::Channel and then it would work.

I'm not very familiar with what you're doing here though. I'll think on it.

You could also do concrete implementations since this is macro generated anyway.

[usbalbin]

You could also do concrete implementations since this is macro generated anyway.

Yeah that would probably be the simplest solution. I'll give it a go