PC software for FPGA control through USB port

[Altera_Forum]

On one side you have developped a PC control software (i.e. Visual C++ .net application). On the other side you have a Cyclone III development kit. What is the best/simplest way to make them communicate (i.e. exchange some control/status parameters) through USB during operation ? Does somebody has some experience or advice regarding this ? Any tip is welcome. Thanks.

[Altera_Forum]

Well I haven't specifically done this with a Cyclone III development kit. But I've done several projects where USB was the primary communication between the host PC and the board. In those cases, I've used the EZ-USB series from Cypress so the actual implementation is slightly different but here are the steps. 

 1 - Define a simple packet protocol for transferring the kind of info you are interested in (register address, data, whatever). 2 - Develop a driver for the host PC. This part is kind of a pain unless you've done it before. FTDI I believe gives you a driver to start from. You could also consider using libUSB which is primarily used for Linux but has been ported to Windows. In my case we used the Windows bulksys driver as a starting point for Windows and wrote our own driver for Linux. 3 - Develop a driver for your embedded system. This is pretty easy as you're usually just reading/writing from/to FIFOs in the USB chip. You may have to do some initial endpoint configuration. 4 - Then you need to write your application code for both your embedded and host PC app.  Most of my more recent designs use TCP/IP for communication which is easier to get up and running but incurs a high software overhead due to the stack. Not sure which kit you have but you may wish to consider using ethernet if you just want to get it running quickly. In which case you pretty much get to skip the step of writing a driver as you'll just use a socket interface.  Jake

[Altera_Forum]

I'm not familiar with that specific board, but note that many dev kits don't have a full USB interface. The USB port on many boards is just for the purpose of embedding an USB-Blaster interface. 

 Communication with a PC through an USB-Blaster is very different than a normal USB connection. The FPGA side is one hand easier, you don't need USB drivers. But the PC side is complicated, because there is no docummented way to interface other than with TCL scripts.

[Altera_Forum]

What about RS485? Seems to be implemented in less than a day. 

 I used wxwidgets several times to setup programs to capture Com-Port Data, which is very quick.

[Altera_Forum]

--- Quote Start ---  What about RS485? Seems to be implemented in less than a day.  I used wxwidgets several times to setup programs to capture Com-Port Data, which is very quick.  --- Quote End ---    I second this recommendation. Unless high data rates is a requirement, you'll be better off using simple serial communication over RS-232.   If connectors is a problem, simple USB<->RS232 converters are cheap and plentiful.

[Altera_Forum]

Thanks everybody for your suggestions and comments. 

 The facts are :   - My final objective is to develop a commercial product prototyped and based on the Cyclone III DSP dev. kit design. The provision of an USB port for PC control seems the unavoidable choice for any commercial product nowadays.   - I like the idea of a simple separate USB to RS232 or RS485 converter, but unfortunately the Dev. kit doesn't provide such a simple serial port.   - It's true that the USB port of the Dev. kit is mainly intended for USB-blaster use but the USB fifo chip is fully interfaced to the FPGA which made me think it was also planned for user application purposes.   - Using Ethernet instead of USB is a possibility, but this would appear as a normal choice for the end-user only if it provides the benefits of an embedded web-server. Otherwise, in the case of a simple PC software, USB choice appears as obvious.   To conclude and further to the thoughts you inspired me, I am hesitating between 2 solutions :   1. Continue with an USB + PC software based approach, knowing that no simple pre-made solution exist for low-level communication and that I will have to take care of drivers mostly by myself.   2. Move to an Ethernet + embedded web-server approach.   Does anybody has an opinion on which could be the most simple overall ?   Do you know if an embedded web-server solution (free or paying IP) i.e. based on NIOS core already exists ? (I intend to start a new topic about that).   Whatsoever, I am quite surprised that the control of an FPGA based product from a PC is not a more covered area. I assume this should be a basic common requirement for many companies. This could be an interesting opportunity to provide some new IPs and make money of it...

[Altera_Forum]

--- Quote Start ---  Continue with an USB + PC software based approach, knowing that no simple pre-made solution exist for low-level communication and that I will have to take care of drivers mostly by myself.  --- Quote End ---   The FTDI chip can be accessed through a documented driver interface. I didn't see clearly from the Dev. Kit documentation, how the FTDI parallel interface is routed through the MAX II device and accessible at the FPGA in the MAX II factory configuration, but the reference manual says it's possible.

[Altera_Forum]

