How to implement USB on the SOM?

[MrJackHamilton]

I am looking for examples for how to implement USB on the SOM RT Side.

It is not clear if low-level I/O is performed on the FPGA side and the upper layer control is done on the RT side?

Or is there a method to implement USB directly on the RT?

Any example would be appreciated.

Regards

Jack Hamilton

[Spex]

Hi Jack,

When you ask for examples, are you looking for example software/applications that demonstrate how to access USB? Or are you looking for hardware reference designs describing how to build a carrier board to expose the USB peripheral ports?

If the question is focused on software, what are you connecting to the SOM? I'm assuming you are using the Development Kit reference carrier?

The USB controller is on the RT processor subsystem of the SOM, so it is accessed from LabVIEW RT or C/C++ running on the processor.

-spex

[MrJackHamilton]

Spex,

Looking for Software examples.

Thanks, Regards

Jack Hamilton

>

National InstrumentsCommunity

<https://decibel.ni.com/content/index.jspa>

>

Re: How to implement USB on the SOM?

created by Spex <https://decibel.ni.com/content/people/Spex> in

/Hardware Developers Community for NI Single-Board RIO and System on

Module/ - View the full discussion

<https://decibel.ni.com/content/message/96026#96026>

[Spex]

"what are you connecting to the SOM?"

The most straighforward example is a USB thumbdrive.  If you plug in a thumbdrive, it enumerates as a /u or /v drive.  From that point, the File IO examples/functions work the same as if running on a PC or as accessing a local drive.  The example finder (Help>>Find Examples) will have a variety of example implementations for various file IO needs.

Beyond file IO, the example becomes more specific to what you are plugging in.  What ever you plug in will need a Linux driver and an API to be accessed from LabVIEW or C/C++.  The version of the Linux kernal on the SOM is tweaked for real-time performance, so not all drivers found online will necessarily work out of the box.  A community group focused on SW support and extensions for Linux RT is also available.  Here is the page in that group that focuses on various USB devices connected to Linux RT: https://decibel.ni.com/content/docs/DOC-37389

-spex

[MrJackHamilton]

Spex,

I wish to create a Peer-to-peer connection between my SOM and the outside world via USB. I would create an LabVIEW application on my host PC to connect to and communicate with the SOM. This is only for device R&D testing at this time.

It appears that I can do this via VISA USB control VI's on the RT. I was able to create a VI under the RT and drop the VISA USB control functions. So this looks promising. I am new to RAW-VISA-USB-LaBVIEW so I am not sure if this will force a connection to occur. From what I read on USB Visa; the OS is expecting the device (Driver) to already exist on the OS (RT) and make calls to it.

Question 1?

I am not sure what is the VISA 'address' specifier for the native USB port on the (SOM) RT. If I can create a connection to the native RT USB, than I can send data in an agreed format of my choosing between the SOM and my host application.

Question 2?

I am not seeing an immediate examples of peer-to-peer USB and LabVIEW, I've done this with Serial, parallel and Ethernet. but I'm not sure how much of that will translate to the USB.

My other route would be to load the FTDI USB-Serial driver on the RT and configure the USB as a serial port. There is much to read on RAW USB and I will post my findings here.

Any thoughts is appreciated.

Regards

Jack Hamilton

[Kevin_Hooper]

Hi Jack

I have been looking at a similar requirement for SOM FPGA peer to peer data streaming.

So I will interested to see what you achieve.

The obvious solution was the secondary Ethernet which is routed through the FPGA.

Unfortunately, my FPGA skills are insufficient - hence why I am using LabVIEW FPGA.

My best solution uses SOm with FTDI FT2232 configured for parallel FIFO over USB.

I achieve 35MByte/second continuous data streaming to PC host writing to TDMS file.

Regards

Kevin

[Spex]

Ahh, OK. Now we are starting to get on the same page.

USB is designed as a host/device or master/slave interface, rather than a peer-to-peer bus.  Most of the peer-to-peer implementations of USB that I have seen (such as PC transfer cables), emulate an Ethernet network between two USB host controllers. 

The VISA USB raw VIs you are looking at support the SOM acting as a host, communicating to a device.   It is rare that you will find a PC that is capable of being a USB device, so the VISA USB raw VIs are probably not going to help. Ideally, if you want to connect to a specific USB device, you would find and load a Linux driver for the device with a dedicated API, rather than attempting to mimic a dedicated device driver with VISA USB raw. 

If you reverse roles and consider a PC the host and the SOM a device, then NI supports a specific set of capabilities.  In this configuration, the USB device port on the SOM is detected by the PC host as a network interface (NIC).  The SOM NIC automatically assigns IP addresses to both the SOM and the host PC within a dedicated range.  After the network is configured by SOM, you can treat the USB interface between PC and SOM as a standard Ethernet network, with support for TCP/IP, UDP/IP, etc. 

The primary intention for this USB Device/Ethernet communication path is configuration and commisioning of the SOM device, rather than dedicated long-term peer-to-peer communication, so I don't have benchmark performance metrics for the streaming capability of this interface. 

As an aside, @Kevin_Hooper ... The SOM shouldn't require any additional or specific FPGA skills to enable the secondary Ethernet port through the FPGA.  The sbRIO CLIP Generator is able to enable the secondary Ethernet port and the FPGA routing requirements with a couple clicks.  The SOM Reference Carrier board also demonstrates the hardware design and FPGA/CLIP SW for enabling the secondary port. 

-spex

[Kevin_Hooper]

I think we have a different definition of FPGA peer to peer data streaming.

My definition means a method of high bandwidth data transfer with minimal

SOM ARM processor overheads.

In my application, the SOM is receiving and processing a 35MByte/second data stream.

The processing results in a slower data stream of ~3MByte/second. I would like the optionto log raw and processed data together.This becomes valuable when trying to debug implementation and algorithm

issues.Currently, I failed to get the SOM to stream 35MByte/second data over its Gigabit Ethernet.

I suspect the issue is the SOM ARM processor is too busy moving data between loops and

running its TCP/IP stack. I guess my issue is not obvious as my NI service request on this

topic is still open.

[Spex]

That makes sense.  I wasn't considering the FPGA data source In your scenario.  There is overhead in translating your data from the FPGA, through the processor, and onto the Ethernet bus.  Even when the second Ethernet port is configured 'through the FPGA', the MAC is connected directly to the processor.  Just the data lines from the MAC to the PHY are routed through the FPGA fabric when enabling secondary Ethernet.

For direct from FPGA streaming, a hardware interface that connects to the FPGA will be the lowest overhead implementation.

-spex