LINUX.ORG.RU

В чем глубинный смысл ttyACMx?


3

1

Сабж. Прочитал несколько статей на тему разницы 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 (всего исправлений: 3)

Ответ на: комментарий от cvs-255

в линуксах, где есть 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 ★★★★★
()
Ответ на: комментарий от cvs-255

там нет файлов устройств, только симлинки на них. Проверил — вроде и в дебиане анстейбле, и генте имеется.

demidrol ★★★★★
()

Все очень просто.

ttyACM - это стандартный USB CDC ACM.

ttyUSB - это проприетарный протокол, похожий на USB CDC ACM, но с расширениями и модификациями.

Соответственно и драйверы разные для них.

alexru ★★★★
()
Последнее исправление: alexru (всего исправлений: 1)
Ответ на: комментарий от alexru

О, хоть кто-то просветил!

А то я сильно матюкался, когда мой микроконтроллер вместо /dev/ttyUSBx определился как /dev/ttyACMx.

Ну, в принципе, теперь все ясно: если у тебя что-то вылезает на /dev/ttyUSBx, ты не можешь никаких ioctl'ов применить, кроме tty'шных. А на /dev/ttyACMx можешь.

А в остальном — те же яйца, только в профиль.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Микроконтроллеры определяются как ttyACM потому что какой им смысл поддерживать FTDI, SiLabs и еще черт знает кого. Да чтобы потом FTDI-ные дрова убили устройство как недавно случилось.

Я бы хотел найти аналог FTDI, но поддерживающий CDC ACM, но чего-то пока не видать.

alexru ★★★★
()
Ответ на: комментарий от Eddy_Em

http://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-ftdi-ft232/

Если кратко, то FTDI выпустил драйвер (для винды), который делает хитрую попытку записи 0 в EEPROM на месте PID, но операцию не завершает. Это игнорируется настоящими чипами, но убивает клоны.

FTDI уже пожалели об этом и извинились, но поздно метаться.

alexru ★★★★
()
Ответ на: комментарий от alexru

А нет возможности увидеть девайс как uart порт, в который пишешь байт - и в порт улетел байт. Без всяких там протоколов?

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

Hу так /dev/ttyACMx и /dev/ttyUSBx дают такую возможность. Но чтобы байт «улетел» на нужной скорости порт нужно конфигурировать.

alexru ★★★★
()
Ответ на: комментарий от alexru

Выставить baud rate, что там еще делать?

Во всяких МК, когда нужно на uart что то вывести, записываешь baudrate, после чего выводишь побайтно данные в регистр порта, и они выводятся на порт.

Почему в линуксе надо не так? Символьное устройство с ioctl, задающим скорость и всякие там стоповые биты и четность.

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 3)
Ответ на: комментарий от cvs-255

Число бит данных, стоповых бит, бит четности и контроля потока.

Те драйверы больше ничего особо и не позволяют делать. Все остальное - как запрашивалось, послали байт, получили байт на выходе.

alexru ★★★★
()
Ответ на: комментарий от alexru

Hу так /dev/ttyACMx и /dev/ttyUSBx дают такую возможность.

Ох, как я на днях задолбался, пытаясь установить скорость 250000 на /dev/ttyACM0 устройства, которое точно поддерживает эту скорость.

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

Почему в линуксе надо не так?

Можно, почему нельзя. Нужно узнать по какому адресу находится контроллер UART, mmap-нуть этот адрес в пространство процесса. После этого контроллер будет доступен как набор регистров.

alexru ★★★★
()
Ответ на: комментарий от alexru

А какие еще бывают com порты? Вот у меня есть железка с ардуиной, в ней usb com порт для связи с компом. Вполне себе «железный»

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 2)
Ответ на: комментарий от cvs-255

У ардуино стоит отдельный преобразователь USB-UART. Так что ищи комп с COM-портом и будет как в ардуино.

Только и с ардуино придется выкинуть преобразователь и подключать UART напрямую к компу (через преобразователь уровней RS232).

alexru ★★★★
()
Последнее исправление: alexru (всего исправлений: 1)
Ответ на: комментарий от alexru

Зачем мне это? Почему нельзя нормально работать с портом на usb, а не через изврат с патченой pyserial, которая таки может перевести этот tty в нужный режим?

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

