Создадим свой открытый протокол обмена данными между контроллером и модулями

можно-то можно, кто ж спорит. Только wi-fi это метров 100 максимум на открытой местности с постоянной потерей сигналаsevpro, 09 Янв. 17, 09:35

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

+ необходимость иметь какой-никакой мост на той стороне. А мост тоже не 3 копейки будет стоить (если не считать поделку для рукоблудия - esp8266).sevpro, 09 Янв. 17, 09:35

сейчас практически любой роутер может работать в режиме моста, опять же есть openwrt, роутеры стоят копейки особенно на вторичном рынке ну и лично у меня их полно.

машины это как раз самое меньшее зло. Там длительность пакета единицы мс.sevpro, 09 Янв. 17, 09:35

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

все решено. Я ж говорю УАРТ абсолютно прозрачен, никакого мусора и промежуточных костылейsevpro, 09 Янв. 17, 09:35

нужно самому обеспечить целостность данных, контролировать доставку пакетов и т.п.

 Чего то я непонимаю.
Мосты шлюзы подразумевается бесплатные наверное.
Потом - так беспроводное все или проводное?

Чего то я непонимаю.PavelSaratov, 09 Янв. 17, 10:45

тогда о чем ты ведешь разговор?
я отвечал на это

А это все маниловщина: хочу езернет, ви-фи на каждом датчике, адресация, квитирование и т.п. Тем более смысла во всем этом не много учитывая, что все оборудование размещено на площади 1-2 кв.метраsevpro, 08 Янв. 17, 12:45

все решено. Я ж говорю УАРТ абсолютно прозрачен, никакого мусора и промежуточных костылейsevpro, 09 Янв. 17, 09:35

дак 485 и есть UART только односторонний,с переключением прием передача. Но если UART до 5 метров то 485 до 1,3 км. а так писать больше ни чего ни надо только один вывод переключение прием-передача.

Добавлено через 3мин.:

Микросхема 20 руб, от процессора TX,RX, управляющий прием-передача выход два диф канала A и Б.

Добавлено через 6мин.:

Скорость можно сделать 250К как у DMX-512 и библиотеки взять от туда и чуть справить их. Ну а если свой протокол сделать то и надежность передачи будет высокая.

terminal, не выдергивай из контекста. Это я с makом общался на тему удаленного беспроводного подключения гаража. Разговор шел за модули беспроводной передачи. Не думаю, что он захочет 60 метров витухи через двор тянуть.

недолго она провисит
основная прелесть - в IP можно сейчас капсулировать что угодно, как угодно и при этом прозрачно

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

terminal, ты не понял о чем речь
насрать на то чем и как передавать, хоть rs485, хоть can, хоть ethernet, хоть лазерами, важно что передавать
Чтобы исполнитель производителя А понял что от него хочет автоматика производителя B он должен помимо соответствия физического интерфейса понимать те данные, что ему передали, но это идеал, и у меня есть определенные сомнения что он достижим
Как минимум пока что почти все стараются запихать все что можно в одну железку без возможности какого-то масштабирования
Из возникшего много выше вопроса появилась мысль что в самом простом варианте автоматика в один из последовательных портов пишет лог всех своих событий, а исполнитель читает его и отлавливает то что сможет выполнить
к примеру узел отбора выставляет пропускную способность или скорость, фракционник переключает ёмкости и т.д.

terminal, ты не понял о чем речь
насрать на то чем и как передавать, хоть rs485, хоть can, хоть ethernet, хоть лазерами, важно что передавать
Чтобы исполнитель производителя А понял что от него хочет автоматика производителя B он должен помимо соответствия физического интерфейса понимать те данные, что ему передали, но это идеал, и у меня есть определенные сомнения что он достижим
Как минимум пока что почти все стараются запихать все что можно в одну железку без возможности какого-то масштабирования
Из возникшего много выше вопроса появилась мысль что в самом простом варианте автоматика в один из последовательных портов пишет лог всех своих событий, а исполнитель читает его и отлавливает то что сможет выполнить
к примеру узел отбора выставляет пропускную способность или скорость, фракционник переключает ёмкости и т.д.mak, 09 Янв. 17, 13:22

Дак я для этого и хочу свой протокол

Добавлено через 4мин.:

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

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

для начала нужно описать структуру данных, элементы данных и связи между нимиmak, 09 Янв. 17, 13:33

ну вот, а я о чем. Я и говорю Вам, зачем городить огород со всеми протоколами которые не заточены под наши цели, можно сделать свой краткий и понятный, только что не стандартизированный.
Как Я это вижу, нужно описать все устройства которые мы можем поставить в нашу сеть, потом данные для этих устройств, потом формат этих данных, ну и потом уже протокол передачи. К примеру: 1- термометр 2- спиртометр 3- датчик уровня и.т.д. формат данных термометр 2 байта,спиртометр 1 байт, датчик уровня 2 байта
А вот пример данных от датчиков допустим что их в контроллере несколько и у контроллера адрес 20 тогда получится  A5 01 20 0d 01 XX XX 02 XX 03 XX XX контрольная сумма вот и весь пакет (тут я скромно) A5 - начало пакета 01 пакет мастеру от устройства с портом 20, 0d -данные с датчиков устройства, 01 данные температуры 02 данные спиртуозности 03 данные уровня жидкости. А перед этим мастер запрашивает командой типа 20-й дай мне данные датчиков.В данном случае у мастера порт 01.

