Нужна помощь max485, Atmega16 Опции

[klin-2006]

Рисую принципиальную схему с МК Atmega 16, необходимо передавать данные с МК на ПК по интерфейсу rs-485 по протаколом CAN. Все впринципе понятно, кроме протакола CAN. Непойму следующее: для того чтобы был CAN протакол, нужна специальная микросхема или CAN описывается только в программе? Просто я сделал так: с МК веду на микросхему max485 потом опять на нее, затем на max232 и к ПК. Пример смотри ниже, только для МК PIC. А вот что с CAN делать непонятно. Подскажите пожалуйста.

Модератор. Две темы были объединены. Напоминаю, что кросспостинг запрещен п.3.2 Правил форума.

Эскизы прикрепленных изображений

 

[rezident]

Протокол CAN подразумевает физический уровень в виде интерфейса CAN. MAX485 это драйвер RS485, а не CAN. И на вашей схеме нарисована сеть RS485. Вы вообще-то правильно (верно) поняли свое задание?

[klin-2006]

Протокол CAN подразумевает физический уровень в виде интерфейса CAN. MAX485 это драйвер RS485, а не CAN. И на вашей схеме нарисована сеть RS485. Вы вообще-то правильно (верно) поняли свое задание?

Так как нам необходимо связать несколько ГРП с одним диспетчерским пунктом на расстоянии 1 000 м, то для нас лучше всего подходит интерфейс RS-485, и необходимо выбрать протокол связи. Будем использовать CAN прокол. Это мое задание. А микросхема MAX 1480 подойдет?

[defunct]

Так как нам необходимо связать несколько ГРП с одним диспетчерским пунктом на расстоянии 1 000 м, то для нас лучше всего подходит интерфейс RS-485, и необходимо выбрать протокол связи. Будем использовать CAN прокол. Это мое задание. А микросхема MAX 1480 подойдет?

Пользуйте MODBUS, он наиболее хорошо подходит для поставленной задачи и имеющегося железа.
А CAN это не протокол.

Нет, modbus для одного мастера.

У него как раз один мастер - Диспетчер, и множество слейвов - ГРП.

Вот только количество и адреса устройств должны быть известны на ПК, Plug & Play не получится

Зачем знать адреса и количество? Прекрасно получится Plug&Play. ПК - делает опрос всех адресов, находит и идентифицирует все устройства в сети. Потом работает только с найденными и проидентифицированными. Периодически повторяет поиск новых устройств в сети.

[rezident]

У него как раз один мастер - Диспетчер, и множество слейвов - ГРП.

Вы не очень внимательны.

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

Если мы правильно интерпретировали процитированное ("оповещать оператора"), то для этого режим "мультимастер" требуется.

[defunct]

Вы не очень внимательны.

Просто последние 10 лет тесно связан с АСУТП системами.
И точно знаю, что никакой мультимастер здесь не нужен.

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

Если мы правильно интерпретировали процитированное ("оповещать оператора"), то для этого режим "мультимастер" требуется.

Оповещать оператора - это задача АРМ'а диспетчера, т.е. надо забабахать туда какой-нибудь сигнал сирены, блыманье всего экрана красным цветом и т.п.. - это задача сугубо ПКшного ПО.

ГРП же, должен, в обязательном порядке, иметь уставки, и при выходе за них - также в обязательном порядке регистрировать аварийное событие (дата, время, уставка и отклонение) и хранять его до тех пор пока ПО верхнего уровня его не вычитает. АРМ диспетчера (в общем виде ОИК сервер) должен сам запрашивать архив аварийных событий (будь то температура, давление, перегруз по току, и прочее).

Только такая схема единственно правильная т.к. ни при каких условиях аварийное событие не потеряется. В противном случае (мультимастер и отправка данных с ГРП самостоятельно по инициативе ГРП) может привести к потере аварийного события - потому что как раз в момент аварии канал связи могут разорвать, переехать трактором, залить водой, банально выключить комп диспетчера. Плюс ко всему мультимастер усложнит систему в разы, что пагубно отразится на ее надежности.