Dieter wrote: >>> 1) a data gatherer on the OGD1 itself >>> >>> 2) a program to control the data gatherer and upload data >>> >>> 3) a program to display the data >>> >>> In most cases, 2 and 3 will run on the same machine, but if someone >>> needs to work remotely, 2 would run on the support machine with the >>> RS-232/USB/Ethernet/whatever link to the test machine, and 3 would >>> run on the machine with the display. 3 can run standalone using >>> data from a regular disk file. Assuming we need to use demand paging >>> of the data, we need for 3 to be able to talk to 2. And it would >>> be convenient if the user could start a new test run directly from 3. >>> > > >>> We need a protocol for communication between 1 and 2. >>> >>> specify trigger condition >>> specify capture window start and stop times relative to trigger >>> specify which signals to capture >>> >> I think we would usually capture them all. The best you could do is >> shave off a few bits. >> > > I'm not familiar with the signals on the PCI bus. Would it always be > necessary to look at the data bits, or would the control lines be > sufficient in most cases? If you can eliminate 32 or 64 signals > then the data would upload faster. And potentially allow storing more > samples in memory. > > You pretty much have to have the address, and probably the data too, but since they are the same lines, if you are capturing one you get the other "for free". >> Then to be able to specify which ones you DO >> have could cost you more bits. >> > > 2 sends 1 a mask. Not that many bits. > > If we think we will need most of the signals most of the time > we could leave this feature out. Simplicity is good. There can > always be a version 2 later. > Capture hardware needs to capture everything. Let the software sort it out. The capture pipeline is a critical path and any conditional logic it would be an issue. It the MCU pulling data out of the capture pipe and storing it in memory is fast enough to do the processing, then someone can easily update the program for it in a later rev. > >>> We need a file format for the data files. >>> >>> magic string >>> format version number >>> data, including user specified strings for signal names >>> checksum >>> allow for comments (e.g '#' ) >>> allow for demand paging (how?) >>> >> We should look at VCD format to see if it serves our purposes well. >> If so, then someone could use GTKwave to view the same data. >> > > What is VCD in this context? Somehow Video Compact Disc doesn't seem right. > > >>> We need a protocol for communication between 2 and 3. >>> >>> Same needs as protocol between 1&2? >>> >> No. I think it should be an API, not a protocol. Just a set of function >> calls. >> > > 2 and 3 might be running on different machines. > KISS. Properly written it would be reasonably straight forward to put a network interface between 2 and 3. But we need working software more than we need to cover every possible feature and use case. > >>> We need setup/rc type file for 2 >>> >>> specify trigger condition >>> specify capture window start and stop times relative to trigger >>> specify which signals to capture >>> specify resolution (samples per second) >>> user specified strings for signal names >>> comments >>> >> Some stuff needs to go into an rc file. We should also be able to let >> the user load some of these (like trigger conditions) in separate >> files. And most importantly, there should be an intuitive way to >> enter them into the GUI. >> > > Yesterday I suggested that the GUI should have buttons for > switch to a different config file > edit config file (launch $EDITOR) > > config file = setup file = rc file > > It occurs to me that it would be nice to have a way to select a sample > and export that into a config/setup/rc file and make it the trigger > for the next run. > > >>>> I take it we want plain C for this? >>>> >>> C would be a very good choice. Proven, well known, fast, portable. >>> >> Just consider development time versus Perl/Python/Ruby. >> > > Cranking out the actual code is the easy and fast part. > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > >
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
