AdcFifo not configurable with DynPin about rp-hal HOT 4 CLOSED

Is it the intended way of using it?
OneShot has a separate implementation for that case, so read can be called directly on a DynPin. IMHO it would be more consistent if all functions were callable on the same set of types (as long as it's meaningful).

from rp-hal.

DynPin can be "concretised" before being used in the AdcFifoBuilder.

from rp-hal.

As long as the required configuration is applied on the pin before the sampling and restored when the pin's no longer used as adc input, it's fine by me :)

from rp-hal.

As long as the required configuration is applied on the pin before the sampling and restored when the pin's no longer used as adc input, it's fine by me :)

The additional impl should still require an AdcPin<Pin<DynPinId, F, M>>, just with a where bound AdcPin<Pin<DynPinId, F, M>>: Channel<Adc, ID = ()> or similar. So the proper configuration should already be in place.

from rp-hal.