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

Даже даташит не прочитали. Разницы между 1wire и i2c с точки зрения физики нет. Драйвер под параметры линии ставишь и работаешь. А вот вешать 1wire (ds18b20) на контроллер без драйвера - это действительно костыли и колхоз. Но почему то работает, хотя не у всех

makh, здорово. Но Ты разбираешься в этом вопросе и если что-то пойдет не так, знаешь куда рыть, а у другого не заработает и потом всем форумом будут лечить по фотографии.

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

Разницы между 1wire и i2c с точки зрения физики нет.woddy, 08 Янв. 17, 01:03

Это как? Что у них общего? Что шину данных к нулю тянут и все?
Квадратная шина синхронная и скоростная (относительно 1-wire), чувствительная к емкости линии, помехам и пр.

А вот вешать 1wire (ds18b20) на контроллер без драйвера - это действительно костыли и колхоз.woddy, 08 Янв. 17, 01:03

Где в доках оговорено обязательное использование драйверов кроме как на линиях под 200-300 метров?  

Это как? У часов (ds1307?) свой адрес, у памяти свой.sevpro, 08 Янв. 17, 01:00

а вот так. Написал производителям ЧВР отмазались типа не поняли вопроса, в инете несколько человек проверили и ошибка подтвердилась.

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

Так что после этого строить какие то системы на I2C не соит.Еще преобразователя USB-I2C я не встречал.

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

СAN шина тож не плохая только у нее все посылки не более 8 байт.

Так что после этого строить какие то системы на I2C не соит.terminal

Могучий, просто фантастический вывод! Инженеры Philips безутешно рыдают в уголке, а историки поднебесной пишут новую чуньцю о том как под чутким руководством КПК уничтожили I2C.
--------------------

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

Суть подхода стара как мир. Это объектно-ориентированный (ОО) подход в проектировании установок. Обычно концепция ОО ассоциируется с разработкой компьютерных программ, но она вполне применима и при конструировании инженерных устройств. Почему? Потому что наиболее адекватно отражает устройство человеческого мозга и человеческого способа познания и описания окружающего мира.

На верхнем (на самом деле - на нижнем, но это уже кто как привык :))) уровне этой иерархии мы будем иметь набор классов на каком-нибудь высокоуровневом ОО-языке программирования, полностью абстрагированных от всего "земного" (контроллеров, протоколов и т.п.) и отражающих автоматизируемую установку на уровне физических (физико-химических) объектов и процессов. В нашем случае, это что-нибудь типа: класс "нагреватель (кипятильник)", класс "колонна", класс "дефлегматор (холодильник)", класс "устройство отбора" и т.п. Управляющая программа будет оперировать только объектами этих классов на уровне абстракции, соответствующем физико-химическим процессам в автоматизируемой установке. Все остальные детали будут инкапсулированы в иерархиях классов этих объектов.

Где-то как-то именно такой подход я и планировал здесь реализовать. К сожалению, я еще не сильно далеко продвинулся в этом направлении, но первые попытки уже вселяют в меня некий оптимизм.

Поскольку управляющим компьютером является малинка под Linux, то в качестве ОО-языка вполне естественно был выбран python. В принципе, можно и C++, но ИМХО, уровень питона более способствует данной задаче (слишком много рутины еще останется в поле зрения программиста, если работать на C++).

--------------------
PS
В приложении - картинка из замечательной книги Гради Руч "Объектно-ориентированный анализ и проектирования". Эта книжка здОрово приводит мозги в порядок, когда начинаешь теряться в сложностях проектируемого объекта и "зашиваться" в мелочах :))))

Инженеры Philips безутешно рыдают в уголке, а историки поднебесной пишут новую чуньцю от том как под чутким руководством КПК уничтожили I2C.OldBean, 08 Янв. 17, 08:24

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

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

Еще можно сделать мост между интерфейсами I2C-485 но формат данных и протокол должен быть близким. Чтоб была легкая конвертация данных.

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

