Комментарии 40
Печально видеть COM порт в современном изделии. Популярных SDR приёмников ведь много, думаю, можно было выбрать протокол посовременнее. Или сделать кастомный протокол и написать плагин для декодирующей программы (к примеру, в SDRangel это делается несложно).
Как по мне, развитие SDR технологий — хороший повод пересмотреть исторические подходы.
Потому, что устройство — приёмник, а не COM-порт и звуковая карта. Мало того, что типы соответствуют функции весьма отдалённо, так ещё и устройство не одно, а два.
Допускаю, что в данном конкретном случае прямой путь может быть слишком сложен, однако отбрасывать его даже не рассматривая — это странно.
Аналогия — хранение числовых переменных в памяти в виде строк. Удобно, достаточно выучить, как работать со строками, не нужно думать о порядке байтов, диапазоне значений. Иногда в этом есть смысл, но чаще всего это приводит лишь к дополнительным расходам ресурсов памяти (на хранение) и процессора (на постоянное преобразование типов туда-сюда).
Или сделать кастомный протокол и написать плагин для декодирующей программы (к примеру, в SDRangel это делается несложно).
так автор же написал, что нет опыта программирования.
А чем плох COM в данном конкретном случае?
Так удалось же с USB разобраться.
COM — это лишняя сущность, не требующаяся ни со стороны ПК, ни со стороны приёмника.
Раз уже есть USB, то более чистое решение — использовать для связи непосредственно его.
Возможно, эмуляция какого-то другого приёмника добавит ещё больше лишнего кода, но это можно понять только после анализа.
Это недостаток кастомного протокола, верно. Однако, если устройство существует в одном экземпляре, то это может и не быть проблемой. Второй вариант — эмуляция популярного устройства — предполагает, что драйверы уже кем-то написаны.
Для связи между ПК и приёмником. Правила, по которым формируются USB пакеты (то, что я называл протоколом), знают драйвера устройства и программы, которые с этим устройством работают. Чтобы посмотреть на то, как работает "невозможное", достаточно покопаться в исходниках библиотек современных приёмников, к примеру, LimeSDR или RTL-SDR.
Через СОМ устройством можно управлять с любого устройства, от АТмеги до сервера, напрямую или через долларовый переходник, просто посылая ему текстовые строки. Если же, как вы предлагаете, делать проприетарный протокол, то вы такое устройство не сможете подключить к своему микроконтроллеру, если на протокол нет документации, исходников или времени на разработку.
COM — это лишняя сущность
COM вас переживёт, могу поспорить. Это промышленный стандарт, возможности которого (особенно гальванически развязанного) и не снились USB. Единственно в чём он проигрывает — скорость.
Простота реализации (железо+код), полный дуплекс, помехозащищенность (-12V \+12V против 0\+5V), кабель 3 жилы против 5 у USB, максимальная длина кабеля 100м против 5 у USB.
Не смейтесь над старичком, он — Кощей Бессмертный.
Вы возможно удивитесь, но почти в каждом роутере, в том числе и бытовом, присутствует железный, распаянный COM-порт, только кабель подключи. Про всякие одноплатные машинки и не говорю.
Речь не о COM вообще, а о его применении в SDR приёмнике. Допустим, COM защищён от помех, защищён ли так же хорошо от них аудиокабель? Допустим, поддержку COM легко реализовать, но так ли это важно, если всё равно надо разбираться с USB?
В роутерах, полагаю, для отладочного интерфейса важна надёжность. Чем меньше кода, тем меньше шансов допустить в нём ошибку. Отлаживать же работу USB через USB… думаю приятного мало.
Арбитраж напишите свой, если его нет или работает некорректно. Или вы на уровне ОС работаете?
2. Как организован вывод звука?
3. Откуда это все тактируется?
Вот сейчас лежу, и пытаюсь реализовать абсолютно то же самое, но используя библиотеку libopencm3.
По крайней мере, слово «композитное» сразу вызывает в голове нужные ассоциации.
Составное устройство USB на STM32. Часть 2: USB Audio Speaker
Составное устройство USB на STM32. Часть 3: Звуковое устройство отдельно, виртуальный СОМ-порт отдельно
Составное устройство USB на STM32. Часть 1: Предпосылки