Utyff 0 23 января, 2014 Опубликовано 23 января, 2014 · Жалоба Есть задача - передать поток данных от ADC через USB на комп. Два ADC генерируют по больше 20 мбит. Вопрос в том сколько может пропустить USB. Правильно ли я понял что ограничения такие: 1 фрейм за 1 милисек за 1 фрейм можно передать один буфер из EndPoint. Максимальный размер буфера = 512 -0x18 (BTAB) - 2 * 0x40 (END0 buff) = ~ 350 байт Т.е. максимальная скорость STM32 USB будет 3,5 мбайта? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 23 января, 2014 Опубликовано 23 января, 2014 · Жалоба Для устройств USB 2.0 регламентировано три режима работы: Low-speed, 10—1500 Кбит/c (клавиатуры, мыши, джойстики) Full-speed, 0,5—12 Мбит/с (аудио-, видеоустройства) High-speed, 25—480 Мбит/с (видеоустройства, устройства хранения информации) этот проц фул спид, значит до 12 мегабит должен качать. просто есть разные виды передачи, и максимум будет в изохронном режиме, правда без гарантий... и это 1.5 МБайта, Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ataradov 0 23 января, 2014 Опубликовано 23 января, 2014 (изменено) · Жалоба просто есть разные виды передачи, и максимум будет в изохронном режиме, правда без гарантий... и это 1.5 МБайта, Максимум будет в Bulk, если шина не нагружена и хост сможет поставить 19 запросов за кадр. Bulk - 19*64 байт = 1216 байт/мс = 1.2 МБ/c. Iso - 1023 байт / мс = 1.023 МБ/c. Edit: На практике ни винда ни линукс 19 запросов на моем железе не ставят, получается 13-15 только. Поддержка Iso в ОС и библиотеках тоже оставляет желать лучшего. Изменено 23 января, 2014 пользователем Taradov Alexander Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 23 января, 2014 Опубликовано 23 января, 2014 · Жалоба вот потому максимум и будет в изохроне%:) 15*64 Кбайт = 960 Кбайт/мс = 0.93 МБ/c, все же я настаиваю что в МБайте 1024 КБайта балк он как бы без потерь потому из-за приемной стороны могут быть прососы по скорости, ну как оно и получается. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ataradov 0 23 января, 2014 Опубликовано 23 января, 2014 · Жалоба балк он как бы без потерь потому из-за приемной стороны могут быть прососы по скорости, ну как оно и получается. Потери, они если и есть, то незначительные. Тут просто хост не успевает столько запланировать за 1 мс. Iso поддержка в стандартных универсальных драйверах винды вообще никакая, только свой драйвер писать. В libusb поддержка есть только в каком-то запущенном форке. Под линуксом с libusb iso получается полные 1023000 б/c. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Utyff 0 23 января, 2014 Опубликовано 23 января, 2014 · Жалоба Максимум будет в Bulk, если шина не нагружена и хост сможет поставить 19 запросов за кадр. А можешь объяснить или дать ссылку - как сделать больше одного запроса за кадр? Мне нужна конкретная реализация на STM32F103 идеально если есть пример. Абстрактные ограничения протокола или драйверов Win это вторично если до этого дойдет. Пока я вижу - только 350 байт за 1 милисек. Это 350 кбайт/сек или 2.7 мбит/сек. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 23 января, 2014 Опубликовано 23 января, 2014 · Жалоба А можешь объяснить или дать ссылку - как сделать больше одного запроса за кадр? Мне нужна конкретная реализация на STM32F103 идеально если есть пример. Абстрактные ограничения протокола или драйверов Win это вторично если до этого дойдет. Пока я вижу - только 350 байт за 1 милисек. Это 350 кбайт/сек или 2.7 мбит/сек. запросы делает HOST, то есть компьютер, как у него есть на это силы. Так что никак вы его больше запросов чем он хочет сделать не заставите. Может я что-то не так помню, но вроде википедия со мной согласна: Изохронный канал позволяет доставлять пакеты без гарантии доставки и без ответов/подтверждений, но с гарантированной скоростью доставки в N пакетов на один период шины (1 КГц у low и full speed, 8 КГц у high speed) Поточный канал дает гарантию доставки каждого пакета, поддерживает автоматическую приостановку передачи данных по нежеланию устройства (переполнение или опустошение буфера), но не дает гарантий скорости и задержки доставки. последний это Bulk они так назвали. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Utyff 0 23 января, 2014 Опубликовано 23 января, 2014 · Жалоба Максимум будет в Bulk, если шина не нагружена и хост сможет поставить 19 запросов за кадр. Александр, можешь дать пруф? Ссылку на доку или пример реализации? Изохронный канал позволяет доставлять пакеты без гарантии доставки и без ответов/подтверждений, но с гарантированной скоростью доставки в N пакетов на один период шины (1 КГц у low и full speed, 8 КГц у high speed) Т.е по Изохронный каналу можно отправлять свой буфер несколько раз за фрейм? А размер буфера ограничен? Буду благодарен за конкретный пример или описание. Потери пакетов допустимы, главное передать максимум возможного. Я понимаю что вопросы глупые и решаются чтением доки. Но она огромная, не конкретная и дело движется очень медленно. А еще разбираться как кодировать это в STM32. У меня вторую неделю мозги кипят :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 23 января, 2014 Опубликовано 23 января, 2014 · Жалоба стандарт говорит The USB limits the maximum data payload size to 1,023 bytes for each full-speed isochronous endpoint. High-speed endpoints are allowed up to 1024-byte data payloads. A high speed, high bandwidth endpoint specifies whether it requires two or three transactions per microframe. вот, дальше в стандарте таблички, и получается что для Full Speed, если пихаеш 1023 байта, то максимум 1 транзакция в кадр, который раз в миллисекунду. а вот если пихать по 64 байта, то можно сделать до 20 посылок во фрайм 128 байт - 10 посылок 256 байт - 5 посылок и получить скорость 1280 байт в кадр. вот так и получается 12 МБит обещанные в секунду. для балка максимальный размер данных 64 байта, максимальное число посылок 19 и скорость 1216. Но как вам правильно сказали выше, хрен вы эти 19 запросов получите. Балк - это режим передачи при котором пакеты не должны теряться, потому если хост не готов их принять, он приостановит передачу, так же как и вы, если кончатся данные. и реальность будет ниже ожидаемых 19 запросов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Utyff 0 23 января, 2014 Опубликовано 23 января, 2014 · Жалоба Golikov A. Спасибо! Изохронный больше подойдет мне. Буду копать его реализацию в STM32. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rikorsev 0 23 января, 2014 Опубликовано 23 января, 2014 · Жалоба Golikov A. Спасибо! Изохронный больше подойдет мне. Буду копать его реализацию в STM32. Столкнулся с такой же проблемой реализации USB изохронной передачи на STM32. Как то не понятно, как через 512 байтный буфер (где еще должны размещаться другие буферы эндпоинтов) передать 1023. Был бы благодарен если бы кто то вывалил пример кода в котором передавалось бы 1023 байта за Фрейм. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ataradov 0 23 января, 2014 Опубликовано 23 января, 2014 · Жалоба Как то не понятно, как через 512 байтный буфер (где еще должны размещаться другие буферы эндпоинтов) передать 1023. Я с этим чипом не знаком близко, но если максимальный размер памяти под endopoint 512 байт, то никак. Это странное ограничение в современном мире, но встречается. Так что тут максимальная производительность будет с bulk и скорость - какая уж получится. А можешь объяснить или дать ссылку - как сделать больше одного запроса за кадр? Это от хоста зависит. Самый простой способ ему намекнуть - просто запросить сразу много байт переслать. Я обычно запрашиваю 64кБ. Мне нужна конкретная реализация на STM32F103 идеально если есть пример. C STM не работал, примеров нет. Абстрактные ограничения протокола или драйверов Win это вторично если до этого дойдет. Дойдет сразу. Если вам тут сейчас дадут пример, то как вы его испытывать будете? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Utyff 0 23 января, 2014 Опубликовано 23 января, 2014 · Жалоба Столкнулся с такой же проблемой реализации USB изохронной передачи на STM32. Как то не понятно, как через 512 байтный буфер (где еще должны размещаться другие буферы эндпоинтов) передать 1023. Был бы благодарен если бы кто то вывалил пример кода в котором передавалось бы 1023 байта за Фрейм. 1023 никак. Как я понял, можно использовать двойной буфер и тогда можно передавать за 1 фрейм несколько посылок. И в изохронном и в балк режиме. При этом можно выбрать всю возможную ширину канала. Сейчас разбираюсь с реализацией. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
misyachniy 0 23 января, 2014 Опубликовано 23 января, 2014 · Жалоба Я с этим чипом не знаком близко, но если максимальный размер памяти под endopoint 512 байт, то никак. Это странное ограничение в современном мире, но встречается. Прием синхронизируется по стартовым синхро-битам. При увеличении размера посылки растет вероятность рассинхронизации. По этому размер ограничен. В стандарте FULL устройств была максимально допустимая посылка 64 байта, для HIGH увеличили до 512. Для передачи больших данніх используют дробление на короткие посылки и двойную буферизауцию Так что тут максимальная производительность будет с bulk и скорость - какая уж получится. На FULL прокачивается 1 мегабайт. Только нужно качать "большим куском". Если если работать в режиме запрос/ответ то скорость значительно упадет. При прокачке программа зависает. Если нужно чтобы прграммма реагировала на управление, нужно или отдельную нить запускать или использовать OVERLAPPED метод обмена. Это от хоста зависит. Самый простой способ ему намекнуть - просто запросить сразу много байт переслать. Я обычно запрашиваю 64кБ. Я бы сказал от операционной системы. Хост все равно посылает/принимае пакеты не более 512 байт. Windows XP позволяет закачивать частями по 128кБайт Вот проект для SAM7 которым я изучал http://njnmnp.narod.ru/proj/usb_bulk_sam7/usb_bulk_sam7.html Сейчас я пользуюсь libusb. Работает устойчиво, скорость я не измерял. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ataradov 0 23 января, 2014 Опубликовано 23 января, 2014 · Жалоба Для передачи больших данніх используют дробление на короткие посылки и двойную буферизауцию Для максимальной производительности на Iso нужен полный буффер на 1023 байта. Комментарий был про это ограничение. Сейчас я пользуюсь libusb.Работает устойчиво, скорость я не измерял. Опять-же на винде libusb не поддерживает изохронную передачу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