Вот к примеру по формату данных, кто то может высказать свои соображения какие еще нужны датчики и какой формат данных для них нужен.
0х10 - датчик температуры
0х11 - датчик температуры воздуха
0х12 - датчик температуры жидкости
0х20 - датчик влажности
0х30 - датчик уровня жидкости
0х40 - датчик освещенности
0х50 - датчик углекислого газа
0х60 - датчик давления
0х70 - датчик солесодержания или токопроводности
0x80 - PH датчик

0хA0 - исполнительное устройство аналоговая розетка 220 В
0хA1 - исполнительное устройство аналоговая розетка 12 В
0хA2 - исполнительное устройство цифровая розетка 220 В
0хF0 - составное устройство конфигурация устройства по запросу в поле данных

Под тип устройства:
первый байт количество устройств в блоке 0-255 (0-значит одно устройство)



Формат данных: b: 00 w: 00 00 l:00 00 00 00 H: 00 00 00 00 00 00 00 00

температура            w 2 байта последняя тетрада дробная часть
влажность              b 1 байт
уровень жидкости      W 2 байта 0 - значит минимальный FFFF максимальный уровень
Датчик PH              b 1 байт первая тетрада целая часть вторая дробная
датчик солесодержания  w 2 байта 0- значит дисцилят

но у меня на плате сидят часы и еще память да еще на разных портах, еще одну эмуляцию I2C просто не выдержат.terminal

Если речь идет о малинке, то, возможно, поможет ниженаписанное:

У меня тоже была проблема с RealTime. В малинке нет своих часов, поэтому пытался приспособить DS1307. Вроде бы и работали часы, но синхронизация периодически глючила. Тогда я их просто выкинул и реализовал RT следующим образом. В малинке есть синхронизация часов с удаленными серверами точного времени. Но иногда процедура синхронизации занимает много времени (десятки минут) и, естественно, требует наличия Интернета. Я сделал так. В файле /etc/ntp.conf малинки заремовал внешние сервера и прописал синхронизацию часов с часами на одной из рабочих станций в этой же локальной сети, к которой подключена малинка, а на той рабочей станции запустил ntp-сервис. Все проблемы с часам в малинке исчезли.

ну к при меру идет поток данных 0D 20 10 30 00 10 - а нам понятно что 0D данные, от датчика влажности влажность 16 % уровень жидкости 16 ед

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

Если речь идет о малинкеOldBean, 08 Янв. 17, 09:44

В том то и дело что не о малинке, а об Atmege128. У малинки есть USB туда можно воткнуть USB-485. В эту сеть можно воткнуть еще и комп, который будет работать в качестве монитора передачи данных. И писать к примеру температура 87 градусов уровень 20 мм и.т.д.

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

Вот видите у Вас уже I2C занят под реалтайм.

terminal, зря стараешься. Каждому хочется быть изобретателем своего собственного велосипеда, и у всех он уже есть. В чем аргументы перехода на другой протокол?
У меня дока в ворде на 15 страниц, которую я писал почти неделю. Что теперь ее выкидывать? А она уже в коде реализована и отлажена.
Даже модбасом не соблазнился, хотя очень хотелось.

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

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

зря стараешься. Каждому хочется быть изобретателем своего собственного велосипеда, и у всех он уже есть. В чем аргументы перехода на другой протокол?
У меня дока в ворде на 15 страниц, которую я писал почти неделю. Что теперь ее выкидывать? А она уже в коде реализована и отлажена.capsolo, 08 Янв. 17, 10:13

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

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

Кто то делает на малинке, кто то на компе, кто то на STM, кто то на ПИК, кто то на AVR. Понимаете к чему я?

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

Если "Пупкин" написал обработку датчика на ПИКе, зачем мне изучать ПИК? А есть соглашение, я возьму его датчик и вставлю в систему.

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

Если кто то пишет на малинке то зачем ему резать синус и программировать Мк когда он Взял мой блок и у его уже розетка с регулируемой мощностью.

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

updated: хотя понял чем - не всякое устройство чудесный слейв для этого самого модбаса.

Вот видите у Вас уже I2C занят под реалтайм. terminal

Во-первых, на одну шину I2C можно посадить до 127 устройств, а во-вторых, синхронизация RT малинки у меня идет не по I2C, а по локальной сети с Wi-Fi. Кстати, никто не отменял и обычный шланик Ethernet, если Wi-Fi-я нет и/или другие протоколы не нравятся.

