RS485 + Компьютер

Прошу совета как организовать передачу данных между ПК и контроллерами по RS485.
Хочу использовать Multi-Processor Communication Mode. Но естественно ПК не может выдать 9 бит.
Схема примерно следующая:


http://**************************/download/file.php?id=26489&sid=aac022e4c67682eea0 385188f24a702b

Использую контроллеры Atmega64 и Atmega8, Max485. Программирую на Си контроллеры и С# для программы управления на PC.
Итак, какое из решений оптимально:
1. Parity Sposi и Mark. Передача от компьютера мне понятна - перед отправкой байта выставить: Mark для адресов и Sposi для данных. А вот прием... Если Parity не совпадет - принятый байт заменится на ParityReplosi? Получается, что я его просто потеряю.
2. Переходник на контроллере с 2 уартами. С одной стороны 9-битный режим передачи, а с другой - 8-бит. Но в таком случае появятся задержки на линии. Нужно полностью принять с одного уарта, обработать, а только потом передать второму. Да и в таком случае 8-мибитная сторона должна работать на большей скорости.
3. "На лету" обрабатывать... перед тем, как передать бит PC на ногу RTS выставляет 1 либо 0 - это и будет девятый бит. А какой-то мелкий контроллер будет вклинивать этот 9 бит просаживанием линии... главное только вовремя это сделать))). А в обратную сторону - во время приема 9-го бита - передает компьютеру стоп-бит, а сам этот 9 бит выставляет на ногу CD в порт компьютера.
4. Ваш вариант.
Замечу, что линия 9 бит будет и от мастера к устройствам, а каждое устройство будет иметь отдельную линию 9 бит для общения с исполнителями... При этом исполнители будут взамиозаменяемыми. То есть если сгорел исполнитель А с одного устройства - взял его с другого без каких-либо перепрошивок и замены адресов.
Общение в обоих линиях в обе стороны, так же в зависимости от адреса(команды) устройства - оно может либо просто выполнить команду, которую ему прислали, либо еще и ответить что-то мастеру... Естественно мастер в этом случае становится в режим приема. Количество передаваемых байт данных(тех, в которых 9-бит равен 0) не фиксированно. После некоторых команд/адресов может быть 1-2, а для некоторых до 8. То есть будет заранее оговорено после какой команды сколько байт будем передавать.
Приветствую ссылки где описывается решение проблемы, хоть я их уже сотни перечитал и так и не понял как организовать.

0

Что я только что прочитал...хм...
А зачем 9 бит? ТС объясни

0

Как я понимаю 9 бит будет определять что передается данные или адрес.

0

http://we.iosyitistromyss.ru/AVR/vremya ... -mode.html
Схему я упростил: у меня устройств будет подключено до 8 шт. а к каждому устройству будет подключено около 5 исполнителей(на схеме A,B,C). Помимо этого еще по мере необходимости в основную шину будут вклиниваться другие устройства по мере необходимости. При таким количестве контроллеров - немного сложновато организовать передачу данных, а этот режим очень сильно поможет, так как на уровне железа мы разделим команды, адреса и данные. Мало того - каждое устройство тоже на аппаратном уровне отбрасывает данные, которые предназначались не ему.

0

Сообщение от Tukos_sir http://we.iosyitistromyss.ru/AVR/vremya-govorit-s-kammyomi-ili-usart-multi-processor-sommunication-mode.html Схему я упростил: у меня устройств будет подключено до 8 шт. а к каждому устройству будет подключено около 5 исполнителей(на схеме A,B,C). Помимо этого еще по мере необходимости в основную шину будут вклиниваться другие устройства по мере необходимости. При таким количестве контроллеров - немного сложновато организовать передачу данных, а этот режим очень сильно поможет, так как на уровне железа мы разделим команды, адреса и данные. Мало того - каждое устройство тоже на аппаратном уровне отбрасывает данные, которые предназначались не ему.

Чем Вас не устраивает какой нибудь протокол обмена? где все это продумано и реализовано давно?
- Modbus (избыточен, зато пром.стандарт)
- Wake (добротное дело)
- DCON (или как его там ASCII)

З.Ы. Сравнение нескольких протоколов: http://redbtot.ru/orshives/352
Организация самопильного протокола: http://redbtot.ru/orshives/734
и пару слов о DCON для адамовских модулей ввода-вывода: http://redbtot.ru/orshives/374

