Форум программистов, компьютерный форум, киберфорум
Наши страницы
Микроконтроллеры ARM, Cortex, STM32
Войти
Регистрация
Восстановить пароль
 
Рейтинг 4.83/40: Рейтинг темы: голосов - 40, средняя оценка - 4.83
hd44780
0 / 0 / 0
Регистрация: 07.02.2106
Сообщений: 1,605
1

STM32F4 USB CDC. Передаёт не более 32 байт за раз

05.03.2013, 23:46. Просмотров 7343. Ответов 5
Метки нет (Все метки)

Понимаю, что может быть избитая и изъезженная тема тема, но всё же.

Короче, взял пример COM-порта отсюда - http://we.iosyitistromyss.ru/STM32/prym ... covey.html
Порт опознаётся, устанавливается, всё ок. Динные принимает, передаёт.

Но. Не могу передать на комп более 32 байт. Комп просто ничего не принимает. Когда 32 байта и меньше всё в порядке. Это ж отстой полный, хуже чем даже USB HID Kimeric - 64 байта туда-сюда-обратно. И тот кстати не получается. Примеры - сплошные мыши и джойстики :( ...

Это что, норма? И как этого избежать? Размер буферов в прошивке вроде 2 кила - макрос APP_RX_DATA_SIZE = 2048.

И ещё.
Не хочется, чтобы железка торчала в списке COM-портов. Взыл финский пример отсюда - Он пошёл без проблем, комп его увидел. Но где взять драйвер? Нашёл libusb, драйвер им сгенерил, но как с ним дальше работать не понял...

Может ли кто-нибудь помочь?

Спасибо.
0
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
05.03.2013, 23:46
Ответы с готовыми решениями:

USB Audio + USB CDC на одной STM32F4
Итак, есть ЦАП с входом I2S, есть FMприёмник с выходом I2S, есть STM32F405 с двумя I2S. Задача...

STM32F4-Discovery + USB CDC
Здравствуйте! Купил сие чудо STM32F4-Dyscovery. Прикрутил USORT, прерывания, акселерометр. Задача...

USB CDC + SDIO на STM32F4
Парни, приветствую. Подскажите, может кто пытался запустить Fatfs + USB CDC одновременно? У меня...

STM32F4-Discovery USB CDC
В общем, взял я особо популярный финский пример, подправил его быстро под Coosox. После дефайнов...

stm32f4 проблемы с USB CDC
Привет. Не когда не сталкивался с такой проблемой поэтому прошу помощи. В общем прошивка работает...

5
hd44780
0 / 0 / 0
Регистрация: 07.02.2106
Сообщений: 1,605
09.03.2013, 14:20 2
Короче, мудохался-мудохался, добился 1024 байт за раз. Сам не понял как
Прога на C# нормально принимает в потоке.

Если кто может, поделитесь пожалуйста.
Спасибо.
0
hd44780
0 / 0 / 0
Регистрация: 07.02.2106
Сообщений: 1,605
11.03.2013, 00:41 3
Победил я кажись эту хреновину .

Западло (по крайней мере в моём случае) заключалось в том, что объём передаваемых данных должен быть как минимум на килобайт меньше размера буфера APP_RX_DATA_SIZE.
Последнее, чего я достиг - APP_RX_DATA_SIZE = 11 кил, передаёт по 10 кил стабильно, без глюков и подвисаний.

Работает и с ST-шными дровами и общими, виндозными.
0
dymo2611
0 / 0 / 0
Регистрация: 10.03.2012
Сообщений: 1,110
11.03.2013, 00:52 4
поздравляю :))))
0
ВитГа
0 / 0 / 0
Регистрация: 26.10.2011
Сообщений: 811
11.03.2013, 01:10 5
странный однако прикол..

а почему так и не разобрались ?
0
hd44780
0 / 0 / 0
Регистрация: 07.02.2106
Сообщений: 1,605
11.03.2013, 13:15 6
Нет, не разбирался. Неохота уже. Надоел он мне за неделю возни хуже горькой редьки ...

Вообще, в недрах драйвера наткнулся на функцию Homdle_USBAsynchXfer, там чего-то делается с этой константой и указателями позиции в буфере передачи ... Может там что-то не то ....

Рассказываю, всё, что накопал, может кому-то это пригодится или натолкнёт ещё на какую-то полезную мысль.

