Форум по микроконтроллерам: Использование режима MPCM. - Форум по микроконтроллерам

Перейти к содержимому

Страница 1 из 1
  • Вы не можете создать новую тему
  • Вы не можете ответить в тему

Использование режима MPCM.

#1 Гость_dimmer_*

  • Группа: Гости

Отправлено 02 Октябрь 2016 - 01:42

Как известно у модуля USART микроконтроллеров AVR аппаратно реализован режим мультипроцессорного обмена. Данный режим позволяет осуществлять эффективный обмен данными по интерфейсам, допускающим подключение более чем двух устройств к одной линии (RS-422,RS-485). Когда я захотел для своего "парка" девайсов иметь возможность замены прошивки и мониторинга работы по линии RS-485, то не нашел в интернете ни одной реализации обмена данными по протоколам с использованием MPCM. Для себя я написал загрузчик для линейки ATmega и программу для ПК, но мне осталось непонятно - почему эта тема нигде не поднимается. Мне интересно было-бы узнать ваше мнение. Может просто это никому не интересно, или это "вчерашний день", или может все что-то знают, только я не в курсе?

#2 Гость_boatcall_*

  • Группа: Гости

Отправлено 03 Октябрь 2016 - 09:00

Не знаю, что такое MPCM, но что касается мультипроцессорного обмена, то он широко и повсеместно применяется. I2C, SPI, Modbus, 1wire, разные проприетарные протоколы. Всё вышеперечисленное - протоколы с SingleMaster т.е. с одним мастером, который и руководит всей активностью на шине. Протоколы с MultyMaster тоже имеются: CAN, Ethernet, и др. тут каждый узел может стать мастером. Вся сложность в реализации с несколькими мастерами - разрешение коллизий, когда два мастера одновременно намереваются захватить шину. Этот конфликт мастеров нужно как-то "разрулить". Для этого применяются программно-аппаратные методы, но все они достаточно дорогие. Поэтому протоколы с одним мастером применяются там, где скорость обмена, обмен пересылаемых данных не являются критичными и где важнее стоимость конечного устройства. Там, где требуется высокая надежность, скорость и объёмы данных высоки, там стоимость решения является вторичной и предпочтение отдается MultyMaster протоколам. Поэтому в производстве, автомобильной промышленности, авионики применяются именно CAN, Industrial ethernet, Profibus и иные системы с несколькими мастерами. В современных авто, может быть две-три CAN-шины, одна быстрая, для работы с двигателем, трансмиссией и тормозами, вторая медленная для управления системами развлечения, кондиционера и.т.д, её и называют Comfort-CAN. Для управления дверями-зеркалами-сидениями ещё есть совсем дешёвый протокол LIN, но он тоже уже SingleMaster. Так-что ничего особо революционного в "полевых" шинах пока не придумано. Всё перечисленные протоколы достаточно старые. Мелькало сообщение, что новый виток со скоростями в Ethernet происходит, но это всё-же уже из профессиональной электроники, так-же, как и разные SATA, PCIExpress и.т.д. Единственное, где что-то происходит, так это в беспроводных технологиях, разные MESH-сети, там ещё долго, наверное, всё не устаканится. Мне вот так всё в целом видится.

Сообщение отредактировал boatcall: 03 Октябрь 2016 - 09:06


#3 Гость_dimmer_*

  • Группа: Гости

Отправлено 05 Октябрь 2016 - 21:03

Почувствовал себя непонятым. Попробую ещё раз. MPCM - Multi Processor Communication Mode (Режим мультипроцессорного обмена данными) реализован в микроконтроллерах AVR аппаратно. АППАРАТНО - это значит, что нет необходимости ПРОГРАММНО отслеживать данные, поступающие по линии связи. Работая в режиме MPCM контроллер аппаратно игнорирует все байты у которых отсутствует признак того, что этот байт является адресом устройства. Если в линию связи поступает специальный (адресный) байт, то его обрабатывают ВСЕ контроллеры, подключенные к линии. Что значит обрабатывают? Определяют - идёт обращение к ним или нет. Если полученный адрес совпадает с присвоенным устройству адресом, то ОДИН контроллер из ВСЕХ переходит к приёму остальных байт посылки. Остальные контроллеры аппаратно игнорируют следующие байты. Это позволяет использовать для передачи бинарный формат, т.е. передавать байт не в виде его ASCI образа. И можно не опасаться, что в массиве передаваемых данных "нечаянно" встретится последовательность, совпадающая с определением адреса устройства. Но самое главное, что это вдвое увеличивает эффективность канала связи. Почему я вообще решил поднять эту тему? Мне просто интересно - кто-нибудь занимается подобными вопросами?

Сообщение отредактировал dimmer: 05 Октябрь 2016 - 23:57


#4 Пользователь офлайн   Alex 

  • Убиватель МК
  • PipPipPipPip
  • Группа: Пользователи
  • Сообщений: 1 903
  • Регистрация: 15 Февраль 11

Отправлено 06 Октябрь 2016 - 09:24

Цитата

Остальные контроллеры аппаратно игнорируют следующие байты.
Очень интересно, что означает фраза "следующие байты". Следующие до какого момента ?
Как модуль в контроллере будет определять АППАРАТНО, следующие это байты после адреса, или адрес, после которого пойдут новые следующие байты ?
Определение конца посылки, влюбом случае, не избежать. А это, как минимум, ещё один модуль - таймер, для таймаута.
Не говорите что мне делать, и я не скажу куда Вам идти !
0