Потому что настоящий COM-порт цепляется к настоящему контроллеру UART, нет тут никакой шины. Виртуальный порт - это имитация. Те-же байты пакуются в кадры и передаются по USB и могут быть приняты только по USB .

Схема до USB: PC UART --- RS-232 --- кабель --- RS-232 --- МК UART. Схема ардуино: PC USB --- USB кабель --- мост USB-UART --- МК UART.

Соответственно UART на стороне PC больше нет и работать с байтам «как на МК» уже не выйдет.

alexru ★★★★
()
Ответ на: комментарий от cvs-255

Зачем мне это? Почему нельзя нормально работать с портом на usb, а

Работай. libusb и вперед изобретать велосипед (CDC ACM).

CDC ACM - это 2 конечных точки - настройки и данные. Настройки имеют заранее известный формат. Данные - это просто сырые данные (те самые байтики).

alexru ★★★★
()
Последнее исправление: alexru (всего исправлений: 2)
Ответ на: комментарий от alexru

В случае без USB:

CPU --- PCI --- UART --- TTL to RS232 --X-- провод --- RS232 to TTL --- МК UART

В случае USB:

CPU --- PCI --- USB --- провод --- UART --X-- МК UART.

Расположение провода в этой цепочке, очевидно, ни на что не влияет. Преобразователь уровней напряжения ttl to rs232 тоже. В обоих случаях UART является периферийным устройством компьютера, даже если физически он на плате с ардуиной. На схеме выше области, где заканчивается периферия компьютера и начинается МК, я разделил значком «X».

Именно компьютер указывает, на какой скорости работать UART. А контроллер управляет тем, на какой скорости работает МК UART. И было бы неплохо, чтобы эти скорости совпадали.

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 2)
Ответ на: комментарий от cvs-255

Но как я понял, ttyACM0 это совсем не serial порт, а какой-то другой тип устройств, который по какому-то недоразумению в линуксе тоже работает через tty абстракцию.

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от alexru

для винды

мастдайкоюзвери должны страдать.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от cvs-255

ttyACM0 это совсем не serial порт

