Флешка плюс опрос портов

Здрасте.
Хочу сделать прибор - собирающий данные с портов или АЦП и выгружающий на комп по USB файло: пример про HID-USB я нашёл, но это ещё не флешка - как сделать флешку? - посоветуйте пример.

0

Сообщение от COKPOWEHEU Вы же хвастались, будто читали документацию. Там прямым текстом указываются применения этих точек.

Да - применять их надо там, где требуется гарантированная передача. Уже 100500 раз написал это.
Из этого следуют все варианты применения. Вы документации USB не видели или не способны понять написанного там, потому для вас все аргументы - пустой звук. Всё равно что слепому объяснять как выглядит солнце.

Сообщение от COKPOWEHEU Перевожу: приперли к стенке, аргументы кончились, но признать свою неправоту ну вот совсем не хочется.

Куда именно вы там что-то "припёрли"? Вы игнорируете все неудобные вам аргументы, перевираете высказывания, передёргиваете... Обычная практика тролля.

Вывод из всего этого один: Для реалтайм-потоков данных, наиболее разумно - использовать изохронные точки.
Точка. Я всё сказал. Кто не понял - я не виноват.

0

Сообщение от COKPOWEHEU Неужели разработчики USB-шины все поголовно идиоты, раз зачем-то придумали такую "ненужную" вещь как изохронные точки?

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

1

Nname100, "прикол" в том, что в осциллографе нафиг не нужна гарантия времени доставки. Обязательна гарантия целостности пакета: вряд ли тебе понравится, что на экране компьютера ты будешь видеть в осциллограмме провалы и недостающие пакеты.
Поэтому изохронные точки в таких вещах и не используют - передают bulk, к каждому пакету прикрепляют временнýю метку.
И в любой научной аппаратуре важно не время доставки, а целостность данных. Астроном, например, спокойно может подождать пять минут, пока сливается кадр с ПЗС-матрицы (он знает, что если хотя бы в 2 раза повысить скорость считывания, шумы возрастут значительно).
А вот когда мы слушаем музыку, то, наоборот: пропуск некоторых пакетов не влияет на прослушивание (конечно, если их не 10% и больше), а вот изохронность важна. Поэтому всякие плееры и пользуют изохронные пакеты. Аналогично с видео.

Вот и определились: изохронные пакеты важны для непрерывных потоков аудио и видео, больше их некуда применить.

0

Сообщение от jcxz Да - применять их надо там, где требуется гарантированная передача. Уже 100500 раз написал это.

"Применять единственный тип точек, который не гарантирует доставки там, где требуется гарантированная доставка". Гениально!

Сообщение от jcxz Вы документации USB не видели или не способны понять написанного там

Ну вот кого конкретно вы пытаетесь обмануть-то? Даже в этой теме вас минимум трижды ткнули носом в ваши "знания".

Сообщение от jcxz Вы игнорируете все неудобные вам аргументы

А. Это, видимо, я не сумел продемонстрировать реальную пропускную способность своего устройства и свято верю, что изохронная точка по волшебству все обеспечит.
Это, видимо, я свято уверен, что bulk транзакция может быть лишь единственной за кадр.
Это, видимо, я свято уверен, что стоит в хаб воткнуть LS-устройство, как он тоже станет LS-устройством.
Это, видимо, я напрочь игнорирую опыт производителей железа.
---
Кстати, как вы думаете, может ли быть больше одной изохронной транзакции за фрейм? Подсказываю: я об этом в данном треде уже говорил.

Сообщение от jcxz Кто не понял - я не виноват.

Кто не понял - таки может хоть немного ознакомиться с материалом.

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

Позвольте, угадаю. Вы не читали начало темы?

1

Сообщение от Nname100 изохронный. Он предназначен для передачи данных, критичных к времени доставки, однако не гарантирует ее успешность. Самый классический пример — аудиоустройства

Да, именно так. Аудиоустройства - это частный случай потоковых устройств. А не единственное недоразумение предназначение USB (как считают некоторые местные персонажи).
В общем случае: "потоковые устройства", это любые устройства, требующие передачи реал-тайм потока данных. Именно для того и были созданы изохронные точки. Поток данных с АЦП - это тоже потоковый режим работы.
И вся инфраструктура и самих изохронных точек и кода, их обслуживающего в USB-стеках и драйверах хоста - она строится именно с прицелом потокового реалтайм-применения. Достаточно посмотреть API соответствующих пакетов: cyusb, libusbk, ... И обслуживать изохронные точки драйвер хоста обязан каждый USB-фрейм, а не "как карта ляжет".

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

