Showing results for 
Search instead for 
Did you mean: 

Do I have any control of the USB-C ports on a cRIO-9053?

Wondering if it's possible to communicate to another device out of the USB-C ports on a cRIO-9053. Meaning, can I use SPI or I2C protocols on the usb ports?


More specifically, I want to connect a master device to the cRIO's USB-C port and request data from the cRIO. Possible?

0 Kudos
Message 1 of 6

USB is not I2C or SPI so no without an external USB to I2C or SPI hardware adapter you won't be able to use that port as such.


For the rest it is all very vague. Your first sentence sounds like you want to talk to a device connected to that USB port. The second question sounds like the opposite where you want the USB C port on the cRIO to be a device interface that an external master can control. What master device? How?


If you can explain in more detail what you really want to do we may be able to help with some real suggestions. Right now it sounds like you ask some random questions without even knowing yourself what you really want.


The default usage of that USB C port on those controllers is to use it as a more modern form of Display Port interface for an external monitor. It's not the only possible usage for USB C ports but using USB ports for random hardware connections is something that has never been possible. USB is too complex to use it through generic interfaces. There is always some specific system driver needed that talks the actual protocol of the device that is connected to the USB port and USB C has made that only even more complex and not just by a percentage but by at least a magnitude if not more.


Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 6

We have a WiFi dongle that we designed that we want to use to connect the cRIO to the internets. The wifi dongle would request information from the cRIO and then send that data off to the database.


Right now the dongle communicates over RS232, and it would be easiest if we could communicate through the USB port of the cRIO and use an adapter to convert it to RS232. I assumed USB was just the hardware protocol, and can use something like I2C or SPI over it (I'm still learning comm protocols). But I don't think that's all that important. The important part is, can I even communicate through the USB ports period. Do I have any sort of control over them.


If this is not feasible/not worth it, then we will just have to add ethernet capabilities to our wifi dongle.

0 Kudos
Message 3 of 6

Without a kernel driver on the cRIO that talks your dongle protocol (whatever that is) and translates it into something useful on the cRIO for the NI Linux OS, I would not see how that can be useful. Something specific for your dongle has to be present in the Linux OS and be prepared to connect to your dongle when it is attached. So do you have a Linux kernel driver for your dongle? Do you have a driver at all for your dongle (Windows, whatever)?

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 6

Probably too late for the OP, just posting here in case others find it useful. I've been able to communicate with serial devices (a USB sensor that enumerates as a FTDI serial device, and an RS485-USB converter) over the USB-C port of a cRIO-9053 by just installing the FTDI serial module with 'modprobe ftdi_sio' per this document:


The port is then available in LabVIEW if you have the VISA drivers installed on the cRIO, or you can use the usual Linux tty devices to access it if you are writing a Linux app. On top of this I am writing the LabVIEW driver but you may find drivers already available for your device.


The slightly more involved part is getting the ports to be installed on startup each time; I am doing this via an init.d script:




# Provides:

# Required-Start: $all

# Required-Stop: $all

# Default-Start: 2 3 4 5

# Default-Stop: 0 1 6

# Short-Description: Load USB serial device driver and environment sensor IDs at boot time



modprobe ftdi_sio

echo 0590 00d4 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

echo "Installed environmental sensor"


This is far from perfect since it runs on any state change such as shutting down. It can be refined - I wanted it simple for now; there are templates for full init.d scripts widely available.


The final part is getting the ports to be identified consistently in LabVIEW on startup each time; I don't have a solution for this yet. 

0 Kudos
Message 5 of 6

In recent NI Linux versions (~LabVIEW 2018 or newer) the FTDI chips are by default recognized by the installed FTDI compatible driver. There should not be any need to execute special commands anymore. In earlier versions, depending on the actual serial device you had to edit the udev and before 2014 the mdev configuration to load a specific driver for certain USB serial port devices. Stock FTDI should usually work even there. 


Your specific device does use a FTDI chip but with custom manufacturer and product ID. Since these two are the way Linux and any other OS identifies USB devices, and it is not a standard device contained in the according USB device ID database that was included with the build of your USB subsystem, you have to hold hands for Linux and tell it manually what driver these product and manufacturer ID should map to. This is what the documentation in the Omron documentation explains. This works since the hardware really is an FTDI RS232 compatible chip and since the Linux OS contains such a driver already, it just doesn't know that it should use that driver for this device.


For other hardware, things are usually a bit more complex, especially if it is self made hardware. If you are lucky there is a ready made stock driver for the hardware chip you used on the board and you just have to make sure that driver is installed and then tell Linux that your manufacturer and product ID map to that driver.


Another less convenient situation is if there is a Linux driver in source code for the chip but it is not a standard Linux driver and hence not included in standard kernel distributions, that the NI Linux kernel tracks indirectly through the upstream repositories. In this case you have to compile the driver yourself for the NI Linux target in question, install it on the target according to the build scripts for that driver and possibly map it also to your specific manufacturer and product ID, if you customized them.


If you don't have the ready made source code for a driver, you have to write it yourself, which only is possible if you have the low level chip documentation and you also need a bit of courage. Kernel driver development is not for the faint of heart!


If your device doesn't have a driver tracked in the main kernel, or the source code for a working driver is not available to compile it yourself for the RIO hardware, or you can't get the low level documentation for the hardware and write a driver yourself or hire someone to do so, you can consider your piece of hardware a nice decoration object on your desk as far as using it with a NI RIO device or any other non-mainstream Linux platform is concerned. For specific Linux desktop distributions, the hardware manufacturers may sometimes provide precompiled drivers, but if you ask such a manufacturer about a myRIO (or cRIO) compatible driver you will at best get a bewildered "For What??" or simply a blank star.

Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 6