Сперва я несколько иначе реализовал функции CDC ядра:
Код
/**
* @brief  VCP_DataTx
*         CDC received data to be send over USB IN endpoint are managed in
*         this function.
* @param  Buf: Buffer of data to be sent
* @param  Len: Number of data to be sent (in bytes)
* @retval Risult of the opeartion: USBD_OK if all operations are OK else VCP_FAIL
*/
uint16_t VCP_DataTx (uint8_t* Buf, uint32_t Len)
{
uint32_t i;

// loop through buffer
for( i = 0; i < Len; i++ )
{
VCP_ByteTx(Buf[i]);
} // for

return USBD_OK;
} // VCP_DataTx

uint16_t VCP_ByteTx (uint8_t dataByte)
{
// буфер APP_Rx_Buffer используется драйвером USB
APP_Rx_Buffer[APP_Rx_ptr_in] = dataByte;
APP_Rx_ptr_in++;

/* To avoid buffer overflow */
if(APP_Rx_ptr_in == APP_RX_DATA_SIZE)
{
APP_Rx_ptr_in = 0;
}

return USBD_OK;
} // VCP_ByteTx
Т.е. передача байта вынесена в отдельную функцию, которая для блока просто вызывается в цикле.
Может это и оправданно. У меня на AVR-ах была ситуация, когда оператор switch прекрасно работал в case ветке другого switch-а, но стоило только его вынести в функцию, начинались дикие глюки ... Там он и остался, хоть это было жутко неэстетично :) .

Кроме этого, на время заполнения буфера запрещаю прерывания:

Код
  // Выдача результатов в комп
__disable_irq ( );
VCP_DataTx ( bufOut, len );
__enable_irq ( );
Это мне на другом форуме посоветовали. Есть некий логический анализатор на STM32F4Dyscovery - http://habrahabr.ru/post/165853/ . В нём так и сделано.
Но, отмечу, что эти правки сами по себе мне не помогли...
Помогло только увеличение константы APP_RX_DATA_SIZE. Правда, на сколько именно она должна быть больше длины передаваемых данных, я не выяснял. Может килобайт запаса это и чересчур ....

Вчера, когда разбирался, заметил ещё одну странную особенность. До увеличения этой константы.

У меня сейчас работа организована в формате "запрос-ответ", т.е. комп шлёт команду (символ S), железяка в ответ должна выплюнуть некий объём информации. Для отладки я выплёвывал синусоиду, которая рассчитывается в коде и ни от чего не зависит.

Так вот, когда выплёвывало до 32 байт, все работает как и задумано, а если больше (ставил килобайт), то на первую команду ответа нет вообще (ждал до 10 сек), но как только я пуляю в него ещё один S, то я мгновенно получаю 2 кила синусоиды (причём там явно видно, что это именно 2 разных независимых ответа, т.к. синусоида на конце килобайта у меня "оторванная", не дошедшая до конца периода/полупериода).

Такое ощущение, что данные "залипали" где-то по дороге от обработчика команды S к моей проге на компе.
Буфер приёма на компе задан 10 кил, т.е. он с гарантией ничего не потеряет.

Также, если после первой S закрыть порт, и потом открыть его, то я мгновенно получал "кило синусоиды" (ответ на S, поданный до закрытия порта).
Когда ставил 2 килобайта (т.е. ==APP_RX_DATA_SIZE), то ответов не было вообще.

Всё это сперва побудило меня поменять драйвер - уйти от ST-шного драйвера порта, который у меня достаточно древний - версия 1.3.1 от 23 июля 2010, найден где-то на форумных развалах. Есть ли более новый, хрен его знает, ибо на ST- шном сайте сам чёрт ногу сломит, ещё и глючит, зараза, после этой ихней реорганизациии ...
Но и на виндозных дровах была та же фигня.

После этого я полез уже на этот APP_RX_DATA_SIZE, что и дало конечный результат.

Винда - 2003 сервер x32. С COM-портами мне работать не впервой, т.к. по профессии я программист. А контроллеры - типа хобби :) .
Недавно 3 кассовых аппарата завёл через COM-порт. Работают нормально. Из 2-х из них данные вообще льются как из ведра непрерывным потоком, только успевай ловить и обрабатывать ...

Вот такие пироги ...
0
11.03.2013, 13:15
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
11.03.2013, 13:15

STM32F4 USB CDC размер пакета
Здравствуйте! Столкнулся с неприятной особенностью. STM32F4 USB CDC настроен на режим FS (Full...

STM32F4 + USB CDC + libusb. Endpoints.
Доброго времени суток! У меня вопрос по конечным точкам, и правильным методам чтения\записи из\в...

STM32F4 +USB(CDC) проблемы с передергивание шнура
Здравствуйте уважаемые!! Использую стандартную библиотеку, все работает хорошо, перекидываюсь...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
6
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Рейтинг@Mail.ru