Здравствуйте!
Подскажите как лучше реализовать сетевой обмен между МК, если имеется следующие требования:
- обмен по последовательному каналу (планирую использовать UART + MAX232);
- число абонентов от 1 до 16;
- возможность горячего подключения/отключения абонентов;
- длина передаваемого сообщения данных / команд не более 64 байт.

Сетевой обмен будет макетироваться на STK500 и моделироваться в Proteus'е.
Есть ряд вопросов по реализации:
- следует ли реализовывать некое подобие Ethernet, TokenRing, HDLC?
- как следует осуществлять квитирование? (для связи будет использоваться нуль-модемный кабель (RS-232C, COM (DB-9M)))
- будут ли программно доступны линии спецификации RS-232C (9-контактов), кроме TxD/RxD/GND? Есть подозрения, что они будут недоступны. Поясню, планировал использовать ряд линий как запрос на конфигурирование сети и быстрый ответ на передачу данных (принято без/с ошибками), без них же будет затруднительно это реализовать.

Полагаю использовать преамбулу в 2 байта + 2 байта, определяющие тип передачи, + 2 байта CRC16. Думаю, что имеет смысл реализовать некоторый набор стандартных команд-пакетов, например опрос статуса и т.д. По-началу хотел реализовать детерминированный доступ к каналу - в духе TokenRing, однако сейчас в недоумении, как организовать выбор монитора (резервного монитора) из всех МК, а также организовать обход абонента, которому нечего передавать и/или передача адресована не ему, - это для сокращения временных задержек, связанных с приемом, а затем перепередачей данных. Сейчас же в раздумьях, как это можно сделать, чтобы потом была возможность выполнить макетирование на STK500.

Подскажите, пожалуйста, как решить вышеописанные вопросы. Заранее благодарен.

В догонку, есть еще одно требование - реализовать "средства (аппаратные и программные), обеспечивающие контроль работы канала связи с помощью пульта оператора в режиме диагностики, предусмотрев централизованное управление всеми транзакциями по командам оператора", следует ли на этой плате ставить дополнительную ИМС памяти (для приемного буфера), если да, то какого объема лучше? Для индикации будет использован цифро-буквенный ЖКИ типа LM041L/LM044L.

P.S.: также было высказано "требование-пожелание" - программы должны быть написаны на ассемблере (это несколько огорчило... ).

MAX232 (как и RS232 вообще) не предназначена для построения сетей. ИМХО Ваш выбор - RS485 и что-то типа max483.
AT90S8515 - странный выбор,контроллер не производится лет 5.
Про Протеус лучше забыть, в нем хорошо только игрушки отлаживать.
Линий кроме RXD и TXD у AVR нет. Если нужны следует выбрать другой контроллер, например AT91SAM7S128.
Протоколов много стандартных - MODBUS, WAKE, или на их основе изобретайте свое.
Курсовик?

Именно, курсовик. Свой уже сдал, попросили сделать за небольшую премию)).

Согласен про AT90S8515, что он уже не выпускается, однако в техническом задании указана как раз эта модель. Какой из предложенных протоколов лучше выбрать: MODBUS или WAKE?

Зачем? Берем любые GPIO и называем их так как надо.


Я бы выбрал modbus.


