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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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



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


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

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


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

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

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

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

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

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




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

Есть конкретный пример "современного PLC" в вашем понимании?
Покажите такой, где применяется SPI через DMA.

Автору нужно видимо передавать сообщения между МК, а не отображать периферию (тем более что и МК на 2-х концах возможно будут разные).
А сообщение - это некая структура. Которая заполняется при отправке программно и парсится после приёма программно. И каким боком тут отображение каких-то областей памяти одного МК на адресное пространство другого? И какая безсофтовость, если и приёмник и передатчик - это программа. Это совершенно неудобно при передаче сообщений от одной программы к другой.


Так это была скрытая реклама Кинетиса?

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

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

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

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

Для большинства МК - не требует, так как таймер входит в состав UART-периферии МК. И имеются и соответствующие статусные биты и прерывания. На приём конечно. На передачу тоже можно обойтись: дождавшись состояния "сдвиговый регистр TX пуст", перевести TX-ногу в режим GPIO в неактивный уровень, выплюнуть некоторое число символов, опять дождаться состояния "сдвиговый регистр TX пуст" и перевести ногу обратно.


Неудобство-то не со среднестатическим, а с максимальным: все буфера под максимум нужно рассчитывать, да и время обработки тоже и таймауты всякие и пр. Если что-то будет не успевать или переполняться только в редких случаях, то то что "среднестатистически всё работает" - будет слабым утешением.


Всё это имеет и COBS, но кроме того - не имеет такого большого оверхеда по объёму при кодировании.
Раньше я тоже обычно использовал SLIP.


Вангую что кроме собственно управления движками у ТСа там ещё много чего надо будет передавать. О чём намекает упоминание кнопок и пр.
И откуда и куда и каким образом это будет делаться - знает только он сам.

Чет тут ванговать.
Циклы движка самые важные и самые быстрые в его системе.
Быстрее циклов быть не может, иначе упрется в риалтаймность движка.
Если SPI буде давать актуальные данные на этих циклах, то во всех остальных потоках и подавно не надо никаких сообщений и их очередей.

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

CAN не редкость, напр. STM32F103 итд. Используется как один из стандартный интерфейсов в упомянутых PLC.
В протоколе должна быть как минимум реализована проверка целостности пакета по CRC (в CAN это уже имеется, как и адресация узлов).
Из "сложностей" CAN - потребуется внешний трансивер 82C250 или другой (много аналогов).
Развязка - по линиям Tx,Rx между трансивером и контроллером.

ps развязка для CAN на оптронах pg 9

Так никто и не говорил, что он - редкость
Просто, встроен он далеко не в каждый МК, в отличие от того же USART, который нынче есть в любом МК.

, однако, по-ходу, не все об этом знают, хотя CAN используют в таких сетях лет этак 15..20


Да и тут сложности особой нет, т. к. трансивер все равно нужен для любого интерфейса, даже того же USART (кроме межплатных соединений).
Для CAN существуют трансиверы со встроенной гальвано-развязкой, например, уже довольно старый и уже упомянутый тут ISO1050.

Если между двумя чипами на плате нужен целый CAN для коммуникации, то такую плату проще выкинуть.

Если между двумя блоками/модулями, раскиданными по шкафу, используется голый SPI, то такое "изделие" "проще выкинуть"

Исключение составляет SPI, обвешанный соотв. трансиверами и защитами, но такой интерфейс придуман очень-очень давно, и называется он SSI.
Встречал его в датчиках положения рабочих органов станка.
Кстати, его можно рассмотреть как вариант для задачи этой темы.

CAN сам по себе хорош для распределенной системы, где много узлов и узлы делают РАЗНЫЕ производители, опираясь на некий единообразный самодельный или готовый протокол (например, тот же CANopen).
Но для тривиальной задачи - один блок + один выносной пуль от ОДНОГО производителя - CAN может оказаться несколько избыточным, и поэтому вполне сгодится обычный UART с трансиверами RS-422/485.

Сколько символов надо выплюнуть, чтобы получить паузу в три с половиной байтовых интервала? Какие статусные биты и прерывания AVR, STM32, LPC2xxx позволяют отличать паузу в два с половиной байтовых интрвала от паузы в три с половиной байтовых интервала?
Я собираю и разбираю на лету, буфера не увеличиваются ни на байт.

Видимо все дело в реализации.

Зачем 3.5? На передачу нужно обеспечить чтобы пауза была >=3.5.


Это пока имеете дело с простейшим случаем байтового потока - железным UART. Когда этот байтовый поток - часть комплексного канала (например тот же TCP-сокет), то без буферов будет сложновато. Хотя это уже за пределами задачи ТСа. Я просто хочу сказать, что если среда передачи байтового потока - железный UART, то modbus так же имеет право на жизнь. И ничем не хуже SLIP, а имеет свои плюсы. Вот например - обошлись Вы без буферов, но забыли что не только объём увеличился, но и время передачи тоже. Соответственно - там где протоколу с modbus или COBS хватит меньшей бодовой скорости, со SLIP придётся скорость увеличить. Т.е. - возможно поставить более дорогие элементы гальванической развязки.
Для других типов байтовых потоков (типа TCP-сокета; или SPP в bluetooth; или CDC в USB; ...), modbus вообще не подходит, но и у SLIP-а появляются серьёзные минусы. Если уж упираться в универсальность, то из всех этих вариантов, COBS - самый универсальный: оверхед маленький и фиксированный, и временнЫх привязок (как modbus) тоже никаких не имеет. Ну конечно кодирование-декодирование чуток сложнее.


Согласен.

https://github.com/speedcontrols/wifi-confi...doc/protocol.md

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

JSON то зачем? Чтоб максимально усложнить себе жизнь?

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

