Здравствуйте!
Подскажите как лучше реализовать сетевой обмен между МК, если имеется следующие требования:
- обмен по последовательному каналу (планирую использовать 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.: также было высказано "требование-пожелание" - программы должны быть написаны на ассемблере (это несколько огорчило... ).

Огласите пжалста, весь список!
То есть, задание поподробней.
Что за сеть, кому, куда, между чем.
Может, достаточно режима 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. Единственный недостаток - нестандартность.

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

Сообщение отредактировал Qwertty - Jun 3 2008, 12:05

Просто мысль - для курсовика экономика не важна, можно тупо применить 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 в данном случае.

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