Стандартизация протоколов устройств на МК для радиолюбителей

[NoName]

Создается много разных конструкций на МК, в которых содержится определенный функционал. Объединить усилия авторов для работы над ними не всегда получается: инфраструктуры нет, амбиции авторов не позволяют, либо кому-то хочется испытать что-то свое, причин море. В общем есть некая самостийность.
Но есть другая безумная группа людей - у которой возникает безумная идея объединять их под одной крышей с мультиплексорами к LCD и синтезаторам, дабы съэкономить деньги и место, что есть бред.... Вот если бы каждый автор, сразу делал для своей поделки выход на USART или I2C с возможностью внешнего управления (такой небольшой API с доступом через терминальную прогу), то в конечном варианте можно было бы сделать внешний контроллер управления и отображения для нескольких устройств. Получился бы такой небольшой коллективный труд, кто-то делает свою железку, а кто-то их соединяет вместе. Тем более уже есть образцы воплощения данной концепции, надо только стандартизировать протоколы ну и доку создавать каждому на свой протокол... А уж любители объединить тоже найдутся. Если посмотреть сколько версий частотомеров и синтезаторов создано, то глаза разбегаются
Вот например:
1. У Сергея (transistor) http://www.cqham.ru/forum/showthread...l=1#post655305 в RF-Lab есть модуль частотoмера, который работает либо по USB с внешним миром либо по USART с контроллером управления, индикатора нет, только вывод данных на комп. Правда он свою разработку не публиковал, но я например давно мечтал иметь мощемер и частотомер в одном флаконе. Может опубликует....
2. NWT тоже пример устройства с которым можно общаться по USART, правда там родной протокол дибильный.
3. Я думаю и FCL метр найдется с внешним протоколом, ну либо кто нибудь из авторов допишет.

Сергей так же предлагал протокол обмена, далее цитата

"Мне давно приглянулся стандартный для всех профессиональных проиборов протокол,
который исторически развивался следующим образом:
HPIB - Hewlett Packard Interface Bus (середина 60-ых!);
GPIB - General Purpouse Instrument Bus ;
IEEE488 -> IEEE488-1/-2
IEEE1174 - вариант интерфейса IEEE488 адаптированный к последовательной RS232-линии (с применением USB-RS232 моста и к USB, естественно);
Примерное описание команд дистанционного управления.
1. Начинаются команды с <*>-для Общих команд или с <:> - для команд, относящихся к конкретному прибору.
2. Заканчиваются - <CR> и/или <LF> и/или <CR> <LF>.
3. Могут быть командные строки из набора команд, разделенных <;> (здесь при ограниченном быстродействии могут возникнуть проблемы).
4. Есть программный механизм управления потоками (flow control) - XON/XOFF.
В общем, можно взять за основу для своего протокола, на мой взгляд.
"
От себя могу добавить, можно добавить пару букв в команду для названия девайса и в путь.

[UR4UDT]

Вопросы стандартизации чрезвычайно актуальны.
Как бы не хотелось сделать "более правильно", но зачастую мы становимся заложниками уже того, что "де факто".
Пример тому протокол обмена NWT или CAT в любительской практике. Попытка поменять - наверняка фиаско.
Можно внедрить любой протокол, если он будет поддерживать "звездную" конструкцию. Допустим создается NewWinNWT который имеет массу новых возможностей, легкое дополнение новыми функциями и на первом этапе совместим с существующими конструкциями по базовым функциям (без изменения прошивок контроллера). Новые возможности - новая прошивка МК. И затем легкий переход на более "правильный" протокол.
Я делал такую попытку. Увы, вариант был на VB6 (по доброй памяти) и до конца не доведен, хотя частотомер, LC-мер и еще мелочевка работают.
Оставил эту затею.
Вынашиваю планы и мелкими шагами двигаюсь в сторону использования планшета для измерительных приборов (особенно на крыше).
Все в наших руках!

[Хигэ]

Стандартизация протоколов устройств на МК для радиолюбителей

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

о, придумал как объяснить коротко и на пальцах, это как стандартизировать схемные решения радиолюбителей, во!

[redd]

Думаю что тут уже давно все изобретено, просто нужно переходить на контроллерные системы под управлением какой нибудь реал тайм ОС, написать стандартный модуль или несколько сразу (telnet, ssh, web морда например), и подключать к новым проектам ....

[UR4UDT]

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

Вопрос вроде философский, но.
Автономные конструкции будут всегда. КСВ-метр я никогда не буду интегрировать в измерительный комплекс, а панорамный измеритель комплексных сопротивлений на ЖКИ - извращение.
Стандартизировать схемные решения и не предлагается. Измеряли напряжение (своя схема) и стандартным протоколом в РС, а дальше очевидная обработка по закону Ома (или по своему закону).
Если я правильно понял тему, то желательно создать нечто, что не много облегчит нашу р/л жизнь.

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

В измерениях примерно то же.

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

[redd]

Вот например FreeRTOS, avr mega поддерживает, в случае чего можно на более мощный контроллер перекомпилить ....

[RA9YTJ]

