Организация сетевого обмена на AT90S8515, Построение локальной сети микроконтроллеров Опции

[nelord]

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

[Qwertty]

Здравствуйте!
Подскажите как лучше реализовать сетевой обмен между МК, если имеется следующие требования:
...

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

[defunct]

Линий кроме RXD и TXD у AVR нет. Если нужны следует выбрать другой контроллер, например AT91SAM7S128.

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

Какой из предложенных протоколов лучше выбрать: MODBUS или WAKE?

Я бы выбрал modbus.

следует ли на этой плате ставить дополнительную ИМС памяти (для приемного буфера), если да, то какого объема лучше?

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

[nelord]

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

Разумеется, что можно использовать любой 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, как я понял почитав по следующим ссылкам:

http://masters.donntu.edu.ua/2004/fema/kov...brary/art7.html
http://www.gaw.ru/html.cgi/txt/interface/rs485/start.htm
http://www.gaw.ru/html.cgi/txt/publ/_rtcs/maxim_rs485-2.htm
http://www.gaw.ru/html.cgi/txt/interface/rs485/power.htm
http://www.gaw.ru/html.cgi/txt/interface/rs485/app.htm

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

[defunct]

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

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

Также вопрос: почему RS-485 лучше, чем RS-232, как я понял почитав по следующим ссылкам:
он отличается только в передаче по дифференциальной паре, то есть лучше применим для сетей с удаленными абонентами + лучше помехозащищен.

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

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

[nelord]

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

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

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

[Dog Pawlowa]

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

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

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

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