Dev ttyacm0 что это
Hекоторые девайсы типа модемов детектятся как /dev/ttyACM0, некоторые — как
/dev/ttyUBS0.
Какой в этом глубокий смысл вообще (то есть для чего это сделано) и смысл с
точки зрения драйверов?
Nickita A Startcev
2014-06-02 17:40:10 UTC
02 Jun 14 , 19:33 Dmitry the Zuryanovich писал к All:
DtZ> Hекоторые девайсы типа модемов детектятся как /dev/ttyACM0, некоторые
DtZ> — как /dev/ttyUBS0.
DtZ> Какой в этом глубокий смысл вообще (то есть для чего это сделано) и
DtZ> смысл с точки зрения драйверов?
ttyUSBx — это симуляция компорта со всеми извратами типа битовой скорости,
RTS/CTS/etc. в общем, натягивание дохлой совы-компорта на жирный глобус USB,
причем со всякой проприетарной порнографией в формате посылок и с странными
ограничениями скорости.
ttyACM — это просто поток байтов точка-точка. бред типа битов состояния звонка
и битов (не)готовности и (не)желания приемопередавать выкинуты, ибо
(не)подтверждение приема уже есть на уровне усб-стека.
. С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
. А лицо у него было не очень физическое
В чем глубинный смысл ttyACMx?
Сабж. Прочитал несколько статей на тему разницы ttyUSBx и ttyACMx.
Как я понял, ttyUSBx это UART, подключенный на usb. А ttyACMx это нечто, прикидывающееся модемом, и вовсе необязательно ведущее себя как uart.
Т.е. вроде как tty* != uart. Или не так? зачем это сделано? Кому сейчас нужны реальные терминалы, чтобы ради них городить tty? причем так, что uart кроме как через tty недоступен. И к тому же не всякий tty это uart.
Например, в QNX, емнип, нет /dev/ttyS0, а есть /dev/ser1, который именно uart, без всяких tty заморочек.
Да, насколько я помню, tty* можно использовать так, чтобы он ничего не вставлял лишнего, а сразу гнал данные в порт. Но зачем вообще тащить это наследие времен, когда компьютеры были большими?
Перемещено mono из talks
cvs-255 ★★★★★
06.12.14 02:02:39 MSK
← 1 2 →
фиг знает. Сам давно отказался от этого в пользу /dev/serial/
demidrol ★★★★★
( 06.12.14 02:39:16 MSK )
Ответ на: комментарий от demidrol 06.12.14 02:39:16 MSK
Это где /dev/serial/?
cvs-255 ★★★★★
( 06.12.14 03:06:19 MSK ) автор топика
Ответ на: комментарий от cvs-255 06.12.14 03:06:19 MSK
в линуксах, где есть udev.
$ find /dev/serial/ /dev/serial/ /dev/serial/by-path /dev/serial/by-path/pci-0000:00:14.0-usb-0:2:1.0-port0 /dev/serial/by-id /dev/serial/by-id/usb-Silicon_Labs_CP2103_USB_to_UART_Bridge_Controller_0001-if00-port0 demidrol ★★★★★
( 06.12.14 03:08:25 MSK )
Ответ на: комментарий от demidrol 06.12.14 03:08:25 MSK
У меня есть udev. /dev/serial нету. Напиши, какие там файлы устройств?
cvs-255 ★★★★★
( 06.12.14 03:21:10 MSK ) автор топика
Ответ на: комментарий от cvs-255 06.12.14 03:21:10 MSK
там нет файлов устройств, только симлинки на них. Проверил — вроде и в дебиане анстейбле, и генте имеется.
demidrol ★★★★★
( 06.12.14 03:23:08 MSK )
Ответ на: комментарий от demidrol 06.12.14 03:23:08 MSK
На какие устройства линки?
cvs-255 ★★★★★
( 06.12.14 03:33:16 MSK ) автор топика
Ответ на: комментарий от cvs-255 06.12.14 03:33:16 MSK
ну, вроде на /dev/ttyUSB*, но если мне память не изменят, там же и /dev/ttyACM* оказывались.
demidrol ★★★★★
( 06.12.14 03:57:07 MSK )
Ответ на: комментарий от demidrol 06.12.14 03:57:07 MSK
т.е. это те же самые tty.
cvs-255 ★★★★★
( 06.12.14 03:59:39 MSK ) автор топика
Все очень просто.
ttyACM — это стандартный USB CDC ACM.
ttyUSB — это проприетарный протокол, похожий на USB CDC ACM, но с расширениями и модификациями.
Соответственно и драйверы разные для них.
alexru ★★★★
( 06.12.14 07:49:32 MSK )
Последнее исправление: alexru 06.12.14 07:53:05 MSK (всего исправлений: 1)
Ответ на: комментарий от alexru 06.12.14 07:49:32 MSK
О, хоть кто-то просветил!
А то я сильно матюкался, когда мой микроконтроллер вместо /dev/ttyUSBx определился как /dev/ttyACMx.
Ну, в принципе, теперь все ясно: если у тебя что-то вылезает на /dev/ttyUSBx, ты не можешь никаких ioctl’ов применить, кроме tty’шных. А на /dev/ttyACMx можешь.
А в остальном — те же яйца, только в профиль.
Eddy_Em ☆☆☆☆☆
( 06.12.14 08:14:26 MSK )
Ответ на: комментарий от Eddy_Em 06.12.14 08:14:26 MSK
Микроконтроллеры определяются как ttyACM потому что какой им смысл поддерживать FTDI, SiLabs и еще черт знает кого. Да чтобы потом FTDI-ные дрова убили устройство как недавно случилось.
Я бы хотел найти аналог FTDI, но поддерживающий CDC ACM, но чего-то пока не видать.
alexru ★★★★
( 06.12.14 08:41:27 MSK )
Ответ на: комментарий от alexru 06.12.14 08:41:27 MSK
Это чего за страшилка?
Eddy_Em ☆☆☆☆☆
( 06.12.14 08:58:59 MSK )
Ответ на: комментарий от Eddy_Em 06.12.14 08:58:59 MSK
Если кратко, то FTDI выпустил драйвер (для винды), который делает хитрую попытку записи 0 в EEPROM на месте PID, но операцию не завершает. Это игнорируется настоящими чипами, но убивает клоны.
FTDI уже пожалели об этом и извинились, но поздно метаться.
alexru ★★★★
( 06.12.14 09:04:18 MSK )
Ответ на: комментарий от alexru 06.12.14 07:49:32 MSK
А нет возможности увидеть девайс как uart порт, в который пишешь байт — и в порт улетел байт. Без всяких там протоколов?
cvs-255 ★★★★★
( 06.12.14 11:38:31 MSK ) автор топика
Ответ на: комментарий от cvs-255 06.12.14 11:38:31 MSK
Hу так /dev/ttyACMx и /dev/ttyUSBx дают такую возможность. Но чтобы байт «улетел» на нужной скорости порт нужно конфигурировать.
alexru ★★★★
( 06.12.14 11:45:42 MSK )
Ответ на: комментарий от alexru 06.12.14 11:45:42 MSK
Выставить baud rate, что там еще делать?
Во всяких МК, когда нужно на uart что то вывести, записываешь baudrate, после чего выводишь побайтно данные в регистр порта, и они выводятся на порт.
Почему в линуксе надо не так? Символьное устройство с ioctl, задающим скорость и всякие там стоповые биты и четность.
cvs-255 ★★★★★
( 06.12.14 12:07:09 MSK ) автор топика
Последнее исправление: cvs-255 06.12.14 12:10:20 MSK (всего исправлений: 3)
Ответ на: комментарий от cvs-255 06.12.14 12:07:09 MSK
Число бит данных, стоповых бит, бит четности и контроля потока.
Те драйверы больше ничего особо и не позволяют делать. Все остальное — как запрашивалось, послали байт, получили байт на выходе.
alexru ★★★★
( 06.12.14 12:10:37 MSK )
Ответ на: комментарий от alexru 06.12.14 11:45:42 MSK
Hу так /dev/ttyACMx и /dev/ttyUSBx дают такую возможность.
Ох, как я на днях задолбался, пытаясь установить скорость 250000 на /dev/ttyACM0 устройства, которое точно поддерживает эту скорость.
cvs-255 ★★★★★
( 06.12.14 12:11:39 MSK ) автор топика
Ответ на: комментарий от cvs-255 06.12.14 12:07:09 MSK
Можно, почему нельзя. Нужно узнать по какому адресу находится контроллер UART, mmap-нуть этот адрес в пространство процесса. После этого контроллер будет доступен как набор регистров.
alexru ★★★★
( 06.12.14 12:13:17 MSK )
Ответ на: комментарий от alexru 06.12.14 12:13:17 MSK
Только это естественно для железного COM-порта.
alexru ★★★★
( 06.12.14 12:14:32 MSK )
Ответ на: комментарий от alexru 06.12.14 12:14:32 MSK
А какие еще бывают com порты? Вот у меня есть железка с ардуиной, в ней usb com порт для связи с компом. Вполне себе «железный»
cvs-255 ★★★★★
( 06.12.14 12:14:57 MSK ) автор топика
Последнее исправление: cvs-255 06.12.14 12:16:10 MSK (всего исправлений: 2)
Ответ на: комментарий от cvs-255 06.12.14 12:14:57 MSK
Виртуальные через USB. О них в этом топике и идет речь.
alexru ★★★★
( 06.12.14 12:16:20 MSK )
Ответ на: комментарий от cvs-255 06.12.14 12:14:57 MSK
У ардуино стоит отдельный преобразователь USB-UART. Так что ищи комп с COM-портом и будет как в ардуино.
Только и с ардуино придется выкинуть преобразователь и подключать UART напрямую к компу (через преобразователь уровней RS232).
alexru ★★★★
( 06.12.14 12:17:31 MSK )
Последнее исправление: alexru 06.12.14 12:21:18 MSK (всего исправлений: 1)
Ответ на: комментарий от alexru 06.12.14 12:16:20 MSK
Чем он виртуальный? Как виртуальность зависит от того, на какой шине висит порт?
cvs-255 ★★★★★
( 06.12.14 12:29:16 MSK ) автор топика
Ответ на: комментарий от alexru 06.12.14 12:17:31 MSK
Зачем мне это? Почему нельзя нормально работать с портом на usb, а не через изврат с патченой pyserial, которая таки может перевести этот tty в нужный режим?
cvs-255 ★★★★★
( 06.12.14 12:34:25 MSK ) автор топика
Ответ на: комментарий от cvs-255 06.12.14 12:29:16 MSK
Потому что настоящий COM-порт цепляется к настоящему контроллеру UART, нет тут никакой шины. Виртуальный порт — это имитация. Те-же байты пакуются в кадры и передаются по USB и могут быть приняты только по USB .
Схема до USB: PC UART — RS-232 — кабель — RS-232 — МК UART. Схема ардуино: PC USB — USB кабель — мост USB-UART — МК UART.
Соответственно UART на стороне PC больше нет и работать с байтам «как на МК» уже не выйдет.
alexru ★★★★
( 06.12.14 12:35:44 MSK )
Ответ на: комментарий от cvs-255 06.12.14 12:34:25 MSK
Зачем мне это? Почему нельзя нормально работать с портом на usb, а
Работай. libusb и вперед изобретать велосипед (CDC ACM).
CDC ACM — это 2 конечных точки — настройки и данные. Настройки имеют заранее известный формат. Данные — это просто сырые данные (те самые байтики).
alexru ★★★★
( 06.12.14 12:38:22 MSK )
Последнее исправление: alexru 06.12.14 12:44:14 MSK (всего исправлений: 2)
Ответ на: комментарий от alexru 06.12.14 12:35:44 MSK
В случае без USB:
CPU — PCI — UART — TTL to RS232 —X— провод — RS232 to TTL — МК UART
CPU — PCI — USB — провод — UART —X— МК UART.
Расположение провода в этой цепочке, очевидно, ни на что не влияет. Преобразователь уровней напряжения ttl to rs232 тоже. В обоих случаях UART является периферийным устройством компьютера, даже если физически он на плате с ардуиной. На схеме выше области, где заканчивается периферия компьютера и начинается МК, я разделил значком «X».
Именно компьютер указывает, на какой скорости работать UART. А контроллер управляет тем, на какой скорости работает МК UART. И было бы неплохо, чтобы эти скорости совпадали.
cvs-255 ★★★★★
( 06.12.14 15:15:12 MSK ) автор топика
Последнее исправление: cvs-255 06.12.14 15:20:03 MSK (всего исправлений: 2)
Ответ на: комментарий от cvs-255 06.12.14 15:15:12 MSK
Но как я понял, ttyACM0 это совсем не serial порт, а какой-то другой тип устройств, который по какому-то недоразумению в линуксе тоже работает через tty абстракцию.
cvs-255 ★★★★★
( 06.12.14 15:36:36 MSK ) автор топика
Ответ на: комментарий от alexru 06.12.14 09:04:18 MSK
мастдайкоюзвери должны страдать.
Eddy_Em ☆☆☆☆☆
( 06.12.14 16:19:14 MSK )
Ответ на: комментарий от cvs-255 06.12.14 15:36:36 MSK
ttyACM0 это совсем не serial порт
Очень даже serial. У меня, например, почти все ioctl’ы поддерживаются. Потому что я использую их для задания скорости USART’а (у микроконтроллера 2 USART’а и 1 USB, к компьютеру подключение по USB, а параметры USART’а МК узнает при подключении посредством ioctl’ов — скорость, четность и т.п. так и задается).
Вот только мне не нужны DTR и т.п., поэтому их я не обрабатываю. А нужны были бы — тоже поддерживал бы эти ioctl’ы.
Eddy_Em ☆☆☆☆☆
( 06.12.14 16:25:00 MSK )
Ответ на: комментарий от Eddy_Em 06.12.14 16:25:00 MSK
Если ttyACM это тоже serial, то в чем его тогда отличия от ttyUSB?
Казалось бы, serial это 2 провода — RX и TX. А также параметры — скорость и биты конца и четности.
Казалось бы, все. Драйвер serial порта должен уметь выставлять скорость, параметры стоб битов и четности, при записи в файл устройства посылать их в uart, а при чтении читать из uart.
но некоторые устройства видятся как ttyUSB, а некоторые как ttyACM. Но если они оба это uart, то в чем различие?
или различие в том, что они это не только драйвера собственно uart, но и еще поверх него что-то реализуют, и это что-то разное?
cvs-255 ★★★★★
( 06.12.14 16:52:40 MSK ) автор топика
Ответ на: комментарий от cvs-255 06.12.14 16:52:40 MSK
Железный UART конфигурируется локально и физически посылает биты на нужной скорости.
Через USB конфигурируется внешний контроллер, а сама конфигурация и данные посылаются на максимальной для USB скорости и с соответствующей запаковкой в кадры и разделением шины между устройствами. USB CDC и не-CDC — это протоколы общения с этим контроллером.
Тот-же /dev/ttyUSBx может быть интерфейсом к параллельному контроллеру, например.
Если хочется общаться напрямую с МК, то нужно брать МК с контроллером USB и тогда можно не мучиться с /dev/ttyUSB и протоколом CDC, а напрямую слать данные в МК с любом формате на максимальной для USB скорости.
alexru ★★★★
( 06.12.14 20:00:35 MSK )
Последнее исправление: alexru 06.12.14 20:00:47 MSK (всего исправлений: 1)
Ответ на: комментарий от alexru 06.12.14 09:04:18 MSK
Пожалели, не пожалели — проблема до сих пор сохраняется, что с дровами с сайта, что с теми что винда сама ставит. Уже 5 раз перешивал. Кабели к AirConsole оказались с подделкой.
VinilNavigator ★
( 06.12.14 21:31:45 MSK )
Ответ на: комментарий от alexru 06.12.14 20:00:35 MSK
Вот у меня есть шнурок мост usb-rs232. Я его втыкаю в usb порт и посылаю данные. И из него идут данные с указанной скоростью, а не со скорость usb. В случае ардуины, как я понял, то же самое, только uart сторона моста сразу к юарту мк подключена.
Atmega2560 вообще не имеет usb. Она имеет 2 юарта. И к одному из юартов подключен мост.
cvs-255 ★★★★★
( 06.12.14 22:33:49 MSK ) автор топика
Последнее исправление: cvs-255 06.12.14 22:40:02 MSK (всего исправлений: 1)
Ответ на: комментарий от cvs-255 06.12.14 22:33:49 MSK
Я его втыкаю в usb порт и посылаю данные. И из него идут данные с указанной скоростью, а не со скорость usb.
Ага, но до моста данные идут со скоростью USB.
Да, и поэтому со стороны меги соединение выглядит как простой UART, а со стороны компа как сложный USB. Я не понимаю в чем проблема. Если хочется так же просто со стороны компа, то нужно подключать к комповому-же железному UART-у.
А так комп посылает не последовательные данные, а команды мосту, который посылает данные. И формат этих команд определяется протоколом CDC ACM. И поэтому нужен специальный драйвер, который делает этот USB мост похожим на COM-порт. Но драйвер не обязателен, можно взять libusb и говорить с железкой напрямую, никакого COM-порта в этом случае не будет.
Я не знаю как это объяснить еще проще.
alexru ★★★★
( 06.12.14 22:50:04 MSK )
Ответ на: комментарий от alexru 06.12.14 22:50:04 MSK
А есть еще мосты Ethernet-UART. И с ними абсолютно та же ситуация.
alexru ★★★★
( 06.12.14 22:54:44 MSK )
Ответ на: комментарий от alexru 06.12.14 22:50:04 MSK
Более того на новых ардуинах мост сделан на МК ATxmega16U4 или подобном и прошивка открыта. Так что можно ее поправить, например зафиксировав скорость и настройки порта. Тога конфигурация со стороны ПК не будет требоваться и можно будет просто слать и принимать данные (через libusb естественно). Это по сути изобретение собственного «удобного» протокола.
alexru ★★★★
( 06.12.14 23:03:24 MSK )
Ответ на: комментарий от Eddy_Em 06.12.14 08:14:26 MSK
Ну, в принципе, теперь все ясно: если у тебя что-то вылезает на /dev/ttyUSBx, ты не можешь никаких ioctl’ов применить, кроме tty’шных. А на /dev/ttyACMx можешь.
ммммм? а можно с этого места поподробнее? почему понятно? а то недавно бился с устройством на уарт.
next_time ★★★★★
( 06.12.14 23:19:48 MSK )
Ответ на: комментарий от cvs-255 06.12.14 12:07:09 MSK
Во всяких МК, когда нужно на uart что то вывести, записываешь baudrate, после чего выводишь побайтно данные в регистр порта, и они выводятся на порт.
во всяких МК точно также задаются стоповые биты и чётность
next_time ★★★★★
( 06.12.14 23:22:32 MSK )
Ответ на: комментарий от alexru 06.12.14 11:45:42 MSK
эх, где вы были. недавно задавал в технических разделах вопрос, никто не осилил дать вразумительный ответ, как же это сделать.
next_time ★★★★★
( 06.12.14 23:23:52 MSK )
Ответ на: комментарий от next_time 06.12.14 23:23:52 MSK
mono на мой взгляд, данному вопросу место в технических разделах.
next_time ★★★★★
( 06.12.14 23:27:21 MSK )
Ответ на: комментарий от next_time 06.12.14 23:23:52 MSK
недавно задавал в технических разделах вопрос, никто не осилил дать вразумительный ответ, как же это сделать.
alexru ★★★★
( 07.12.14 00:33:18 MSK )
Ответ на: комментарий от alexru 07.12.14 00:33:18 MSK
видеть девайс как uart порт, в который пишешь байт — и в порт улетел байт
next_time ★★★★★
( 07.12.14 11:02:24 MSK )
Елки, что вы тут развели флейм ни о чем?
Нет никакой разницы между ttyACM и ttyUSB. Суть в том, что используются просто два разных подхода для распространения девайсов:
1. Это когда вендор создает новый USB-serial чип, но ему влом писать свой драйвер.
Тогда он просто реализует в своем чипе прошивку согласно USB CDC ACM спецификации. И реализует (или не реализует) в ней поддержку нужных команд. Например, не делает (или делает) поддержку baud rate, не делает (или делает) parity и прочее в соответствии с CDC ACM спекой (тут уже про это говорили). Т.е. на все воля вендора. В этом случае юзер — программер при попытке установить baud rate и прочие не поддерживаемые вещи (всякие другие ioctl) получит ошибки с определенными кодами.
Основной цимус в этом подходе в том, что вендору не нужно писать свой драйвер, т.к. CDC ACM девайс — это class-specific устройство для которого в любой оси есть уже встроенный драйвер. И этот девайс будет работать в любой оси без проблем (в идеале). И все фичи строго регламентируются/ограничиваются CDC ACM спецификацией и тем «стандартным» драйвером, который есть в ОС.
2. Это когда вендор создает новый USB-serial чип, но ему хочется написать свой драйвер.
Тогда он пишет драйвер для каждой из платформ. В котором также он может реализовать или нет определенные serial фичи, а также добавить в него некие дополнительные ioctl (например, включить лампочку на устройстве или подрыгать дополнительными GPIO ножками и прочее). Здесь с точки зрения конечного юзера-программера нет никакой разницы. т.е. также могут не поддерживаться установки baud rate и прочих плюх.
Основной цимус в этом подходе в том, что вендору не нужно писать специфичную прошивку для девайса в соответствии с CDC ACM спекой. Вендор тут волен делать все что ему хочется. Но он должен предоставить драйвер с описанием всех поддерживаемых фич (ioctl и прочее). Хотя, по-хорошему., и в п.1. он тоже должен предоставить описание всех фич.
Кроме того, вендор может вообще не предоставлять свой девайс как serial/tty девайс. А может просто как некий иной кастомный девайс (dev/myCoolDevice), в котором напридумывать свой API для его конфигурирования и прочее (привет, FTDI 🙂 ). Например как 1-Wire, SPI и прочее.. А может сделать тот-же SPI и прочее через serial..
Резюмируя: Для конечного пользователя нет разницы вообще. Поэтому — забейте. 🙂
UPD: И это касается не только serial устройств, а вообще любых. Например, те-же USB Audio/Video и прочее.
kuzulis ★★
( 07.12.14 15:38:28 MSK )
Последнее исправление: kuzulis 07.12.14 15:45:19 MSK (всего исправлений: 2)
Скрипт для слежения за подключением/отключением устройств /dev/ttyUSB и /dev/ttyACM
Пользователям Линукса хочу представить небольшой скрипт, который выводит уведомления на рабочий стол о подключении/отключении устройств /dev/ttyUSB и /dev/ttyACM:
/dev/ttyUSB и /dev/ttyACM — это устройства, которые создаются при подключении переходников USB-UART или USB-модемов. Иногда нужно знать под каким номером подключено устройство. Для этого можно воспользоваться командой:
ls /dev/ttyUSB*Но постоянно ей пользоваться может утомить. Меня, например, утомило и я сделал скрипт, который автоматически сообщает о подключении/отключении устройств.
Скрипт выложен на Гитхаб.
Работоспособность скрипта я проверил только на Xubuntu версий 13.10 и 12.10. Буду рад, если мне сообщат о его работоспособности в других дистрибутивах.
Уведомления на рабочий стол выводятся с помощью программы notify-send, которая должна присутствовать во многих дистрибутивах.
Также скрипт использует утилиту inotifywait из пакета inotify-tools, который во многих системах доступен из родного репозитория. Утилита следит за созданием/удалением файлов в /dev. При отсутствии утилиты скрипт опрашивает каталог /dev раз в секунду.
Кроме уведомлений на рабочий стол, скрипт выводит уведомления в стандартный поток в следующем виде:
[01.01.2013 20:20:01] Подключено ttyUSB0 [01.01.2013 20:20:05] Подключено ttyUSB1 [01.01.2013 20:20:08] Отключено ttyUSB0 [01.01.2013 20:20:10] Отключено ttyUSB1Рекомендую добавить скрипт в автозагрузку.
Для тех, кому лень ходить на Гитхаб, привожу скрипт здесь:
#!/bin/bash # Скрипт для слежения за подключением/отключением устройств /dev/ttyUSB и /dev/ttyACM. # # Сайт проекта: https://github.com/bravikov/detect-ttyusb # # Зависимости: # inotify-tools (для наблюдения за изменениями вкаталоге /dev) # notify-send (для уведомлений на рабочем столе) # # С помощью утилиты из inotify-tools скрипт устанавливает слежение за каталогом /dev и в случае его изменения дает об этом знать. Если inotify-tools не установлен, то скрипт проверяет каталог /dev раз в секунду. # # Пример вывода: #[01.01.2013 20:20:01] Подключено ttyUSB0 #[01.01.2013 20:20:05] Подключено ttyUSB1 #[01.01.2013 20:20:08] Отключено ttyUSB0 #[01.01.2013 20:20:10] Отключено ttyUSB1 NOTIFY_SEND_SUMMARY="Слежение за устройствами /dev/ttyUSB и /dev/ttyACM" DIR="/dev" PREV_DEV_LIST="" while [ 1 ] do DEV_LIST="`ls \"$DIR\" | grep 'ttyUSB\|ttyACM'`" ##### find new device ##### for DEV in $DEV_LIST do NEW_DEV=yes for PREV_DEV in $PREV_DEV_LIST do if [ "$DEV" == "$PREV_DEV" ] then NEW_DEV=no break fi done if [ $NEW_DEV == yes ] then echo [`date "+%x %X"`] Подключено $DEV NOTIFY_SEND_BODY="`date "+%x %X"`\nПодключено устройство\n/dev/$DEV" notify-send "$NOTIFY_SEND_SUMMARY" "$NOTIFY_SEND_BODY" fi done ########################### ##### find remote device ##### for PREV_DEV in $PREV_DEV_LIST do REMOTE_DEV=yes for DEV in $DEV_LIST do if [ "$DEV" == "$PREV_DEV" ] then REMOTE_DEV=no break fi done if [ $REMOTE_DEV == yes ] then echo [`date "+%x %X"`] Отключено $PREV_DEV NOTIFY_SEND_BODY="`date "+%x %X"`\nОтключено устройство\n/dev/$PREV_DEV" notify-send "$NOTIFY_SEND_SUMMARY" "$NOTIFY_SEND_BODY" fi done ############################## PREV_DEV_LIST="$DEV_LIST" if [ -x "`which inotifywait`" ] then inotifywait -e create -e delete "$DIR" > /dev/null 2>&1 else sleep 1 fi done What is the difference between /dev/ttyUSB and /dev/ttyACM?
Have you ever wondered why some USB devices used /dev/ttyUSB0 (or 1, or n) and others /dev/ttyACM0 (or 1, or n) when they are plugged into the host computer, while they seem to be acting as UART devices (RS-232-like) over USB in both cases? Have you wondered why example USB firmwares for microcontrollers always end up with names such as /dev/ttyACM0 and never as /dev/ttyUSB0 ?
Warning: this is a Linux specific post, although it also contains genuine pieces of USB culture.
What does ttyACM mean?
The USB implementors forum organization has described how devices conforming to the Communications Device Class (CDC) should present themselves to the USB host. The USB implementors forum also specified how CDC subclasses should act, including for those devices intended to talk with each other over the public switched telephone network (PSTN). Those are known as modems because the data goes through a modulation operation on the sending side, which transforms the bits into analog signals that can be carried over phone wires, and then through a demodulation operation on the receiving side to convert the analog signal back into the original bits.
To discuss with the modem, the host USB driver must use one of the existing control models. For example, the direct line control model controls how data is exchanged between the host and the modem through an audio class interface, with the host taking charge of the modulation, demodulation, data compression (such as V.42bis) and error correction (such as V.42). This model is used by some USB soft modems, which are very cheap because they mostly contain a DSP chip and some amplification and line adaptation layers.
Another control model, aptly named abstract control model or ACM, lets the modem hardware perform the analog functions, and require that it supports the ITU V.250 (also known as Hayes in its former life) command set, either in the data stream or as a separate control stream through the communication class interface. When the commands are multiplexed with the data in the data stream, an escape sequence such as Hayes 302 (also known as “1 sec +++ 1 sec”) or TIES (that nobody remembers) must allow the host to put the modem into command mode.
When developping on a USB-enabled embedded microcontroller that needs to exchange data with a computer over USB, it is tempting to use a standardized way of communication which is well supported by virtually every operating system. This is why most people choose to implement CDC/PSTN with ACM (did you notice that the Linux kernel driver for /dev/ttyACM0 is named cdc_acm ?) because it is the simplest way to exchange raw data.
But what about the mandatory V.250 command set? It is almost never implemented in such devices, but since the host has no reason to spontaneously generate V.250 commands by itself, the device will never have to answer them. Pretending the embedded device is a modem is the simplest way to communicate with it, even though it will probably never perform any modulation or demodulation task. Linux will not know that the device is lying, and will have it show up as /dev/ttyS0 .
What does ttyUSB mean?
Sometimes, the embedded microcontroller does not come with a hardware USB interface. While it is possible to use a software-only USB stack, the additional constraints put onto the CPU and the usually small storage size often lead board designers to include a dedicated UART to USB bridge. Several vendors, such as FTDI or Prolific sell dedicated chips for a few euros.
Those vendors opted not to lie to the host computer in having the chips announce themselves as USB modems when they were not. Each vendor defined its own (usually proprietary) protocols, with commands allowing to control functions of the chips such as setting the baud rate or controlling additional signals used to implement hardware flow control.
When it is practical to do so, Linux groups devices with similar functionalities under the same default device or interface names. For example, the UARTs present on your computer (if any) will be named /dev/ttyS0 and /dev/ttyS1 even if one of them is a legacy 16550 chip and the other one is a MAX3100 SPI-controlled UART. Similarly, the devices offering UART-over-USB functionalities are named /dev/ttyUSB0 , /dev/ttyUSB1 , and so on, even though they are in fact using distinct device drivers.
Conclusion
So, when you see a /dev/ttyACM0 popping up, you can try to send it the escape sequence followed by AT commands, but there is a good chance that the device only pretends to be a modem and will happily send those characters to the core application without even considering intercepting them. If it is a /dev/ttyS0 , do not try, unless the device behind the USB-UART bridge understands those command by itself (this is the case for the XBee chip).