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

На скорости 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" вызывал дополнительную обработку прерываний, однако это на производительность не сильно сказалось. Спасибо большое за помощь в решении возникших вопросов, работа была успешно сдана!