Нужно организовать обмен данными между ПК и камнем. В основном данные записываются в камень, но небольшие пакеты подтверждения состояния процеса в камне передаются в ПК.
В качестве базового кода использовал пример lwIP_Demo_Rowley_ARM7 из пакета FreeRTOS выбросив оттуда работу с сетью и добавив ещё одну задачу обработки данных от USB. В результате, у меня в системе крутятся две задачи: первая (с высшим приоритетом) производит обмен данными между контролером USB и двумя очередями (одна на приём, другая на передачу), вторая - обрабатывает данные используя их для выполнения своих задач. В качестве драйвера устройства используется стандартный виндосовский usbser.sys (работаю под WinXPPro).
В камне зарезервированы очереди на приём (размером 300 байт) и на передачу (размером 100 байт), а также очередь обмена сообщениями между обработчиком прерываний и первой задачей. Насколько я разобрался с протоколом работы USB, в даном примере код написан достаточно грамотно с использованием двойной буферизации (ping-pong процесора) и там не должно бы быть задержек (возможно я не прав). В нескольких словах как это всё работает. По приходе пакета от ПК вызывается прерывание которое записывает информацию о пакете в очередь обмена с задачей и вызывает переключение задач. Первая задача ожидает этого переключения, вытягивает данные из буфера FIFO, запихивает их в очередь приёма, данные из очереди передачи передаёт в FIFO и выставляет нужные флаги. Когда есть время вторая задача обрабатывает данные в очередях.
Запустив всю эту систему я смог получить скорость обмена даными приблизительно 125 кБит/с, а нужно где-то 5Мбит/с.
Чтобы проверить где может быть узкое место я изменил код следующим образом:
в первой задаче, дополнительно при передаче данных из буфера FIFO в очередь приёма я дописывал размер полученого пакета и номер кадра в котором пришёл пакет. Вторая задача все данные из очереди приёма после некоторой задержки отправляла обратно на ПК.
На ПК я отправлял данные из масива размером 249 байт. Програма написана на Delphi. Порт открываю командой hCom:=Createfile(port, GENERIC_READ+GENERIC_WRITE, 0, nil, OPEN_EXISTING, 0, 0);. Скорость обмена устанавливается на камне 115200, но как мне раньше ответили эта скорость, только для совместимости и реально она не ограничивает потока данных (я это проверял - скорость обмена не изменялась при установке других чисел). Данные из программы на ПК я отправлял командой WriteFile(hCom, test[0], 249, bytes, OvLapp);. Как и предполагается в протоколе USB у меня пришло четыре пакета: 64+64+64+57=249. Но почему-то все пакеты приходят не в одном кадре (или в двух соседних кадрах), а через один-два кадра (номера кадров разнятся на две-три единицы). Может я ещё не до конца разобрался со стандартом USB, но вроде-бы, все пакеты могут передаться в одном кадре несколькими транзакциями.
Такое ощущение, что передачу данных тормозит драйвер CDC usbser.sys. Если да, то какая может быть альтернатива? Желательно бы обойтись без написания собственного драйвера.

Возможно кто-то подскажет как можно ещё попробовать поискать где узкое место.
Может кто-то работал с этой реализацией CDC, получал ожидаемые большие скорости обмена данными и знает где нужно изменить код.

Помогите, пожалуйста.

Альтернатив нету. По книжке Агурова - втроенный драйвер поддреживает только до 64 Кбит/сек или около того. Чего хватает для мыши, клавы и проч устройств. Нужен full-speed - придется писать дройвер с помощью DDK.

Не уверен. У Агурова насколько я помню ограничение в 64к дано только для HID устройств, а это CDC. Да и скорость у меня уже 125 кбит. Похоже что проблема не тут.
Может много времени занимает копирование данных из FIFO USB в приёмную очередь?

