История изменений
Исправление kuzulis, (текущая версия) :
Елки, что вы тут развели флейм ни о чем?
Нет никакой разницы между 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, :
Елки, что вы тут развели флейм ни о чем?
Нет никакой разницы между 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..
Резюмируя: Для конечного пользователя нет разницы вообще. Поэтому - забейте. :)
Исходная версия kuzulis, :
Елки, что вы тут развели флейм ни о чем?
Нет никакой разницы между 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..
Резюмируя: Для конечного пользователя нет разницы вообще. Поэтому - забейте. :)