Посоветуйте по изучению USB, каким путём лучше идти Опции

[NaughtyFreak]

Всем ДВС!

Хотел бы спросить у уважаемого сообщества совета по изучению USB, так сказать чтобы указали направление, а дальше сам. Сейчас на столе лежит некое устройство, скажем, телеметрии. Оно должно собирать инфо с сенсоров в кучу и отправлять всё это дело в ПК + возможность настройки устройства через оболочку на ПК. В связи с тем, что стандартного HID класса ввиду ограниченности размера посылки может не хватить, хочу забацать свой собственный. И вот тут начинаются вопросы и трудности. Сам я после чтения Агурова и ресурсов, посвященных сабжу, изучения библ от STM более-менее разобрался и как я понял главное это правильный дескриптор и настройка ендпоинтов. Как я понял, для моих задач потребуется тип передачи interrupt, 4 ендпоинта (EP0, control EP, TxEP, RxEP), т.е. концепция более-менее понятна. В какую сторону дальше копать и какой контроллер лучше взять для того, чтобы пощупать работу USB? Правильно ли я понимаю, что потребуется custom class? Сейчас имеется stm32f417, но судя по многочисленным обсуждениям его движок USB очень тяжёл для начала. Делать USB-COM не хочу принципиально
Что посоветуете, опытные гуру?

[kovigor]

Что посоветуете, опытные гуру?

Каков объем данных в секунду ? Если объем невелик, то достаточно FS, HS не нужна. Если хватит FS, то не нужен и STM. Возьмите NXP или ATMEL, они гораздо проще, и документация к ним гораздо удачнее, а примеры вполне разбираемы даже для тех, кто раньше с USB не работал.
Нужна ли высокая надежность ? Если нужна, откажитесь от USB, это будет постоянный источник проблем.
Свой класс, наверное, не стоит изобретать. Кстати, можно реализовать тот же Mass-storage, и обращаться к дивайсу как к обычному диску. То-то ваши программисты обрадуются .
P.S. Агурова не читайте, там вагон ошибок, самого разного калибра. Почитайте лучше Гука "Шины PCI, USB и FireWire" (например; а вообще у него нет книг, которые не стоило бы прочесть):
http://rutracker.org/forum/viewtopic.php?t=2466185

[Herz]

Всем ДВС!

Двигатель Внутреннего Сгорания? И Вам того же.

Что посоветуете, опытные гуру?

Бежать от USB, как от чумы. Если имеется хоть единственная альтернатива.

[telix]

Если Вы хотите копать USB то вот этот вариант наилучший.

Сообщение отредактировал telix - Feb 5 2013, 10:28

[toweroff]

или их же драйвер,

совсем необязательно. LibUsb прекрасно справляется (конечно, если не использовать загрузку прошивки при включении по USB)
Кстати, в последней редакции есть подписи под Win7 x64, что есть плюс

Для Вас, если важно что то свое наваять, не вникая в железо, а только софт, то вот этот вариант наилучший.

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

А для CDC можно и свой inf под usbser сделать

[NaughtyFreak]

Двигатель Внутреннего Сгорания? И Вам того же.

Я тоже кружок шутки юмора на досуге посещаю.
ДВС = "Доброго Времени Суток"

Бежать от USB, как от чумы. Если имеется хоть единственная альтернатива.

Обоснуйте?..

Объём невелик, FS хватит за глаза.
Я почему-то так и думал что всё сведется к Atmel/NXP. Ок, спасибо за наводочку, скорее всего NXP. Сразу вопрос: какой? Я их ранее никогда в руках не держал. Простенького Cortex-M3 хватит (LPC17xx)?
Я сам себе прогаммер, поэтому радоваться буду сам Цель изучения скорее самообразование на переспективу владения и умения.

На Cypress тоже смотрел, но пока дальше чтения сайта не углублялся. Откровенно говоря вещь не самая массовая, поэтому больше склоняюсь к тому же Atmel/NXP/ST.
С HID не очеень хочу заморачиваться, всё-таки склоняюсь к кастом-устройству + свой драйвер на Windows Driver Kit.

[kovigor]

Объём невелик, FS хватит за глаза.
Я почему-то так и думал что всё сведется к Atmel/NXP. Ок, спасибо за наводочку, скорее всего NXP. Сразу вопрос: какой? Я их ранее никогда в руках не держал. Простенького Cortex-M3 хватит (LPC17xx)?

