Serial communication with RS 232 USB Emulator, AGX Xavier

[shravan.anand007]

Hi,
How can i send serial coomands to this device using python

Bus 001 Device 004: ID 04d8:000a Microchip Technology , Inc. CDC RD-232 Emulation Demo

[linuxdev]

I’m not a Python guy, but this is fairly standard and Python should not change how this works. Here is some background which might help…

The device is a serial UART, and each side of the cable has another serial UART. Both UARTs must run at the same settings, e.g., both are probably set by default as speed 115200, 8-bits, no parity, and one stop bit. The result of having the driver run for a UART is the existence of the device special file. Examples: “/dev/ttyUSB0” for the first FTDI brand chipset (numbers increment if there is more than one), “/dev/ttyS0” if using an older 16550A compatible chip (which is what serial console normally does when exposed to individual header pins, but this differs when exposed via USB), or some other name scheme. The name is irrelevant other than giving clues as to which driver and chipset are used. The CDC name makes me believe the device special file would be something like “/dev/ttyACM0” (because this is a manufacturer of serial UARTs).

Once these devices are paired you simply treat the device special file as an ordinary file to read or write to. You would simply use something like an “open('/dev/ttyACM0', 'r')” for reading, or with a “'w'” for writing, or you could open read-write. Then print to that file, or read from that file.

Note that if you monitor “dmesg --follow”, and then plug in the USB side of that device, the logs should tell you about what device special file name is used, or if it is missing a driver it’ll just note plug-in but not provide more details. It is highly likely it would “just work”, but you can always ask more questions if not.

[shravan.anand007]

There is no dev file name, how can get the drivers.
or
where can i find cdc-acm my kernal version is 4.9.201-tegra.

[linuxdev]

If you run the command “dmesg --follow”, and then plug in the device, what log lines show up from the plug-in? Normally the cdc-acm is is already present. To verify, what do you see from:
zcat /proc/config.gz | grep '_ACM'

I would expect the above to result in something like this:

# zcat /proc/config.gz | grep '_ACM'
CONFIG_USB_ACM=m
CONFIG_USB_F_ACM=y
CONFIG_USB_CONFIGFS_ACM=y

[shravan.anand007]

dmesg --follow shows the device
[ 112.678429] usb 1-4: USB disconnect, device number 3
[ 114.803847] usb 1-4: new full-speed USB device number 4 using tegra-xusb
[ 114.827269] usb 1-4: New USB device found, idVendor=04d8, idProduct=000a
[ 114.827279] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 114.827284] usb 1-4: Product: Qioptiq Imaging Controller
[ 114.827287] usb 1-4: Manufacturer: Qioptiq, Inc.

and this is as expected
$ zcat /proc/config.gz | grep ‘_ACM’
CONFIG_USB_ACM=m
CONFIG_USB_F_ACM=y
CONFIG_USB_CONFIGFS_ACM=y

but i have installed an cdc-acm driver of kernal version 4.4.38-tegra, this shows as ‘Exec format error’ when i use modprobe.

[linuxdev]

You already have ACM supported. Installing a driver from an outdated and incorrect release will cause an error. Also note that “Exec format error” means the driver you added is also for the wrong architecture. Where did you get the module for the 4.4.38-tegra release? I suspect this is so old it might be from a 32-bit ARM system, which is armhf, but you need 64-bit aarch64/arm64 (but that is only if the feature did not already exist…adding this in addition to already having this would have unpredictable consequences).

Looking at the actual logs I can identify idVendor 04d8 as “Microchip Technology, Inc.” (which is a common supplier of UARTs), and the specific idProduct 000a as “CDC RS-232 Emulation Demo”. I don’t know if this is enough to identify the device for the driver or not, but I don’t see a log saying the device tried to load a driver.

The first step though is to determine if your driver you added has overwritten the “CONFIG_USB_ACM” module which was previously present. If so, then you will probably have to repair the module content. The driver which you added would have to be removed since you already had the driver and the “new” driver (the old and incorrect architecture driver) would have to be removed.

If it turns out that the only issue is the driver not identifying itself as using the ACM driver, then the typical way of handling this is with a udev rule. udev is typically used to perform tasks like renaming a device special file, or adding a symbolic link in “/dev” which points at a default name. A typical example of when this is done is if a manufacturer uses a “standard” device, but has the USB identify the device with the actual vendor’s name for marketing purposes. Then udev could be used to trigger upon insert of the “custom” name via USB, and create an association with the “standard” driver to the “custom” name.

Do you have a URL for this emulation demo hardware? I am curious if they show a udev file in their “driver”. You could not use the actual incorrect armhf driver, but you could still use the udev file for association.