Помогите разобраться с USB Опции

[Vladimir_T]

Здравствуйте, уважаемые коллеги, помогите пожалуйста! Делаю USB-устройство (Device) на МК, ПК мой приборчик принимает, и принимает пакеты правильно, а вот из ПК пакеты идут длиной в один байт, т.е. если из терминальной программы через вертуальный порт отправляю строку, то эта строка приходит в МК не целиком, а побайтно... Буфер конечной точки настроены правильно, т.е. минимальный размер буфера (8 байт). Просматриваю поток с помощью программы USBlyzer так и есть строка передается побайтно... В чем может быть дело?

[Xenia]

ПК мой приборчик принимает, и принимает пакеты правильно, а вот из ПК пакеты идут длиной в один байт, т.е. если из терминальной программы через вертуальный порт отправляю строку, то эта строка приходит в МК не целиком, а побайтно... Буфер конечной точки настроены правильно, т.е. минимальный размер буфера (8 байт). В чем может быть дело?

Дело может быть в том, что ПК передает байты поштучно с паузой между ними. Тогда предыдущий байт будет отправлен, не дожидаясь остальных. USB ведь не по опросу работает, а шлёт пакеты через 1 мс (если есть чего посылать). И если за эту миллисекунду вы не успели послать второй байт, то поезд уйдет с одним пассажиром.

Для проверки надо собрать в буфере много/несколько байт, а потом отправить его целиком в виртуальный порт API-шной функцией
WriteFile( handle, buf, len, &bytes, NULL);
Но это, если ваше USB-устройство работает по CDC-протоколу, а из ПК видно, как виртуальный COM-порт. Но если ваше устройство - HID-девайс, то тогда не знаю.

[Vladimir_T]

Строку посылаю из терминальной программы в виртуальный порт по протоколу CDC. Неужели эта программа побайтно посылает в порт побайтно? Тогда как понять тот факт, что конечная точка имеет буфер, пусть 8 байт, и Host знает об этом, значит он должен все же отправить пакет такой длинны, а потом принять от девайса статус результата транзакции...

[Xenia]

Тогда как понять тот факт, что конечная точка имеет буфер, пусть 8 байт, и Host знает об этом, значит он должен все же отправить пакет такой длинны, а потом принять от девайса статус результата транзакции...

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

Вот еще добавление. На моем AT90USB647 под число принимаемых байт выделен специальный аппаратный регистр UEBCLX:

UEBCLX - Byte Count Bits
Set by the hardware:
- (for IN endpoint) increased after each writing into the endpoint and decremented after each byte sent.
- (for OUT endpoint) increased after each byte sent by the host, and decremented after each byte read by the software.

И по наличии прерывания по вектору "USB_Endpoint_Pipe" (когда приходит посылка) я забираю из буфера ТОЛЬКО то число байт, которое указано в "Byte Count", хотя буфер по размеру больше (у меня в нём 32 байта).

Отсюда следует, что либо посылки бывают более короткими, чем размер буфера, либо бывают посылки с "мусором" вместо значимых байт. Установить, которое из этих предположений истинно, не удается, т.к. аппаратная кухня от программиста закрыта. Но я полагаю первое предположение более вероятным.

[Vladimir_T]

Спасибо за обстоятельное объяснение. В моем STR912 есть тоже подобные счетчики байтов для конечных точек, именно эти счетчики и анализируются после приема.
Тогда если воспользоваться функцией ОС WriteFile (), о которой вы писали ранее, то можно все же передать пакеты, видимо...

[Xenia]

Есть еще и такая тонкость - У ПК размеры буфера тоже устанавливаются функцией API
SetupComm( handle, wInQueue, wOutQueue);
wInQueue - размер буфера не приём
wOutQueue - размер буфера не передачу
причем оба числа должны быть четными (иначе SetupComm вернет false, проигнорировав установку).

Я не знаю, что там стоит по умолчанию, т.к. сама всегда задаю свои размеры. В основном ради wInQueue, чтобы поток принимаемых байт было где хранить, т.к. в своей программе опрашиваю (ReadFile) виртуальный COM-порт по таймеру раз в секунду.

[редактор]

Большинство стандартных терминальных программ при работе с COM-портом отправляет код клавиши сразу после ее нажатия. Для передачи строки скорее всего придется написать свою прогу и использовать WriteFile(). Другой вариант проверки, запустить передачу файла (но придется реализовывать стандартный протокол обмена со стороны МК).