Hi Mathias,
I'm sorry for taking so long to look at your patches, I was away from
home when you posted them so didn't have a Rigol to test on at the time.
Now I am looking and it seems I am missing some commits somewhere. The
patches you have posted here do not apply against my current
rigol_ds_unified branch. It fails at the first hunk of the second patch,
where it appears that the version you're patching against already has an
extra field in struct rigol_ds_model ("number of horizontal divs") which
I don't have.
Am I missing another patch series? I'm not seeing anything from you
between the last standalone version of the driver, and this latest set
of patches.
I can answer one thing from your comments though:
> The driver has now "gained" dependencies between settings, i.e. we can
> only set sample memory depth after we know how many channels are
> active. The same is true for the DS1xx2 series as far as I
> understand. No idea if this may cause problems for pulseview later.
The planned approach, in future at least, is that frontends should
always re-call sr_config_list() after making configuration changes, so
that they get the settings which are now "reachable" from the current
configuration.
This is more intent than practice just now, and somewhat entangled with
the plans for changing how we enumerate possible configuration settings
in the first place - see e.g.:
http://sigrok.org/wiki/Improved_Configuration_Enumeration
In short, yes we plan to deal with that situation, we just haven't quite
worked out the details yet. This is on the list of things for us to
discuss at 30C3.
Martin
On Wed, Nov 20, 2013 at 10:30:07PM +0100, Mathias Grimmberger wrote:
>
> Hi Martin,
>
> today was a holiday over here so I managed to finish putting the sample
> memory stuff for the DS2000 series into the unified driver.
>
> It is now possible to select data sources "Live", "Memory" (and
> "Segmented").
>
> Sample memory depth is for now fixed at 14K/7K samples, this needs to be
> made configurable later.
>
> The driver has now "gained" dependencies between settings, i.e. we can
> only set sample memory depth after we know how many channels are active.
> The same is true for the DS1xx2 series as far as I understand. No idea
> if this may cause problems for pulseview later.
>
> The code is a bit of a hairball for now, I tried to not touch any DS1xx2
> code and keep the code paths separate. I hope a lot of the code can be
> unified to keep it readable.
>
> I also think we need to more clearly delineate the overall structure of
> driving the device. By that I mean it should be made obvious where the
> device as a whole is set up, where capturing of one set of data frames
> is set up and where reading data from one channel is handled. I tried to
> structure my new code along this way, have a look if it looks sensible.
>
> Also have a look at the names I gave the new stuff, e.g. I'm not
> especially happy with the protocol designators but couldn't come up with
> something better.
>
> I also amended the trigger waiting. I tested it for a bit and it turned
> out that for the wrong conditions 9 out of every 10 data frames were
> duplicate data. So for timebases to fast to read the trigger status it
> now just sleeps for about the sweep time, this should cut down on the
> amount of duplicate data.
>
> I think it should work reasonably well in practice because only crazy
> people like me look at a 0.1Hz signal with a 20ms/div timebase,
> everybody else probably want's to actually see their signal. ;-)
>
> Patches follow as replies to this mail.
>
>
> Enjoy,
>
> MGri
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
sigrok-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