Должно хватить, если там есть FS. Еще раз повторю, если нужна надежность и (или) система должна быть необслуживаемой, или обслуживаемой редко, то от USB лучше отказаться сразу ...

[toweroff]

Простенького Cortex-M3 хватит (LPC17xx)?

LPC175x скорее всего вполне. Тем более, что они пин-в-пин в этой линейке

всё-таки склоняюсь к кастом-устройству + свой драйвер на Windows Driver Kit.

да зачем городить с WDK? Посмотрите по-внимательнее на libusb, я с ним булки гоняю уже лет 7

[NaughtyFreak]

Нет-нет, супернадёжности не требуется, более того система автономна, но иногда требуется её подключать к компу для настройки/калибровки/считывания.
kovigor, toweroff весьма благодарен за разъяснения. Буду пробовать тогда с NXP и заодно покурю LibUsb. Не подскажите тогда, какие есть отладки с USB2.0 для контроллеров LPC?

[toweroff]

Не подскажите тогда, какие есть отладки с USB2.0 для контроллеров LPC?

я использовал USBTrace и пример Mass Storage от Keil или codebundle от NXP, точно не помню
Выбросил весь уровень SCSI и использовал только bulk передачу
Фактически, нужно только отладить правильные энумерацию и конфиги, все остальное уже просто прикладной уровень

[kovigor]

более того система автономна

Для автономных систем USB не годится. Или система превратится в неавтономную. Раз в несколько дней вы будете ездить на обслуживаемый ей объект и ее перезапускать.
Отладочные платы здесь:
http://www.starterkit.ru

[shreck]

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

...

С HID не очеень хочу заморачиваться, всё-таки склоняюсь к кастом-устройству + свой драйвер на Windows Driver Kit.

Вы думаете, что свое устройство+драйвер будет резко проще чем HID устройство?
О какой ограниченности посылки вы говорите. HID-репорт может быть до 64кБ размером. И никто не мешает передавать данные в несколько приемов. Зато никаких головняков с драйверами.

[NaughtyFreak]

Вы думаете, что свое устройство+драйвер будет резко проще чем HID устройство?
О какой ограниченности посылки вы говорите. HID-репорт может быть до 64кБ размером.

пока не думаю, пока изучаю
А разве не 64 байта?

[kovigor]

А разве не 64 байта?

Нет, конечно. Я же говорю, Гука почитайте ...
P.S. Не все так просто. Длинную посылку для FS придется передавать блоками по 64 байта:
http://www.jungo.com/st/support/documentat...sfer_types.html
Выдержка из этого документа:

"3.6.3 Interrupt Transfer
Interrupt Transfer is intended for devices that send and receive small amounts of data infrequently or in an asynchronous time frame.
This transfer type can be used for low-, full- and high-speed devices.
Interrupt transfer type guarantees a maximum service period and that delivery will be re-attempted in the next period if there is an error on the bus.
The interrupt pipe, like the isochronous pipe, is unidirectional and periodical.
The maximum packet size for interrupt endpoints can be 8 bytes or less for low-speed devices; 64 bytes or less for full-speed devices; and 1,024 bytes or less for high-speed devices."

[NaughtyFreak]

Понял, буду изучать!
Скачал refernce manual на LPC1700, сразу волна ностальгии по АВР нахлынула. После беглого взгляда по периферии USB device ужас от STM32 понемногу начал проходить.

[kovigor]

Понял, буду изучать!
Скачал refernce manual на LPC1700, сразу волна ностальгии по АВР нахлынула. После беглого взгляда по периферии USB device ужас от STM32 понемногу начал проходить.

Качайте Keil и разбирайте идущий с ним пример HID для вашего МК ...

[shreck]

Нет, конечно. Я же говорю, Гука почитайте ...
P.S. Не все так просто. Длинную посылку для FS придется передавать блоками по 64 байта:
http://www.jungo.com/st/support/documentat...sfer_types.html
Выдержка из этого документа:

Не путайте размер конечной точки и размер hid-репорта.

[kovigor]

Не путайте размер конечной точки и размер hid-репорта.

Признаюсь честно: я никогда не делал HID - устройств с репортами, превышающими по длине 64 байта. Пусть этот момент для ТС разъяснит кто-то более опытный ...

[NaughtyFreak]

