at90usb1287 - малая скорость передачи по USB, Передача данных в режиме CDC USB Опции

[Mty]

Привет!

Необходимо за 0.1 сек передать с at90usb1287 в комп массив данных из 600 чисел типа int
Я пользуюсь для этого printf()

Код

    
while( buffindex < buffmax ){
printf( "%x %x\r\n", databuff[ buffindex ], databuff[ buffindex + 1 ] );  
buffindex += 2;
}

И получаю очень малую скорость - порядка 100 байт за 0.1 секунды.
А нужно порядка 20 килобайт в секунду.
Посоветуйте, как можно увеличить скорость, что я делаю не так?

За основу я взял AT90USBxxx CDC demonstration с сайта Atmel.
Функцию вывода буффера я поместил в функцию cdc_task()

Спасибо.

[Xenia]

А приём-то у вас работает? А то как-то странно: printf обычно передает по UART, а не по USB.

[kovigor]

А нужно порядка 20 килобайт в секунду.

Просто ради интереса посмотрел, какая предельная скорость передачи у моего фабричного переходничка на ИС вроде FT232. Написано, что 128000 Бит/сек. А 20 КБайт - это 200000 Бит/Сек. Чувствуете разницу ?

Сообщение отредактировал kovigor - Nov 23 2010, 09:34

[Mty]

А приём-то у вас работает? А то как-то странно: printf обычно передает по UART, а не по USB.

Да, работает.
Где-то видимо putch переназначен для работы через USB. Не искал где.

Просто ради интереса посмотрел, какая предельная скорость передачи у моего фабричного переходничка на ИС вроде FT232. Написано, что 128000 Бит/сек. А 20 КБайт - это 200000 Бит/Сек. Чувствуете разницу ?

Не совсем близкая параллель. FT232 это конвертер в RS232 насколько я помню, а у at90usb1287 на борту хардверный USB контроллер на 12mbit/s. На www.avrfreaks.net видел сообщения что реально у людей он работал до 7 мбит в одну сторону и до 4 в дуплексе. Правда с правкой родных библиотек от Atmel.

[zhevak]

И получаю очень малую скорость - порядка 100 байт за 0.1 секунды.
А нужно порядка 20 килобайт в секунду.
Посоветуйте, как можно увеличить скорость, что я делаю не так?

Отделите мух (USB) от котлет (printf) и попробуйте найти, кто из них самый медленный.

Может быть имеет смысл сначала накидать инфу в буфер (sprintf), так сказать подготовить данные к передаче. А потом уже готовый текст выводить из этого буфера. К стати, почему Вы используете printf? Для конвертации их int в ASCII есть более быстрая функция -- itoa.

[Xenia]

К стати, почему Вы используете printf? Для конвертации их int в ASCII есть более быстрая функция -- itoa.

Есть где? В стандарте C? Однако же в IAR-компиляторе ее нет и никогда не было.

[demiurg_spb]

Передавайте бинарный массив сразу без всяких printf.
Должно стать ЗНАЧИТЕЛЬНО быстрее.

[MrYuran]

Передавайте бинарный массив сразу без всяких printf.

Или на худой конец sprintf().
Тогда формирование строки и передача буфера будут хотя бы разнесены во времени

[zhevak]

Есть где? В стандарте C? Однако же в IAR-компиляторе ее нет и никогда не было.

Эта функция из стандартной библиотеки Си. Я использую avr-libc, там она есть.

Знаете, Ксения, Вы меня удивили! У меня Венды нет принципиально, поэтому я не могу быстро проверить Ваше утверждение. Но тем не менее, я очень удивлен отсутствию этой функции в столь дорогом (и надо отдать должное -- не плохом) продукте. Как же так? Наверно в стандартной Си-библиотеке IAR-а есть какая-нибудь другая, эквивалентная ей, функция?

demiurg_spb
Быстрее-то быстрее. Причем значительно. Но как и чем ТС принимает поток данных и что с ним делает, он почему-то ничего не сказал. Может он в текстовый файл этот поток складывает?

[Mty]

Отделите мух (USB) от котлет (printf) и попробуйте найти, кто из них самый медленный.

Спасибо, с этого начну.

[Xenia]

Знаете, Ксения, Вы меня удивили! У меня Венды нет принципиально, поэтому я не могу быстро проверить Ваше утверждение. Но тем не менее, я очень удивлен отсутствию этой функции в столь дорогом (и надо отдать должное -- не плохом) продукте. Как же так? Наверно в стандартной Си-библиотеке IAR-а есть какая-нибудь другая, эквивалентная ей, функция?