On the contrary, every design I have ever done has had an interface to the PC. To date I have used all of the methods discussed here (serial UART, USB, Ethernet). 

 Honestly, if it were me I'd go with Ethernet. Your assumption that this would only be beneficial if it included a web server is in my opinion false. If you decide to go with Ethernet you get to take advantage of all the existing hardware and software in the world that is based on the TCP/IP protocol. Everybody has done the hard stuff for you. You almost don't even have to think about it.  I've got a design that uses Ethernet right now to connect to a host PC. I don't use a web server. I have my own GUI that communicates with the board using my own packet protocol. In addition, users can also control the board via a telnet interface. I can guarantee if it were USB (like my last device) there would be no Telnet, no FTP, no option of a web server.  Ethernet: 1 - drivers and protocol already written for you. 2 - socket API is so simple it hurts. 3 - Take advantage of existing hardware / software (routers, hubs, TCP/IP tools, telnet, FTP, HTTP, etc). 4 - Your device can be located anywhere in the entire world and as long as it's got a network connection, you can interface with it. 5- Consumes more resources (memory) to implement the TCP/IP stack. 6 - Cross platform. Users can be running any OS (Windows, Linux, MAC, Solaris, etc).  USB: 1 - No drivers or protocol written for you. You have to write them. 2 - You write the API. 3 - All you get to take advantage of is the USB cable and the hub inside the PC. 4 - Your device is tied to one and only one PC and is limited by cable length. 5 - Higher bandwidths achievable because the protocol you design will be lighter than TCP/IP. 6 - You have to write a driver for every OS you wish to support.  Serial (RS232) - Well I guess if you want to. Kind of like putting a floppy drive in a brand new PC.  If you need the speed then go with USB. Otherwise, save yourself a few months of development time and use Ethernet.  Jake

[Altera_Forum]

I would immediately follow the ethernet suggestion, with a compact and flexible hardware ethernet stack available as a Megafunction or third party IP. It seems to me, that ethernet is used now almost exclusively by embedded processor applications. Or did I miss something? 

 USB with FTDI chips doesn't require driver programming, at least for Windows and popular Linux OS. The existing driver can be interfaced at the application level with a few lines of code. But it doesn't provide the rich choice of communication options as ethernet, so I basically share your preference.

[Altera_Forum]

--- Quote Start ---  I didn't see clearly from the Dev. Kit documentation, how the FTDI parallel interface is routed through the MAX II device and accessible at the FPGA in the MAX II factory configuration, but the reference manual says it's possible.  --- Quote End ---    Yeah, the documentation about this is extremely unclear.  Jeff, please note the following. Even when the FPGA can access the FTDI interface, it is still not a "standard" USB controller as Cypress or Phillips ones. Go to FTDI website and read about them. The good news, as Franck is saying, is that you don't need to write low levels drivers. Note that it supports USB 2.0, but not HS (high speed).  One problem you might have during development is the conflict with your application and the USB-Blaster interface. If you can afford an external USB-Blaster and wouldn't mind "killing" the embedded one, then you can reprogram the USB VID/PID in the FTDI eeprom. Otherwise the PC would see an USB-Blaster.

[Altera_Forum]

Thanks for all the information. It opens more and more options but it also rises more and more questions. 

 I have now 3 options : USB + control software, Ethernet + control software, Ethernet + webserver.  At the end, I think my product can live with any of these 3 options but further to your comments, I am now a lot in favor of the Ethernet options.  The main issue for me is now to identify THE solution which will be the fastest and easiest to develop (at a reasonible cost but not necessarly no cost).  The ideal situation would be if I can find a comprehensive package including low-level staff (drivers, stacks, etc...) on both PC and FPGA sides as well as some templates of web server or control applications which I could simply adapt/enrich to make my own.  In other words, since I am more an FPGA developper than a software developper, I would highly prefer to start from a working ensemble and modify it rather than trying to build or assemble a new one (unless it is quite straight forward without unknowns).  Thanks to all your tips, I have now identified the following potential solutions :  - USB approach http://www.slscorp.com/pages/ipusb20sls.php  - Ethernet approach http://www.altera.com/support/exampl..._tutorial.html (http://www.altera.com/support/examples/nios2/exm-micro_tutorial.html) http://www.iniche.com/nios.php http://www.sics.se/~adam/uip/index.php/main_page http://www.micrium.com/products/tcp-..._download.html (http://www.micrium.com/products/tcp-ip/tcp-ip_download.html)  For those having experience in some of these and knowing now my target (find a ready-to-use/modify or straight forward and simple comprehensive solution), which one of the above options would you recommend ?   Note : this message was also posted in "Embedded web-server in FPGA" thread since it overlaps both threads.