#5 Пользователь офлайн   nick14 

  • Группа: Администраторы
  • Сообщений: 1 481
  • Регистрация: 15 Февраль 11
  • ГородРыбинск

Отправлено 06 Октябрь 2016 - 10:16

Просмотр сообщенияdimmer (05 Октябрь 2016 - 21:03) писал:

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


Я не вникал в AVRы, но разницы особой нет. Вопрос то в чем?
0

#6 Гость_dimmer_*

  • Группа: Гости

Отправлено 06 Октябрь 2016 - 22:39

Для Alex: признаком передачи адреса устройства является установленный 9-тый бит кадра. Все байты со сброшенным 9-тым битом модуль USART, в режиме MPCM, считает байтами данных. При этом не возникает прерывание URXC - завершен прием байта. Что касается размера посылки, её можно определять по приходу следующего адресного байта, но наверное правильнее в протоколе предусмотреть поле "длина посылки" или как делал я - все посылки фиксированной длины.

Сообщение отредактировал dimmer: 06 Октябрь 2016 - 22:46


#7 Гость_dimmer_*

  • Группа: Гости

Отправлено 06 Октябрь 2016 - 22:44

Для nick14: просто я написал для себя бутлоадер, выложил его для общего пользования (avr-assm.ru) и мне хотелось узнать мнение коллег радиолюбителей. Может что-то исправить нужно.

#8 Пользователь офлайн   Alex 

  • Убиватель МК
  • PipPipPipPip
  • Группа: Пользователи
  • Сообщений: 1 903
  • Регистрация: 15 Февраль 11

Отправлено 06 Октябрь 2016 - 23:01

Цитата

Что касается размера посылки, её можно определять по приходу следующего адресного байта
, который проигнорируется аппаратно в модуле :)

Цитата

При этом не возникает прерывание URXC - завершен прием байта.
Всё равно, событие должно быть какое-то. Хотя бы, как минимум, для инициализации счётчика принятых байтов.

Цитата

мне хотелось узнать мнение коллег радиолюбителей. Может что-то исправить нужно.
Думаю, мнение будет только от тех, кто будет использовать Вашу разработку.
Не говорите что мне делать, и я не скажу куда Вам идти !
0

#9 Гость_dimmer_*

  • Группа: Гости

Отправлено 06 Октябрь 2016 - 23:12

Да, Alex, мне интересно мнение тех, кто интересуется данной проблемой. Я не собираюсь здесь заниматься ликбезом.

#10 Пользователь офлайн   Alex 

  • Убиватель МК
  • PipPipPipPip
  • Группа: Пользователи
  • Сообщений: 1 903
  • Регистрация: 15 Февраль 11

Отправлено 06 Октябрь 2016 - 23:30

Занятие ликбезом не всегда идёт в пользу того, кому его проводят. Так что, Вы напрасно так реагируете на наш диалог. У нас идёт обычный технический разговор, в котором даже у Вас могут возникнуть какие-либо идеи по улучшению ПО или исправлению каких-либо недочётов.
Тем более, Вы сами завели тему по этому модулю. Почему бы его не обсудить ?
Ну а если Вы завели тему ради своего продукта, то так бы и написали, не упоминая никаких протоколов. Ведь пользователем, в основном, нужен "Plug & Play", без разборов того, как оно устроено. Мало кто будет сидеть и разбираться во всех этих протоколах, лишь для того, чтобы узнать как оно работает. Работает - да и ладно :)
Не говорите что мне делать, и я не скажу куда Вам идти !
0

#11 Гость_boatcall_*

  • Группа: Гости

Отправлено 07 Октябрь 2016 - 07:17

Просмотр сообщенияdimmer (05 Октябрь 2016 - 21:03) писал:

...Мне просто интересно - кто-нибудь занимается подобными вопросами?

А вот оно что, недопонял сначала сути сообщения. Про режим MPCM на основе 9-битной посылки, услышал только от Вас, поискал и увидел, что это чисто ATMega-вская "фича", ещё каких-то МК от бывшей Atmel и особого толка в ней не заметил, равно, как и в особой необходимости перепрошивки МК по RS485 в силу ресурсоёмкости этого процесса. Так-что Ваш "ликбез" лично мне и без надобности, вернее то, что Вы им называете. Недавно возникали у меня вопросы межпроцессорной коммуникации, я это решал посредством Modbus. Протокол открытый, нетребовательный к ресурсам, со своими ограничениями, но куда-ж без них, в сеть подключается любое устройство с USART и фактически стандартными настройками 8-N-1, любое, обратите внимание, от PC до 8-и ногих PIC, а не обязательно построенное на ATmega. Написали/выложили - молодец, а раз мало интересуются, значит это мало кому нужно в том виде, который Вы описали. 9-битная передача, использование какой-то редкой периферии, экзотика сплошная, давайте ещё 2 стоп бита приделаем. Вы пишете: "вдвое увеличивает эффективность канала связи", эта цифра откуда? Что значит "эффективность"? Эфффективность в чём? В скорости? А как насчёт достоверности данных? Есть какие-то исследования, эксперименты при таком подходе? Так-что IMHO, всё это - очередное проприетарное велосипедостроение. Чем я сам пользуюсь, написал в своем предыдущем посте, а закладывать в конструкцию, даже любительскую, жесткую аппаратную привязку, опять-же IMHO, путь тупиковый.

Сообщение отредактировал boatcall: 07 Октябрь 2016 - 07:41


Поделиться темой:


Страница 1 из 1
  • Вы не можете создать новую тему
  • Вы не можете ответить в тему

1 человек читают эту тему
0 пользователей, 1 гостей, 0 скрытых пользователей