Also, I recommend you take a look at or fpgalafw sub-project: http://sigrok.org/wiki/Fpgalafw
I've been trying to start a pluggable FPGA firmware project for a while now. Some intial work had been done by myself and Iztok derived from the OpenBench Logic Sniffer (OLS) "Demon Core" code. The OLS has a Spartan 3 and an RS232 interface via a PIC. As Alex says, RS232 LAs are quite inferior. Much better to get a SAM3U or a FT232H as an interface. Debugging the driver is not hard - in Linux you can use Wireshark with usbmod to trace packets. Then the simple protocol in fx2lafw is probably a good starting point. Joel On 06/12/13 02:23, mrnuke wrote: > On 12/05/2013 03:31 PM, Matthias Weber wrote: >>> we are a group of students from University of applied sciences >>> in Augsburg. We're currently working on a project where we >>> implement software for running a hardware board developed by >>> another student as his bachelor thesies a few years ago. >>> >>> The current hardware consists of a ATmega32U4 microcontroller, >>> an Altera Max II CPLD, 1 MB SRAM and some driver ICs - it is a >>> 24 bit logic analyzer. > > I doubt the ATmega32U4 will do you much service in getting 24 bits > of data through a low-speed USB connection to the host computer. If > you think bandwidth, you have too ask if you have enough available > to have any usable sampling frequency. Of course, if you trigger > and sample than you can transfer the buffer, and bandwidth is of > less concern. I think it's doable. > >>> Control and data communication between PC and uC will be >>> handled via a virtual serial interface (via USB). > > 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 > >>> 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. > >>> For the first few steps we will try to control the analyzer in >>> a simple terminal, so we might use ASCII characters, > > 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. > >>> Can you please give us a small hint where to start >>> implementation/ integration in sigrok? I've seen that there is >>> a demo device. Is it a good way to start here or is there any >>> further documentation on how to integrate new devices? >>> > 'demo' is a different beast. I would start with a device that most > closely matches what you are trying to create. Of the top of my > head, I can think about buspirate (serial) and fx2lafw (USB). > > Good luck! > > Alex > > ------------------------------------------------------------------------------ > > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code > base. Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > > _______________________________________________ > sigrok-devel mailing list [email protected] > https://lists.sourceforge.net/lists/listinfo/sigrok-devel > ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
