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

[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? Я думаю многим интересно будет.