Полноценный драйвер USB

[mike-y-k]

worldmasters, клавиатура на USB работает и при загрузке Windows, а это классическое использование именно HID устройства. Потом можно будет с минимумом затрат ещё и на синий зуб перенести , там тоже есть HID.

[Исбанни]

И где тут полноценные дрова?? Эти статьи я читал там CDC и HID

Впишите нужные вам VID и PID - и будут вам полноценные дрова

Чтобы через драйвер можно было запросить текстовые строки, числа и тп.

Ясно. Классическая терминалка, VCP. Это класс CDC, ничего сложного.

[worldmasters]

А если мне нужна скорость передачи выше чем 64кбит/с как быть?

[DanilinSA]

А что мешает реализовать скорость UART 460800 или 921600 бод?

Или делай обычный обмен на протоколе конечных точек. Для WinUSB дрова не нужны. И реализовать не сложно.

[worldmasters]

А что мешает реализовать скорость UART 460800 или 921600 бод?

Или делай обычный обмен на протоколе конечных точек. Для WinUSB дрова не нужны. И реализовать не сложно.

Не понял?? А поподробнее?
Как можно сделать усарт с такой скоростью если базовая скорость для CDC класса 64 кбс.

[DanilinSA]

Нету там ограничения 64 кбс. Разве что принудительно в драйвере.
Если через CDC отправлять пакеты по 127 байт каждую 1 мс :
127 байт / 0.001 с * 8 бит = 1*016*000 Бит/с
Обычно 200-300-500 кбс без проблем пролетают.

Например: http://cxem.net/mc/mc269.php
Посмотри там на достигнутые скорости на скринах. И подозреваю в скорость работы МК уперлись. И это в режиме передачи CDC.

[worldmasters]

Нету там ограничения 64 кбс. Разве что принудительно в драйвере.
Если через CDC отправлять пакеты по 127 байт каждую 1 мс :
127 байт / 0.001 с * 8 бит = 1*016*000 Бит/с
Обычно 200-300-500 кбс без проблем пролетают.

Например: http://cxem.net/mc/mc269.php
Посмотри там на достигнутые скорости на скринах. И подозреваю в скорость работы МК уперлись. И это в режиме передачи CDC.

Ну как я могу отправлять каждую мс если после передачи буфера в класс USB для передачи у меня флаг BUSY висит до тех пор пока данные не уйдут. А в USB только мастер он же комп может инициировать передачу данных и по протоколу вроде как для стандартных классов CDC и HID определена максимальная скорость в 64 кбс скорее всего эта скорость получается из скорости опроса устройства мастером. Или я не прав?

[DanilinSA]

Стоп. Если отправлять по 64 байта каждый 1 мс - то получите что имеете.
Увеличивайте размеры буфера и обьем пересылаемого пакета.

Во первых увеличьте буфер. На стороне МК и на стороне ПК. ›1 кБ.
Во вторых - обьеденяем наши куски в рамках одного кадра.

Кадр USB FS равен 1 мс, поэтому, если ты поместишь 64 байта в буфер (используя функцию HAL), он отправит эти 64 байта в следующий кадр. И он не будет отправлять больше данных, пока через 1 мс не будет другой кадр.

Но! В кадре может быть много пакетов от ЕР! Хост будет просить у endpoint'а столько раз по 64 байта, пока endpoint не вернёт кусок данных с длиной меньше 64. Тогда хост "отвяжется" и будет считать, что вся информация большого размера собрана.

Тебе нужно в прерывание EP1_IN вставить отправку 64 байт ( USB_SIL_Write(EP1_IN, answer, 64);
SetEPTxValid(ENDP1)
пока не передаст все что нужно, а потом передать нулевой массив (Zero Length Packet) ?

Примерно так "на пальцах"

[worldmasters]

Стоп. Если отправлять по 64 байта каждый 1 мс - то получите что имеете.
Увеличивайте размеры буфера и обьем пересылаемого пакета.

Во первых увеличьте буфер. На стороне МК и на стороне ПК. ›1 кБ.
Во вторых - обьеденяем наши куски в рамках одного кадра.

Кадр USB FS равен 1 мс, поэтому, если ты поместишь 64 байта в буфер (используя функцию HAL), он отправит эти 64 байта в следующий кадр. И он не будет отправлять больше данных, пока через 1 мс не будет другой кадр.

Но! В кадре может быть много пакетов от ЕР! Хост будет просить у endpoint'а столько раз по 64 байта, пока endpoint не вернёт кусок данных с длиной меньше 64. Тогда хост "отвяжется" и будет считать, что вся информация большого размера собрана.

Тебе нужно в прерывание EP1_IN вставить отправку 64 байт ( USB_SIL_Write(EP1_IN, answer, 64);
SetEPTxValid(ENDP1)
пока не передаст все что нужно, а потом передать нулевой массив (Zero Length Packet) ?

Примерно так "на пальцах"

Ох ты ж .... То есть вы предлагаете типа кольца сделать и в таймере каждую мс проверять состояние BUSY и дальше закладывать очередной пакет??

Так блин ... каждую мс отправляется 64 байта пакет. В секунде 1000мс то есть 64000 байт в сек максимум.
Или опять не так мыслю?

[DanilinSA]

Блин ... похоже рассказчик из меня ... некудышний. Попробую повторить медленно и подробно.

Сам я с Пик не работаю ( очень давно для них не программировал). Но думаю принципиальной разницы работы с чипами STM.

И уходи от принудительной проверки BUSY. Это очень плохой стиль работы. Все ресурсы тратятся на проверку. Используй обработчики прерываний. Все станет гораздо проще. Не нужно будет постоянно крутиться в цикле проверки. Подпрограммы проверки и передачи сами отработают когда нужно будет.

Смотри: каждую 1 мс хост посылает запрос. Один пакет OUT, device его принимает и обрабатывает. Потом хост присылает пакет IN, чтобы забрать данные от device. Размер пакета 64 байта.
По умолчанию - у тебя все работает по схеме "один запрос-›один пакет". И естественно скорость будет "никакая".

Период 1 мс и размер пакета фиксирован. Это ты не можешь изменить. Это стандарт. Но можно ответить несколькими пакетами на запрос!
Но можно передать и больше за запрос! Hост будет просить у endpoint'а столько раз по 64 байта, пока endpoint не вернёт кусок данных с длиной меньше 64. Тогда хост "отвяжется" и будет считать, что вся информация большого размера собрана.

Скорее всего у вас передача неправильно организована. Если дело в этом, то хост, получив первые 64 байта и не дождавшись намерения endpoint'а посылать ещё, прекращает запросы до следующего фрейма (через 1 миллисекунду).

Сделай:

Первым делом увеличиваем размер приемного буфера на приемной стороне (Host). По умолчанию там обычно 64 байта. Ставь 2 килобайта.

Потом на device прописываешь USB CDC. Обычный, типовой. 2 endpoint`a EP1_IN и EP2_OUT.

И в рамках одного фрейма пихаешь данные в канал по 64 байта. Пока все не передашь. Потом кидаешь "zlp" (Zero Length Packet) как сигнал хосту о окончании данных. Таким образом можно пропихнуть за один фрейм гораздо больше чем 64 байта. Только выше теоретического порога не прыгай и по времени больше чем 1 мс не затягивай.

В принципе могу и пример набросать. Но он будет для STM и на Паскале. Но вполне рабочий