Сориентируйте по протоколам/транспортам для связи 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 это еще проще.

[Forger]

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

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

[jcxz]

Но мне удавалось безсофтово делать отражение АЦП, портов, и других вещей одного контроллера в память другого даже на STM32.

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

На Kinetis это еще проще.

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

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

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

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

[scifi]

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

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

У SLIP-подобных протоколов главный недостаток, имхо то, что избыточность зависит от передаваемых данных. И может быть очень большой.

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

[AlexandrY]

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

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

[jcxz]

Как минимум то, что механизм деления на кадры завязан на времянки и требует дополнительного таймера

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

Среднестатистический пакет длиной в пару десятков байтов увеличивается на два-три байта. Меня это не напрягает.

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

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

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

Но в управлении движками (а мы обсуждаем не коней в вакууме, если кто забыл) есть несколько циклов с фиксированным периодом.

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

[AlexandrY]

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

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

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

[k155la3]

. . . Минус CAN один - требуется соотв. МК. Плюс - уже аппаратно решены многие протокольные проблемы ...

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

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

[Forger]

CAN не редкость, напр. STM32F103 итд.

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

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

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

Из "сложностей" CAN - потребуется внешний трансивер 82C250 или другой (много аналогов).

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

[AlexandrY]

В протоколе должна быть как минимум реализована проверка целостности пакета по CRC (в CAN это уже имеется, как и адресация узлов).

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

[Forger]

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

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

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

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

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

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

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

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

Я собираю и разбираю на лету, буфера не увеличиваются ни на байт.

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

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

[jcxz]

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

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

Я собираю и разбираю на лету, буфера не увеличиваются ни на байт.

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

Но для тривиальной задачи - один блок + один выносной пуль от ОДНОГО производителя - CAN может оказаться несколько избыточным, и поэтому вполне сгодится обычный UART с трансиверами RS-422/485.

Согласен.

[p_v]

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

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

[jcxz]

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

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

[p_v]

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

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

[AlexandrY]

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

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

[p_v]

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

[p_v]

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

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

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

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

[Forger]

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

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

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

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

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

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

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

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

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

[AlexandrY]

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

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

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

[p_v]

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

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

[jcxz]

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

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

[sidy]

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

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

[mantech]

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

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

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

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

CODE

struct config
{
    typedef uint8_t version;
    static version const VERSION = 3;
    version Version;

    struct localhost
    {
        uint8_t     MAC_address[6];     // big endian
        uint8_t     Built_in_MAC  :1;
        uint8_t     DHCP_enabled :1;
        ip_addr_t   IP_address;         // big endian
        ip_addr_t   Netmask;            // big endian
        ip_addr_t   Gateway;            // big endian
        ip_addr_t   DNS[2];             // big endian
        char        Hostname[64];
    }   Localhost;

    struct telnet
    {
        in_port_t   Port;
        char        Password[21];   // 20 symbols + trailing '\0'
    }   Telnet;

    struct ademco685
    {
        uint32_t    Baudrate;
        uint8_t     Receiver_ID;            // Receiver ID
        uint8_t     System_enabled;         // bitset
        uint8_t     Keep_alive_timeout;
        uint16_t    Copy_filter_timeout;    // seconds
    }   ADEMCO685;

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

[Alechek]

То же самое, так и не понял кошмарности. Там 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?

[jcxz]

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

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

[p_v]

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

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

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

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

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

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

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

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

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

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

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

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

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

[AlexandrY]

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

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

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

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

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

[Forger]

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

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

[p_v]

Имхо, идеально подойдут готовые платки из китаев, например эти: тынц, тынц, тынц.

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

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

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

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

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

[scifi]

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

[AlexandrY]

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

Чел уже сделал схему и просто ищет ей оправдание, что тут непонятного?

[p_v]

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

Если не вдаваться в характеристики - тупо больше деталей за сравнимые деньги. Не вижу смысла.

[scifi]

Ну не знаю... 2 оптрона - и будет UART. Хозяин - барин, конечно.

[p_v]

Ну не знаю... 2 оптрона - и будет UART. Хозяин - барин, конечно.

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

[scifi]

Ну и считайте. Я же не настаиваю

[p_v]

Ну и считайте. Я же не настаиваю

Есть встречное предложение - не встревайте с бесполезными советами. Когда мне захочется пообщаться за жизнь с интересными людьми, я создам отдельную тему, или найду более подходящую.