hd44780 0 7 марта, 2013 Опубликовано 7 марта, 2013 · Жалоба Понимаю, что может быть избитая и изъезженная тема тема, но всё же. Короче, взял пример COM-порта отсюда - http://we.easyelectronics.ru/STM32/primery...4-discovey.html Порт опознаётся, устанавливается, всё ок. Данные принимает, передаёт. Но. Не могу передать на комп более 32 байт. Комп просто ничего не принимает. Когда 32 байта и меньше всё в порядке. Это ж отстой полный, хуже чем даже USB HID Generic - 64 байта туда-сюда-обратно. И тот кстати не получается. Примеры - сплошные мыши и джойстики :( ... Это что, норма? И как этого избежать? Размер буферов в прошивке вроде 2 кила - макрос APP_RX_DATA_SIZE = 2048. И ещё. Не хочется, чтобы железка торчала в списке COM-портов. Взял финский пример отсюда - http://forum.easyelectronics.ru/viewtopic....=35&t=10245 Он пошёл без проблем, комп его увидел. Но где взять драйвер? Нашёл libusb, драйвер им сгенерил, но как с ним дальше работать не понял... Может ли кто-нибудь помочь? Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KnightIgor 2 7 марта, 2013 Опубликовано 7 марта, 2013 · Жалоба И ещё. Не хочется, чтобы железка торчала в списке COM-портов. Очень странное требование. Суть USB CDC есть эмуляция COM-порта, поэтому он и виден как COM-порт, чтобы приложения, которые работают с COM-портами, могли без изменений работать с новым железом. Если нужна коммуникация между железом и компьютером без COM-порта, надо создать иной класс USB устройства (например, HID) и гонять свой собственный протокол. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
hd44780 0 7 марта, 2013 Опубликовано 7 марта, 2013 · Жалоба Ну пусть COM-порт уже, фиг с ним ... А чего только 32 байта гоняет? Кривизна ST-шных библиотек? Или моих рук? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Juk1976 0 7 марта, 2013 Опубликовано 7 марта, 2013 · Жалоба Ну пусть COM-порт уже, фиг с ним ... А чего только 32 байта гоняет? Кривизна ST-шных библиотек? Или моих рук? КакбЕ #ifdef USB_OTG_FS_CORE #define RX_FIFO_FS_SIZE 128 #define TX0_FIFO_FS_SIZE 32 #define TX1_FIFO_FS_SIZE 128 #define TX2_FIFO_FS_SIZE 32 #define TX3_FIFO_FS_SIZE 0 в файле usb_conf.h строка 144 Глубоко не копал - может отсюда ноги ростут??? У меня HID - проблем нет Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
hd44780 0 8 марта, 2013 Опубликовано 8 марта, 2013 · Жалоба Нашёл в интернете вот такое: #define RX_FIFO_FS_SIZE 128 #define TX0_FIFO_FS_SIZE 64 #define TX1_FIFO_FS_SIZE 128 #define TX2_FIFO_FS_SIZE 0 #define TX3_FIFO_FS_SIZE 0 Поставил себе - ничего не изменилось. Кстати размер конечных точек - по 64 байта ... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flexz 0 8 марта, 2013 Опубликовано 8 марта, 2013 · Жалоба А пример из библиотеки ST вы брать не пробовали? у меня на его базе пара проектов построена, работает без нареканий. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
hd44780 0 8 марта, 2013 Опубликовано 8 марта, 2013 · Жалоба FlexZ, это из архива STM32_USB-Host-Device_Lib_V2.1.0? Попробовал - то же самое :( . А у Вас сколько байт за раз передаёт? Можно конечно самому дробилку-сшивалку пакетов написать, но, может, готовое есть? Может ещё какой-то пример есть? Или Вы поделитесь, если можете .... Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flexz 0 8 марта, 2013 Опубликовано 8 марта, 2013 · Жалоба Да, пример из этого архива. Пачки уходят вплоть до 24кб за раз. Правда на каком-то этапе они разбиваются на блоки размером не более 4кб (видно в USBTrace). Подробно не вникал где именно, но это явно больше чем 32 байта. Один из проектов есть в открытом доступе https://code.google.com/p/logicdiscovery/so...FLogicDiscovery PS а вы случайно не в HS режиме его запускаете? У меня в HS режиме с внешней физикой этот код тоже тупил. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
hd44780 0 9 марта, 2013 Опубликовано 9 марта, 2013 · Жалоба Спасибо. Пачки уходят вплоть до 24кб за раз. Правда на каком-то этапе они разбиваются на блоки размером не более 4кб (видно в USBTrace). Подробно не вникал где именно, но это явно больше чем 32 байта. Круто :laughing: . Один из проектов есть в открытом доступе https://code.google.com/p/logicdiscovery/so...FLogicDiscovery Да, натыкался на него, только с головы вылетел, посмотрю. Вот, кстати, статья от этого кода - http://habrahabr.ru/post/165853/ PS а вы случайно не в HS режиме его запускаете? У меня в HS режиме с внешней физикой этот код тоже тупил. Нет, FS. HS физика в виде маленькой платки с USB3300 ко мне пока едет ... С ней буду потом разбираться. Когда доедет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
hd44780 0 9 марта, 2013 Опубликовано 9 марта, 2013 · Жалоба Короче, мудохался-мудохался, добился 1024 байт за раз. Сам не понял как :laughing: Прога на C# нормально принимает в потоке. Flexz, если можете, поделитесь, как у Вас 24кил получилось? Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flexz 0 10 марта, 2013 Опубликовано 10 марта, 2013 · Жалоба Может у вас проблема в другом месте? Кабель плохой, например.. У меня с USB на STшных процессорах никогда проблем не было - просто брал пример, заменял верхнюю часть и оно просто работало. (если не учитывать некоторых косяков в HS режиме, с которыми я так и не взялся разобраться) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
hd44780 0 11 марта, 2013 Опубликовано 11 марта, 2013 · Жалоба Кабель длиной где-то 30 см от телефона Nokia X2-02. Точнее куплен был отдельно для этого телефона. Плюс USB удлинитель 1.8м, т.к. эти 30 см короткие... Может я отсылку данных неправильно осуществляю. В библиотеках драйвера есть метод uint16_t VCP_DataTx (uint8_t* Buf, uint32_t Len), который вроде и предназначен для отсылки данных в комп: uint16_t VCP_DataTx (uint8_t* Buf, uint32_t Len) { uint32_t i; // loop through buffer for( i = 0; i < Len; i++ ) { // буфер APP_Rx_Buffer используется драйвером USB APP_Rx_Buffer[APP_Rx_ptr_in] = (uint8_t) Buf[i]; //increase pointer value APP_Rx_ptr_in++; // To avoid buffer overflow if(APP_Rx_ptr_in == APP_RX_DATA_SIZE) { APP_Rx_ptr_in = 0; } } // for return USBD_OK; } // VCP_DataTx Т.е. он просто копирует мои данные во внутренний буфер драйвера. Константа APP_RX_DATA_SIZE равна 2048, т.е. 2 кила он должен вроде отсылать. Этот метод я и вызываю для отсылки своих данных в комп. Единственное, что я изменил - убрал с него модификатор static, чтобы его можно было извне вызывать ... Может из-за этого косяки и его надо через какую-то функцию-обёртку вызывать (я такое где-то видел)? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flexz 0 11 марта, 2013 Опубликовано 11 марта, 2013 · Жалоба Вот в этом месте у меня во всех проектах немного по-другому - тело цикла вынесено в функцию, которая кладет в буфер один единственный байт (изначально делалось для putchar). uint16_t VCP_ByteTx (uint8_t dataByte) { 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; } В том проекте, на который я выше ссылку давал, перемещение массива в буфер дополнительно обернуто в запрет прерываний, и там тоже по байту кладется. Возможно, это имеет значение, по-другому я даже не пробовал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
hd44780 0 11 марта, 2013 Опубликовано 11 марта, 2013 · Жалоба Сделал, но заметил следующую странность: У меня сейчас работа организована в формате "запрос-ответ", т.е. комп шлёт команду (символ 'S'), железяка в ответ должна выплюнуть некий объём информации. Сейчас для отладки выплёвывает синусоиду, которая рассчитывается в коде и ни от чего не зависит. Так вот, когда я выплёвываю до 32 байт, все работает как и задумано, а если больше (например килобайт), то на первую команду ответа нет вообще (ждал до 10 сек), но как только я пуляю в него ещё один 'S', то я мгновенно получаю 2 кила синусоиды (причём там явно видно, что это именно 2 разных независимых ответа, т.к. синусоида на конце килобайта "оторванная", не дошедшя до конца периода). Такое ощущение, что данные где-то "залипают". Буфер приёма на компе задан 10 кил, т.е. он с гарантией ничего не потеряет. Также, если после первой 'S' закрыть порт, и потом открыть его, то я мгновенно получаю ответ на 'S', поданный до закрытия порта. Если ставлю больше килобайта, то ответов нет вообще. Может это вообще косяки ST-шного драйвера порта, а не прошивки? Драйвер версии 1.3.1 от 23 июля 2010, найден где-то на форумных развалах. Понимаю, что старьё, но на ST- шном сайте сам чёрт ногу сломит, ещё и глючит, зараза :( винда - 2003 сервер. С COM-портами работать умею, т.к. по профессии программист. Недавно 3 кассоовых аппарата завёл через COM-порт. Работают нормально. Из 2-х из них данные вообще льются как из ведра непрерывным потоком, успевай ловить.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
hd44780 0 11 марта, 2013 Опубликовано 11 марта, 2013 · Жалоба Победил я кажись эту хреновину . Западло (по крайней мере в моём случае) заключалось в том, что объём передаваемых данных должен быть как минимум на килобайт меньше размера буфера APP_RX_DATA_SIZE. Последнее, чего я достиг - APP_RX_DATA_SIZE = 11 кил, передаёт по 10 кил стабильно, без глюков и подвисаний. Работает и с ST-шными дровами и общими, виндозными. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться