js_slider 0 19 мая, 2014 Опубликовано 19 мая, 2014 (изменено) · Жалоба Камень 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 не вариант, т.к. свободной памяти мало. Пожалуйста направьте в нужном направлении. Изменено 19 мая, 2014 пользователем IgorKossak [codebox] для длинного кода, [code] - для короткого!!! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
js_slider 0 19 мая, 2014 Опубликовано 19 мая, 2014 · Жалоба Заметил еще проблему... Если массив данных более 64 байт, то переодически происходят сбои в передаче данных... Кто сталкивался? Подскажите что не так делаю? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Vladimir_T 1 19 мая, 2014 Опубликовано 19 мая, 2014 · Жалоба Размер буфера данных между конечными точками не должен превышать 64Б, по стандарту USB. Таким образом вы и передавайте блоками, кратными 64Б, если последний блок будет 64Б, то потребуется передать дополнительный пустой блок. Пользуюсь примером от ST, правда процессор STR912, удается передавать до 62 кБ. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
js_slider 0 19 мая, 2014 Опубликовано 19 мая, 2014 (изменено) · Жалоба Размер буфера данных между конечными точками не должен превышать 64Б, по стандарту USB. Таким образом вы и передавайте блоками, кратными 64Б, если последний блок будет 64Б, то потребуется передать дополнительный пустой блок. Пользуюсь примером от ST, правда процессор STR912, удается передавать до 62 кБ. Опишите пожалуйста, если можно с примером, как реализованно заполнение буфера? Заполняете 64байта, потом ждете какой-то таймаут или прерывание по окончании передачи? затем вновь 64 байта...? Отключаете ли прерывание USB на время заполнения буфера в цикле? Не происходят ли переодические сбои при передачи больших массивов данных? Изменено 19 мая, 2014 пользователем js_slider Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 19 мая, 2014 Опубликовано 19 мая, 2014 · Жалоба не совсем верно, это при передачи через контрольную точку 64 байта пакеты. Но вроде виртуальный ком порт еще 2 интерапт точки делает, а там размер буфера 1024 бита вроде как... сбои которые вы видите, видят многие, пока есть мнение что какие то ошибки в драйверах винды, но может вы видите какие то другие сбои. Как работает USB лучше почитать стандарт. Смысл в том что USB с вашей стороны это слейв, его опрашивает мастер, если грубо и коротко, то каждую милисекунду проверяют наличие данных, и если они есть они уходят в компьютер. При этом есть 2 вида пакетов DATA1, DATA2 и они уходят по очереди, это как раз чтобы пока отгружают первый буфер, второй уже набивался. По уму ваша задача решается через ДМА, которая из огромного буфера отгружает данные, но можно и проще. Полингом проверять ушел прошлый пакет, и если ушел, то добавлять новый... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
js_slider 0 19 мая, 2014 Опубликовано 19 мая, 2014 · Жалоба сбои которые вы видите, видят многие, пока есть мнение что какие то ошибки в драйверах винды, но может вы видите какие то другие сбои. Сбои заключаются в том что посланный массив данных от МК к PC, не доходит весь, а частично где то теряется. Как решается данная задача потери? неужели это не лечится на VCP? По поводу DMA.. USB у меня работает в режиме FullSpeed, как я понял в этом режиме нет поддержки DMA у ST32F4, поправте если ошибаюсь. но можно и проще. Полингом проверять ушел прошлый пакет, и если ушел, то добавлять новый... Люди добрые покажите примером как это можно сделать... как понять что буфер APP_Rx_Buffer[] освободился на N-ое кол-во байт... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 19 мая, 2014 Опубликовано 19 мая, 2014 · Жалоба Вот, потеря данных... http://electronix.ru/forum/index.php?showtopic=118917 вот ваши коллеги... а вот еще http://electronix.ru/forum/index.php?showtopic=118369 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
js_slider 0 19 мая, 2014 Опубликовано 19 мая, 2014 · Жалоба У коллег ветка заглохла.. и без результатно в отношении потери данных... Неужели Virtual COM Port не способен стабильно работать... работают же как то FTDI и им подобные... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 20 мая, 2014 Опубликовано 20 мая, 2014 · Жалоба у коллег по первой ссылке ближе к концу был пример как сделать передачу. А мой знакомый разработчик который боролся с этой проблемой сказал что увеличение таймаута ожидания данных ему помогло. Ну и конечно стандартное решение, при долгом отсутствии данных - переконект. В общем пока что я видел в качестве решения - заплатки. А FTDI еще имеет свой драйвер, и все обычно в конце на него переходят, неспроста.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 242 20 мая, 2014 Опубликовано 20 мая, 2014 · Жалоба Я уже конечно давно не работал с CDC, но по-моему скорей всего ТС просто не разобрался со своим стеком. Когда я работал с CDC (на стеке LPC и его CPU), никаких таких потерь не было. Вообще. API для юзера там позволяло отправлять и большие блоки (они разбивались внутри стека). Уведомление о завершении передачи от стека (и подкачка новых данных) там было сделано через callback-вызовы. не совсем верно, это при передачи через контрольную точку 64 байта пакеты. Но вроде виртуальный ком порт еще 2 интерапт точки делает, а там размер буфера 1024 бита вроде как... У меня сейчас в комп воткнуты два разных (с разными дровами) USB-COM. В обоих имеется только по два bulk-эндпоинта. Никаких интеррапт. Не уверен, но возможно FS позволяет несколько транзакций с одной bulk-точкой за один 1мс-фрейм. Надо читать описание USB. PS: Нет, сорри - в одном из CDC-устройств имеется одна интеррапт-точка. Но размер её == 2байта с интервалом 1мс. А значит - в ней только какие-то статусы передаются. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 20 мая, 2014 Опубликовано 20 мая, 2014 · Жалоба Я давно не ковырял USB, так что вполне могу ошибаться. Помниться что 90% идет через контрольную конечную точку, и помниться что вроде в стандарте было еще 2 какие то конечные точки, почему то казалось что interrupt. Но bulk тоже подходит. на interrupt наверное RTS, CTS повесили:) HS - устройства точно имеют микрофреймы внутри милисекундного кадра, вроде как 8 микрофреймов, FS и LS не должны иметь. Хотя в стандарте было как-то путано написано, но вроде как решили что речь идет о передаче через несколько конечных точек одновременно... Вот почитал стандарт. Bulk обмен для FS устройств может делать до 19 передач в один фрайм, буфера размером 64 байта. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 242 20 мая, 2014 Опубликовано 20 мая, 2014 · Жалоба Вот почитал стандарт. Bulk обмен для FS устройств может делать до 19 передач в один фрайм, буфера размером 64 байта. Вот! я же слышал где-то звон, но не помнил где он ;) Как я помню стратегию bulk - она самая низкоприоритетная, но одна точка может занимать весь канал и обеспечивать 100% скорости всей USB-FS при отсутствии передач по другим точкам. 19*64=1216 - как раз полные 100% скорости USB. А фрагментацию должен стек осуществлять. Стек от LPC умеет её делать, и для Control-кадров тоже. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 21 мая, 2014 Опубликовано 21 мая, 2014 · Жалоба Виртуальный COM, как отмечалось, использует bulk трансфер. PC-шные bulk-драйверы умеют принимать только заранее известный объем данных. Для передачи этой информации используются дополнительные interrupt ендпоинты. Оба типа обменов, естественно, должны быть жестко засинхронизированы. Именно потерями на синхронизацию объясняется невозможность достижения максимальнх скоростей при использовании FTDI. И именно проблемами этой синхронизации (IMXO) объясняются обсуждавшиеся потери информации в направлении девайс - РС. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 242 21 мая, 2014 Опубликовано 21 мая, 2014 · Жалоба Да ну, правда что-ль? ;) Интересно - как тогда пашет тот мой USB-COM, в котором только две bulk-точки? А ведь как-то умудряется на 230400, а местами и на 460800 работать! CP210x А что мешает драйверу периодически (раз в неск. мс) опрашивать эти самые bulk-точки, а в CP210x иметь буфер на несколько размеров bulk-точки? Конечно - если есть интеррапт, то оно вроде как само. Но не надо забывать, что любые транзакции, с любыми типами точек (и даже interrupt и isochronous), инициирует хост-драйвер. Точно также и драйвер конкретного устройства может периодически инициировать транзакции со своими bulk-точками. Ну конечно когда ему выдадут ресурс времени в соответствии с приоритетом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 21 мая, 2014 Опубликовано 21 мая, 2014 · Жалоба ...А ведь как-то умудряется на 230400, а местами и на 460800 работать!... Даже Ваши 460800 это как-то не совсем USB-шные теоретические 12Мb... А что мешает драйверу периодически (раз в неск. мс) опрашивать эти самые bulk-точки, а в CP210x иметь буфер на несколько размеров bulk-точки? Что мешает - не знаю. Знаю, как работают функции bulk_read из известных мне драйверов. Знаю (из собственного опыта), что "обычный" bulk-обмен (с фиксированным размером пакета) достаточно легко пoзволяет скорости до 750kB/s и работает часами без потерь информации, а моя единственная (может быть не очень умелая) попытка организовать обмен пакетами пермеменной длины с приемлемой (более 300 kB/s) скоростью закончилась такими же результатами, как и те, что имеет сообщество с виртуальным (не FTDI) COM Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
