On 04/17/2012 01:56 PM, Joel Holdsworth wrote:
> First off, it has been said may times before, so we know the v0.3 cycle
> was very long. Though there were some special circumstances, I think it
> would be good to release earlier and more often in the coming cycles.
> Would a 4-month cycle be possible? Could we conceivably release v0.4 in
> August?
Yes, absolutely. Four months is way too long even: we are most definitely
switching to a RERO schedule. A feature and a bugfix? Release it. That's
what the version numbers are for, after all.
The TODO list at
http://sigrok.org/wiki/TODO
has lots of cool features and fixes to get us started.
> Second, if everyone is happy, I would like to delete (or at least
> disable) the saleae driver now, so that we can give fx2lafw the maximum
> level of testing. Is everyone happy if I go ahead and do that within the
> next couple of days?
Yes, go for it. Just clean it all up, no point in leaving unused code lying
around.
Fx2lafw is a BIG deal. As soon as a bunch of us have put it through its
paces, we have to release it.
> Fourth, who owns the Braintechnology USB-LPS and the Saleae Logic16? I
> guess the USB-LPS would be easy to add support for if someone wants to
> work with me on that. I just need to add a new sampling mode to fx2lafw,
> along with analog support. The Logic16 must have some kind of CPLD on
> it's front end. Has anyone had a look inside one of these?
Uwe has the USB-LPS. Neither of us have the Saleae Logic16.
> Fifth, I'm interested in possibilities for making libsigrok more
> threaded with a FIFO of buffers inside to solve buffer overflow problems
> that we experience with Fx2s. This would allow us to do away with the
> fixed number of transfer buffers in the fx2lafw driver, and just allocate
> more as we need them (up to some limit), and the front ends can consume
> them as fast as they can, but without having to keep up. Correct me if
> I'm wrong, but from my knowledge of libsigrok this doesn't sound as hard
> as it could be. Has anyone made any plans to tackle this? I'm quite busy,
> but I might be able to have a go some time.
We will certainly need to separate out the low-level driver IO from the rest
of libsigrok (and the frontend), and glib gives us portably threads already,
so that's definitely the way to go.
However, this will in no way fix that problem with the FX2s. The root of the
problem there is sending 24MB/s across a USB bus with only the barest
minimum of transmit buffers. Receiving it all in a separate thread -- with
some OS-level higher priority if we can help it -- will help matters along, but:
- the FX2 still isn't the only thing on the bus: other devices doing a
transfer will use up throughput capacity on the USB bus.
- sigrok is still not the only process on the system. A high priority thread
does not a real-time system make.
(see separate mail for analog progress)
--
Bert Vermeulen [email protected] email/xmpp
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
sigrok-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
