AWG - RFC

[alon]

This is related to issue #2

It is partially I think correct and partially definitely not.

I would like to get comments on:
enums - is this the right way?
PicoDriver trait extension - ditto? especially the use of unimplemented macro.
ps2000a implementation

Lastly the PicoStreamingDevice additions are pure throw away code, just for testing. What worked was basically:

    fn connect_to_scope_real(&mut self) {
        // ... get a device the regular way
        let stream_device = device.into_streaming_device();

        //stream_device.set_sig_gen_arbitrary();
        stream_device.set_sig_gen_built_in_v2();

        stream_device.enable_channel(PicoChannel::A, PicoRange::X1_PROBE_2V, PicoCoupling::DC);
        stream_device.enable_channel(PicoChannel::B, PicoRange::X1_PROBE_1V, PicoCoupling::AC);
        // When handler goes out of scope, the subscription is dropped

        stream_device.new_data.subscribe(self.handler.clone());
        stream_device.start(1_000_000).unwrap();

        self.stream_device = Some(stream_device);
    }

[timfish]

For the enums variants, I would shorten them like:

pub enum PicoSigGenTrigType
{
    Rising = 0,
    Falling = 1,
    ...
}

For the PicoStreamingDevice functions, rather than many arguments, it might be nicer to put them into a struct and then implement Default. This way you can leave out properties that aren't important and use it like:

device.set_sig_gen_properties_built_in(SigGenProperties { 
  trigger_type: PicoTriggerType::Rising,
  ..Default::default()  
});

Having not used the sig gen/awg APIs on these devices I don't know how viable default options are.
I still need to find some time to try out these APIs and also see how they compare across the many drivers.

The PicoStreamingDevice attempts to try and hide all the differences between all the drivers/devices and was primarily for my own use case which was streaming raw, gap-less data at high speed from any Pico device. It also automatically reconfigures and restarts streaming if it gets disconnected and stores the device config required to do this.

What are your plans for siggen/awg while streaming?

[alon]

I will do both suggestions, they make sense. Meanwhile I implemented the software trigger function and one of the on the fly update functions since the initial PR. My aim is to allow software triggering to allow a complete capture. Right now I have some unexpected delays that probably result from misuse of the API. Doing stop, then calling sig gen, then enable again already works. It is very fast jn human terms, although there must be some lost samples, but I did not measure that yet.