2015-08-12 17:44 GMT+02:00 Joel Holdsworth <j...@airwebreathe.org.uk>: > Hi Hubert, > > Sorry for the delay in getting back to you. That sounds like a bug - we > could use a shared lock if we have no other way, but it sounds like > signal_from_channel maybe holding onto its lock longer than it needs to. > For example if that function sends an event to the UI thread, but is > holding the lock while waiting for the event to complete, this would > prevent the UI thread from getting through paintEvent and processing the > evening. > > With regard to oscilloscope modes. Yes this would be very welcome. > > However, looping sample_thread_proc probably isn't the right way to do it. > > libsigrok does have support for actual oscilloscopes. It signals the > start/end of a new sweep by SR_DF_FRAME_BEGIN/END.
Alright, so this is what these frame types are for... I used them in ACME driver as frame delimiters, but ACME "frames" contain only a single sample from every channel - it kind of simulates sending several samples in a single packet, but since ACME channel-groups send out samples with different units (current, voltage, etc.) I can't put them all in a single struct sr_datafeed_analog. In oscilloscope mode this would mean a frame would have the width of a single point in time, which is useless. Since Hubert is working on the oscilloscope mode useful for ACME I think we should rethink the way the samples are sent out. Could we make struct sr_datafeed_analog contain int *unit instead of int unit that would hold the unit type for each analog measurement? Best regards, Bartosz Golaszewski > At the moment PV doesn't handle these - but it could and should. > > Now for devices that don't support continuous-sweeping, we can emulate > that in software. Now the question is where should this functionality > go? Should it be in PulseView? I think not, because this is > functionality other clients can use. Should it go in the drivers? In > many cases yes, I would say, but would the sweep emulation have to be > duplicated across many drivers? Would it go in libsigrok's core somehow? > I don't know. > > It would be good to have a discussion with use_ and biot on the #sigrok > IRC channel. > > The other issue is that painting needs work to improve speed. It would > be good to bring back some OpenGL painting. But also the various > painting/data storage algorithms need to be revisited. > > Joel > > On 05/08/15 10:35, Hubert Chaumette wrote: >> Hi, >> >> I am experimenting on a continuous oscilloscope-like mode for >> PulseView (I basically added a loop in sample_thread_proc), and I >> encounter a deadlock on pv::Session::signals_mutex_. >> It appears both pv::view::Viewport::paintEvent (main UI thread) and >> pv::Session::signal_from_channel (sampling thread) try to acquire the >> mutex exclusively. >> >> The deadlock disappears when replacing lock_guard by shared_lock in >> signal_from_channel. So, is exclusive access to pv::Session::signals_ >> necessary there? >> >> Best regards, >> >> Hubert Chaumette >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> sigrok-devel mailing list >> sigrok-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/sigrok-devel >> >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > sigrok-devel mailing list > sigrok-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sigrok-devel ------------------------------------------------------------------------------ _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
