Блин ... похоже рассказчик из меня ... некудышний. Попробую повторить медленно и подробно.
Сам я с Пик не работаю ( очень давно для них не программировал). Но думаю принципиальной разницы работы с чипами 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 и на Паскале. Но вполне рабочий