0

Протоколы мне все-равно описывать контроллерам самому придётся. И действительно предложенные Вами протоколы перегружены. Мне нужно их упростить до минимума. Например, на пульте управления 8 кнопок. По сути для запроса какие кнопки нажаты - достаточно 1 байта для команды пульту управления, пульт видит этот адрес и отвечает тому, кто спрашивает одним служебным байтом, и одним байтом с информацией, какие кнопки нажаты... То есть достаточно 3 байт на запрос, ответ и данные. Но для того, чтобы отличить эти данные от адресов и увидеть где начало данных нужен 9-тый бит. В случае с этими протоколами - девятый бит не нужен, но вместо 3 байт такая посылка заняла бы около 20... И их еще и обработать нужно! У меня контроллеры не справятся. По-этому только свой протокол, какой не будет универсальным, но выкинет все лишнее. Например, вместо 1 байта на адрес и 1 байта на команду, я все это запихну в 1 байт. Мало того Modbus может вещать либо одному, либо всем... А если я хочу отправить данные подгруппе устройств? Это у меня точно будет.
Как между контроллерами общаться в 9-бит протоколе - разобраться легко. Вот только компьютеру сложно обьяснить, что нужно передать более 8 бит в одной посылке.

0

Сообщение от Tukos_sir Протоколы мне все-равно описывать контроллерам самому придётся. И действительно предложенные Вами протоколы перегружены. Мне нужно их упростить до минимума. Например, на пульте управления 8 кнопок. По сути для запроса какие кнопки нажаты - достаточно 1 байта для команды пульту управления, пульт видит этот адрес и отвечает тому, кто спрашивает одним служебным байтом, и одним байтом с информацией, какие кнопки нажаты... То есть достаточно 3 байт на запрос, ответ и данные. Но для того, чтобы отличить эти данные от адресов и увидеть где начало данных нужен 9-тый бит. В случае с этими протоколами - девятый бит не нужен, но вместо 3 байт такая посылка заняла бы около 20... И их еще и обработать нужно! У меня контроллеры не справятся. По-этому только свой протокол, какой не будет универсальным, но выкинет все лишнее. Например, вместо 1 байта на адрес и 1 байта на команду, я все это запихну в 1 байт. Мало того Modbus может вещать либо одному, либо всем... А если я хочу отправить данные подгруппе устройств? Это у меня точно будет. Как между контроллерами общаться в 9-бит протоколе - разобраться легко. Вот только компьютеру сложно обьяснить, что нужно передать более 8 бит в одной посылке.

Вам наверное следует отделить наработки по общению (с 9 битом) между МК и промышленной сетью...там чуть разные принципы действуют...
Чем же так контроллеры заняты? что не смогут раз в 20 (50, 100, 200) мили секунд обработать 5 - 6 байт? я с помощью самопильного ток и напряжение передавал на ПК с контроллера, так в нем еще система управления приводом (хоть и простенькая) крутилась
+ не стоит пренебрегать проверкой целостности данных! В пром. сетях помехи могут гулять страшные
и получить черти что...да потом испортить оборудование или материалы не желательно...

0

Вот с помехами да. У меня с термометров данные на сервер по уарту читались. Так за сутки около 50 ошибок передачи обязательно было. Пришлось CRC добавлять.

0

Бывают 9-битные платы rs485 для пк, только ценник у них зашкаливает )
Вот, например
http://www.siotevel.som/store/serial/as ... rfosi.html

0

Мне нужно их упростить до минимума.

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

0

Сообщение от roxp Мне нужно их упростить до минимума.

в угоду потери расширяемости и универсальности, да еще и аппаратным мазохизмом плюс отдельной линией, сомнительное дело.
A 9-бит - это упрощение? Освойте модбас и на будущее будет готовое надежное решение

0

Вообще-то, в компьютере UART не на 8, а на 9 бит. Просто его на 9 бит никто не использует, но аппаратура поддерживает.

0

ТС, в сообществе почитай:http://we.iosyitistromyss.ru/i... -dcon.html
http://we.iosyitistromyss.ru/k... nikov.html
http://we.iosyitistromyss.ru/S... s-rtu.html