Кто то делает на малинке, кто то на компе, кто то на STM, кто то на ПИК, кто то на AVR. Понимаете к чему я? terminal

Поэтому-то и "унифицироваться" нужно (если нужно) на более высоком уровне абстракции, чем протоколы, контроллеры или управляющие компьютеры (в том числе, и модбас).

https://www.indiegogo.com/...-pi-extension#/

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

И еще один немаловажный момент - если бы обалденно универсальная шина для всего и вся существовала бы - то наверное ее бы везде и использовали, как самую дешевую и практичную.
А пока наша промышленность дошла только до того чтобы разделить физический уровень от канального и прочих (читай витая пара или еще чего https://en.wikipedia.org/wiki/Physical_layer)

Как предложение - начать отсюда - какое железо предпочтительнее. Я например вообще за profibus pa  чтобы все и запитывать от шины, но это высшие материи будут а не практичное решение

В автомобильной промышленности - CAN.

никто не отменял и обычный шланик EthernetOldBean, 08 Янв. 17, 10:35

дак 485 и есть сеть только линия одна(из двух проводов) и по цене копейки.

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

profibus paPavelSaratov, 08 Янв. 17, 10:42

Есть информация по протоколу ? Почитать ?

А просто погуглить слобО? Есть много готовых решений для термопар. Например, MAX31855.

да слобО. Похоже не удачно сформулировал мысль. Мысль была о том , что что то дешевое и практичное присобачить по 4-ех проводке к контроллеру. Можно и с этой MAX31855 а можно и без нее. Основной вопрос - в покупке чего то
1 дешевого
2 практичного
3 уже отградуированного
4 желательно иметь возможность калибровки - но это уже хотелка просто.

Упрощу уж до предела - где взять TCM100 или ТСМ 50 подходящих размеров и в подходящем для нас корпусе дешевый уже готовый к 4-ех проводной, а можно и к трехпроводной схеме соединения.
Вот пример подобного вида устройств http://sibspz.ru/...mednye-tsm-0503

в том числе, и модбасOldBean, 08 Янв. 17, 10:35

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

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

1 дешевого
2 практичного
3 уже отградуированного
4 желательно иметь возможность калибровки - но это уже хотелка просто.

Вот именно. Я и предлагаю Датчик-контроллер-485 , Исполнительное устройство-контроллер-485,комп-485, малинка- 485

Если охота голову себе сломать - вот пример промышленной башкиPavelSaratov, 08 Янв. 17, 11:17

Дак примеров то много а описания протокола не кто дать не может ибо он за деньги продается. Он кстати на 485 основан.

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

ватчдог рубит все ФИЗИЧЕСКИPavelSaratov, 08 Янв. 17, 11:28

Вот по этому я и не хочу садится на модбас.

Где блин пример ?PavelSaratov, 08 Янв. 17, 11:17

строб два байта
0xA5 -  маркер начала старт байт
0x00 - длинна пакета 10-255   (245 для данных) уже знаем сколько байт осталось до CRC
ID - 0x00 кому
ID -0x00 кто  
ID - 0x00 - номер пакета в пачке пакетов(счетчик транзакций )
0x00 - тип данных,команда,
0x00,0x00 - расширение данных, подтип данных,регистр
данные 0-245
контрольная сумма СRС-16
скорость 250К интерфейс 485

 Чето я не догнал зачем вы описали модбас.. Скажем так его творческую интерпретацию.

Чето я не догнал зачем вы описали модбас..PavelSaratov, 08 Янв. 17, 11:49

Это не модбас, у модбаса сразу идет адрес, без строба, нет от кого, нет контроля пакета.

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

Это что то близкое к DMX и RDM

 Елы палы.. А коллизии как вы решать будете? Хотите одноранговую сеть ? Ну так используйте CAN.http://www.bookasutp.ru/Chapter2_6.aspx На кой хрен изобретать велосипед? Все уже придумано для промышленности. Я правда не понимаю. Контроль пакета зачем? Вы драйвер хотите с нуля написать? Не проще ли забить и использовать уж тогда старндартне 4-20 мА для связи между всем и вся? Я вообще не пойму чето ничего.

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

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