Костылинг передачи реал-тайм потоков через не предназначенные для этого интерфейсы - это именно костылинг. Который говорит только об уровнях компетенции костыле-строителя. Когда дело доходит до работы в реальных условиях, эти костыли ломаются, а костыле-строители скрываются в тумане.

0

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

0

Сообщение от Nname100 но ни кто запрещает взять контроль реал тайма на себя

Точно! Никто не запрещает переписать системный драйвер USB-хоста операционки.

0

Что двойная, что одинарная - а все равно буферизация ☺
И превращается этот изохронный поток…
Почти аналогичную штуку можно сделать на USB CDC: просто не дожидаться, пока предыдущий пакет хост примет, а отклонять запись текущего пакета. Привяжи эту отправку к получению SOF - вуаля ☺

0

Сообщение от COKPOWEHEU Позвольте, угадаю. Вы не читали начало темы?

каюсь
прочитал назваание но дискуссия уважаемых донов плавно перешла в формат пикеровки а ты это читал , а я читал, но ты невнимательно читал а я очень читал.
и отвечу словами т Шарикова - Позвольте узнать, что вы можете сказать по поводу прочитанного. Шариков пожал плечами. - Да не согласен я. - С кем? С энгельсом или с каутским? - С обоими, — ответил Шариков. - Это замечательно, клянусь богом. "Всех, кто скажет, что другая…" А что бы вы со своей стороны могли предложить? - Да что тут предлагать?.. А то пишут, пишут… Конгресс, немцы какие-то… Голова пухнет. Взять все, да и поделить…
Подробнее на livelib.ru:
https://www.livelib.ru/quote/9... l-bulgakov

Добавлено через 10 минут

Сообщение от jcxz Точно! Никто не запрещает переписать системный драйвер USB-хоста операционки

а для чего.

вот пример как у меня реализовано Цапе (хотя можно было использовать USB audio)

по шнурку дата данные бегут в 1 буфер а цапа кушает с буфера 2 когда его опустошит перейдет на первый а второй будет заполнятся и так по кругу очень древнее решение,
и ничего сложного.

1

Сообщение от Eddy_Em Что двойная, что одинарная - а все равно буферизация ☺

И точно - мальчик, девочка - да какая в *опу разница!?
И эти люди (не понимающие главного смысла двойной буферизации) ещё тут чего-то доказывают с пеной у рта....

Сообщение от Eddy_Em Почти аналогичную штуку можно сделать на USB CDC: просто не дожидаться, пока предыдущий пакет хост примет, а отклонять запись текущего пакета. Привяжи эту отправку к получению SOF - вуаля ☺

Ну-ка, ну-ка - подробнее! Как это "не дожидаться, пока предыдущий пакет хост примет"? Что такое "отклонять запись текущего пакета"? Поделитесь мастерством!

Сообщение от Nname100 и отвечу словами т Шарикова - Позвольте узнать, что вы можете сказать по поводу прочитанного. Шариков пожал плечами. - Да не согласен я. - С кем? С энгельсом или с каутским? - С обоими, — ответил Шариков. - Это замечательно, клянусь богом. "Всех, кто скажет, что другая…" А что бы вы со своей стороны могли предложить? - Да что тут предлагать?.. А то пишут, пишут… Конгресс, немцы какие-то… Голова пухнет. Взять все, да и поделить…

"...взять всё да и через CDC запердолить!"

1

Сообщение от jcxz Точно! Никто не запрещает переписать системный драйвер USB-хоста операционки.

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

Сообщение от Eddy_Em Почти аналогичную штуку можно сделать на USB CDC

Если бы бульк и изохронные точки были взаимозаменяемыми, то возможно, и опрос АЦП делали не на бульках.
Им ведь и правда полоса выделяется по остаточному принципу.
Это, конечно, не отменяет того, что и изохронные не могут захватить всю полосу.

Сообщение от jcxz "...взять всё да и через CDC запердолить!"

Несомненно, лучше "взять все и через изохронные запердолить". Правда, вместо стандартного протокола придется городить свой, ни с чем несовместимый. Правда, в отсутствие аппаратного контроля целостности пакетов придется городить софтовые костыли. Но это все мелочи! Главное верить, что хост обеспечит 150% пропускной способности шины!

1

Сообщение от jcxz Костылинг передачи реал-тайм потоков через не предназначенные для этого интерфейсы - это именно костылинг. Который говорит только об уровнях компетенции костыле-строителя. Когда дело доходит до работы в реальных условиях, эти костыли ломаются, а костыле-строители скрываются в тумане.

