Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Посоветуйте, пожалуйста, открытый протокол
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > RS232/LPT/USB/PCMCIA/FireWire
kkobru
Добрый вечер!

Пришло время разработать некий внутренний стандарт управления приборами, и хотелось бы найти какой-нибудь открытый протокол, удовлетворяющий следующим требованиям:

- Работа через полудуплексный или полнодуплексный последовательный порт, либо через другие каналы, в том числе IP.
- Архитектура точка - точка, мастер-слейв.
- Событийная модель (то есть, возможность получать с мастера асинхронные события/данные, с возможностью настройки, как их получать, через поллинг, либо через отдельный канал)
- API для встраивания протокола в C/C++ на стороне мастера и С на стороне устройства.

Думаю, такое должно быть, просто не понимаю, как искать.

Заранее спасибо!
megajohn
Да это вы описали SNMP

AlexandrY
Цитата(megajohn @ Jan 28 2018, 20:14) *
Да это вы описали SNMP

Я бы добавил - SNMP с кодировкой BER поверх PPP.
А то неясно как через RS232, или RS485 этот SNMP переправлять.
Реализация SNMP и PPP как раз есть в RTOS MQX под микронтроллеры Kinetis и i.MX RT
Там же можно найти реализацию VCOM. Тогда цепочка будет такая: SNMP->BER->PPP->vCOM->USB
А на PC мастер SNMP легко делается в RAD Studio.
megajohn
Цитата(AlexandrY @ Jan 28 2018, 21:30) *
Я бы добавил - SNMP с кодировкой BER поверх PPP.


да, это верно поправили

прикладываю для ТС архивчик
SNMP_Simple_Network_Management_Protocol.pdf - пример как можно организовать управление железкой
SNMP.pdf SNMP_brief_3.pdf - тоже теория
b6300a.cap - примера обмена SNMP по IP для WireShark
пакет 3 - запрос значений для обьектов 1.3.6.1.2.1.1.5.0 и 1.3.6.1.2.1.1.6.0
пакет 4 - ответ
gosha-z
Интересно посмотреть на PPP по полудуплексному каналу...
megajohn
Цитата(gosha-z @ Jan 29 2018, 11:24) *
Интересно посмотреть на PPP по полудуплексному каналу...


да пожалуйста, этож не симплекс !
kkobru
Мда. Дело конечно интересное, но вот мне пока не очень понятно, как это всё будет работать, если:

1. со стороны слейва у нас MSP430 без ОС.
2. необходимо от слейва к мастеру передавать поток данных со скоростью до 200 отсчётов в секунду.

и, кстати, там не PC мастером, а как правило, приложение под встроенный линукс.

Я смотрел на MessagePack, но он, по-моему избыточен.
AlexandrY
Цитата(kkobru @ Jan 29 2018, 12:41) *
Я смотрел на MessagePack, но он, по-моему избыточен.

Это просто аналог BER. А где все остальное?
ViKo
Слово "приборы" ассоциируется у меня с SCPI.
https://en.wikipedia.org/wiki/Standard_Comm...ble_Instruments
kkobru
Давайте я уточню с точки зрения предметной области.
Это лабораторные приборы, которые работают по RS232/485 либо Ethernet, если нужен большой поток данных.
Набор команд простой должен быть:
1. Установить значение параметра
2. Переключить что-то
3. Считать значение с измерителя
4. Получать поток значений с метками времени с измерительного канала
5. Получать события (готовность, ошибка, и т.д.)

Самое важное, что это должна быть открытая библиотека на С, которую легко подключить к коду, работающему без ОС.
megajohn
п. 1,2,3,5 это вполне подойдет для SNMP . Можно и Modbus использовать
п. 4 тут конечно что-то другое надо использовать. Я бы передавал как UDP over PPP и далее в UART

пример прикладываю



Baser
Цитата(kkobru @ Jan 28 2018, 17:17) *
- Архитектура точка - точка, мастер-слейв.
- Событийная модель (то есть, возможность получать с мастера асинхронные события/данные, с возможностью настройки, как их получать, через поллинг, либо через отдельный канал)

Цитата(kkobru @ Jan 29 2018, 12:41) *
2. необходимо от слейва к мастеру передавать поток данных со скоростью до 200 отсчётов в секунду.

Цитата(kkobru @ Jan 29 2018, 16:55) *
4. Получать поток значений с метками времени с измерительного канала
5. Получать события (готовность, ошибка, и т.д.)

Ваше ТЗ выглядит несколько противоречивым.
Наверное, все же получение от слейва асинхронных событий и данных?

По режиму работы это больше получается мультимастер.

А получать поток значений и события нужно с какими максимальными задержками?
Может быть достаточно по запросу мастера раз в секунду получать один пакет с 200-и отсчетами?
mantech
Цитата(kkobru @ Jan 28 2018, 18:17) *
Добрый вечер!

Пришло время разработать некий внутренний стандарт управления приборами, и хотелось бы найти какой-нибудь открытый протокол, удовлетворяющий следующим требованиям:

- Работа через полудуплексный или полнодуплексный последовательный порт, либо через другие каналы, в том числе IP.
- Архитектура точка - точка, мастер-слейв.
- Событийная модель (то есть, возможность получать с мастера асинхронные события/данные, с возможностью настройки, как их получать, через поллинг, либо через отдельный канал)
- API для встраивания протокола в C/C++ на стороне мастера и С на стороне устройства.

Думаю, такое должно быть, просто не понимаю, как искать.

Заранее спасибо!


Modbus (COM port) Modbus TCP (Ethernet) Простая реализация, единый протокол и хорошо стандартизирован.
AlexandrY
Цитата(kkobru @ Jan 29 2018, 16:55) *
Самое важное, что это должна быть открытая библиотека на С, которую легко подключить к коду, работающему без ОС.

Как можно легко подключить развитую библиотеку, а вернее стек протоколов к коду без оси?
Я вот этого не понимаю.
Тот же MessagePack, он же парстит, кодит, жрет память ... в совершенно непредсказуемых количествах и качествах.
Как его можно просто так взять и вставить в код без ОС? Это же профайлинг и перекапывание всей библиотеки до потемнения в глазах.
Вот в этом главное противоречие.
mantech
Цитата(AlexandrY @ Jan 29 2018, 22:21) *
Тот же MessagePack, он же парстит, кодит, жрет память ... в совершенно непредсказуемых количествах и качествах.
Как его можно просто так взять и вставить в код без ОС? Это же профайлинг и перекапывание всей библиотеки до потемнения в глазах.


Как же далеки стали сегодняшние кодеры от классического оптимального ПО laughing.gif
kolobok0
Цитата(mantech @ Jan 30 2018, 09:25) *
Как же далеки стали сегодняшние кодеры от классического оптимального ПО laughing.gif


последствия всемирных попыток снизить себестоимость разработки. мало было кризиса 2001 явно... всё ходит кругами - посему надо ждать снижения какчества и траблы по темам...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.