Какой драйвер используете? Я - стандартный из Windows. И я думал, что 64К - это "потолок" для CDC. Интервал опроса 1мс, размер данных для конечной точки 64байта. Или при энумерации утстройства нужно передавать в дескрипторах другое значение, а не 64? Я переделываю пример атмела BASIC_USB. Кстати, по книге Агурова если размер передаваемых данных совпадает с объемом буфера конечной точки, то нужно передать еще 0 байтов. В примере Атмела так не делают, а я в конечную точку 0 пытался передать 8 байтов (описываемая ситуация) - название устройства.... и ничего не работало.

Так, про драйвер зря спросил....
А может, это винда тормозит?
Я сталкивался с тем, что если написать в процессе опроса
Application->ProcessMessages....
то нужно вставить хотя бы delay(1), иначе ReadFile(hComm....) не отработает. К чему бы это?

На задержку винды не похоже, так как посылаю один масив в 249 байт и он приходит в моё устройство пакетами в кадрах номера которых разняться на единицу, двойку. А при таком разбросе как раз и получается где-то 125кбит/с данных.
Что-же касается CDC, то там, как мне кажется, скорость не ограничена - сколько можна выжать столько и выжмется.
Ещё добавлю, что у меня две конечные точки одна на вход, другая на выход (плюс нулевая), данные кидаются в bulk пакетах. Кроме этих данных других типов передачи не добавляется.

Это мне тоже очень инетерсно.

Поговорил с человеком на эту тему. Сказал, что когда работал с блютуз - у него тоже возникли проблемы с виртуальным портом на той же скорости - больше не давало, чем 115200. Думаю, что проблема все таки в драйвере винды, и нужно писать свой. Или же искать готовый, чем намерен заняться в ближайшее время. Если не найдем - будем писать все вместе :-)

А чем вы смотрите обмен по USB?
Смотреть надо аппаратным анализатором. Он показавает наличе запросов от хоста. Программные логеры этого не видят.

Так вот когда я смотрел работу конечной точки виртуального COM, то наблюдал передачу запросов каждые 5 мкс. Но после того как в кадре проходил один ответ больше запросов от хоста на данную конечную точку до конца кадра не поступало. Следовательно потолок для виртуального COM порта это 64 байта в 1 мс на USB 2.0 FS т.е. 512 КБит/сек

Все верно. Явно в стандарте не нашел, но по жизни так и есть.



Неправильный у Вас наверное USB был. Я тоже думал что ограничение 64 кбит. Но когда получил максимальную реальную скрорость > 300 кб/с я изменил свое мнение.
При тупой непрерывной посылке байтов контроллером и тупым приемом потока компом (Сел1.7) скорость была что-то около 340-380 кб/с.

Веселое обоснование.

Изделие как правило должно обладать таким свойством, как повторяемость. Если мы вот так будем писать правельное-неправлеьное - грошь цена таким высказываниям. Другие устройства, такие как flash drive например спокойно работают на этом же порте с довольно высокой скоростью, а вот виртуальный com порт не хочет. В этом вопрос, и вопрос принципиальный.

Правильно. Это значит что теоретически USB может дать скорость 10-12 мбит через одну логическую точку (как ее использует Mass Storage).
А вот реализация конкретного драйвера - здесь можно многое потерять. Недаром у многих возникают проблемы с CDC мелкософтовским. Значит надо уточнять версию драйвера. Ведь известно, что в Win2k он сильно глюкавый. И его надо менять на такой же от WinXP.
И камень. Я работаю с LPC124х. Устройство реально СЧИТЫВАЕТСЯ на 100 кб/с.
OlegHmt пытается в AT91 ЗАПИСАТЬ на скорости 5 мбит.
Направление у нас разное. Может на передачу CDC ограничен.

Я думаю, SAM7S и SAM7X в плане USB идентичны. Мне, при экспериментах с первым, удавалось получить 32 Кбайта/сек со своим драйвером. Посылки по 64 байта. При использовании примера Mass Storage от Atmel 1 Мб за 25 сек. Это еще шустрее.