Библиотеки у IAR, можно сказать, спартанские - необходимый минимум. Я и сама по началу удивлялась, а потом привыкла. Самой приходилось itoa писать, чтобы не тащить большой (по мастштабам МК) код от printf'а.

[Mty]

Передавайте бинарный массив сразу без всяких printf.
Должно стать ЗНАЧИТЕЛЬНО быстрее.

Спасибо.
Как вариант. Попробую. Со стороны РС будет прога на LabView.
Пока что терминал putty в режиме com port.

---

У меня возникла одна мысль.
Для нормальной обработки система должна работать в режиме "мультизадачности"
В библиотеке atmel usb есть scheduler() который запускает по очереди cdc_task() и usb_task() в цикле.
А я внутри функции cdc_task() запихиваю большой массив данных в USB.
Может проблемы возникают из за того что блокируется usb_task в это время?

[zhevak]

Спасибо.
Как вариант. Попробую. Со стороны РС будет прога на LabView.
Пока что терминал putty в режиме com port.

Эх, если бы Вы юзали Линух, я бы Вам посоветовал одну вещицу...

Когда я давным давно тоже сидел под Вендой, меня тема передача потока данных раньше тоже очень сильно напрягала. Приходилось мучатся писать всякие комповые проги по приему данных и записи их в файл. Проги строились как многопоточные: один поток занимался приемом-записью, другой обслуживал клаву и мышь, т.е. должен был реагировать на действия юзвера не зависимо от потока данных. Вобщем сложный лес всякой ненужной деятельности.

После миграции на Линь и открытия для себя UNUX-way, я понял, что все эти сложности не от великого ума. Эти сложности надуманны и провоцируются M$-подходом. Цель более чем банальна -- нарубить как можно больше капусты. Чем сложнее и навороченнее прога, тем больше бабла можно снять с клиента. И никого не волнует, что функциональность в системе многократно дублируется и переплетается с уже готовыми решениями очень хитрыми способами. По большому счету эта бесполезная мишура и самообман. Вы обманывайте своих клиентов. Как минимум это не этично. Но простительно, т.к. это краеугольный камень любого успешного бизнеса. Но вы также обманываете и себя. А это уже -- себя не уважать. Вы тратите свою жизнь не на движение вперед, а на создание малоотличающихся копий сущностей -- точно таких же, но только с кнопочкой "изменить цвет панели". А главная зада, не решается. Она замерзла на этапе отладки очередного дубля сущности. Вы понимаете меня?

Но я сильно отвлекся. Итак. После перехода на Линух, у меня на стороне компа нет никаких моих комповых программ вообще! Все, что мне надо, делается одной-двумя командами оболочки. Например, так:

$ stty -F /dev/ttyUSB0 115200
$ cat /dev/ttyUSB0 mydata

Если надо как-то отслеживать получаемые данные, то добавляю команду tee

$ cat /dev/ttyUSB0 | tee mydata

Теперь, когда данные приняты и записаны в файле, я могу с ними делать все, что захочу. Нужно разбить данные на столбцы, на строки, собрать обратно? -- все это есть в утилитах Линя. Нужно построить графики? -- пожалуйста, gnuplot? Нужно обработать каким-то необычным методом? -- Тоже не проблема. Пишу свою консольную линуховую прогу. Но я не обманываю себя, я не делаю ненужной работы, например, по украшательству оконного интерфейса. Через полчаса-час моя брутально-написанная консольная прога уже работает на меня. Вы улавливаете суть? Кто на кого работает?

Я не говорю, что мой путь единственно правильный. Я просто хочу сказать, что иногда бывает полезно в корне изменить подход к проблеме, и проблемы могут вообще отпасть. Не усложняйте без необходимости.

У меня возникла одна мысль.
Для нормальной обработки система должна работать в режиме "мультизадачности"
В библиотеке atmel usb есть scheduler() который запускает по очереди cdc_task() и usb_task() в цикле.
А я внутри функции cdc_task() запихиваю большой массив данных в USB.
Может проблемы возникают из за того что блокируется usb_task в это время?