Добавлено через 3мин.:

только здесь я опустил строб для сброса линии и счетчик транзакций для контроля пакетов.

ачем городить огород со всеми протоколами которые не заточены под наши цели, можно сделать свой краткий и понятный, только что не стандартизированный.terminal, 09 Янв. 17, 13:52

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

Портов может быть 255, на одном порту (1 контроллер 1 порт,порт здесь виртуальный )может сидеть несколько датчиков. 

Добавлено через 7мин.:

нахрена вообще изобретать велосипед?mak, 09 Янв. 17, 14:08

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

Добавлено через 3мин.:

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

я у себя использую в основном физический can, поэтому прикладной уровень у меня - canOpen
для rs485 если сильно заморочиться то PavelSaratov правильно говорил есть profibus, хрень навороченная в том числе с языками описания устройств

profibusmak, 09 Янв. 17, 14:28

платный протокол - хош пользовать плати. Есть еще один платный протокол RDM он специализирован под освещение. Протокол по сути это договоренность об обмене, RDM к примеру описывает полностью все данные светильника сколько ламп в светильнике сколько у них наработка итд итп.

Добавлено через 5мин.:

canOpenmak, 09 Янв. 17, 14:28

он же восьми байтный, большие потоки не организуешь.

Разговор глухого со слепым Или тролли появились, что хуже.

платный протокол - хош пользовать плати

Да будет тебе известно, что покупается просто микросхема драйвер. Библиотеки поставляются с драйвером как и development kit. Никто в своем уме не пишет свою реализацию profibus.
Ознакомьтесь, распишитесь. Хватит уже пургу то нести. https://procentec.com/products/asics/?content-1

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

У меня все проще -
Есть одна башка - мастер - stm32. К ней вся периферия по оптимальным для меня физическим каналам (1 физический уровень и канальный если угодно).
В моей воображаемой системе 3 узла которым надо между собой общаться:
1 - пульт управления (в нем же все мозги stm32 или еще чего, кому как нравится) Та самая центральная штука к которой уже все подсоединяется.
Требования к пульту - иметь входы АЦП, иметь UART, иметь i2s или чего угодно для связи с дисплеем, иметь входа выхода общего назначения - то бишь ножки входов для кнопок - выходы для управления клапаном скажем.
2 - комп - связь через UART (USB-UART переходник)
3 - модуль скажем для беспроводной связи - SIM карта или Wifi или еще хрен знает что. Связь с ней скорее всего i2c - так как на одной плате/корпусе все будет.

Все что тут наметелили не без моей помощи - просто не системные внезапные перепрыгивания по тупо разным уровням абстракции.
Та типа уникальная вилосипеда которая абстрагирует все и вся, называется уровень приложений - т.е. 7 уровень OSI - т.е. как абстрагировано будут общаться между собой приложения (программы) в разных узлах. Для меня это вообще сейчас не составляет проблемы, потому как более нижних уровней еще законченных нет.
Все исполнительные и измерительные узлы будут на центрально башке - самогонный аппарат ни разу не распределенная система ввода вывода, все рядом и компактно.
От чего потом хотелос бы уйти - от 1wire для датчиков - заменить на хардварный вариант - скомпенсированное термосопротивление или если уж совсем замечтаться - токовая петля.
Клапана - твердотельные реле как вариант.
Симистор - управление ТЭН.
Идеальнее опять же аналогвый токовый выход для всего регулирующего, но пока не занимаюсь этим.
Так что можно и дальше троллить друг друга внезапными перепрыгиваниями по всем узлам -выхлоп будет нулевой.

Еще раз
Начинать надо с описания структуры данных
Все остальное - вторично

 гыг.
Хорошо.
Есть датчик температуры - есть автомат который дергает ТЭН по какому то закону. Какую вы структуру данных сюда прилепите.

Вот вам супер универсальная структура данных, пользуйтесь:
Температура
Давление
Положение по шкале 0-100%
Состояние
Расход
Напряжение
Ток
Время
Текстовое сообщение для пользовательской (какой угодно вспомогательной) информации.

copypaste нужное количество раз.

Теперь как я вижу систему. В системе могут быть как датчики так и исполнительные устройства,ну и конечно модуль который будет управлять всем этим. Датчики могут быть как составные так и отдельные но каждый датчик это в первую очередь микроконтроллер который делает опрос своего датчика самостоятельно а уже микроконтроллер включен в шину (пусть 485 для примера) Центральное устройство не парится с опросом датчиков оно просто делает запрос на другое устройство(в данном случае МК с датчиком) и в ответе сразу получает значение температуры в удобном для работы формате, тоже самое и с исполнительными устройствами центральный блок не занимается регулированием напряжения он просто отсылает в блок (микроконтроллер-розетка) данные что на 8 розетке (к примеру) должна быть мощность 30% и все.