Не стандартность протоколов высокого уровня (а именно об этом идет речь) микроконтроллерных устройств объясняется просто - малым вычислительным ресурсом распространенных чипов (до не давнего времени).
По этому в каждом конкретном случаи придумывается протокол минимизирующий затраты на его обработку. Например: САТ протокол Kenwood требует большего от процессора, чем YEASU, а его популярность объясняется гибкостью и хорошим восприятием человеком, а т.к. AVR PIC последних покалений уже легко справляются с ним, он становится дефакто в самодельных устройствах, да и поддерживается большинством программ.
Современные микроконтроллеры позволяют создавать протоколы уровня командной строки ОС без напряга. Думаю дело времени. Практика показывает, что на первом месте по важности стоят программы запускаемые на компьютере для работы с устройствами. и если они удобные и многофункциональные, то разработчики альтернативных устройств подстраиваются под протокол этих программ. Пример: PowerSDR, сколько синтезов пытаются работать с ней, даже делаются специальные контроллеры, которые "переваривают" посылки в LPT для схематически других синтезов и это не смотря на то, что PowerSDR открыта с исходниками.
Сейчас встает другая проблема, которая ложится поверх сабжевой и думаю сейчас более важная.
Это тип интерфейс подключения устройств. Известно, что СОМ и LPT практически отсутствуют на современных материнках, от них нужно отказываться в устройствах. Нужна замена и она есть - это USB.
Но тут встает проблема, в каком виде устройство должно "выглядеть" с точки зрения ОС и программы. есть 2 варианта: VirtualCOM и HID.
Рассмотрим сначала VirtualCOM, преимущество одно: простота работы с ним из программы и из контроллера (при использовании чипа USB-COM, т.к. UART есть во всех микроконтроллерах), дальше одни недостатки: нет стандартного драйвера, либо надо писать самому драйвер либо, если используется стандартный чип USB-COM, его драйвер, который не всегда обновляется и может иметь проблемы совместимости (сам сталкивался), да и обычно имеет ограничение по скорости. А необходимость установки чипа USB-COM ведет к усложнению устройства.
Рассмотрим HID, недостаток один: немного сложнее в программировании из программы (но это чисто по не знанию, реально там даже удобнее) и необходимость библиотеки HID для микроконтроллера (но они есть для всех USB содержащих чипов контроллеров).
Дальше достоенства: Самый главный - во всех современных ОС есть стандартный, а значит отлаженный и стабильно работающий драйвер. Скорость ограничена только самим USB. Подключается напрямую к микроконтроллеру.
Я за HID.

[Леонид Иванович]

А какой смысл в стандартизации протоколов? Все равно для каждой конструкции нужно писать свой софт, реализация протокола - лишь небольшая часть этого софта, особой экономии времени не получится. Главное - это документированность протокола.

Лично я последние 10 лет использую в своих устройствах протокол WAKE (если заказчик не просит чего-то иного). Работает как точка-точка, так и в сети (с транспортом, например, RS-485). Открытая спецификация, открытые исходники. Есть реализации на asm и C для 8051 и AVR, а также для PC в виде класса на C++, модуля на C или отдельной DLL, кому вообще лень возиться с протоколом. Есть клоны для nix-систем.

[MIKHAEL]

UB3TAF Андрей, незнаю кто и что мог бы собирать из законченых проэктов.
1. Конешно можно чтото подчеркнуть для себя в выложенном исходнике, причем наказуемо (это всё равно что помыться в бане под камерами центрального TV), от этого Вы вероятно и видите скампилированые *.hex-сы.
2. Для тех кто имет желание собирать, нужно хотя-бы освоить языки причом начиная с bascom C asm и т.д.
3. MK от MICROCHIP и ATMEL совершенно не похожи как с наружи (единого протокола здесь просто невозможно)
4. Да и вобще это глобальная проблема.


Пока формулировал как бы это без ихидства высказать. Прочитал пост Леонида Ивановича и понял, что мне по этому поводу уже сказать нечего, (всё сказано постом выше)

Добавлено через 14 минут(ы):

Хотя вполне возможно выводить линию TX к интерфейсу RS232, много места не надо, а за ним преобразователь логических уровней интерфейса+терминаль льный soft, короче огород.
Можно конешно и I2C.
For whom it is necessary?

[khach]

Если говорить про измерительную аппаратуру- то стандарт давно существует- SCPI http://en.wikipedia.org/wiki/Standar...le_Instruments Прекрасно реализуется для КОМ порта (в том числе и USB). Команды немного длинноваты, но допускают сокращение. Единственная проблема- больщие массивы данных в реальном времени, но и это обычно реализуется без проблем. Можно подсмотреть примеры реализации в том же "народном "осциллографе Rigol 1052. Немного хуже ситуация когда SCPI реализуется по чистому USB без виртуального КОМ порта- для драйверов протокола USBTMC (USB Test & Measurement) приходится ставить на комп огромную монструозную VISA, которая и триальная к тому же. Но можно найти в сети обрезанные версии VISA (2-3 мегабайта вместо 200-300 полной версии) и с ними прекрасно работать, да еще и сэкономить место, установив поддержку только USB (без GPIB VXI PXI и прочих изврашений для встроенных инструментов).