Как стать автором
Обновить

Комментарии 40

Очень интересно, жду продолжения.
Продолжение следует:
04.03.2021 Часть 2: USB Audio Speaker
09.03.2021 Часть 3: Звуковое устройство отдельно, виртуальный СОМ-порт отдельно
11.03.2021 Часть 4: Два-в-одном

Печально видеть COM порт в современном изделии. Популярных SDR приёмников ведь много, думаю, можно было выбрать протокол посовременнее. Или сделать кастомный протокол и написать плагин для декодирующей программы (к примеру, в SDRangel это делается несложно).

Программы управления и всяких контестов заточены под работу с классическими трансиверами, а там — ком-порт. Ну так исторически сложилось. А HAM-радио — вещь изрядно замшелая.

Как по мне, развитие SDR технологий — хороший повод пересмотреть исторические подходы.

Зачем ломать то, что хорошо работает? И плодить сущности, изобретая новые, несовместимые со старыми, интерфейсы?

image

Потому, что устройство — приёмник, а не COM-порт и звуковая карта. Мало того, что типы соответствуют функции весьма отдалённо, так ещё и устройство не одно, а два.
Допускаю, что в данном конкретном случае прямой путь может быть слишком сложен, однако отбрасывать его даже не рассматривая — это странно.
Аналогия — хранение числовых переменных в памяти в виде строк. Удобно, достаточно выучить, как работать со строками, не нужно думать о порядке байтов, диапазоне значений. Иногда в этом есть смысл, но чаще всего это приводит лишь к дополнительным расходам ресурсов памяти (на хранение) и процессора (на постоянное преобразование типов туда-сюда).

Или сделать кастомный протокол и написать плагин для декодирующей программы (к примеру, в SDRangel это делается несложно).

так автор же написал, что нет опыта программирования.
А чем плох COM в данном конкретном случае?

Так удалось же с USB разобраться.
COM — это лишняя сущность, не требующаяся ни со стороны ПК, ни со стороны приёмника.
Раз уже есть USB, то более чистое решение — использовать для связи непосредственно его.
Возможно, эмуляция какого-то другого приёмника добавит ещё больше лишнего кода, но это можно понять только после анализа.

Зато под СОМ ненужно переписывать драйвер, когда поменяется операционная система или потребуется работа на разных платформах.

Это недостаток кастомного протокола, верно. Однако, если устройство существует в одном экземпляре, то это может и не быть проблемой. Второй вариант — эмуляция популярного устройства — предполагает, что драйверы уже кем-то написаны.

Безусловно, обычно драйвера для адаптеров пишет производитель. А т.к. объем рынка весьма велик, то качество и разнообразие поддерживаемых систем обычно весьма велико. И если СОМ позволяет реализовать функционал, то он гораздо удобнее даже в серийных устройствах, и на уровне отладки, и на уровне поддержки.
Использовать для связи ЮСБ невозможно в принципе, поскольку ЮСБ — это транспортный протокол, который знать не знает, что там ходит между конечными точками — аудио, файлы или команды.

Для связи между ПК и приёмником. Правила, по которым формируются USB пакеты (то, что я называл протоколом), знают драйвера устройства и программы, которые с этим устройством работают. Чтобы посмотреть на то, как работает "невозможное", достаточно покопаться в исходниках библиотек современных приёмников, к примеру, LimeSDR или RTL-SDR.

Вы не ответили на вопрос — зачем ломать, то, что работает и чего достаточно? Только потому, что СОМ-порту 100 лет в обед и вам захотелось чего-то новенького???

Через СОМ устройством можно управлять с любого устройства, от АТмеги до сервера, напрямую или через долларовый переходник, просто посылая ему текстовые строки. Если же, как вы предлагаете, делать проприетарный протокол, то вы такое устройство не сможете подключить к своему микроконтроллеру, если на протокол нет документации, исходников или времени на разработку.

Ответил в соответствующей ветке.
В статье речь о подключении к ноутбуку. Если есть планы подключать к другим устройствам, то это другой разговор.

COM — это лишняя сущность