Попахивает arduino.

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

У меня вопрос по CAN. Не уверен, насколько вообще критична автоматическая ретрансмиссия битых фреймов, но в принципе было бы интересно заюзать эту штуку вместо UART. Возможно, не столько по большой нужде сколько из любопытства.

1. Насколько стабильными должны быть частоты самих микроконтроллеров? Можно например их оба запустить на внутренних RC-генераторах?

2. Правильно ли я понимаю, что если точек только две и токовая петля не нужна, то можно заюзать все тот же дешевый ADUM1201 от UART?

Надо ли при этом городить схему с диодами и резистором, или можно просто can_tx/can_rx крест на крест соединить?

Для "любопытства", имхо, лучше купить пару отладочных плат и на них в полной мере утолить свое любопытство


Тут все упирается в стабильность этого самого RC-генератора на всем диапазоне рабочих температур и требуемой скорости CAN-шины.
Подробности как всегда см. в гуглях.


Наверно можно, если удастся правильно понять вашу мысль


Не вижу никакого смысла соединять два MK голым CAN без соотв. трансиверов и защит - это как из пушки по воробьям. Для подобной цели вполне хватит и обычных USART.
Хотя ничто не мешает извратиться и по такой "методе" соединить даже два ETH

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

Здесь не консультационное бюро.
Качество ответов зависит от качества вопроса.
Так что сначала сами потрудитесь.
Ссылка на то что вы нашли вам в минус в профессиональной ветке.
Вашей теме в такой постановке место в ветке про ардуино или о чем-то подобном, о возможности туда ее перенести я и намекнул.

CAN контроллеры не могут соединятся по линиям tx и rx напрямую, нужна как минимум логика И на каждый rx от двух tx.
От RC генераторов CAN контроллеры врядли будут работать, поскольку там каждый бит делится еще на 13 точных квантов минимум, хотя и есть ресинхронизация по 3-м квантам.
Но опять же, это не консультация и все сказанное может быть неточным.

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

Если это не относится к обсуждаемой теме, то почему бы не подумать немного и не сообразить что тогда нет и смысла постить это сюда?

Поясните в чем заключается кошмар? Старый и очень простой и понятный протокол передачи данных.

То же самое, так и не понял кошмарности. Там 1 таймаут и то, +-лапоть.

Все данные (кроме оговоренных в комментариях) в маленьких индейцах. Напишите чтение/запись через modbus. Только честно - чтобы можно было менять как один параметр через Preset Single Register, так и произвольную группу через Preset Multiple Registers. И чтобы в процессе записи группы или через Preset Single Register не допускалась запись половины 32-битного числа. Любопытно глянуть на простоту реализации. А это только малая часть настроек моего устройства.

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



А что сразу функции 4/6/16? MODBUS ими не ограничивается!
Кто мешает использовать 20/21 (Read File Record/Write File Record)?
Или даже (при действительно необходимости) свои функции, стандарт ведь это допускает.

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

Из modbus-а имеет смысл использовать только его механизм деления на кадры. Я говорил уже.

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

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


Все упирается в простоту/цену. Когда все комплектующие стоят 15 баксов, тулить туда развязку за 10 как-то жаба душит.

Одна крайность - фигарить все на рассыпухе из оптронов. Не считая их кривых характеристик, пролетаем в простоте. Другая крайность - многоканальные и специализированные развязки, где вопросы с доступностью и ценник от 5 долларов.

Вариант с ADUM1201 мне кажется довольно удачным балансом - запаять не проблема, размер небольшой, цена приемлима. Правда всего 2 линии передачи.


Давайте от печки начну, возможно так будет понятнее. Нужны малогабаритные и простые регуляторы скорости для "хоббийных" моторов разных типов, все в пределах 1kW. Которые в готовом виде купить нельзя. Все опенсорчное, делается специально чтобы "любой мог повторить". Там где управление чуть более кучерявое чем пара кнопок, по понятным причинам нужна гальваноразвязка.

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

Спрашивайте, если что.

Единственный нюанс - т.к. это все делается именно под повторяемость разными людьми, а не под серию, то допустимы некоторые компромиссы по цене, если это упростит сборку. Но не сильные . Ради простоты разработки компромиссы тоже возможны.

Не путайте пожалуйста то что я описывал с выносным пультом. Там совершенно другая задача. Под нее воткнутo ESP8266 для настройки с мобилки через браузер. Но к внутренней изолирующей шине на плате это отношения не имеет.

В интернетах MAX14933ASE+ будет подешевле чем ADUM1201
Если выбираете I2C, то на другой стороне даже процессор не нужен.

Скажем протестировал я тут намедни I2C контроллер клавиатуры-дисплея AS1115-BSST как раз в управлении частотником.
Скажу эффект порадовал. Дисплей с 40мА сегментами горит на полную мощность.
Скорость до 1 Мбит/с держит стабильно. Опорос сделал с частотой тика операционки.
Никаких протоколов и прочих модбасов. Работает железно.
Ну правда у меня Kinetis, он со спец. защитой от глитчей на I2C, может поэтому так надежно работает.

Дык, с этого и нужно было начинать!
Это все меняет: подобное "изделие" можно собрать как говорится "из говна и палок"
Имхо, идеально подойдут готовые платки из китаев, например эти: тынц, тынц, тынц.

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

Это должен быть какой-то дешевый чип, плюс баланс между стоимостью самого чипа и сложностью софта.


Примеры в студию пожалуйста. Где конкретно есть дешевые MAX14933ASE+ и по какой цене. Работу i2c в условиях силовых наводок обсудим потом, если до этого дойдет.

ADUM1201 есть тут, заказывать можно будет вместе с платой, что особенно ценно для самодельщиков.

Никак не пойму, что не так с банальным оптроном?