Вчера немного разбирался с проблемой и вот что смог найти, вычитал на форуме, но не успел попробовать. Тут же на форуме раньше поднималась похожая тема, но люди использовали CDC на базе BasicUSB от Atmela. В качестве драйвера виртуального ком-порта использовался всё тот-же usbser.sys, правда работали они с ним с использованием usblibrary.dll (код тоже идёт в комплекте), где открывание порта и передача даных организована немного по другому. И там народ получал скорости вплоть до установленого пределе 1 Мбайт/с. Сегодня вечерком попробую разобраться с такой последовательностью работы с портом и запустить.
То-есть пока два варианта тормозов при передаче данных:
1. неправильно организована работа процесора в моём устройстве;
2. некоректно работают функции передачи данных на ПК.
Второй вариант сегодня попробую проверить

а мне посоветовали "забить" на виртуальный com порт, и пользовать USBIO.

Как только придет горячо ожидаемая плата - сразу займусь экспериментами.

Если можно, то поподробнее о USBIO - с чем его едят и от чего отталкиваются? И почему всё же "забить" - по какой причине?

Наверное по той самой причине, что виртуальный com порт в том виде в каком он описывается в данном применении в принципе не может обеспечить высокой скорости обмена. Однако на сколько мне известно, чипы FTDI например поддерживаются драйвером с виртуальным com портом со скоростью до 1 Мбит.



Относительно USBIO 20 - это библиотека, кому надо могу дать ссылку или попросить отправить на mail. Там куча экземплов, и на сколько видно из описания поддерживает вплоть до USB 2.0.

Да, вы оказались правы
Что-то тогда было не то.
Сейчас протестировал работу стандартного драйвера виртуальномого COM-а с другого чипа.
Перекачка в окно терминала проходит со скоростью 200 кбайт/сек. Не так все и плохо.
Анализатором еще не смотрел ситуацию на шине, как погляжу может сообщу.

Так, новые данные о работе виртуального COM порта.
Скорость считывания из устройства в комп реально ничем не ограничена кроме пропускной способности USB шины и собственно устройства.
Я реально достиг передачи 11-и 64-х битных пакетов за один кадр, т.е. 704 Кбайта в секунду.
И эта граница целиком определялась быстродействием моего устройства (платформа на базе STR91x).
Больше устройство просто не успевало обрабатывать транзакции типа IN.

А вот с передачей данных из компа в устройство сложнее. Комп никак не захотел отдавать более 2-х пакетов за кадр. Причем они шли так: 64 байта, а потом 36 байт. Если комп получал после первого пакета ответ NAK, то он долбил в течении кадра пока не пересылал оба пакета, а потом замолкал до следующего кадра, т.е. переставал отправлять запросы OUT
Перетыкание на другие разъемы USB в компе ситуацию не меняет.
Использовал для посылки данных терминальную программу TeraTerm. Посылал двоичный файл в 1 Мег.
Т.е. пока вывод, что на передачу в устройство достичь скорости более 100 Кбайт в секунду на виртуальном COM порте не удалось.

Да, как оказалось, usbser.sys заточен лишь под модем, как и usbprint.sys - чисто под принтер.
Налицо ситуация, когда мелкософтовцы отлаживали лишь приемную часть драйвера...

Я тестировал скорость передачи данных от компа на девайс по full-speed USB и получил 500КБайт/сек. В качестве контроллера использовался SiLabs C8051F347. Включал двойную буферизацию на прием, размер буфера 256 байт. Мне хватило. При этом я думаю скорость передачи тормозилась только скоростью забора данных микроконтроллером.
Кстати был обнаружен интересная ошибка в драйвере usbser.sys от небезызвестного производителя. IN endpoint буфер был сконфигурирован 256 байтного размера. При передаче всех 256 байтов данных в компьютер гарантированно получался "'экран смерти" . Ошибку обошел простым увеличением размера буфера до 257 байт (естественно в дескрипторе) .
На данный момент устройство успешно реализовано и выглядит как виртуальный COM-порт.

Ситуация, прояснилась окончательно.
Выводы о кривизне usbser.sys были явно преждевременны.
Похоже тормоза исходят от более верхних прикладных уровней.
На этот раз я для тестирования написал в Delphi свою прогу на базе компонента AsyncPro для работы с виртуальным COM портом.
И сразу скорость закачки в устройство подскочила до максимальной с какой способен принимать мой дивайс, где-то более 200 Кбайт в секунду.