Если у Вас есть свободные ножки, навешайте на них LED-ы. Зажигайте ЛЭД, когда входите в сервис (или как Вы пишите -- задачу.) и гасите его, когда выходите. Очень просто и наглядно, а самое главное абсолютно незатратно узнать, кто сколько съедает процессорного времени. Измеряя стрелочным вольтметром напряжение на ноге, можно примерно узнать скважность импульсов (зависимость пропорциональная!). Можете посмотреть осциллографом, еще больше узнаете интересного.

Извините, за советы. Просто мне хотелось это кому-нибудь рассказать
Подвернулись Вы

[shrek]

Да, работает.
Где-то видимо putch переназначен для работы через USB. Не искал где.



Не совсем близкая параллель. FT232 это конвертер в RS232 насколько я помню, а у at90usb1287 на борту хардверный USB контроллер на 12mbit/s. На www.avrfreaks.net видел сообщения что реально у людей он работал до 7 мбит в одну сторону и до 4 в дуплексе. Правда с правкой родных библиотек от Atmel.

А вы бы не могли бы по подробнее про последнее написанное)))
Сам столкнулся с ограничением USB to Serial максимум 64 килобайта в секунду из-за ограничения спецификацией USB на конечные точки с BULK типом передачи данных. Для команд скорость вполе годится, для сыплющихся данных маловато)))

[Mty]

А вы бы не могли бы по подробнее про последнее написанное)))
Сам столкнулся с ограничением USB to Serial максимум 64 килобайта в секунду из-за ограничения спецификацией USB на конечные точки с BULK типом передачи данных. Для команд скорость вполе годится, для сыплющихся данных маловато)))

К сожалению подробностей там было мало. В одном из постов я прочел что перцу адвлось получить на at90usb 7 мбит в одну сторону и 4.2 mbit в дуплексе. Правда для этого он писал что пришлось править родную библиотеку т.к. в ней взаимно блокировались прием и передача.
Подробностей там не было. Что речь шла конкретно о CDC тоже поручится на 100% не могу ...

Отделите мух (USB) от котлет (printf) и попробуйте найти, кто из них самый медленный.

Попробовал выкинуть в цикле строку из 7 (включая CR LF) символов через puts()
Результат - 7 секунд на 7 кб = 1 кб/сек.
Мда, не радует.

Может это putty так медленно с портом работает? Может попробовать другой терминал?

[zhevak]

Попробовал выкинуть в цикле строку из 7 (включая CR LF) символов через puts()
Результат - 7 секунд на 7 кб = 1 кб/сек.
Мда, не радует.

Может это putty так медленно с портом работает? Может попробовать другой терминал?

А у Вас вообще терминал на какую скорость настроен? Такое ощущение, что на 9600 бод?
Я понимаю, что там у Вас USB, но у меня такое чувство, что там где-то есть быть настройки, которые эмулируют /dev/ttyS* (COM*) и этим ограничивают скорость обмена. Я не совсем представляю Вашу конфигурацию, поэтому советы не конкретные, а только предположения. Попробуйте поискать настройки скорости у терминала.

[mempfis_]

Сам столкнулся с ограничением USB to Serial максимум 64 килобайта в секунду из-за ограничения спецификацией USB на конечные точки с BULK типом передачи данных. Для команд скорость вполе годится, для сыплющихся данных маловато)))

Это где в спецификации usb 1.1 такое ограничение указано? Может Вы спутали с ограничениями связанными с классами устройств?
ЕР типа INTERRUPT с размером в 64 байта (применяются в HID-устройствах) могут опрашиваться раз в 1 мС поэтому там скорость ограничена 64 кбайт/с.
ЕР типа BULK по 64 байта используются в таких классах устройств как mass storage и там реально можно получить скорость 700-800 кбайт/с (старый mp3 usb1.1 работал на такой скорости).

[ARV]

а вы не рассматривали такую возможность: в WinAVR система stdio реализована так, что для орагнизации ввода-вывода в любое устройство надо определять функции ввода-вывода одного символа, т.е. ввод-вывод изначально НЕ ПОТОКОВЫЙ, а СИМВОЛЬНЫЙ. в связи с этим не происходит ли при выводе каждого байта отправка пакета USB? каким образом определен вывод байта? если вызовом какой-то функции типа send_usb(&buffer), где буфер состоит из единственного символа - вот вам и тормоза... и очень большие тормоза!

[Mty]

а вы не рассматривали такую возможность: в WinAVR система stdio реализована так, что для орагнизации ввода-вывода в любое устройство надо определять функции ввода-вывода одного символа, т.е. ввод-вывод изначально НЕ ПОТОКОВЫЙ, а СИМВОЛЬНЫЙ. в связи с этим не происходит ли при выводе каждого байта отправка пакета USB? каким образом определен вывод байта? если вызовом какой-то функции типа send_usb(&buffer), где буфер состоит из единственного символа - вот вам и тормоза... и очень большие тормоза!