COM вас переживёт, могу поспорить. Это промышленный стандарт, возможности которого (особенно гальванически развязанного) и не снились USB. Единственно в чём он проигрывает — скорость.
Простота реализации (железо+код), полный дуплекс, помехозащищенность (-12V \+12V против 0\+5V), кабель 3 жилы против 5 у USB, максимальная длина кабеля 100м против 5 у USB.
Не смейтесь над старичком, он — Кощей Бессмертный.
Вы возможно удивитесь, но почти в каждом роутере, в том числе и бытовом, присутствует железный, распаянный COM-порт, только кабель подключи. Про всякие одноплатные машинки и не говорю.

Речь не о COM вообще, а о его применении в SDR приёмнике. Допустим, COM защищён от помех, защищён ли так же хорошо от них аудиокабель? Допустим, поддержку COM легко реализовать, но так ли это важно, если всё равно надо разбираться с USB?
В роутерах, полагаю, для отладочного интерфейса важна надёжность. Чем меньше кода, тем меньше шансов допустить в нём ошибку. Отлаживать же работу USB через USB… думаю приятного мало.

TCI потихоньку поддерживается всё большим количеством программ, и в нем как раз заложено много всего.

Интересный вариант, особенно если в ноутбуке есть Ethernet разъём.
Протягивать же Ethernet через USB не намного лучше, чем COM порт.

Увеличивайте размер буфера аудио, тогда не будет хрипеть.
Да там опустошение происходит, а не переполнение. Хотя потоки входящих/выходящих на устройство и близко не дотягивают до возможного максимума. Если виртуальный COM не активен — тогда все норм.
Вот для этого и надо увеличить буфер, чтобы не происходило опустошение за то время, пока идут данные в СОМ.
С буфером вроде все ОК, это не однократно проверялось и тестировались разные варианты, но да — очевидно теряются пакеты. Делать бесконечно большой буфер тоже не вариант — звук там — не из файл происходит, а из источника в реальном времени и рассинхрон с видеорядом недопустим (допуск 1/10 секунды — что по идее более чем). Создалось впечатление что нет арбитража очередности пакетов при использовании композитных устройств на USB, возможно это проблема USB в целом, а возможно проблема STM в частности, ну или я что-то делаю не так.
Пакеты теряться не могут, т.к. хост будет переотправлять их до тех пор, пока девайс не подтвердит получение, а уже в девайсе их можно потерять только из-за своих ошибок. Если это не изохронный режим, но в нём нежелательно параллельно поднимать что-то ещё, если нет уверенности, что полосы интерфейса и ресурсов контроллера гарантированно хватит на всех.

Арбитраж напишите свой, если его нет или работает некорректно. Или вы на уровне ОС работаете?
Понятно, что теряются в девайсе. Может и из-за своих, но я бы не был столь категоричным, может и из-за ошибок разработчиков девайса.
Нет, не хрипит.
Надо будет ваш вариант попробовать адаптировать. Спасибо!
1. У Вас какой MCU?
2. Как организован вывод звука?
3. Откуда это все тактируется?
У меня STM32F407G-DESC1 и все по примерам, ну кроме того, что я к ней еще USB3300 ULPI прикрутил.

В общем как-нибудь разберусь. Может быть ))

Обратите внимание:


  1. На размер приемного буфера USB. Назначается в файле usbd_conf.c функцией HAL_PCDEx_SetRxFifo ( ). Расчет есть в руководстве по HAL для F4.
  2. На мастерклок. Лучше его не колхозить из тактовой частоты MCU, а взять с калиброванного генератора.
Господи, спасибо огромное.
Вот сейчас лежу, и пытаюсь реализовать абсолютно то же самое, но используя библиотеку libopencm3.
Всегда пожалуйста!
Я для этого и начал публикацию, чтобы другие обошли мои грабли.

Не могу не спросить… А почему лежу ?

Мне почему-то лучше программируется лежа :)
Почему-то хочется вместо слова «составное» видеть слово «композитное».
По крайней мере, слово «композитное» сразу вызывает в голове нужные ассоциации.
Долго я пытался запустить ADTRX UR4QBP. Так ничего и не получилось, к сожалению.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.