Очень даже serial. У меня, например, почти все ioctl'ы поддерживаются. Потому что я использую их для задания скорости USART'а (у микроконтроллера 2 USART'а и 1 USB, к компьютеру подключение по USB, а параметры USART'а МК узнает при подключении посредством ioctl'ов — скорость, четность и т.п. так и задается).

Вот только мне не нужны DTR и т.п., поэтому их я не обрабатываю. А нужны были бы — тоже поддерживал бы эти ioctl'ы.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Если ttyACM это тоже serial, то в чем его тогда отличия от ttyUSB?

Казалось бы, serial это 2 провода - RX и TX. А также параметры - скорость и биты конца и четности.

Казалось бы, все. Драйвер serial порта должен уметь выставлять скорость, параметры стоб битов и четности, при записи в файл устройства посылать их в uart, а при чтении читать из uart.

Всё.

но некоторые устройства видятся как ttyUSB, а некоторые как ttyACM. Но если они оба это uart, то в чем различие?

или различие в том, что они это не только драйвера собственно uart, но и еще поверх него что-то реализуют, и это что-то разное?

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

Железный UART конфигурируется локально и физически посылает биты на нужной скорости.

Через USB конфигурируется внешний контроллер, а сама конфигурация и данные посылаются на максимальной для USB скорости и с соответствующей запаковкой в кадры и разделением шины между устройствами. USB CDC и не-CDC - это протоколы общения с этим контроллером.

Тот-же /dev/ttyUSBx может быть интерфейсом к параллельному контроллеру, например.

Если хочется общаться напрямую с МК, то нужно брать МК с контроллером USB и тогда можно не мучиться с /dev/ttyUSB и протоколом CDC, а напрямую слать данные в МК с любом формате на максимальной для USB скорости.

alexru ★★★★
()
Последнее исправление: alexru (всего исправлений: 1)
Ответ на: комментарий от alexru

Пожалели, не пожалели - проблема до сих пор сохраняется, что с дровами с сайта, что с теми что винда сама ставит. Уже 5 раз перешивал. Кабели к AirConsole оказались с подделкой.

VinilNavigator
()
Ответ на: комментарий от alexru

Вот у меня есть шнурок мост usb-rs232. Я его втыкаю в usb порт и посылаю данные. И из него идут данные с указанной скоростью, а не со скорость usb. В случае ардуины, как я понял, то же самое, только uart сторона моста сразу к юарту мк подключена.

Atmega2560 вообще не имеет usb. Она имеет 2 юарта. И к одному из юартов подключен мост.

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от cvs-255

Я его втыкаю в usb порт и посылаю данные. И из него идут данные с указанной скоростью, а не со скорость usb.

Ага, но до моста данные идут со скоростью USB.

Да, и поэтому со стороны меги соединение выглядит как простой UART, а со стороны компа как сложный USB. Я не понимаю в чем проблема. Если хочется так же просто со стороны компа, то нужно подключать к комповому-же железному UART-у.

А так комп посылает не последовательные данные, а команды мосту, который посылает данные. И формат этих команд определяется протоколом CDC ACM. И поэтому нужен специальный драйвер, который делает этот USB мост похожим на COM-порт. Но драйвер не обязателен, можно взять libusb и говорить с железкой напрямую, никакого COM-порта в этом случае не будет.

Я не знаю как это объяснить еще проще.

alexru ★★★★
()
Ответ на: комментарий от alexru

А есть еще мосты Ethernet-UART. И с ними абсолютно та же ситуация.

alexru ★★★★
()
Ответ на: комментарий от alexru

Более того на новых ардуинах мост сделан на МК ATxmega16U4 или подобном и прошивка открыта. Так что можно ее поправить, например зафиксировав скорость и настройки порта. Тога конфигурация со стороны ПК не будет требоваться и можно будет просто слать и принимать данные (через libusb естественно). Это по сути изобретение собственного «удобного» протокола.

alexru ★★★★
()
Ответ на: комментарий от Eddy_Em

Ну, в принципе, теперь все ясно: если у тебя что-то вылезает на /dev/ttyUSBx, ты не можешь никаких ioctl'ов применить, кроме tty'шных. А на /dev/ttyACMx можешь.

ммммм? а можно с этого места поподробнее? почему понятно? а то недавно бился с устройством на уарт.

next_time ★★★★★
()
Ответ на: комментарий от cvs-255

Во всяких МК, когда нужно на uart что то вывести, записываешь baudrate, после чего выводишь побайтно данные в регистр порта, и они выводятся на порт.

во всяких МК точно также задаются стоповые биты и чётность

next_time ★★★★★
()
Ответ на: комментарий от alexru

эх, где вы были. недавно задавал в технических разделах вопрос, никто не осилил дать вразумительный ответ, как же это сделать.

next_time ★★★★★
()
Ответ на: комментарий от next_time

mono на мой взгляд, данному вопросу место в технических разделах.

next_time ★★★★★
()
Ответ на: комментарий от next_time

недавно задавал в технических разделах вопрос, никто не осилил дать вразумительный ответ, как же это сделать.

Что сделать?

alexru ★★★★
()
Ответ на: комментарий от alexru

видеть девайс как uart порт, в который пишешь байт - и в порт улетел байт

next_time ★★★★★
()

Елки, что вы тут развели флейм ни о чем?

Нет никакой разницы между 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 ★★
()
Последнее исправление: kuzulis (всего исправлений: 2)
Ответ на: комментарий от alexru

Ага, но до моста данные идут со скоростью USB.

А в случае 16650, например, данные до него идут со скоростью PCI. И комп посылает не последовательные данные, а пакеты шины PCI.

Какая разница, с какой скоростью идут данные внутри компьютера? Важно, с какой скоростью они из моста выходят и читаются.

Но драйвер не обязателен, можно взять libusb и говорить с железкой напрямую, никакого COM-порта в этом случае не будет.

Это называется написать юзерспейс драйвер, встроенный в конкретное приложение.

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от alexru

формат этих команд определяется протоколом CDC ACM

Т.е. все отличие от ttyUSB в том, какой формат пакетов данных используется для управления uart?

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

Выше же говорили, что отличие лишь в том, что ACM — более общий класс. Т.е. если что-то вылезло на /dev/ttyUSBxx, то это — явно какая-то свистоперделка, являющаяся посредником USB<->RS-232. А если оно на /dev/ttyACMxx вылезло, то там еще что-то может быть.

// но таки да: изврат. Лучше бы все вылезало на /dev/ttyUSBxx, так приятней.

Eddy_Em ☆☆☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.