Истинно! В этом дело.
Спасибо.

РЕШЕНО!
Кидаю данные из массива char arr[20] через функцию uart_usb_send_buffer( arr, sizeof(arr) );
Скорость - 20кб/сек
arr[60]
Скорость - 60кб/сек !!!

1. Нужная скорость достигнута.
2. Похоже буфер уходит раз в миллисекунду, независимо от размеров.
Отсюда скорость при передаче буфера -
1 байт 1кб/сек
20байт - 20кб/сек
60байт - 60кб/сек
80байт - 37кб/сек (буфер дробится)

[Xenia]

А вы еще "double bank mode" включите (это в конфигурации конечных точек), если до сих пор этого не сделали. Еще быстрее станет.

А то в демонструхе установлен ONE_BANK мод.
Это функция usb_user_endpoint_init() в файле usb_specific_request.c
там надо заменить ONE_BANK на TWO_BANK для точек TX_EP и RX_EP (2-ой и 3-ий вызовы usb_configure_endpoint()), а точку INT_EP оставить, как была (1-ый вызов usb_configure_endpoint()).

После этого прогоните свой тест снова. Напишите, что изменилось. Возможно, что тогда при 80байтах буфер перестанет дробиться.

[shrek]

Это где в спецификации usb 1.1 такое ограничение указано? Может Вы спутали с ограничениями связанными с классами устройств?
ЕР типа INTERRUPT с размером в 64 байта (применяются в HID-устройствах) могут опрашиваться раз в 1 мС поэтому там скорость ограничена 64 кбайт/с.
ЕР типа BULK по 64 байта используются в таких классах устройств как mass storage и там реально можно получить скорость 700-800 кбайт/с (старый mp3 usb1.1 работал на такой скорости).

The USB defines the allowable maximum bulk data payload sizes to be only 8, 16,
32, or 64 bytes for full-speed endpoints and 512 bytes for high-speed endpoints.

Получается за кадр, период которого 1 мс, full-speed девайс может передать максимум 64 байта и это получается 64 килобайта в секунду или 512000 бит в секунду в одну сторону.
С изохорными передачами устройство по теории может выдать в одну сторону 4 мегабита в секунду.
В CDC классе тоже используются конечные точки типа BULK. У Агурова в примере с пецификации на CDC класс и конкретно для моего девайса (AT91SAM7A3) в библиотеках производителя также две конечные точки типа BULK на прием и передачу и еще одна по прерыванию.
at90usb1287 так же как и AT91SAM7A3 имеет на борту контроллер USB full-speed.

Сообщение отредактировал shrek - Nov 25 2010, 07:12

[Mty]

А вы еще "double bank mode" включите (это в конфигурации конечных точек), если до сих пор этого не сделали. Еще быстрее станет.

После этого прогоните свой тест снова. Напишите, что изменилось. Возможно, что тогда при 80байтах буфер перестанет дробиться.

Спасибо за идею, в моей версии библиотек (USBKEY_STK525-series6-cdc-2_0_3-doc.zip) похоже уже включен double bank mode.

Код

  usb_configure_endpoint(TX_EP,         \
                         TYPE_BULK,     \
                         DIRECTION_IN,  \
                         SIZE_64,       \
                         TWO_BANKS,     \
                         NYET_ENABLED);

Получается за кадр, период которого 1 мс, full-speed девайс может передать максимум 64 байта и это получается 64 килобайта в секунду или 512000 бит в секунду в одну сторону.

А как получается что mass storage работает на скоростях гораздо больше 60кб/сек? Там используется BULK?
Насколько я помню USB флешки на USB 1.1 выдают скорость около мегабайта в секунду.

[mempfis_]

А как получается что mass storage работает на скоростях гораздо больше 60кб/сек? Там используется BULK?
Насколько я помню USB флешки на USB 1.1 выдают скорость около мегабайта в секунду.

Это всё получается потому, что для BULK-передач отводится всё свободное время на шине. Если нет SETUP/ISO/INTERRUPT-передач и есть заполненные BULK EPs то USB-host будет считывать данные из них постоянно по мере их заполнения. За 1 мС BULK EP может быть заполненной и считанной несколько раз. Помогает повышению скорости двойная буфферизация.

