Стал использовать впервые USB контроллер в новых STM (до этого именно в STM не использовал) и столкнулся с проблемой совместимости с предыдущем устройством, сделанным на микроконтроллере от NXP. Дело в том, что в репорте HID устройства с USB библиотекой для STM не могу выставить номер ID репорта равным 0. Если ставлю, то устройство висит в диспетчере устройств как HID, но с восклицательным знаком, то есть Винде такое описание репорта сразу не нравиться. Любой другой номер пожалуйста, главное не 0.

Старое же моё аналогичное устройство сделанное на LPC1343, как выяснилось теперь, шлёт репорт, а главное писать в него можно, репорт у которого номер равен 0. В LPC1343 это было скрыто для разработчика и я в этот вопрос при разработке не вдавался.

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

Может ли этот номер быть нулевым и почему пример от ST не даёт этого сделать?

Спецификацию читали?

Report ID zero is reserved and should not be used.

Нет, спецификацию не читал, оставил это последним путём, вот и хотел что бы ткнули носом на конкретную строчку, как это Вы и сделали.

Но тогда остаётся вопрос - почему старое устройство на микроконтроллере LPC1343 делало именно такие репорты и Винда это съедает? И не только Винда - iOS тоже замечательно работает с этим устройством.

Видимо (не знаю), оно туда само что-то не нулевое подставляло. Возьмите сниффер, да посмотрите, что там реально по шине шло.

Так вот в том то и дело что в сниффере оттуда и идут репорты, с нулевым ID. И всё прекрасно работает. А главное, пишутся в него репорты ТОЛЬКО, если ID у них 0. С ненулевыми не пишутся!

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

А чем можно посмотреть на стадии энумерации, не посоветуете? Просто мой снифер, которым я пользуюсь, может только уже определившиеся устройства показывать.

Одно только уже для себя понял, что и пытался собственно выяснить - было сделано не правильно. Но почему работало: вопрос-загадка?

я пользуюсь USBTrace 2.6
под Win7 x64 нормально работает. Там можно захватывать непосредственно порт и смотреть все, что с ним происходит

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

Спасибо, буду пробовать!




Если оно и принимало и отправляло данные, то я так понимаю что это уже два репорта?

Проблему, совместимости решил - по сути как и посоветовал toweroff, проснифирел на стадии инициализации описание самого HID репорта от старого устройства, которое там оказалось каким то хитрым, и тупо байт в байт скопировал его в новое устройство. Это позволило отправлять данные без указания ID репорта и у которых это ID при передаче равен 0.
USBTrace 2.6 - оказалась замечательной программой! Давно бы такую...

Всем спасибо!

А скопируйте сюда этот репорт, попробуем разобраться

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


const uint8_t CustomHID_ReportDescriptor[] =
{
0x06, 0x00, 0xFF, 0x09, 0x01, 0xA1, 0x01, 0x15, 0x00, 0x26, 0xFF, 0x00, 0x75, 0x08, 0x95, 0x10, 0x09, 0x01,
0x81, 0x02, 0x95, 0x02, 0x09, 0x01, 0x91, 0x02, 0xC0
};

Я позволил себе расшифровать этот дескриптор:

В нем нет поля REPORT_ID. Поэтому в самом рапорте это поле тоже отсутствует, совсем.


Нету там ID равного нулю. Это просто байт данных. У ваш рапорт состоит из 16 8-битовых полей(REPORT_SIZE(8), REPORT_COUNT(16)). Все байты этого рапорта являются данными, как я и писал вам в самом начале.

Вот описание пункта REPORT_ID из "Device class definition fort HID":


Это не более одного в каждую сторону.

Спасибо за расшифровку, буду вникать!