Качайте Keil и разбирайте идущий с ним пример HID для вашего МК ...

Смотрел для STM32. Честно? Нихрена там не понял + как мне показалось она завязана на RTX библу, которая у меня не поддерживается.

[kovigor]

Смотрел для STM32. Честно? Нихрена там не понял + как мне показалось она завязана на RTX библу, которая у меня не поддерживается.

Для вашего LPC cмотрите. Чтобы что-то понять, необходимо понимать, как работает шина. USB - не UART ...

[toweroff]

Смотрел для STM32. Честно? Нихрена там не понял + как мне показалось она завязана на RTX библу, которая у меня не поддерживается.

при чем тут STM32, если уже вроде как определились с LPC?
Если надо с RTX, то найдете и с RTX, если надо БЕЗ нее, то и это имеется.

\Keil\ARM\Boards\Keil\MCB1700\USBHID\
\Keil\ARM\Boards\Keil\MCB1700\USBMem\

И если уж хоть как-то Агурова смотрели, то представление о работе шины должно быть. Если представления нет, то и копать код нет смысла, действительно "нихрена" непонятно

[andrewlekar]

О какой ограниченности посылки вы говорите. HID-репорт может быть до 64кБ размером.

Где это Вы видели hid репорт в 64К размером?

[shreck]

Где это Вы видели hid репорт в 64К размером?

В дескрипторе репорта есть поля REPORT_SIZE и REPORT_COUNT, которые вместе определяют суммарный размер репорта в байтах.
Откуда у меня это значение в 64к? Из Агурова и я это принял на веру, возможно, зря. Сейчас пытаюсь вспомнить подробности, но сдается мне, что есть ограничения на максимальные значения этих полей. 64к наверное не достигнуть, но 1к без проблем.

[NaughtyFreak]

при чем тут STM32, если уже вроде как определились с LPC?
Если надо с RTX, то найдете и с RTX, если надо БЕЗ нее, то и это имеется.

\Keil\ARM\Boards\Keil\MCB1700\USBHID\
\Keil\ARM\Boards\Keil\MCB1700\USBMem\

Точно, я невнимательно посмотрел...
На STM я до этого смотрел, но там реально очень замороченный движок в самом проце. Вчера вечером за рюмкой чаю раскуривал мануал на USB в LPC, так там школьник разберется что к чему.

Откровенно говоря как работает на все 100% пока понимания нету, нужен опыт, но базовые принципы работы USB мне понятны. Гука качнул, буду изучать!

[kovigor]

Гука качнул, буду изучать!

Вот еще полезный материал:
http://www.beyondlogic.org/usbnutshell/usb1.shtml
Ну и книги Jan Axelson по USB очень и очень хороши:
http://www.lvr.com/usb.htm#books

[toweroff]

kovigor, там в примерах для LPC, в общем-то, все прозрачно. Запускается "на раз", разобраться в иерархии несложно. Для стартапа device самое оно.
Нужно только полное понимание дескрипторов
А вот если делать host, тогда да, много чего курить надо

[kovigor]

kovigor, там в примерах для LPC, в общем-то, все прозрачно. Запускается "на раз", разобраться в иерархии несложно. Для стартапа device самое оно.
Нужно только полное понимание дескрипторов
А вот если делать host, тогда да, много чего курить надо

Хост это вообще отдельная песня.
Тут вот еще что важно: на каком уровне человеку это все нужно освоить ? Мне нужно было копать очень глубоко, для решения весьма специфической задачи. Поэтому пришлось досконально разобрать пример для LPC214x. И все оказалось совсем не так прозрачно, как вы пишете ...

[NaughtyFreak]

Задача почти тривиальная:
Есть, ну скажем, гироплатформа. Она напичкана всякими сенсорами-датчиками и километром математики. Там и всеми любимый Калман, и интегратор и еще много чего. Но иногда для диагностики системы и коррекции её работы ее нужно подрубать к ПК. Ну там коэфф-ты матрицы ковариации подправить (не переписывать же каждый раз код!), калибровочные константы, посмотреть он-лайн что она выдаёт здесь и сейчас, в конце концов реализовать DFU. Подразумевается, что на ПК соотв-ий софт имеется. Для этого COM не подойдёт, очень уж замороченный получится свой протокол поверх него, да и не хочу я велик изобретать, уж коль скоро для этого юсб придумали.

