Trait SendScdcClient 

pub trait SendScdcClient: Send {
    type Error: Send;

    // Required methods
    fn read_flt_ready(
        &mut self,
    ) -> impl Future<Output = Result<bool, Self::Error>> + Send;
    fn read_update_flags(
        &mut self,
    ) -> impl Future<Output = Result<UpdateFlags, Self::Error>> + Send;
    fn clear_update_flags(
        &mut self,
        flags: ClearableUpdateFlags,
    ) -> impl Future<Output = Result<(), Self::Error>> + Send;
    fn read_ltp_requests(
        &mut self,
    ) -> impl Future<Output = Result<LtpRequests, Self::Error>> + Send;
    fn read_source_test_config(
        &mut self,
    ) -> impl Future<Output = Result<SourceTestConfig, Self::Error>> + Send;
    fn write_config_0_defaults(
        &mut self,
    ) -> impl Future<Output = Result<(), Self::Error>> + Send;
    fn write_frl_config(
        &mut self,
        config: FrlConfig,
    ) -> impl Future<Output = Result<(), Self::Error>> + Send;
    fn read_ced(
        &mut self,
    ) -> impl Future<Output = Result<CedCounters, Self::Error>> + Send;
}

ScdcClient with Send futures, for code that spawns link training on a multi-threaded executor.

ScdcClient’s async fns promise nothing about their futures, so code generic over C: ScdcClient cannot spawn a future that calls them, however C is bounded. This trait has the same methods and contract, each returning a future that is Send, and errors that are Send too: a spawned task returns them. Implementations still write async fn; the compiler checks that each future is Send. With a SendScdcClient and an hdmi_hal_async::phy::SendHdmiPhy, the futures of FrlTrainer’s training methods and exit_to_tmds are Send in generic code too (train_with_events given a Send callback).

Bound generic code by SendScdcClient alone. Adding + ScdcClient, which it implies anyway, makes the compiler use that bound instead of the blanket implementation, and the futures are no longer known to be Send; the same holds for SendHdmiPhy and + HdmiPhy.

Every SendScdcClient is an ScdcClient, through a blanket implementation, so it works with everything written against ScdcClient as well; a type implements one of the two (implementing both conflicts with the blanket implementation). A SendScdcClient type has both traits’ methods, so with both traits in scope a method call on it is ambiguous: import only the trait the code is bounded by, or call SendScdcClient::read_flt_ready(…).

Required Associated Types

type Error: Send

Error type returned by SCDC operations.

Required Methods

fn read_flt_ready( &mut self, ) -> impl Future<Output = Result<bool, Self::Error>> + Send

See ScdcClient::read_flt_ready.

fn read_update_flags( &mut self, ) -> impl Future<Output = Result<UpdateFlags, Self::Error>> + Send

See ScdcClient::read_update_flags.

fn clear_update_flags( &mut self, flags: ClearableUpdateFlags, ) -> impl Future<Output = Result<(), Self::Error>> + Send

See ScdcClient::clear_update_flags.

fn read_ltp_requests( &mut self, ) -> impl Future<Output = Result<LtpRequests, Self::Error>> + Send

See ScdcClient::read_ltp_requests.

fn read_source_test_config( &mut self, ) -> impl Future<Output = Result<SourceTestConfig, Self::Error>> + Send

See ScdcClient::read_source_test_config.

fn write_config_0_defaults( &mut self, ) -> impl Future<Output = Result<(), Self::Error>> + Send

See ScdcClient::write_config_0_defaults.

fn write_frl_config( &mut self, config: FrlConfig, ) -> impl Future<Output = Result<(), Self::Error>> + Send

See ScdcClient::write_frl_config.

fn read_ced( &mut self, ) -> impl Future<Output = Result<CedCounters, Self::Error>> + Send

See ScdcClient::read_ced.

Dyn Compatibility

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors