[Forger 17]

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

Есть конкретный пример "современного PLC" в вашем понимании?

Покажите такой, где применяется SPI через DMA.

[jcxz 184]

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

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

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

 

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

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

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

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

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

[scifi 1]

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

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

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

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

 

[AlexandrY 3]

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

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

Тут надо задать вопрос, что такое сообщения.

Сообщение - это надо так думать в контексте обсуждения будет асинхронное событие.

Но вот как раз обработка асинхронных событий и есть лишнее неудобство.

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

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

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

Что собственно принцип работы PLC и доказывает.

 

 

 

[jcxz 184]

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

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

 

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

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

 

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

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

Раньше я тоже обычно использовал SLIP. ;)

 

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

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

И откуда и куда и каким образом это будет делаться - знает только он сам.

[AlexandrY 3]

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

И откуда и куда и каким образом это будет делаться - знает только он сам.

Чет тут ванговать.

Циклы движка самые важные и самые быстрые в его системе.

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

Если SPI буде давать актуальные данные на этих циклах, то во всех остальных потоках и подавно не надо никаких сообщений и их очередей.

 

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

 

 

[k155la3 26]

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

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

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

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

Развязка - по линиям Tx,Rx между трансивером и контроллером.

 

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

[Forger 17]

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

Так никто и не говорил, что он - редкость :laughing:

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

 

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

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

 

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

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

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

[AlexandrY 3]

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

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

 

[Forger 17]

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

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

 

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

Встречал его в датчиках положения рабочих органов станка.

Кстати, его можно рассмотреть как вариант для задачи этой темы.

 

CAN сам по себе хорош для распределенной системы, где много узлов и узлы делают РАЗНЫЕ производители, опираясь на некий единообразный самодельный или готовый протокол (например, тот же CANopen).

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

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

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

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

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

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

 

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

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

[jcxz 184]

Сколько символов надо выплюнуть, чтобы получить паузу в три с половиной байтовых интервала? Какие статусные биты и прерывания 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 0]

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

 

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