[hd44780 0]

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

 

Короче, взял пример 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]

И ещё.

Не хочется, чтобы железка торчала в списке COM-портов.

Очень странное требование. Суть USB CDC есть эмуляция COM-порта, поэтому он и виден как COM-порт, чтобы приложения, которые работают с COM-портами, могли без изменений работать с новым железом. Если нужна коммуникация между железом и компьютером без COM-порта, надо создать иной класс USB устройства (например, HID) и гонять свой собственный протокол.

 

[hd44780 0]

Ну пусть COM-порт уже, фиг с ним ...

 

А чего только 32 байта гоняет? Кривизна ST-шных библиотек? Или моих рук?

[Juk1976 0]

Ну пусть 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]

Нашёл в интернете вот такое:

 

 #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]

А пример из библиотеки ST вы брать не пробовали? у меня на его базе пара проектов построена, работает без нареканий.

[hd44780 0]

FlexZ, это из архива STM32_USB-Host-Device_Lib_V2.1.0?

Попробовал - то же самое :( . А у Вас сколько байт за раз передаёт?

Можно конечно самому дробилку-сшивалку пакетов написать, но, может, готовое есть?

 

Может ещё какой-то пример есть? Или Вы поделитесь, если можете ....

Спасибо.

[Flexz 0]

Да, пример из этого архива.

Пачки уходят вплоть до 24кб за раз. Правда на каком-то этапе они разбиваются на блоки размером не более 4кб (видно в USBTrace). Подробно не вникал где именно, но это явно больше чем 32 байта.

Один из проектов есть в открытом доступе https://code.google.com/p/logicdiscovery/so...FLogicDiscovery

PS а вы случайно не в HS режиме его запускаете? У меня в HS режиме с внешней физикой этот код тоже тупил.

[hd44780 0]

Спасибо.

Пачки уходят вплоть до 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]

Короче, мудохался-мудохался, добился 1024 байт за раз. Сам не понял как :laughing:

Прога на C# нормально принимает в потоке.

 

Flexz, если можете, поделитесь, как у Вас 24кил получилось?

Спасибо.

[Flexz 0]

Может у вас проблема в другом месте? Кабель плохой, например..

У меня с USB на STшных процессорах никогда проблем не было - просто брал пример, заменял верхнюю часть и оно просто работало. (если не учитывать некоторых косяков в HS режиме, с которыми я так и не взялся разобраться)

[hd44780 0]

Кабель длиной где-то 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]

Вот в этом месте у меня во всех проектах немного по-другому - тело цикла вынесено в функцию, которая кладет в буфер один единственный байт (изначально делалось для 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]

Сделал, но заметил следующую странность:

 

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

 

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

 

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

 

Также, если после первой 'S' закрыть порт, и потом открыть его, то я мгновенно получаю ответ на 'S', поданный до закрытия порта.

 

Если ставлю больше килобайта, то ответов нет вообще.

 

 

Может это вообще косяки ST-шного драйвера порта, а не прошивки?

Драйвер версии 1.3.1 от 23 июля 2010, найден где-то на форумных развалах. Понимаю, что старьё, но на ST- шном сайте сам чёрт ногу сломит, ещё и глючит, зараза :(

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

[hd44780 0]

Победил я кажись эту хреновину .

 

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

Последнее, чего я достиг - APP_RX_DATA_SIZE = 11 кил, передаёт по 10 кил стабильно, без глюков и подвисаний.

 

Работает и с ST-шными дровами и общими, виндозными.