I don’t have a way to look at this, but ttyACM is a serial UART device special file. When a driver loads which can handle this UART a file in “/dev/” will be created (it’s really in RAM and talks to the driver). Different UARTs might use different device naming conventions, e.g., a lot of them will create a “/dev/ttyUSB” file, especially the FTDI chipsets. Some manufacturers will use that driver, but create a “udev” rule to rename the device. I wouldn’t be surprised if you get a “/dev/ttyUSB#” file which just needs the “udev” rule to rename it, but I also wouldn’t be surprised if the driver itself was just left out.
On a related note, if the device is plug-n-play (which includes USB), then some manufacturers put in their own IDs even if the generic driver works for the hardware. At this point you’d need whatever “driver” relates that ID to the generic driver. Lots of variations on that.
A good place to read about ttyACM is here:
http://www.jetsonhacks.com/2017/11/19/install-ttyacm-module-nvidia-jetson-tx-development-kits/
I suspect there is just something needing install…either a user space package with a udev rule, or a kernel module to act as a driver (or both).
As an aid while you explore this, take a look at how to examine your running kernel’s configuration list:
# A scrollable and searchable list:
gunzip < /proc/config.gz | less
# A case insensitive list of anything "acm":
gunzip < /proc/config.gz | egrep -i 'acm'
Note that if you have these, then you have kernel support (but may require another package for a udev rule or to link a custom device to the default driver):
CONFIG_USB_ACM=m
CONFIG_USB_F_ACM=y
CONFIG_USB_CONFIGFS_ACM=y
An entry with “=y” is built into the kernel. An entry with “=m” is configured as a module, and would be located somewhere in a subdirectory of “/lib/modules/$(uname -r)/”. A prefix of a hash mark ‘#’ implies the feature was not enabled.