Посмотрел примеры для LPC, вроде не ад типа библы от СТ. Буду копать далее, еще раз спасибо всем за подсказки и советы!

[toweroff]

И все оказалось совсем не так прозрачно, как вы пишете ...

Вполне возможно, т.к. у меня совсем не используются такие вещи, как Suspend, Wake-Up, а так же всякое "хитрое" управление ACK/NACK
Просто обмен булками, все управление обменом на низком уровне - по умолчанию
Я еще раз повторю, что все эти примеры - для стартапа device, а уж дальше - кому как надо

[kovigor]

Вполне возможно, т.к. у меня совсем не используются такие вещи, как Suspend, Wake-Up, а так же всякое "хитрое" управление ACK/NACK

А вот мне это как раз и было нужно, и еще много чего ...

[NaughtyFreak]

Итак, за сутки неплохо продвинулся вперед, детально изучил дескрипторы и вообще что к чему. Многие вопросы отпали сами собой.
Вот, наваял файлик с дескрипторами будущего девайса. Всего 4 рабочих эндпоинта. Остались вопросы по-мелочи: обязательно ли делать строковые дескрипторы и правильно ли я инициализировал порядок работы vendor specific? Никак не могу найти где прочитать про interface protocol, он ведь тоже определен для классов?

Код

typedef unsigned char BYTE;

const BYTE DEVICE_DESCRIPTOR [] = {
    0x12,      //0 0-17 (18) размер в байтах
    0x01,      //1 дескриптор устр-ва
    0x02, 0x00, //2 USB 2.0
    0x00,      //4 см. дескриптор интерфеса  
    0x00,      //5 см. дескриптор интерфеса
    0x00,      //6 см. дескриптор интерфеса
    0x20,      //7 размер EP 0 32 байта
    0x12, 0xab, //8 VID с потолка
    0x00, 0x01, //10 PID с потолка
    0x00, 0x01, //12 Version 1.0
    0x00,      //14 нет
    0x00,      //15 нет
    0x00,        //16 нет
    0x01          //17 1 конф-ия
    };

const BYTE CONFIG_DESCRIPTOR [] = {
    0x09,       // 9 байт
    0x02,       // дескр-р конф-ии
    0x00,0x2e,  // всего байт возвращает - 4x7 (EP) + 2x9 = 46
    0x01,       // 1 интерфес
    0x01,       // "1"
    0x00,       // нет
    0xc0,       // self-powered
    0x96          // 300mA
    };

const BYTE INTERFACE_DESCRIPTOR [] = {
    0x09,    // 9 байт
    0x04,     // дескр-р инт-са
    0x00,    // интерфес "0"
    0x00,    // альт. интерфейс "0"
    0x04,    // 4 ендпоинта: EP1 DIN interrupt, EP1 DOUT interrupt, EP2 DOUT interrupt, EP2 DIN control
    0xff,        // vendor specific class
    0x01,    // subclass "1"
    0xff,        // vendor specific protocol
    0x00        // нет
    };

const BYTE ENDPOINT1_IN_DESCRIPTOR [] = {
    0x07,      // 7 байт
    0x05,      // дескр-р ендпоинта
    0x81,      // EP1 IN, основный данные
    0x03,      // interrupt
    0x00, 0x40, // размер 64 байта
    0x64          // каждые 100 мс
    };

const BYTE ENDPOINT1_OUT_DESCRIPTOR [] = {
    0x07,      //  7 байт
    0x05,      // дескр-р ендпоинта
    0x01,      // EP1 OUT, запись данных в ус-во
    0x03,      // interrupt
    0x00, 0x40, //  размер 64 байта
    0x64          //  каждые 100 мс
    };

const BYTE ENDPOINT2_IN_DESCRIPTOR [] = {
    0x07,      //  7 байт
    0x05,      // дескр-р ендпоинта
    0x82,      // EP2 IN, прочие данные
    0x03,      // interrupt
    0x00, 0x40, // размер 64 байта
    0x64          // каждые 100 мс
    };
    
const BYTE ENDPOINT2_OUT_DESCRIPTOR [] = {
    0x07,      // 7 байт
    0x05,      // дескр-р ендпоинта
    0x02,      // EP2 OUT, команды
    0x00,      // control type
    0x00, 0x40, // размер 64 байта
    0x32          // каждые 40 мс
    };

Нижайше прошу кинуть помидором в то место, где я накосячил

[toweroff]

