Перейти к содержанию
    

Передача большого массива данных от МК к PC (STMicroelectronics Virtual COM Port)

Камень STM32F405

Задача требуется передавать большой массив данных по виртуальному COM порту.

За основу взял пример от ST, COM порт определился, попробывал передавать данные вот так:

 

    for( i = 0; i < Len; i++ )
    {
        //push data into transfer buffer
        APP_Rx_Buffer[APP_Rx_ptr_in] = 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;
        }
    }

данные до размера APP_RX_DATA_SIZE=2048 передает, а вот как сделать чтоб мог передавать свыше APP_RX_DATA_SIZE?

Нужно что то вроде прерывания по окончанию передачи и определять значение сколько можно еще дописать в APP_Rx_Buffer...

Вариант увеличения APP_RX_DATA_SIZE не вариант, т.к. свободной памяти мало.

Пожалуйста направьте в нужном направлении.

Изменено пользователем IgorKossak
[codebox] для длинного кода, [code] - для короткого!!!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Заметил еще проблему...

Если массив данных более 64 байт, то переодически происходят сбои в передаче данных...

Кто сталкивался? Подскажите что не так делаю?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Размер буфера данных между конечными точками не должен превышать 64Б, по стандарту USB. Таким образом вы и передавайте блоками, кратными 64Б, если последний блок будет 64Б, то потребуется передать дополнительный пустой блок. Пользуюсь примером от ST, правда процессор STR912, удается передавать до 62 кБ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Размер буфера данных между конечными точками не должен превышать 64Б, по стандарту USB. Таким образом вы и передавайте блоками, кратными 64Б, если последний блок будет 64Б, то потребуется передать дополнительный пустой блок. Пользуюсь примером от ST, правда процессор STR912, удается передавать до 62 кБ.

Опишите пожалуйста, если можно с примером, как реализованно заполнение буфера?

Заполняете 64байта, потом ждете какой-то таймаут или прерывание по окончании передачи? затем вновь 64 байта...?

Отключаете ли прерывание USB на время заполнения буфера в цикле?

Не происходят ли переодические сбои при передачи больших массивов данных?

Изменено пользователем js_slider

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

не совсем верно, это при передачи через контрольную точку 64 байта пакеты. Но вроде виртуальный ком порт еще 2 интерапт точки делает, а там размер буфера 1024 бита вроде как...

 

сбои которые вы видите, видят многие, пока есть мнение что какие то ошибки в драйверах винды, но может вы видите какие то другие сбои.

 

Как работает USB лучше почитать стандарт. Смысл в том что USB с вашей стороны это слейв, его опрашивает мастер, если грубо и коротко, то каждую милисекунду проверяют наличие данных, и если они есть они уходят в компьютер. При этом есть 2 вида пакетов DATA1, DATA2 и они уходят по очереди, это как раз чтобы пока отгружают первый буфер, второй уже набивался.

 

По уму ваша задача решается через ДМА, которая из огромного буфера отгружает данные, но можно и проще. Полингом проверять ушел прошлый пакет, и если ушел, то добавлять новый...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

сбои которые вы видите, видят многие, пока есть мнение что какие то ошибки в драйверах винды, но может вы видите какие то другие сбои.

Сбои заключаются в том что посланный массив данных от МК к PC, не доходит весь, а частично где то теряется.

Как решается данная задача потери? неужели это не лечится на VCP?

 

По поводу DMA.. USB у меня работает в режиме FullSpeed, как я понял в этом режиме нет поддержки DMA у ST32F4, поправте если ошибаюсь.

 

но можно и проще. Полингом проверять ушел прошлый пакет, и если ушел, то добавлять новый...

Люди добрые покажите примером как это можно сделать... как понять что буфер APP_Rx_Buffer[] освободился на N-ое кол-во байт...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот, потеря данных...

http://electronix.ru/forum/index.php?showtopic=118917

вот ваши коллеги...

 

а вот еще

http://electronix.ru/forum/index.php?showtopic=118369

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У коллег ветка заглохла.. и без результатно в отношении потери данных... Неужели Virtual COM Port не способен стабильно работать... работают же как то FTDI и им подобные...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

у коллег по первой ссылке ближе к концу был пример как сделать передачу. А мой знакомый разработчик который боролся с этой проблемой сказал что увеличение таймаута ожидания данных ему помогло. Ну и конечно стандартное решение, при долгом отсутствии данных - переконект. В общем пока что я видел в качестве решения - заплатки. А FTDI еще имеет свой драйвер, и все обычно в конце на него переходят, неспроста....

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я уже конечно давно не работал с CDC, но по-моему скорей всего ТС просто не разобрался со своим стеком.