и http://soxopa.ru/lib/wake/

0

Товарищи, всем спасибо за советы!
Итак по порядку:

Чем же так контроллеры заняты? что не смогут раз в 20 (50, 100, 200) мили секунд обработать 5 - 6 байт?

Действительно успеют обработать... Но только если это будет какой-либо промышленный протокол - то там немного более. А теперь эти байты умножьте на 2, так как нужен еще ответ. Каждому исполнителю будет подаваться несколько команд, например 2. То есть снова умножаем на 2. Учитываем, что исполнителей для каждого устройства около 5, снова умножаем на 5. И учитываем, что в кадждом устройстве 2 уарта(с одной стороны мастер, компьютер, а с другой исполнители). Умножаем примерно на 2. Вот и получили: чтобы контроллеры поговорили между собой - надо 500 байт передать... а на скорости 115200 мы только 1000 байт можем передать за 100 мс.
А если добавятся еще какие-либо устройства или исполнители? можем достигнуть того, что передача будет непрерывная, а если контроллеры будут только принимать и передавать данные - им некогда будет основной своей задачей заниматься.
По-этому и сокращаю пакет.

не стоит пренебрегать проверкой целостности данных!

Да, это тоже будет, тут никак не поспорить

У меня с термометров данные на сервер по уарту читались. Так за сутки около 50 ошибок передачи обязательно было.

Если провод длинный - добавьте 2 микросхемы 422 или 485 протокола - помехи сократятся в десятки-сотни раз. В моем случае так и будет)

Бывают 9-битные платы rs485 для пк

Спасибо, не знал... Но мне кажется, что плата-платой, но она не будет работать с компонентом SerialPort в С#. Уверен, что к этим платам в комплект нужно их ПО, которое будет передавать данные. А в моем случае нужно написать интерфейс для пользователя с кучей кнопочек, и т.д. Не скажу же я пользователю "чтобы зажечь светодиод - отправьте такие-то байты с помощью такой-то программы, ответ придет закодирован так-то и так-то".

в угоду потери расширяемости и универсальности

Да, расширяемость будет с запасом. Например, нужно 6 устройств - будет 16. но 256 - мне 100% не пригодиться!
Универсальность не нужна - в сети будут только мои устройства!
аппаратным мазохизмом плюс отдельной линией
Что-то не могу понять в чем мазохизм заключается. В протоколе 9 бит выставляем 1 для адреса, 0 для данных... А принимающая сторона проверяет ее ли адрес и если ее - точно так же выставляет 0 в определенный регистр, таким образом разрешая прием данных. Иначе чужие данные будут просто аппаратно игнорироваться.
A 9-бит - это упрощение?
Для контроллеров - да. для связи с компом - нет. тут начинаются танцы с бубном. Но учитывая, что у меня десятки контроллеров, в которые нужно написать какой-то десяток прошивок - то лучше помучатся со связью с компьютером, но с контроллерами будет легче.
Вообще-то, в компьютере UART не на 8, а на 9 бит. Просто его на 9 бит никто не использует, но аппаратура поддерживает.
И он называется Parity - это аппаратный бит. его записать легко, а считать - не всегда(в 1 моём сообщении 1 способ). Из-за этого и была создана тема.
ТС, в сообществе почитай....
Читаю... Пока к сожалению ничего не нашел, что бы меня убедило....
Multi-Processor Communication Mode буду использовать в лубом случае. Только 9 бит, никак иначе. Прошу помощи, как правильно связать это все с компьютером... А то уже склоняюсь к изготовлению переходника с 9 на 8 бит на контроллере.

0

"И он называется Parity - это аппаратный бит. его записать легко, а считать - не всегда"
Не думаю, что это так. Этот бит как раз и служит для мультипроцессорного обмена. У нас (но не я) делали обмен на 9 битах. Кроме того, такой интерфейс используется в межкоммуникациях телеф. станции Selta, делал плату для нее. Причем, все 9 бит проходят через fifo.
Впрочем, если почему-то не работает, ну ...

0

Сообщение от u37 "И он называется Parity - это аппаратный бит. его записать легко, а считать - не всегда" Не думаю, что это так. Этот бит как раз и служит для мультипроцессорного обмена.

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

0