Вообщем HyperTerminal под Windows вообще посылает пакеты чуть не по одному байту. TeraTerm ограничивае трафик в 100 КБ/сек, а вот собственное приложение ничем трафик не ограничивает, но видимо тщательнее надо подходить к инициализации буферов и настройке DCB структуры COM порта. Компонент AsyncPro скрывает от юзера работу с Win API поэтому конкретнее о настройках ничего сказать не могу.

В вашем случае вероятнее виновата выбранная схема взаимодействия задач с USB периферией.
Вы измеряли время переключения задач?
А ситуации заполненной очереди отслеживали?
А сколько во FreeRTOS длится сама постановка в очередь?
На таких скоростях это уже все критично.
Выборка из FIFO думаю должна производиться в самом обработчике прерывания и как можно быстрее еще лучше использовать DMA для этой цели.
Я тоже пишу под RTOS и там имеено эти моменты дают самые большие тормоза.

Я делал модем в своё время и тестировал HyperTerminal. Могу сообщить следующее.

1) Из под XP он действительно дробит пакеты и вставляет задержки даже м/у символами. Работает крайне медленно. Это наблюдается на FTDI. На Win98 такого не замечалось.
2) Терминал имеет ошибки при передаче данных. В том числе в режиме X-modem да и других тоже. Более того одну из ошибок мы задиагностировали в 1999 году ещё в Win98. В том году мы её успешно проверили из под WinXP. Всё нормально! В наличии!

Очень интересны Ваши эксперименты, но вот в каком ключе. Мне самому жутко не хочется писать драйвер. Его же потом поддерживать! Хотелось бы со стороны своего девайса с эмулировать наличие там FT232RL. Так, чтобы благополучно подходил драйвер от FTDI. Они его сейчас вылизали. Работает как часы.

Ни кто не думал над этим?

[quote name='SasaVitebsk' date='Feb 25 2007, 00:47' post='215539']
[quote name='AlexandrY' post='215435' date='Feb 24 2007, 16:23']

Хотелось бы со стороны своего девайса с эмулировать наличие там FT232RL. Так, чтобы благополучно подходил драйвер от FTDI. Они его сейчас вылизали. Работает как часы.

Ни кто не думал над этим?
[/quote]

Вы прямо читаете мои мысли. На настоящий момент мое достижение ~80КБайт/сек. в WinXP с usbser.sys, данные в основном идут в устройство, обратно - подтверждения. Пока эта скорость устраивает.

Меня вообще за глаза.

А на каком проце вы делали? Чем "подсматривали"? Сложно ли реализовать оказалось?

Я наверное, неправильно выразился. Была у меня мысль использовать драйвер от FTDI. Был у меня фирменный диск с FTDI, и там была таблица с описанием, какая информация берется из EEPROM, подключаемой к FT*** и по-моему, была там и таблица с дескрипторами, копию диска себе не делал.
Но пока я остановился на стандартном usbser.sys и получается 80КБайт/сек.
Процессор AT91SAM7S256. Переделываю BasicUSB по-маленьку. Сделал обработку по прерываниям (не уверен, правда, что это добавляет скорости). Ошибку исправил, я уже где-то об этом писал, может в этом топике, что не учитывают, когда длина блока передаваемых данных равна размеру конечной точки, надо передать еще пакет нулевой длины (информацию эту подчерпнул из книги Агурова). А вообще этот модуль с USB еще переделывать долго буду

Сейчас попутно поставил эксперименты.
со чтороны девайса LPC2148, тупое чтение данных из точки в никуда.
со стороны хоста USB 1.1 Celeron 1800, Чтение данных из файла и посыл их в порт.
максимально достигнутое - ~900 000 байт/сек
доступ к порту средствами WinApi, открытие порта по символьному имени (не COMx)
как я понял, в течении кадра передается не больше того, что было послано WriteFile.
Чем больше размер записи - тем быстрее скорость. Прямой зависимости нет
512байт - ~ 250 000 байт/сек
1024 - ~ 410 000
2048 - ~520 000
4096 - ~ 750 000
8192 - ~ 830 000
16384 - ~ 900 000