Я бы ставил 8-32kB (корпуса/сигналы одинаковые), но "не для приемного буфера", а для комфортной работы. Т.е. подключить эту память по шине и использовать также как и внутреннюю - если надо под стек, под переменные и проч.
Чип m162 или m128 (с внешней шиной и с JTAG'ом для отладки).

2 nelord - на счёт модбаза - где то сдесь и исходники валялись

Разумеется, что можно использовать любой I/O вывод, вопрос был относительно поддержки физической коммутации этих выводом с разъемом DB-9M на плате STK500, в документации для указанной коммутации есть только "RS232 SPARE", то есть TxD/RxD + GND

Описание спецификации modbus нашел следующее, если кому быть может понадобится:
http://www.idom.ru/files/Schneider/Info/Ne.../Modbus_Rus.Doc

Также вопрос: почему RS-485 лучше, чем RS-232, как я понял почитав по следующим ссылкам:

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

Дык в чем вопрос? Подведите требуемые линии к разъему.
Всяко проще чем переходить к совсем другим платформам.


1. 2.5км дальность сегмента.
2. можно подключать до 32-х устройств к одной шине из двух проводов.

Он не лучше применим, он создан для сетевых решений, в то время как 232-й это соединение точка-точка и к сетевым решениям не применим вообще.

Согласен, что соединение - точка-точка, что же мешает соединить всех абонентов следующим образом: TxD(n-1)-RxD(n), n=1, ... N-1; TxD(N-1)-RxD(0). Организовав таким образом кольцо связями точка-точка.

Сейчас у меня остался вопрос, как организовать доступ к каналу, если не обходимо поддерживать горячее подключение. Поясню - имеется активный монитор (при чем как отдавать предпочтение одному абоненту не очевидно), возможно что включат новых абонентов, несконфигурированных для работы в сети, или же выключат станцию-монитора. То есть нужно организовать что-то вроде MAC (Media Access Control) канального уровня модели OSI.

1. Мазохизм 2. Потеря быстродействия. 3. Потеря надежности.


Сессия скоро, что, MAC в задании записан?
Даже если записан, пишем, что объединяем этот уровень со следующим и вводим адресацию на перемычках. Хочешь подключиться - сконфигурируй перемычки.

[quote name='nelord' date='Jun 3 2008, 10:49' post='421121']
Согласен, что соединение - точка-точка, что же мешает соединить всех абонентов следующим образом: TxD(n-1)-RxD(n), n=1, ... N-1; TxD(N-1)-RxD(0). Организовав таким образом кольцо связями точка-точка.

Кольцо прекрасно делается на RS485 c применением репитеров. При этом все устройства слушают мастера одновременно. Реализовыется любой одномастерный протокол, MODBUS например. А ваш вариант - кольцо с односторонним движением информации, со всеми вытекающими. Я бы не называл это сетью вообще.

Нет, MAC я просто привел для примера. Вопрос относительно MAC был связан с тем, что как организовать доступ к каналу. Была мысль ввести дополнительную линию занят/свободен, но тогда один абонент может полностью занять канал на продолжительное время, если же в передачу вклинится другой абонент, то это может быть воспринято, как нарушение timeout.
Адекватно ли будет ввести паузу установки занят/свободен 3х видов: передаю кадр, ждите (минимум); хочу начать передачу (средне); только что передал, если кому канал нужен, занимайте (максимум). При приеме любого передаваемого байта сбрасывать соответствующие таймеры. Таким образом, думаю, что пакет будет полностью передан без вклиниваний других станций и передающая станция не займет весь канал.

Куда, простите, Вы собираетесь вводить эту паузу?

Есть два основных варианта -
1) логика Ethernet (все слушают и пытаются вклиниться, если коллизия произошла, повтор по правилам)
2) организация сети Master-Slaves - коллизии исключаются, но Мастер должен опрашивать всех.
ну и там разные еще токен ринги на любителей извращений.

Хотите придумать что-то свое?

Хочу ввести дополнительную линию: свободен или занят канал (busy).
При доступе к этой линии будет использоваться задержка 3х видов (задержка после приема последнего байта информации или сброса счетчиков). В принципе это аналог Ethernet, только прослушивается перед выходом в сеть не канал передачи, а линия busy. Если кто-то начал передавать данные, то он должен передать все без вмешательства в передачу других абонентов (то есть минимальная задержка установки линии busy). Если канал свободен - то его может захватить любой абонент (средняя задержка установки линии busy). Если абонент только что передал данные - то он ждет перед отправкой новых данных время, большее, чем в предыдущем случае (больше средней задержки).

Послушайте.
Тысячи людей, поумнее чем Вы и я, во всем мире, лет сорок уже, работали над созданием локальных сетей. И кое-что придумали. И тут приходите ВЫ!
В Вашей идее с ходу видны элементарные логические дыры.
1) Например, двум узлам есть передавать, они дожидаются, пока освободится канал. И оба одновременно занимают его! И оба начинают передавать. А уж при более подробном рассмотрении дыр найдется гораздо больше.
2) Каким приемопередатчиком Вы будете формировать сигнал Busy? Что-то уникальное закажете?

Если препод лох, то он, конечно, проглотит. Дерзайте.

2 Dog Pawlowa - с его проводом занятости просто надо чтоб дЫвайсы рандомное кол-во времени ждали(на таймер чтоли какой нить повесить или чтото такого), но это дополнительные провода , своя логика, есчё какие либо качели непредвиденные...

2 nelord - зачем вам заново изобретать велосипед ?

Огласите пжалста, весь список!
То есть, задание поподробней.
Что за сеть, кому, куда, между чем.
Может, достаточно режима master-slave?
тогда Modbus с одним ведущим. Все проблемы коллизий и им подобные отпадают на раз, т.к. без спросу никто ничего не пискнет.
Если произвольный доступ - тогда нужно прослушивать линию и анализировать коллизии. Ваши BUSY - это изврат. Плюсов никаких, минус - как минимум лишняя линия.

Так то-то и оно. Если по коллизии запускать случайный таймер, то на зачем тогда специальный сигнал?
Уж проще тогда маркером делить время.
Короче, не изучено все, что накопило человечество. Даже книжки не прочитаны.
Но как 1/4 доцента думаю - а может и лучше предложить что-то ошибочное, чем скачать стандартное

