Sending data from TK1 to x86 via USB


I want to connect the TK1 board running ubuntu to an x86 PC running windows.
The goal is to send/receive data via USB.

Does the ubuntu image has a USB driver for this purpose ?

If not, is it possible to develope such driver ?

Thank you,

The serial port would be able to do this without any special setup. The trick is whether the speed is fast enough. Ethernet would be far faster and simpler, and would not be much more to deal with than a serial port.

Ubuntu handles USB like most any other operating system, though it is probably easier to build custom hardware based on Linux due to the open source framework. You would need to understand the nature of USB though if you want to do it in a reasonable time. Once you start talking USB you need to start considering more about the nature of your data. USB is not just a simple pipe with two-way data.

Are you willing to develop a driver on the Windows side as well? If not, then you have to use a predefined and standardized generic USB device class. Examples of predefined device classes would be human interface devices (HID), such as keyboards and mice…these have a standardized interface the devices must follow (but the host does not need a special driver specific to each keyboard/mouse brand and model). USB video is another…thus the name prefix “uvc” in some video device special files. Mass storage is another generic class…basically something you plug in and it looks like a hard drive. You may find associated with each of these a different “transfer mode”…something streaming live audio or video would use isochronous mode, which is a guaranteed bandwidth for real time data; something like a hard drive would use bulk transfer mode, and the device would need the ability to stop and start…basically pausing at will. So to know about USB development you have to know about what your device will appear as…and also how its data will be treated. If you use serial port or ethernet, then you don’t have those requirements. Other USB devices can be created, but then you need a custom driver at both ends.

So…what kind of use case do you have? Are you interested in a standardized device? What kind of data requirements are there, especially with regards to real time requirements?


I understand that the USB 3.0 port can be a USB host.
Is there a device driver + user driver or I have to develop one ?

On the x86 I have to develop a USB device driver also.

There are no real time requirements. Upon sending a message from the Tegra I want the x86 to get an interrupt. Then, the application will read the received message.
The message size is up to 1MB sent every 20 msec.

What do you mean by “standardized” device ?
My goal is to use a WinDDK example and add some modifications.

Thank you,

USB implies one end will be a host, the other will be a device. The host is in control. The JTK1 micro-USB connector is type “On The Go” (OTG), so either a micro-A or a micro-B connector will fit…if it is a micro-A connector, then the connector will behave as a host and you can plug in normal stuff, e.g., keyboard or mouse. If the connector is used with micro-B, then then the Jetson becomes a device (no specific device is programmed, so unless you set it up, device mode is inert with the exception of recovery mode…recovery mode is a custom device in device mode). It sounds like you want the Jetson to be a device.

When the host queries the device (when Windows asks the Jetson what it is via the micro-B connector), the device can respond with some pre-existing device templates. In order to keep every device in the world from needing its own specialized driver, a generic USB interface was created for known common devices. One class is human input device, or HID. If you have a keyboard, mouse, or game controller, and if it implements a standardized interface for this, then the host does not need to search for a brand-specific driver. Similar examples would include a video device following USB Video Class template, or a hard drive following the Bulk Storage class template. Because your device will not follow a common template for a known class, it is custom. See:

When a device plugs in to a host, the host sees this event and enumerates…which means it asks the device what it is. Your device will respond with a custom device ID, and not with a standardized type. An event of plugging in of this device ID will generate a message within the host’s kernel to announce the device, and a driver which knows this device (which you will write) will claim ownership.

On the device side you will need to detect a type-B connector (OTG can use type-A or type-B). When seeing a type-B connector (when Jetson gets a type-B insert event), any query by the host will need a Jetson reply with standard USB information. Part of that information will be this custom ID. Everything that follows will be your code as a Linux kernel driver taking ownership upon type-B insert event, and your code within the Windows kernel driver taking ownership upon enumeration of that ID insert event…USB just becomes a pipe, everything else is built by you.

You will need to implement your drivers to work in some particular transfer mode, presumably one of isochronous, bulk transfer, or interrupt mode. I’m guessing you would be interested in interrupt mode.

The gadget interface is an aid to rapid prototyping of the pre-existing device classes. If you are building your own brand of some generic device, this would apply to you:

Since your device is custom, this will not apply; however, the information is still correct, except your template won’t be one of those known classes. You’ll basically be writing for a gadget, and then you’ll also need to create the gadget code itself since your device is custom. Since you are interested in interrupts, the closest device type to start with is the HID class for keyboards.