Marek Kvas wrote: > > To summarize, sigrok can't do what you want right now but can be > > extended to do it without too much trouble. > > The expression "without too much trouble" sounds promising, but I > wonder why it has not been implemented yet when it seems to be so > common requirement:)
I think it's both because of lack of developer resources, and connected to that because noone has had a real usecase for it yet. Also it can be a little bit tough to make sense of the diversity in other parts of sigrok, exactly as you point out below. > I suppose that API for protocol analysers is designed to work with > continuous stream of sampled data with fixed sample rate as well. > So if I implement this new packet type, adjust frontend to be able > to process it, I become incompatible with protocol analysers - am I > right? Analysers would have to be written twice in fact (at least their > part). This doesn't sound to me as a good idea. Are there any analysers > already prepared? Should not analyser API work with more general data > format than continuous data stream? I think this is a very important point. This is a challenge that still needs to be solved in sigrok. There is a generic bus so it would be easy to create new data formats and consumers of those formats, but at the same time it's silly to not make sure that existing consumers on the bus can benefit from new data sources. I think it could make sense to consider events a slightly higher-level representation of sampled data. My guess is that most if not all protocol decoders detect events in the datastream already. One solution would be to formalize those different detections, and move them out of the protocol analyzers. That way, events could be synthesized by sigrok if acquisition is a stream of samples rather than a stream of events. For other data consumers on the sigrok bus it might not be possible to do anything useful with event streams. But I think protocol analyzers could do it. > I can write simple GUI which satisfies my current needs, but in > next similar project I will do it again and again as well as many > other people. I would rather contribute to something more general > which I can reuse and from which I can get back even more than I > invested. Great attitude! :) But keep in mind that in order to make something that really is generic and can be used by others in the same way, then as a pioneer you may have to do slightly more work. :) > The question is how far sigrok development will continue... I think it will continue for as long as contributors find it interesting and useful, and it's a unique project that fills a need. And the project is still only very young! //Peter ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