Все в первоисточнике:
http://www.usb.org/developers/docs/usb_20_110512.zip

Код

const BYTE DEVICE_DESCRIPTOR [] = {
    0x12,      //0 0-17 (18) размер в байтах
    0x01,      //1 дескриптор устр-ва
    0x00, 0x02, //2 USB 2.0   <<<<<<<<<<<<<<<< (LSB,MSB)
    0x00,      //4 см. дескриптор интерфеса  
    0x00,      //5 см. дескриптор интерфеса
    0x00,      //6 см. дескриптор интерфеса
    0x20,      //7 размер EP 0 32 байта
    0x12, 0xab, //8 VID с потолка
    0x00, 0x01, //10 PID с потолка
    0x00, 0x01, //12 Version 1.0
    0x00,      //14 нет
    0x00,      //15 нет
    0x00,        //16 нет
    0x01          //17 1 конф-ия
    };


const BYTE CONFIG_DESCRIPTOR [] = {
    0x09,       // 9 байт
    0x02,       // дескр-р конф-ии
    0x00,0x2e,  // всего байт возвращает - 4x7 (EP) + 2x9 = 46  <<<<<< Я бы от sizeof() плясал, чтобы потом не бегать, особенно со строковыми дескрипторами
    0x01,       // 1 интерфес
    0x01,       // "1"
    0x00,       // нет
    0xc0,       // self-powered
    0x96          // 300mA
    };

const BYTE ENDPOINT1_OUT_DESCRIPTOR [] = {
    0x07,      //  7 байт
    0x05,      // дескр-р ендпоинта
    0x01,      // EP1 OUT, запись данных в ус-во
    0x03,      // interrupt
    0x40, 0x00, //  размер 64 байта <<<<<<<<<<<<<<<< (LSB,MSB)
    0x64          //  каждые 100 мс
    };

это так, навскидку

[NaughtyFreak]

спс, пошёл дальше изучтать...

Пока что опираюсь на статью "USB in a nutshell".

Сообщение отредактировал NaughtyFreak - Feb 7 2013, 10:35

[NaughtyFreak]

Да простят меня гуру да не кинут в меня тапками своими...
Вобщем пока на новую платку с LPC раскошеливаться нет желания и возможности, будем работать с чем есть, а именно поциент в лице SK-STM32F417 от любимого starterkit.ru. После досконального чтения RM и спец-ии 2.0 все встало на место. Да, двиг usb у стм конечно заморочен, но не так страшен как с 1го взгляда. Меня загнал в тупик следующий вопрос:
От чего зависет ставить ли бит NZLSOHSK или не ставить в реге DCFG? По спец-ии USB in a nutshell Zero-length data out handshake отсылает хост, типа прожевал, все ок, работаем дальше. Любая ненулевая OUT data от хоста это уже данные, след-но их нужно читать. Значит этот бит оставлять в "0"? Или я где-то страшно затупил? Ткните носом, пжлст!

[SyncLair]

Для автономных систем USB не годится. Или система превратится в неавтономную. Раз в несколько дней вы будете ездить на обслуживаемый ей объект и ее перезапускать.
Отладочные платы здесь:
http://www.starterkit.ru

Тоже купил у него отладочную плату с LPC1768 -- доволен, соединил её с LPC expresso USB пашет.
Правда там небольшая особенность -> но она касается режима Host a не Device.

[NaughtyFreak]

Еще одна непонятка с STM: их бит ENUMDNEM, сигнализирующий о конце энумерации.В RM почему-то пишут что он отвечает за конец состояния USB reset

4. Wait for the USBRST interrupt in OTG_FS_GINTSTS. It indicates that a reset has been
detected on the USB that lasts for about 10 ms on receiving this interrupt.
Wait for the ENUMDNE interrupt in OTG_FS_GINTSTS. This interrupt indicates the end of
reset on the USB. On receiving this interrupt, the application must read the OTG_FS_DSTS

По сбросу понятно - инициализирую КТ0, обнуляю адрес, сбрасываю буферы приёма/передачи и т.д, это легко. Я как-то думал что он (ENUMDNEM) должен высвечивать прерывание по окончанию энумерации когда выбрана конфигурация, а по RM по этому прерыванию нужно настроить КТ0. Или не так?

P.S. Может в отдельную тему вынести обсуждение USB в STM32? Я думаю многим интересно будет.