Когда я работал с CDC (на стеке LPC и его CPU), никаких таких потерь не было. Вообще.

API для юзера там позволяло отправлять и большие блоки (они разбивались внутри стека).

Уведомление о завершении передачи от стека (и подкачка новых данных) там было сделано через callback-вызовы.

 

не совсем верно, это при передачи через контрольную точку 64 байта пакеты. Но вроде виртуальный ком порт еще 2 интерапт точки делает, а там размер буфера 1024 бита вроде как...

У меня сейчас в комп воткнуты два разных (с разными дровами) USB-COM. В обоих имеется только по два bulk-эндпоинта. Никаких интеррапт.

Не уверен, но возможно FS позволяет несколько транзакций с одной bulk-точкой за один 1мс-фрейм. Надо читать описание USB.

 

PS: Нет, сорри - в одном из CDC-устройств имеется одна интеррапт-точка. Но размер её == 2байта с интервалом 1мс. А значит - в ней только какие-то статусы передаются.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я давно не ковырял USB, так что вполне могу ошибаться. Помниться что 90% идет через контрольную конечную точку, и помниться что вроде в стандарте было еще 2 какие то конечные точки, почему то казалось что interrupt. Но bulk тоже подходит.

 

 

на interrupt наверное RTS, CTS повесили:)

 

HS - устройства точно имеют микрофреймы внутри милисекундного кадра, вроде как 8 микрофреймов, FS и LS не должны иметь. Хотя в стандарте было как-то путано написано, но вроде как решили что речь идет о передаче через несколько конечных точек одновременно...

 

Вот почитал стандарт. Bulk обмен для FS устройств может делать до 19 передач в один фрайм, буфера размером 64 байта.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот почитал стандарт. Bulk обмен для FS устройств может делать до 19 передач в один фрайм, буфера размером 64 байта.

Вот! я же слышал где-то звон, но не помнил где он ;)

Как я помню стратегию bulk - она самая низкоприоритетная, но одна точка может занимать весь канал и обеспечивать 100% скорости всей USB-FS

при отсутствии передач по другим точкам. 19*64=1216 - как раз полные 100% скорости USB.

А фрагментацию должен стек осуществлять. Стек от LPC умеет её делать, и для Control-кадров тоже.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Виртуальный COM, как отмечалось, использует bulk трансфер. PC-шные bulk-драйверы умеют принимать только заранее известный объем данных. Для передачи этой информации используются дополнительные interrupt ендпоинты. Оба типа обменов, естественно, должны быть жестко засинхронизированы. Именно потерями на синхронизацию объясняется невозможность достижения максимальнх скоростей при использовании FTDI. И именно проблемами этой синхронизации (IMXO) объясняются обсуждавшиеся потери информации в направлении девайс - РС.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да ну, правда что-ль? ;)

Интересно - как тогда пашет тот мой USB-COM, в котором только две bulk-точки? А ведь как-то умудряется на 230400, а местами и на 460800 работать!

CP210x

А что мешает драйверу периодически (раз в неск. мс) опрашивать эти самые bulk-точки, а в CP210x иметь буфер на несколько размеров bulk-точки?

Конечно - если есть интеррапт, то оно вроде как само. Но не надо забывать, что любые транзакции, с любыми типами точек (и даже interrupt и isochronous),

инициирует хост-драйвер. Точно также и драйвер конкретного устройства может периодически инициировать транзакции со своими bulk-точками.

Ну конечно когда ему выдадут ресурс времени в соответствии с приоритетом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

...А ведь как-то умудряется на 230400, а местами и на 460800 работать!...

Даже Ваши 460800 это как-то не совсем USB-шные теоретические 12Мb...

 

А что мешает драйверу периодически (раз в неск. мс) опрашивать эти самые bulk-точки, а в CP210x иметь буфер на несколько размеров bulk-точки?

Что мешает - не знаю. Знаю, как работают функции bulk_read из известных мне драйверов. Знаю (из собственного опыта), что "обычный" bulk-обмен

(с фиксированным размером пакета) достаточно легко пoзволяет скорости до 750kB/s и работает часами без потерь информации, а моя единственная

(может быть не очень умелая) попытка организовать обмен пакетами пермеменной длины с приемлемой (более 300 kB/s) скоростью закончилась такими

же результатами, как и те, что имеет сообщество с виртуальным (не FTDI) COM

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...