Hey Alex, thanks for your response!
> (...) Of course, if you trigger and sample than > you can transfer the buffer, and bandwidth is of less concern. I think > it's doable. That's the way we go: trigger/ start measurement, stop measurement by command or when memory is full. Furthermore we already want to have a kind of VCD in the CPLD logic or at least in the uC logic, if possible. This means we save sample number/time plus logic data. > In my opinion, you should avoid this like a plague. Implement a proper > USB protocol, and don't emulate over serial. It will take more effort to > write a serial protocol and emulate it over USB, than it will to just > implement pure USB. I did an LPC programmer this summer, pure USB, and > the protocol was not at all complicated Okay, thanks for the hint. The problem is: there's not much time left. The cool thing is that LUFA (http://www.fourwalledcubicle.com/LUFA.php) already offers a virtual serial interface for the Atmel AVR uC series which already works fine. >>> The control/ data transmission protocol is not defined yet, but I have >>> taken a closer look at the currently supported hardware. > > Look at the fx2lafw protocol. I think it provides a good starting point. I've taken a look into libsigrok/hardware for a couple of devices and I've also tested the new-driver script for generating/changing the required files. I also found some documentation about the hardware driver api. > I think it's a waste of resources to write an ASCII protocol only to > replace it later. Write the firmware and software at the same time. It's > fairly easy to do this with libusb. Getting a handshake might take some > tinkering, but I think the rest is a piece of cake. Again the problem of time. This is only a short time project and we'll have to finish by the end of this year. If we cannot integrate it we could at least write a small program to interact with the device, or alternatively could use a simple console program. Maybe it should be seen as a feasability study and development could be continued by the next group. > (...) Of the top of my head, I > can think about buspirate (serial) and fx2lafw (USB). Thanks for the hint. I'll have a closer look at them. Unfortunately for me it's not clear what to implement in the api.c file and what should be implemented in the protocol.c file. Is the API all about devices, device drivers, device instances and protocol all about the way to get and interprete data? Thanks, Matthias ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