Хотел как проще, а получилось ли... не знаю.
Да, при возникновении коллизий аля Ethernet - думал, что их CRC16 отловит.



Хотел как проще, а получилось ли... не знаю.
Да, при возникновении коллизий аля Ethernet - думал, что их CRC16 отловит.

Например CAN, где проблеммы мультимастерности решены способом очень похожим на то, что предложил 'nelord'.

2 'nelord'. Если вам эта тема действительно интересна. В смысле не как курсач сдать, а как хобби что-ли, то рекомендую сделать следующее: использовать вместо приёмопередатчиков RS485 приёмопередатчики CAN (или LIN). У них есть рецессивный и доминантный уровень, и если 100 передатчиков передают рецессивный (1), а один доминантный уровень (0) на линии будет доминантный уровень (0). И если передатчик будет слушать свою передачу, то он сможет распознать коллизию (в отличие от использования приёмопередатчиков RS485). В это случае линия BUSY не будет нужна.
А вообще почитайте и про CAN и про LIN. Я сделал мультимастерную сеть на базе USART с приёмопередатчиками CAN - всё замечательно работало. По крайней мере гораздо эффективнее MODBAS. Единственный недостаток - нестандартность.

Упс - два раза вставилось..

Просто мысль - для курсовика экономика не важна, можно тупо применить CAN. Полностью "ложится" под задание и избавляет от всех проблем разом. Арбитраж, горячее подключение и т.д получатся автоматом. Хотя MCP2515 не такая уж и дорогая.

Нисколько непохожи. В CAN нет никаких доп линий "занятности" канала. Конфликт разрешается "отвалом" группы мастеров-лузеров с рецессивным уровнем сигнала. Т.о. возможна ситуация когда опеределенный мастер вообще никогда не получит шанса "пообщаться".
Идея CAN'a - это I2C с PHY пригодным для подключения на большие расстояния.

nelord предлагает некое подобие CSMA-CD, за тем исключением, что CSMA-CD обходится без доп линий, а использует прослушку и преамбулу для выявления конфликта, плюс случайный таймаут. Его доп. линия - это потеря надежности ровно на 50%. Заглюч какое-то из устройств или оборвись эта линия - и вся система сдохла.

Хотел как проще, а получилось ли... не знаю.
Да, при возникновении коллизий аля Ethernet - думал, что их CRC16 отловит.

Отловит, но уже поздно - несколько фреймов может быть потеряно и нескольким девайсам надо делать перепосылку, тобиш "разрулить" ситуацию по CRC16 - сложно и накладно для линии.

В Ethernet'е используется преамбула фрейма скважностью 2.
В момент посылки преамбулы прослушивается линия, и если скважность импульсов в линии будет отличаться от 2 - посылка фрейма откладывается, т.е. конфликт обнаруживается до отправки фрейма, а не после как в случае с CRC.

Спасибо большое за помощь. С этим я разобрался, но на досуге надо будет почитать про Can и подобное ему.
PS: Описанное ранее я попытался сконструировать основываясь на методах борьбы с перегрузкой буферов портов в коммутаторах и технологией CSMA/CA.

PPS: был бы крайне признателен, если бы кто-нибудь поделился материалом по подключению цифро-алфавитного LCD индикатора, а именно программой на ассемблере. Понимаю, что это не пишут на ассемблере, на С уже есть все готовое, однако в задании именно АССЕМБЛЕР.

2 defunct, спасибо, это я полагал тоже учесть, если посмотреть ранний пост.

2 nelord - а здесь пробовали искать
http://electronix.ru/forum/index.php?showtopic=10934

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

Я имел ввиду, что похоже не по физической реализации, а по методологии. Конечно в CAN нет никакой доп. линии, но имеется РАВНОПРАВНАЯ мультимастерность (в отличие от I2C с его адресами устройств). А ситуация, когда мастер не сможет пообщатся в CAN невозможна (при физической исправности). Возможна только ситуация, когда определённый мастер не сможет никогда отправить сообщение с НИЗКИМ приоритетом. Но никто не мешает ему в случае таймаута этот приоритет поднять - сеть-то совершенно равноправная.

2 'Dog Pawlowa'. Вообще то это я предложил 'nelord' использовать драйвера CAN. Примерно год назад это обсуждали. Это первая моя тема на этом форуме была.

Да-да, простите.
Идея хорошая и скрашивающая натянутость использования USART в данном случае.

То-же задумывался. А какая дальность прогнозировалась и какая получилась?