ЗЫ Были грабли что от всей посылки приходит только первые 64 байт. Вроде вылечилось
установкой SetupComm(PortHandle, 16384, 16384) на хосте

Скажите специалисты. А если требуется реализация полного виртуала со всеми линиями. DTR, DSR, RI, RTS, CTS ну и так далее. Кто-нибудь такое делал?

Такое точно делал MosChip . У них есть такая микруха USB-UART MCS7840 - это USB2.0 HighSpeed и 4 виртуальных ком порта (с DTR, DSR, RI, RTS, CTS ну и так далее ). Обещают до 6Мбит. Пока только заказываю, попробую в деле. Дрова есть под все ОСи ссылка

Наконец дошли у меня руки до исследований USB и вот каков результат: как и писал AlexandrY проблема оказалась в постановке принятых данных в очередь. Как только я заменил постановку в очередь на запись в обычный масив - тут же скорость подскочила: за одну милисекунду (один фрейм) у меня приходило от ПК 7-11 пакетов данных (по 64 байта). То-есть я получал где-то 600 кБайт на секунду. Скорость ещё бы можно поднять изменив процедуру выборки даных из FIFO, но это уже следующий этап - полностью переработать алгоритм работы с посылками USB. Надеюсь больше не вылезут какие-то косяки, особенно с передачей данных от устройства к ПК - пока-что я этой части особо не исследовал.

Кстати, может кому-то пригодится и такая информация. Когда я пробовал сделать на Delphi работу с виртуальным последовательным портом аналогично процедуре в примере BasicUSB, то получил таков результат: Я смог перенести часть кода которая получает список устройств и их описание, но когда пробовал открыть два канала с портом (аналогично BasicUSB), то открывался только тот, который в коде шёл первым. Второй никак не хотел открываться пока не закроется первый.
И ещё одно - данные в открытый канал записывались, но не доходили до устройства. Если же перед открытием канала я открывал порт старым способом: handle:=CreateFile('\\.\COMX', ..... ) после чего устанавливал и читал установленную скорость и сразу же закрывал порт CloseHandle(handle), то после этого в открытый канал по способу BasicUSB данные нормально записывались и доходили до устройства.

И напоследок - большое спасибо всем кто откликнулся, так или иначе вся информация топика оказалась полезной

Интересно было бы узнать, чем всё закончилось? Какую скорость получили?

Я достиг скорости 1,2 кб/с!!!

Пока просто ее ПОЛУЧИЛ! Буду думать как сделать быстрее. Установка скорости COM в 1 мбит/сек ничего не меняет. Пробую на олимексовской платке с lpc2148 усб стек открый, usbser.sys.
Внимательно читатаю топик и собираюсь с USB за скорость.

всех с празником.

Да похвалиться, вообще-то, нечем. Как я писал раньше запустил прокачку даных из ПК в кристал на скорости приблизительно 600 кБайт на секунду заменив запись принятых данных во FreeRTOS очередь на запись в обычный масив, чего мне на данный момент хватило, чтобы запустить базовую функциональность устройства. А к увеличению скорости прокачки и передаче данным из кристала в ПК руки пока не доходят - другие части системы ещё нужно поднять на ноги.

Мдя.
Используя lpc2148 c открытым USB стеком и как mass storage и как custom устройство дает 0,33 мегабайта в секунду при обмене буффер прилагухи или файл диска <--> записи/считывании в озу контроллера. контроллер работает на 60 мегагерцах.
Гденить порытся в исходниках и откопать еще скорость возможно (исходники USB стека для 2148 и драйвера на PC ессесено доступны)? Куда рылом похать.
Начальник сказал что такая скорость пойдет для текущего проекта. Что меня не мало успокоило.
Эта скорость как? медленно, быстро? или так себе? Некоторые тут аж 600кбайт/сек какимто волшебным способом получили .... У кого больше скорость обмена получилось? и при каких остоятельствах вы ее видели в последний раз?

http://www.tnkernel.com/usb_bulk.html

интерсненько, пора значить TNKernel посмотреть. Спасибо.