Мультипроцессорная система

[tytar]

Доброго времени суток всем!
Подскажите, по такому вопросу:
Нужно сделать сеть из микроконтроллеров, где есть главный(мастер) и слейвы. Но они могут все общатся между собой. могут быть разнесены до 10-15 м. Будут использоваться авр, наверно мега32.
Какую сеть использовать? остановился на i2c или can?
ЗЫЖ это дипломка.

[Smirnov]

Доброго времени суток всем!
Подскажите, по такому вопросу:
Нужно сделать сеть из микроконтроллеров, где есть главный(мастер) и слейвы. Но они могут все общатся между собой. могут быть разнесены до 10-15 м. Будут использоваться авр, наверно мега32.
Какую сеть использовать? остановился на i2c или can?
ЗЫЖ это дипломка.

RS485 лучше, выше помехозащищённость, скорость большая, готовых преобразователей навалом. От того же MAX или их аналоги у аналогдевайсес. Самое главное для диплома - он такой же простой как RS232.

[AndyWorld]

А сколько будет реально девайсов? И почему будет использоваться Мега32? Неужели такой тяжелый софт в ней будет сидеть?

[tytar]

мега просто есть в наличии) + на кафедре штук 25 тестовых плат
Реально будет 4(6) слейва + 1 мастер.
но нужно обеспечить подержку до 128 устройств( это по заданию)
как в RS485 обеспечить адресацию и преоритеты подключенных устройств?

[AndyWorld]

не так уж много для i2c. Можно использовать ее. Ну а в реальности 128 устройств ни кто проверять не будет. Для такого количества I2C медленная сеть.

[tytar]

микросхемы для RS-485 в 2 раза дороже чем для CAN)
Может его заюзать)
Главное услевие, что бы использовать простую сеть - из всех я остановился на i2c? can rs-485, но последняя что-то мне не очень( хотя все может быть)
Все мк будут заниматься примитивной работой вкл/выкл диоды по сигналу из сети, отправлять в сеть данные если была нажата кнопка, через заданое время включать/выключать теже диоды. Такой обмен данных может (и должен) быть как и с мастером так и между слейвами.

[GP1]

... Но они могут все общатся между собой. ...

Тут уже не мастер-куча слейвов, тут уже мультимастер, со всеми вытекающими - арбитраж, захват и т.п.

[tytar]

А если упростить) К примеру слейвы общаються между собой, через мастера?

[tytar]

у Вас может и дешево у нас 5 баксов за шт.(

[Smirnov]

что к коту приелись, не хочет рс, дайте ему нормальное описание на кан шину, мяу!

[ibiza11]

топикстартер посмотрите что тут есть : http://piclist.ru/S-CAN-MODULE-RUS/S-CA ... E-RUS.html
это аппаратная часть шины CAN реализованная в PIC
Это все придется делать ПРОГРАММНО.... Товарищ ARV с ней много общался, у меня дела до практики пока не дошли.
на форуме есть тема по CAN... что то там про электронные ценники говорилось.

для вашей задачи самое простое - rs485 и нечего больше выдумывать. Хотя если есть желание изучить, то без проблем, в инете полно инфы по этой шине. Удачи, кот!

[Vov123]

I2C до 3 метров,UART до 15.Используйте штатный UART передатчик без всяких добавок.Протокол запрос-ответ легко написать самому,так-же можно посмотреть 9-битный UART.

[Qwertty]

I2C до 3 метров,UART до 15.Используйте штатный UART передатчик без всяких добавок.Протокол запрос-ответ легко написать самому,так-же можно посмотреть 9-битный UART.

Это не UART 15 метров, а RS232 что далеко не одно и то же. Кроме того эти интерфейсы (UART,RS232) рассчитаны на соединение точка-точка, т.е. слейв будет 1. Лучший выбор конечно CAN, но программно его реализовать непросто и если нет поддерэки в самом микроконтроллере, то попросту дорого. Компромисс RS485 - дешево и сердито. Недостаток один - нет арбитража и поэтому большая латентность шины. При большом количестве датчков мастер сможет узнать о например аварийном событии на одном из слейвов через большой промежуток времени. Потому что система построена на принципах запрос-ответ. В случае с CAN мастера/слейвов как таковых нет, и каждый может общаться с каждым. Причем можно приоритеты сообщениям задавать.
Для большинства же применений RS485 достаточно.

[Vov123]

делается это очень-очень просто.Все ведомые находятся в ожидании(прерывание по получению символа по UART).Назовём его адресом.И вот ведомый хочет получить инфу от конкретного ведомого,посылает адрес(к примеру 01 00 00 00 00 00 00 01).Если у ведомого совпало он отвечает,если нет молчит пока не совпадёт)Длинный адрес оправдан тем,что при передачи инфы другими ведомыми не совпал с чьим нибудь адресом.Проверено,работает на ура.
А вот по поводу CAN,если человек разобрался с этим протоколом,то не стал бы дурацких вопросов про UART спрашивать.

[ARV]

позвольте мне встрять...

из всего вышеназванного я бы советовал выбрать именно CAN.
во-первых, это гораздо солиднее для диплома, чем остальное, так как выглядит именно профессионально.
во-вторых, особенно разбираться там не надо - в диплом вписать то, чего и так полно в журналах или сети, а для программы использовать фирменные библиотеки, для освоения которых надо не так уж много сил. кроме фирменного полно и "самописного" кода.
в-третьих, это на самом деле недорого: применяя MCP2515 и любой из драйверов можно прилепить CAN к любому МК - хоть мега32, хоть тини2313.

[tytar]

По поводу CAN на форуме MicroChip'a читал ветку, где один чел предлагал кому то использовать CAN и микруху, вроде TJA1050.
Это трансивер. И я так понимаю без CAN контроллера ничего не будет?

[ARV]

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

существуют микроконтроллеры, в которых встроен трансивер - такие есть и у микрочипа, и у атмела и у других. я не встречал МК, которые содержали бы впридачу и драйвер, поэтому это всегда отдельная микросхема. я работал и с внешним трансивером MCP2510 и со встроенным в AT90CAN128. разумеется, с внешним проблем чуть больше, но жить можно - это недорого зато.

[ujin]

можно как вариант посмотреть в сторону rs485+протокол modbuss...это уже считается обще промышленным стандартом....достаточно не сложно но и при этом неплохо выглядит + очень много чего с помощью его уже чего всего разного объединить в сетку....

[tytar]

Очень благодарен, за совет использования mudbus, про что-то похожее я давненько подумывал. Заинтересовал этот протокол. Но так же "более притягивает" can, за то что каждое устройство может общаться с любым другим. И вот так сказать выбор между "can" и rc-485+modbus. Но все же склоняюсь к rs-485. В таком случае общение устройств между собой через "масте-сервер". За одно, сервер может вести "лог" всех операций и сообщений сети и отправлять, скажем, на комп.))) А это уже интересно, наглядно видеть "общение" устройств между собой.
Всеми руками за can, но все же использовать две микрухи для организации сети, для меня лично слишком "жирно" будет. Если учесть что надо подключить 5 устройств (мастер+4 слейва). Вот если бы проэкт был бы коммерческий, тогда "да".
Сегодня мне "усложнили" задание, сказали, что очень простое задание, с точки реализации. "Перефразировав" его в программированный пульт управления программируемыми устройствами. С одной стороны это уже интересно мне.

[ujin]

вот собсна ...во вложении разложена структура протокола modbus
может пригодиться.