все кроется в названии USB универсальная шина для этого она создана. те одну и туже задачу можно решить разными способами. и с одним и тем же результатом. просто надо учитывать реальную ситуацию.

0

Сообщение от Nname100 одну и туже задачу можно решить разными способами.

Вот пример реальной задачи реал-тайм потока данных АЦП(МК)->USB->хост(ПК): МК через АЦП получает непрерывный поток данных от чипа цифрового радио и передаёт его в хост. На хосте (ПК или планшет) - демодулятор/декодер потока. Скорость потока скажем = ~800 кБ/с. USB-FS. МК - довольно слабый, не имеет многомегабайтного буфера. Приём - непрерывный: идёт непрерывный поиск сигнала в эфире и демодуляция/декодирование найденных пакетов по потоку сэмплов из АЦП. Кроме того - большой буфер в приёмнике не только труден, но и в принципе невозможен, так как задержка тракта передачи от цифрового радио до декодера на хосте, должна быть минимальной длительности и строго детерминированной по задержке. Так как программа на хосте по результатам декодирования приёмного потока, ищет окна, в которые устройство может выходить в эфир. Окна должны вычисляться с точностью до единиц мсек (лучше если = десятки/сотни мкс). (Промах выхода своего передатчика в эфир не должен превышать одной, двух мс)
Вот тут изохронная точка необходима. Так как имеет гарантированное и строго детерминированное время передачи. Более того - окна для передачи можно вычислять прямо по USB-кадрам. Никакие bulk-и тут в принципе не применимы.

PS: И не надо писать галиматью про осциллографы: ликбез для кухарок, не знающих "что такое осциллограф и как он работает": Осциллограф - это не реал-тайм потоковое устройство. Так как его работа не нарушится, если поток будет на какое-то время приостановлен. Потому - для него изохронная точка не обязательна.

0

Сообщение от jcxz Вот пример реальной задачи реал-тайм потока данных

хороший пример
в первом случае все будет работать пока система позволит если это win а (реал тайм потоки не на осрм это как-то не комильфо)
всмысле не решит выделить время на другую задачу.
и приложение придется зааускать с мах приорететом(в случае обвала(потери контроля хоть на 10ms 100% потеря связи на ХЗ какое время.так как не ты хозяин потока а OS. и все процедура инициализвции и захвата потока заново

второй случай уже декодированный поток идет по USB-audio риск тот-же востановление связи не потребуется всмысле поток не прервется, просто звука не будет и все

Добавлено через 2 минуты
под

Сообщение от Nname100 USB-audio

имеется ввиду внешняя звуковуха

0

Сообщение от Nname100 в первом случае все будет работать пока система позволит если это win а (реал тайм потоки не на осрм это как-то не комильфо)

Было требование кросс-платформенности: хост мог быть любой - win, линух или Андроид.

Сообщение от Nname100 всмысле не решит выделить время на другую задачу. и приложение придется зааускать с мах приорететом

Не всё так страшно: Базовая станция непрерывно транслирует в эфир командные пакеты, оставляя окна для передатчиков терминальных устройств. Положение окна передачи указывается в одном из командных кадров заранее - задолго до самого окна. Минимальное прогнозируемое время выхода в эфир относительно принятого командного кадра: не менее 1сек (от +1 сек до +несколько десятков сек).
Даже если задача демодулятора на хосте будет приостановлена на сотню-две миллисекунд, то ничего страшного - потом нагонит. Главное чтобы синхронность потока кадров от приёмника не была нарушена. По ним и выполняется вся синхронизация и привязка по времени: ведь знаем что каждую миллисекунду обязательно передаётся один кадр. Ни больше ни меньше. Вне зависимости от загрузки системы на уровне приложений. Значит демодулятор всегда может сообщить модулятору точку синхронизации для выхода в эфир в окне передачи.

Ну и естественно - система на хосте не должна быть загружена посторонними задачами на 100%. Тогда всё успеет даже под win.

0

Сообщение от jcxz Ну и естественно - система на хосте не должна быть загружена посторонними задачами на 100%.

я это и имел ввиду

а так да согласен

0

Сообщение от jcxz Вот пример реальной задачи реал-тайм потока данных АЦП(МК)->USB->хост(ПК): МК через АЦП получает непрерывный поток данных от чипа цифрового радио и передаёт его в хост.

Одна из реализаций этого примера https://ftp.radio.ru/pub/2020/06/tuner.zip
Описание конструкции в журнале Радио №6 2020.
Если кратко, STM32 из АЦП / I2S передает семплы по USB в комп.
Но там большая скорость не нужна и используется обычный HID. Его достаточно для 2-ух каналов с частотой семплирования 44100, 16 бит.

0