Implement Observable POC

[usbalbin]

Alternative to #138

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

TODO

• Test
  • ADC
  • Comp
  • DAC
  • GPIO
  • Opamp

[usbalbin]

I had to do this since we can not do this due to 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

[usbalbin]

@burrbull do you have any thoughts on this as a concept?

TLDR(please @AdinAck correct me where I am wrong here):

There are several cases where it is useful to have multiple observers of the same resource while preventing one observer from reconfiguring the resource in a way not compatible with the others.

For example a gpio pin may be "observed" by a comparator while still being usable for AD readings at the same time. However we want to prevent the user from reconfiguring the pin to something other than Analog mode.

Another example would be a Dac. We want it to be observable from the comparator and/or opamp while we still have access to change its output.

This proposes to solve this by introducing a trait Freeze that enables the user to freeze a resource that implements it. By freezing the resource you get a Frozen<YourResource, N> and an array of N number of Entitlement<YourResource> which are proof that the resource exists and is indeed frozen in the expected state. Observers like the comparator or opamp may then take Entitlement<YourResource> instead of YourResource as inputs.

By recombining all N Entitlement with the Frozen, the resource may once again be unfrozen(defrosted?)

[AdinAck]

You are exactly right!

Additional background: this is exactly what references are, the compiler just automatically tracks the "recombination" (dropping of references) and forbids moving or dropping the resource if a reference to it exists. We are electing not to use references for two reasons:

1. Dealing with lifetimes.
2. These resources are of zero size, and we leverage that to produce really good compiler optimizations. Currently, references to ZSTs are not ZSTs themselves so we cannot express composite structures of these resources as ZSTs as well.

The drawbacks of this approach is we need to explicitly dispatch "entitlements" which are our reference analog, and explicitly recombine them, which is a bit of a hassle.

[usbalbin]

@AdinAck do you have any suggestions for how to move forward with this? Are you planning to release your stasis thing so we can depend on it from stm32g4xx-hal (and later I would probably want to use it for usbalbin/stm32-hrtim too). Or do you think I should have a local copy in stm32g4xx-hal for now? :)

[AdinAck]

I am still actively developing proto-hal and haven't reached a stable release point yet, so I wouldn't want my changes to affect you. I think a local copy makes sense, for now :)

[usbalbin]

Makes sense, thanks

Is it ok if I copy your stasis.rs? 8df2caf

[AdinAck]

Yep!

[usbalbin]

Yep!

Awesome! Thank you!

[usbalbin]

@AdinAck

This looks great! Have you run any integration tests?

I have now added some more tests. These ones require a jumper(I took the one at CN12 at the top left corner) when using a Nucleo-G474 between A1 and A2. But I do believe that single modification opens up for some pretty interesting self tests