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)

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

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

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

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

нет. один и тот-же uart можно реализовать и как ttyACM и как ttyUSB.

Например, у нас есть некая микруха - железный uart и мы хотим каким-то образом пришпиндорить ее к PC чтобы слать через нее данные и прочее.. Но как это сделать? Напрямую - никак.. Поэтому нужна еще какая-то дополнительная обвязка. Например, хотим через USB эту микруху протянуть (хотя, можно и через Ethernet и FireWire и прочее.). Поэтому нам нужен некий дополнительный контроллер с поддержкой USB. Тогда мы можем пришпиндорить эту микруху к контроллеру, а контроллер через USB - к PC. Для контроллера нужно реализовать прошивку которая бы могла принимать данные из PC и передавать их микрухе и наоборот.

Например, протокол общения с микрухой мы знаем - берем на нее даташит и смотрим какие там нужно дергать GPIO и прочее.. тут проблем нет. НО! Возникают проблемы - а как передавать и принимать данные от PC через USB?

Вот тут то и есть два пути:

1. Или писать в контроллере прошивку по спеке CDC ACM. 2. Или писать какую-то свою прошивку со своей USB конфигурацией (конечными точками и прочее).

В первом случае весь этот гибридный девайс сразу подцепится и будет фунциклировать.. Но во втором - фигли, т.к. ось не знает как работать с девайсом - нет драйвера. Поэтому нужно писать свой драйвер. Будет ли это наследник от TTY, или какая-то своя хренотень - не важно.

Также, можно использовать libusb для работы с девайсами (как ttyACM так и ttyUSB) «напрямую», конечно, если мы знаем какие там конечные точки что передают и за что отвечают.

Т.е. как-бы между контроллером и микрухой один и тот-же «протокол».. Но между контроллером и PC - разные. CDC ACM - это некий «стандартизированный» класс девайсов (class-specific) - все по спеке.. Остальное - это так называемый vendor-specific класс девайсов - все как хотим.

Тут мне непонятно что может быть непонятно?

ЗЫ: USB спеки открыты - почитайте и все станет ясно. :)

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

ну да, а потом читаешь, а обратно не прилетело, хотя, на самом деле, ответ был.

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

Элементарно же: write(fd, data, size)

Так и работаю со всеми своими микроконтроллерами. Как через переходнички на PL2303, так и напрямую через USB (CDC ACM).

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

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

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

Про select ты, конечно, не слышал?

слышал. в моём случае, оно не помогает, ибо проблема на более низком слое.

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

Интерфейс нормальный. Просто сформулируй по-человечески, что у тебя не получается!

ибо проблема на более низком слое

Если select не помогает, то проблема в неадекватном выборе железа, либо неадекватной частоте опроса порта. Скорость, видимо, слишком большая.

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

формулировал и даже вас туда звал:

Не устанавливаются настройки /dev/ttyUSBX

более подробно, внезапно, в другом треде: Разработчки MacOS X и GNU/Linux — быдлокодеры? (комментарий) (там выше и ниже можете почитать)

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

Я себя неуютно чувствую, когда меня на "вы" кличут! Я — не царь, и возраст у меня не под 100 лет!!!

В ту тему не пошел, т.к. нихрена не понял.

ioctl(ttyUSB, TIOCSSERIAL ,sstruct) устанавливает errno в ENOTTY

я таким ioctl'ом никогда не пользовался. Я даже не понимаю, на кой хрен он нужен.

Если была такая ошибка, то вывод однозначен: железяка этот ненужный ioctl не поддерживает. И это логично: зачем поддерживать ненужные сисвызовы?

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

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

Я наоборот /dev/ttyACMx люблю видеть. Это лишний раз подтверждает, что моя поделка заработает во всех ОС без лишних ковыряний с драйверами.

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

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

Да. ttyUSB имеет расширенные команды для записи данных в EEPROM, который содержит VID/PID. Это позволяет делать на базе FTDI устройства с любыми VID/PID.

ttyACМ это не нужно, так как ка правило такие устройства делаются конкретным производителем.

Более правильным подходом со стороны FTDI было бы сделать либо композитное устройство ttyACМ + проприетарнная конфигурация, либо сделать выбор между ttyACМ / проприетарнная конфигурация с помощью внешней ножки.

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

Мне насрать на игровые прошивки и гей-оси!

А я живу в реальном мире и мне нужно взаимодействовать со всеми людьми не зависимо от их выбора ОС.

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

Более правильным подходом со стороны FTDI было бы сделать либо композитное устройство ttyACМ + проприетарнная конфигурация, либо сделать выбор между ttyACМ / проприетарнная конфигурация с помощью внешней ножки.

Чо? Откуда у драйвера ножки? В USB CDC 1.1 предусмотрено, что вендору может потребоваться свой специфичный интерфейс, для этого в «3.5 Device Models» предлагается в CDC устройство тупо добавить нужное количество интерфейсов для управления и пр. Всё остальное не нужно.

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

Более правильным было бы не использовать эти идиотские FTDI

А их кто-то использует? Они же дорогие!

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

Вот и непонятно, с чего тогда весь сыр-бор. Если самым простым вариантом является взять дешевую STM32F042 или чуть подороже 072, да забульбенить на нормальном USB все, что нужно!

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

Ну, ардуйщики — это вообще какой-то специфический класс обезьян...

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

Я уже смотрел его сразу же. Но мне этот ман ничего не дает, т.к. в нем не написано, что этот сисвызов делает!

Я вообще первый раз здесь о нем услышал. И не понимаю, кому это может понадобиться!

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

Посмотрел исходники. Этот сисвызов используется, чтобы поменять два параметра:

acm->port.close_delay = close_delay;
acm->port.closing_wait = closing_wait;
т.е., по-видимому, нужен лишь для определения паузы перед close(), чтобы буферы успели сбросится.

Т.к. обычно close() выполняется на выходе, когда уже все и так сброшено, то смысла в этом сисвызове не вижу!

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

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

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

Ты уверен?

Что за задача такая, что этот странный вызов нужен?

Если read ничего не видит, то, возможно, ты слишком редко select делаешь. Или еще какой косяк.

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