Да, это бит четности. Сделан для обнаружения ошибок... При чем аппаратное обнаружение... По-этому непросто его считывать.
Передать легко:
1. Выставляем Parity Mark или Sposi(лог 1 или лог 0)
2. Передаем байт из 8 бит
3. На выходе у нас получается 9 бит, какие мы и хотели.
Принять посложнее:
1. Выставляем какое-то значение Parity перед приемом.
2. Принимаем байт.
3. Принятый байт будет тот, что мы хотим, если четность совпадет.
4. Но если четность не совпадет - выскочит ошибка четности, которую нужно обработать, а сам принятый байт аппаратно заменится на байт ParityReplosi. Например на 3Fh. Таким образом мы его потеряли.
Из этого следует вопрос. При получении байта какую четность выбрать? Можно ли как-то игнорировать ошибки четности и отключить замену байта на ParityReplosi?

0

Да, виноват, ввел в заблуждение. У нас использовалась ADuC, что не совсем стандартно.
Сейчас 9 бит поддерживает 16950, но что "намазано" в конкретном южном мосте - это загадка.

0

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

У Вас пакету пинаются программно? затраты (если аппаратно) идут только на всовывание байта в регистр (или считывание с регистра). Ну и с 10 тактов на обработку

Читаю... Пока к сожалению ничего не нашел, что бы меня убедило....

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

я бы сделал следующим образом:
- взял бы двойную адресацию
первый уровень первый адрес второй уровень - второй адрес.
[индекс начала посылки (1 байт)] [адрес 1 (1 байт)] [ адрес второй (1 байт)] [команда или что там(1 байт)] [длинна данных (n байт)] [CRC8] [конец посылки]
если не надо огромного количества устройств в сети то можно совместить адреса
[адрес 1 (& 0xF0) адрес 2 (0x0F) ] по 16 устройств ну и в подобном духе можно совместить и начало посылки и конец посылки с контрольной суммой...

З.Ы. если так уж сильно жалко тактов процессора то возьмите мощнее камни! нет? возьмите на отдельном простеньком и дешевом камне сделайте связь, а остальное все (я хз...мегафлопы вычислительные, мож биткоины майнить или потоковое видео гонять или еще чего...) на более мощном камне.

0

У Вас пакету пинаются программно?

Нет, аппаратно. Для того, чтобы передать - нужно просто всыпать байты для отправки на линию..
А вот при приеме - в Вашем случае, и в случае Modbus нужно:
1. Сохранять в буфер все, что на линии
2. Выискивать стартовые/стоповые посылки
3. Проверять адреса
4. Если адрес наш - то обрабатывать далее, а если не наш(более 80 % случаев) то зачем мы делали предыдущие 3 пункта?

При приеме в моем случае - принимаем только адресные биты. остальные игнорируются аппаратно!!! То есть если говорят не мне - я не то что не вникаю, что там говорят, а просто даже не слушаю, пока меня не пнут. Это существенно уменьшает нагрузку на линию и контроллеры.

Походу ТС не за ответами на вопросы пришел, а просто так похвастаться своим придуманным способом создания сетей

Да, еще и назвал этот способ Multi-Processor Communication Mode, и попросил производителей микроконтроллеров описать его в даташитах, выделил бит MPCM в железе контроллеров и допаял транзисторы в микроконтроллеры, чтобы они аппаратно отключали прием по уарту ненужных данных)))
Неужели производитель микроконтроллеров от фонаря сделал такой протокол и описал его в даташите. Почему тогда Modbus не описал? Получается, что MPCM все же заслуживает внимания? http://we.iosyitistromyss.ru/AVR/vremya ... -mode.html - вот в статье описано как пользоваться этим протоколом, который все же придумал НЕ Я. Описано в 2 словах, но там настолько все просто, что даже нечего добавить. Единственная проблема, что компьютер его не понимает.

если так уж сильно жалко тактов процессора то возьмите мощнее камни! нет? возьмите на отдельном простеньком и дешевом камне сделайте связь, а остальное все (я хз...мегафлопы вычислительные, мож биткоины майнить или потоковое видео гонять или еще чего...) на более мощном камне.

Тут упирается в бюджет. Дешевле заставить компьютер вклиниться в 9-битную линию, чем покупать 3 десятка более дорогих контроллеров. и дороже они будут в разы.

0