In fact there is no "simple" way to handle USB.In fact the USB "Function" is a different layer from the USB "Hardware". These need to be handled separately (e.g. you can use the same USB connector hardware to attach to multiple functions in your device, even several at the same time.) Why do you think, you need to write a driver ? Seemingly you want to do an USB device interface in your design. Do you have appropriate "Device-Site" or "On The Go" hardware ? For such hardware, an USB "hardware-layer" driver should be available. On top of that, you need to handle the basic USB protocol and connect your software to the USB data stream. I suppose you should be able to find a driver in source code that creates a TTY device from the USB device function. Now your user land software can use this to deal with the "user"- byte stream to and from the PC. (Again, in Linux a TTY device is a "file" :) .) To make the PC see the device (e.g. as a serial device) your device needs to provide an appropriate vendor and device ID to the PC, and (supposing your PC runs Windows) you need to install a file that makes the OS load the standard USB-serial-device driver for this device when seeing these IDs. Other Standard USB device types are "Storage-Media" and "Ethernet", but I suppose handling those is a lot more complicated that "serial". Even more demanding is defining your own USB device type. Here you would need to write a propriety Windows USB driver to access your device. -Michael
If a gadget serial (tty) solution will solve your porblem (Im not sure I understand exactly what your're trying to do), then Michael is correct in approach. However, in my experience, the gadget serial interface has not worked well and usually not at all, since the old Microtronix distribution. It is also worth mentioning that we believe all of the currently supported USB chips (nios linux dist) are on a "last time buy" status. We have recently migrated all of our designs to a Host/device (IP) pair from SLS and are using there drivers, including dadget_serial. All work well in the nios environment. I am aware that there has been some recent work on the USB drivers (isp116X, and 136X) if the device side is now working with these, then I apologize in advance. But please note that these chips are among the group that we've been told are going away.
If you just want a serial 'console' port, there are 'cables' that convert 3.3v TTL rs232 data to USB (USB host one end, 6 pin 0.1" pitch the other). With an appropriate host (eg PC) driver the will give serial access via USB.'Interestingly' linux may come with a driver (my one did), but windows may need one downloaded!
--- Quote Start --- there are 'cables' that convert 3.3v TTL rs232 data to USB (USB host one end, 6 pin 0.1" pitch the other). With an appropriate host (eg PC) driver the will give serial access via USB. 'Interestingly' linux may come with a driver (my one did), but windows may need one downloaded! --- Quote End --- I just ordered a couple of the FTDI JTAG-to-UART cables ($26 each); http://search.digikey.com/us/en/products/c232hd-ddhsp-0/768-1011-nd/2767783 http://search.digikey.com/us/en/products/c232hd-ddhsp-0/768-1011-nd/2767783 They both show up as Virtual COM ports under windows, and as USB UARTs under Linux. The MPSSE modes can be accessed via the closed-source FTDI drivers (Windows or Linux), and via libusb and libftdi. Cheers, Dave
--- Quote Start --- But please note that these chips are among the group that we've been told are going away. --- Quote End --- I suggest using a Microchip PIC24 chip for this. It's cheap, needs only very little power, has a built-in USB OTG MAC and Phy, comes with Software for USB host and device, provides SPI master and slave in hardware to connect to the Linux system, and comes with (e.g.) "USB-serial" "driver" (a simple text file) for Windows. They also have a pre-programmed USB-Serial chip but IMHO SPI is more appropriate for this purpose and being able to implement some of your own software functions in the interface chip often makes a lot of sense. Of course there is much more stuff you can use this chip for: - System Watchdog (it provides it's own internal hardware watchdog) - Analogue input (at least watching the power supply always makes sense) - providing low level device history statistics - multiple UARTs - System udate (reprogram the SPI Flash chips (for FPGA content and/or Linux boot - ... -Michael (we are using PIC24 in that way)
Hello,I have a question about the windows side driver for a gadget serial. I know it is just an .inf (text file) to bind the VendorID DeviceID couple to usbser.sys but... I am quite sure to have seen demos of devices that were able to be recognized by Windows even without that file. Were these devices telling a lie (they told to be an FTDI chip, for example)? Is it possible to tell a combination of VendorID/DeviceID which is generic without infringing any law? Thanks in advance to anyone that helps. Regards, Gabriele PS: I am quite sure to have seen this kind of thing but owing to the lack of memory about which device I suspect I may be confused. I also think that those demos may have tricked me in a simpler way: maybe the binding was made by a previous demo (it may also be by another device that told the same couple of IDs).