На скорости 57600 связывались компьютер через USB-HID переходник (самодельный на ATmega64, пишущий трафик во флэш) и 6 блоков ATmega64 (планировалось до 64). Общая длина кабеля 50 м. Сбоев по причине помех не было замечено. Перед передачей контроллеры ждали тишину на линии (контроль тишины происходил постоянно). Передача начиналась с 0xAA как в LIN. Если самопринятый 0xAA был запорчен (коллизия)- опять ждали тишину, время зависящее от N блока. Входы RxD у ATmega64 были соединены с входами захвата таймеров для точного тайминга. За счёт ненужности опроса ведущим (и отсутствия самого ведущего) трафик резко уменьшался, и зависил ТОЛЬКО от частоты событий в сети.
Всё хорошо работало, но перешли к CAN (на то-же место стали паять AT90CAN64). В принципе переход на CAN был скорее маркетинговым ходом.

Тут начал моделировать все запрограммированное, при соединении UART'ов все передает как и было задумано, при установке трансивера MAX487 с подключенными согласующими резисторами 120 Ом (соединяют А и В в непосредственной близости с самыми "удаленными" абонентами), наблюдаю следующую ситуацию: канал свободен и абоненты считывают его состояние, то есть сигнал DE/!RE=0, согласующие резисторы дают на линиях A, B сигнал "1", модель этой ИМС в Proteus 7.2 при таком уровне выдает на линию RO="0", то есть UART абонента принимает этот "0", но он конечно игнорируется до приема 0хАА (начала кадра). Можно ли как-нибудь разрешить эту ситуацию так, чтобы этот "0" не приходил, когда не нужно?

Попутно возник еще один вопрос, при детальном анализе ситуации, принимаемый байт "00", когда на линии никто не активен, устанавливает USR.FE. В документации написано: данный флаг устанавливается в "1" при обнаружении ошибки кадрирования, т.е. если стоп-бит принятого слова равен "0"; флаг сбрасывается аппаратно при приеме стоп-бита, равного "1". Флаг действительно установился в "1", однако вернуть его в "0" - не получается ни "clr temp | out USR, temp", ни приемом нормального стоп-бита. Моделирую в упоминавшемся ранее Протеусе 7.2. Сталкивался ли кто-нибудь с похожей ситуацией, если, подскажите, пожалуйста, как сбросить этот флаг.

Подавить нуль в принципе можно растяжками А и Б в направлении земли и единицы, но так не делают настоящие профессионалы по причинам, которые я не хотел бы сейчас обсуждать
Правильное решение проблемы таково:
- при наличии сигнала break(а это называется именно так) в линии приемник игнорирует принятый байт, сбрасывает все ошибки и продолжает прием.
- передатчик начинает передачу так: включает передатчик, передает сигнал RxD пассивного уровня в течение времени не менее длительности байта.

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

Кроме экономии электроэнергии я других причин отказа от растяжки не вижу.

При таком подходе:
1. В случае тишины на линии ПОСТОЯННО будут приходить 0е байты с ошибкой формата (break). Их придётся всё время обрабатывать по прерыванию тратя на это время. И допустимое время работы с запрещёнными прерываниями уменьшится в 2 раза (из-за занятости одного уровня FIFO приёмника).
2. Передача RxD пассивным уровнем (1) (или что тоже самое - передача FF) будет воспринята приёмником как приём байта в одном из вариантов FF, FE, FC, F8, F0, E0, C0, 80 или 00 без ошибки формата.
3. Это задержит начало передачи собственно данных на время 1 байт. Т.е. существенно затормозит сеть.

Всё это (в т.ч. растяжка резисторами) не нужно т.к. можно использовать приёмопередатчики RS485 со сдвинутыми уровнями у A и B. Есть такие. Их электрические характеристики ПОЛНОСТЬЮ соответствуют стандарту RS485, но уровни у A и B сдвинуты так, что тишина на линии ВОСПРИНИМАЕТСЯ КАК 1.
Вот от использования таких приёмопередатчиков я не вижу причины отказываться.

2 'nelord'
1. За давностью забыл - 1м байтом передавалось не 0xAA, а 0x55. Т.е. в линии 0101010101 (0x55), а не 0010101011 (0xAA).
2. Эта передача (1й 0x55) имеет смысл только при мультимастерной сети (для разрешения коллизий). В случае с 1м ведущим она не нужна т.к. коллизии и так невозможны.
3. Вы какую хотите создавать сеть - с 1м ведущим или мультимастерную?
4. Если вы хотите мультимастерную сеть, то рекомендую использовать CANовские приёмопередатчики. Например PCA82C251. Их кстати можно использовать и просто вместо RS485 приёмопередатчиков, тогда не нужны будут растяжки (у них уровни сдвинуты) и не надо будет переключать приём/передачу (передаётся только 0).

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

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