Сориентируйте по протоколам/транспортам для связи 2 микроконтроллеров Опции

[p_v]

https://easyeda.com/speed/DC_Motor_speed_co...8f540acd1a2f4bb
https://easyeda.com/speed/Universal_speed_c...8f540acd1a2f4bb

Нужно сделать гальваническую развязку между высоковольтной частью регулятора скорости и внешними интерфейсами (индикатор, кнопки и т.п.). Как ни странно, но по деталькам проще всего оказывается поставить 2 микроконтроллера и свинтить их через что-то вроде adum1201.

Понятно, что не особо сложно взять UART и схолхозить протокол типа modbus (запись/чтение по заданному виртуальному адресу). Но может на эту тему есть что-то стандартное, чтобы не изобретать лисапед?

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

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

Сообщение отредактировал p_v - Sep 22 2018, 18:54

[Forger]

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

CAN с соотв. защитами.
Гальванич. изоляция, если необходима.

зы Не пойму, к чему тут тема ARM?

[AlexandrY]

Можно более сложные варианты, если есть готовые библиотеки, но не обязательно. Ну и конечно нужна какая-то минимальная защита от сбоев, чтобы обмен не затыкался.

SPI с DMA с отражением на память. И никаких протоколов не надо.
Должен ходить фиксированный блок данных с фиксированной частотой.
На таком принципе все PLC работают.

[Forger]

На таком принципе все PLC работают.

Вот только не нужно вводить народ в заблуждение!

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

[kovigor]

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

Токовая петля (current loop) с парой оптронов обеспечит и оптоизоляцию, и передачу данных, причем на значительное расстояние, до километра вполне может дотянуть. Больше не пробовал. Вот, например, см. стр. 4:

http://www.kron.com.ua/archive/conv/docs/T...0%20GS%20V1.pdf

[Сергей Борщ]

Понятно, что не особо сложно взять UART и схолхозить протокол типа modbus (запись/чтение по заданному виртуальному адресу). Но может на эту тему есть что-то стандартное, чтобы не изобретать лисапед?

Я изобретаю под каждую задачу. Все мои протоколы поверх поверх УАПП (UART) чем-то похожи на WAKE, но выросли из нижнего уровня IrDA. modbus - кошмар для программиста.

[jcxz]

Все мои протоколы поверх поверх УАПП (UART) чем-то похожи на WAKE, но выросли из нижнего уровня IrDA. modbus - кошмар для программиста.

У SLIP-подобных протоколов главный недостаток, имхо то, что избыточность зависит от передаваемых данных. И может быть очень большой.
Я в последнее время в подобных случаях использую COBS. Он имеет фиксированную избыточность, не зависящую от данных. И очень маленькую избыточность.

[AlexandrY]

Вот только не нужно вводить народ в заблуждение!

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

Я думаю моя мысль понятливым понятна.
Софтварные протоколы нарушают жесткий риалтайм, который обычно нужен при управлении опасной механикой.
SPI по DMA один из вариантов не городить софтовую обвязку.
В PLC для соединений в пределах стойки используют именно такой безсофтовый подход с отражением на память.
Если знаете что-то об этом больше, то назовите хоть одно, а не с умным видом "перечислять их можно долго"

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

[scifi]

Я изобретаю под каждую задачу.

+1.
Причём у меня предпочтительный вариант - это читаемый человеком формат типа "set 1 123\n". sprintf и sscanf не напрягают, да и без них это можно сделать. Тут начали всякую экзотику предлагать, а тем временем ТС так и не озувучил требования, из-за которых наличие экзотики необходимо.

[Forger]

Если знаете что-то об этом больше, то назовите хоть одно, а не с умным видом "перечислять их можно долго"

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

"в китайских многометровых светодиодных панелях".

Вот именно там самое место подобному применению SPI!

SPI по DMA один из вариантов не городить софтовую обвязку.

Тогда давайте уж дальше будем продолжать необоснованные фобии, советуя автору вообще ВСЕ делать на ПЛИС или "гулять так гулять" - на "рассыпухе"!

эти детские заблуждения

Да кто-бы говорил

[jcxz]

В PLC для соединений в пределах стойки используют именно такой безсофтовый подход с отражением на память.

Что значит "безсофтово" применительно к SPI? И причём тут какой-то "жёсткий реалтайм"? И в чём бОльшая жёсткость реалтайма SPI по сравнению с другими интерфейсами?
При использовании SPI не нужен механизм парсинга на кадры, так как это - кадр-ориентированный интерфейс. Кроме SPI есть множество других кадр-ориентированных интерфейсов.
Да и SPI - это не протокол, а интерфейс, всё таки.
И для задачи ТС-а минус SPI в том, что потребуется в два раза больше гальваноразвязок чем для SPI. И скорость прикладного протокола, работающего поверх SPI, может получиться невысокой.

ETHERCAT - используется в современном промышленном оборудовании.
CAN - используется во всех современных авто, в разным машинах обвешивается разными протокольными надстройками. Также используется в промышленном оборудовании.

ТСу нужна гальваноразвязка. И двунаправленная передача. Для данных интерфейсов есть чипы, обеспечивающие её? И на какой скорости?
И зачем ETHERCAT с огромной скоростью для "индикатор, кнопки и т.п."? Зачем использовать необоснованно тяжёлые чипы (содержащие ETHERCAT), для опроса кнопок??

[mantech]

ETHERCAT - используется в современном промышленном оборудовании.
CAN - используется во всех современных авто, в разным машинах обвешивается разными протокольными надстройками. Также используется в промышленном оборудовании.

Если уж разговор про связь ПЛК то модбас еще никуда не списали, а реализация вышеуказанных интерфейсов гораздо сложнее и дороже.

[jcxz]

modbus - кошмар для программиста.

Если рассматривать только его механизм деления на кадры (а только он нужен для данной задачи), то что там такого страшного?

[Forger]

ТСу нужна гальваноразвязка. И двунаправленная передача. Для данных интерфейсов есть чипы, обеспечивающие её? И на какой скорости?

Да, все это есть. Дорого, надежно. Скорости - как у ethernet, он тут является "физикой".
Но, разумеется, для данной темы ETHERCAT вообще ни к месту, это я уточнил в посте, где упомянул про него.
Тут он - как на самолете в булочную, что через дорогу

Для CAN cуществуют готовые драйвера с гальваноразвязкой. Например, ISO1050. Пользовал однажды такой, но его одного мало, все равно нужны доп. защиты.
Если речь идет про некий выносной пульт с кнопками и лампочками, то питание и данные можно развязать еще в силовой коробке. Питание тянуть к пульту в том же кабеле, что и данные.
Получится всего 4 провода. Если нужна аварийная кнопка, то ее лучше тянуть отдельными проводами.

[AlexandrY]

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

Все таки не поняли о чем я написал. Значит с современными PLC не имели дело, и мне нет смысла с вами спорить
Просто к сведению, там есть стойки или модули со своими соединениями, а есть межстоечные соединения.

Что значит "безсофтово" применительно к SPI? И причём тут какой-то "жёсткий реалтайм"? И в чём бОльшая жёсткость реалтайма SPI по сравнению с другими интерфейсами?

Эт трудно объяснить поскольку все тесно завязано на периферию конкретного семейства ARM-ов.
Там надо привлекать не только SPI, но и связанные DMA каналы, таймеры, мультиплексоры ивентов, аппаратный блок CRC и кое-что другое.
Но мне удавалось безсофтово делать отражение АЦП, портов, и других вещей одного контроллера в память другого даже на STM32.
На Kinetis это еще проще.