[Mty]

Это всё получается потому, что для BULK-передач отводится всё свободное время на шине. Если нет SETUP/ISO/INTERRUPT-передач и есть заполненные BULK EPs то USB-host будет считывать данные из них постоянно по мере их заполнения. За 1 мС BULK EP может быть заполненной и считанной несколько раз. Помогает повышению скорости двойная буфферизация.

Ясно, спасибо.
А почему в at90USB128 в CDC примере не получается скорости выше 60кб/сек Т.е. одна передача за один кадр?

--- Дополнение
Возникла мысль что надо слать ровно 64байтные пакеты. Иначе буфер не заполняется полностью и шлется через 1ms.

[shrek]

Это всё получается потому, что для BULK-передач отводится всё свободное время на шине. Если нет SETUP/ISO/INTERRUPT-передач и есть заполненные BULK EPs то USB-host будет считывать данные из них постоянно по мере их заполнения. За 1 мС BULK EP может быть заполненной и считанной несколько раз. Помогает повышению скорости двойная буфферизация.

А разве передача данных из точки или в точку не начинается по маркер пакету SOF?
По идее хост прислал мне SOF, потом шлет пакет с адресом конечной точки и функцией и направлением передачи, после этого если в буфере данные имелись то передаются данные. После передачи по идее хост должен прислать подтверждение. Вроде бы все передачи начинаются после "команды" хоста. Или в течении кадра 1 мс можно окромя 64 байт всунуть еще? например меняя DATA0 на DATA1 и наоборот?

Нда... оказывается так и делается... получается по теории 7 с лишним мегабит в одну сторону...
Значит виндовый драйвер CDC можно разогнать на более чем 64 килобайта в сек)))
С другой стороны как именно организовать передачу непрерывную со сменой PID пакета... Это уже програмные проблемы...
Хотя когда я отправлял с компа данные больше 64 байт они за раз и отправлялись без подтверждений и т.д. хотя я конкретно не смотрел при отладке в течении кадра они принялись и не смотрел PID данных data0 или data1...

По проведенным только что опытам он за раз в течении кадра смог принять 1024 байта!!! Получается 8192000 мегабит в сек... При попытке отправить ему 1025 байт уходит в непонятное зацикливание по прерываниям причем генерится перрывание и по данным банка 0 и по данным банка 1... Я хосту случайно ничего не должен отправить?... Или хост получается не разбивает отправленные байты на транзакции... Пытается все за раз отправить)))

Сообщение отредактировал shrek - Nov 25 2010, 13:17

[mempfis_]

С другой стороны как именно организовать передачу непрерывную со сменой PID пакета... Это уже програмные проблемы...

С at90usb не работал. Нужно смотреть какой тип EP в нём есть - с двойной буфферизацией или без. По поводу пакетов дата0/дата1 - этим занимается usb-контроллер. Ваша задача дождаться освобождения одного из буфферов конечных точек и заполнить соответствующий. Не забудьте что если длина данных кратна размеру конечной точки то надо слать пакет нулевой длины для того, чтобы показать хосту что закончилась передача данных.

[shrek]

С at90usb не работал. Нужно смотреть какой тип EP в нём есть - с двойной буфферизацией или без. По поводу пакетов дата0/дата1 - этим занимается usb-контроллер. Ваша задача дождаться освобождения одного из буфферов конечных точек и заполнить соответствующий. Не забудьте что если длина данных кратна размеру конечной точки то надо слать пакет нулевой длины для того, чтобы показать хосту что закончилась передача данных.

Ну вообще в AT91SAM7A3 контроллер этим не занимается по моему... Только вручну устанавливая и сбрасывая бит... Забрел в эту тему из-за того, что обсуждался крайне важный вопрос скорости передачи данных по USB CDC)))

Сообщение отредактировал shrek - Nov 25 2010, 13:38

[mempfis_]

Ну вообще в AT91SAM7A3 контроллер этим не занимается по моему...

В at91sam7s точно нет надобности следить за data0/data1 - там этим занимается usb-контроллер
Другим usb-контроллеров с которыми я работал была isp1181a - там тоже после настройки просто загружались конечные точки.
Вообще этим программист не должен заниматься т.к. контроль data0/data1 введён для повышения надёжности передачи данных. При сбое передачи usb-контроллер должен повторить отправкку с другим data Программисту-же должен быть доступен результат - данные отправились или ещё висят в конечной точке.