Hi > Right now sigrok does indeed work with fixed sample rates, meaning a > 100Khz rate will expect that many samples/sec, like you said. > > However that's just a function of the current set of drivers and > frontends. The way data transfer between drivers and a frontend > is implemented is through a bus. The frontend sets up the bus and starts > acquisition, the hardware-specific driver shoots packets in it, and the > frontend gets those and does whatever (save, display, etc). The packet > stream is basically a header packet, data packets, and an "end" packet. > The current data packets are all of the form DF_LOGIC8, DF_LOGIC32 and > so on. This refers to logic analyzer data, and the number of bits > per sample in the packet's payload. > > What you want is a packet type that holds a set of timestamp/value > pairs, or perhaps one timestamp and a set of consecutive values. > > So it's a matter of implementing your driver (obviously), defining > those packets and a struct for the payload, and extending the > frontend to do something interesting with your data. > > 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 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?
> Whether it gets you > anything more than what you'd have if you just wrote your own > thing from scratch, is for you to decide :-) > > I think it can get me very much. First of all I am used to program firmwares or work very close to HW. Programming of GUI applications is not my hobby, I don't like it, I don't have enough experience with it and I don't have time for it. I consider sigrok very nice idea. There is need to analyse data from various sources very often and tool which is easy to connect to any data source and visualize it is very useful in my opinion. There exist also very attracting possibility that there will be analysers for various protocols available for sigrok. To do it all on my own is not real. Of coarse for the particular application I have on my mind now 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. The question is how far sigrok development will continue... Marek ------------------------------------------------------------------------------ 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
