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

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

Подскажите пожалуйста к какой ножке МК Atmega16 подключается соединенный вход RE (инверсия) и DE микросхемы LTC485 (интерфейс rs485). Есть пример для PIC контроллера.

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

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

К любой свободной. Этой ногой управляют направлением передачи/приема по RS485 линии. Т.к. встроенный UART не обеспечивает автоматического управления, то используется чисто програмное.
И еще, CAN поверх RS485 - это редкостное извращение

А какой протокол вы бы посоветовали взять для rs485? (чтобы без всяких дополнительных микросхем было, как на рисунках выше)

Сильно зависит от задачи. Какая нужна скорость, какие объемы данных, степень помехоустойчивости и пр? Диапазон протоколов очень широк - начиная с голых пакетов, потом что нибудь типа modbus, WAKE и кончая PPP и пр.
Без. В RS485 их просто некуда воткнуть, даже если бы захотелось

Скорость передачи не играет роли, объем данных маленький (10 КБ), необходимо только чтобы связь между ПК и устройством была двусторонняя, т.е. с устройства на ПК передавать информацию, а также с ПК на устройство. И расстояние 1000м.

Судя по вашим сообщениям вы путаетесь в понятиях и терминах. В частности путаете термины "протокол" и "интерфейс". Если приводить аналогии из человеческой жизни, то интерфейс это легкие, горло, голосовые связки и язык, т.е. то, что служит для получения звуков. "Речевой интерфейс" человека т.с. А протокол это язык общения, который складывается из отдельных звуков, производимых "речевым интерфейсом". Причем "речевой интерфейс" у всех людей схожий, а вот языков общения на планете Земля по-моему не менее 300 существует.
Дальнейшая аналогия про расстояние и наличие/отсутствия "дополнительных" микросхем. Вам вроде нужно передавать данные на расстояние до 1000м? Представьте, что вы в комнате, где громко играет музыка или работает ТВ. Чтобы собеседник вас услышал нужно напрягать голос или кричать. А теперь представьте, что вы с собеседником на разных сторонах оживленной автомагистрали находитесь. Тут даже крик не всегда слышен. А теперь разойдитесь на квартал друг от друга и разговаривать вообще станет невозможно. Зато если у каждого из вас есть мобильник, то расстояние уже не помеха, не так ли? Так вот эти "всякие дополнительные микросхемы" служат как раз для того, чтобы устройства могли "докричаться" друг до друга, несмотря на большое расстояние и наличие помех. Без их (драйверов линии) применения передать сигнал на значительные расстояние не получится.
Надеюсь, я все понятно, на доступных для вас аналогиях, пояснил?
Поверх интерфейса RS485 обычно используют протоколы с адресацией и фреймами (кадрами). Фрейм это законченное сообщение в котором каким-либо образом (спец символами и/или временными паузами) выделяется начало и конец сообщения. А для того, чтобы понять какому конкретно абоненту адресуется данное сообщение в нем содержится как минимум адрес получателя. Для контроля целостности сообщения его обычно дополняют контрольной суммой. Примеры протоколов, пригодных для применения в сетях RS485, вам указал XVR. Протоколы CAN все же больше подходят под соответствующий интерфейс CAN.

Устройство к ПК подключается одно или их несколько?
Устройство по собственной инициативе может передавать данные на ПК, или инициатором всегда выступает ПК?
Весьма прилично для RS485. Может понадобится витая пара для подсоединения и протокол с коррекцией ошибок (как минимум - с обнаружением)
Как насчет помех в окружающей среде? Нет ли там поблизости каких нибудь килоамперных импульсных токов? Какую надежность должна обеспечивать связь?

Вообще я проектирую для одного устройства (но на практике их должно быть n-ое количество). Передает оно по своей инициативе, а также и ПК может запросить информацию. Расстояние скорее всего будет метров 300-500. Помех не должно быть. Принцип работы: Имеются 2 аналоговых датчика температуры DS600, которые опрашивает МК Atmega16 (со встроенным АЦП), преобразует в цифровой код, переводит цифровой код в температуру и передает это значение на LCD FDCC0801A фирмы Fordata со встроенным контроллером – SPLC780D, сравнивает измеренную температуру с заданной, если она входит в заданный диапазон, то цикл повторяется, если меньше заданной, то формируется управляющий сигнал (напряжение) по ПИД-закону и подается через таймер ОСn (ШИМ) на исполнительный элемент. Также необходимо передавать значения текущей температуры на ПК оператору через интерфейс RS-485. А в случае нештатной ситуации также оповещать оператора через RS-485.

Сегодня я принес преподавателю кусок принципиалки, который выше, только с МК не PIC16F877, а Atmega16, а он сказал, ты что за чушь принес, говорит оставь только одну микросхему LTC485 (то что первая после МК), а с нее на разъем типа a, b, gnd. Это разве правильно?

Это уже "мультимастер" получается. Для которого сеть RS485 не совсем подходит.
Конечно правильно. Ваше устройство заканчивается разъемным соединением к которому подключается линия связи. И ни провода связи, ни вторая м/с LTC485, ни MAX232, ни компьютер, изображенный слева внизу, в состав вашего устройства не входят

'Не совсем' - это мягко сказано В RS485 сети должен быть арбитр, распределяющий кванты времени для обмена, если же и количество подключенных устройств заранее неизвестно, то это совсем чехол. Или делать сеть с поддержкой коллизий, как на аппаратном, так и на протокольном уровне. klin-2006, вам надо сначала разработать протокол взаимодействия устройств и ПК, остальное приложится

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

Нет, modbus для одного мастера. Т.е. все будет происходить под жестким управление ПК. Возможно это подойдет, ПК вполне может периодически опрашивать все подключенные устройства
по очереди. Вот только количество и адреса устройств должны быть известны на ПК, Plug & Play не получится

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



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


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

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

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


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

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

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

Я с ними не связан, но тоже согласен, что 'мультимастер здесь не нужен'
Осталось убедить в этом автора топика
Не может, протокол канального уровня должен обеспечить надежную доставку пакетов, а протокол уровня приложения сохранения недоставленных сообщений (в случае фатального отсуствия связи) где то. Но это гораздо сложнее, чем единственный мастер на ПК

+1000%
Про modbus тоже согласен на все 100%

По поводу PnP:

Получится, но в ограниченном объеме
'Все' - это сколько? Если их может быть 10-20 шт, то все ок. А если десятки тысяч, то 'все' ему будет сложно перебрать
Кроме того, каждое устройство должно иметь уникальный (и НЕБОЛЬШОЙ) адрес. PnP подразумевает - взял устройство из коробки, воткнул в сеть (без настроек) и оно заработало.
В принципе даже это можно реализовать при условии, что устройства будут первый раз включаться в сеть строго по очереди (по 1 штуке). Вариант с 'собрал сеть из чистых (только из коробки) устройств и она заработала' не получится

Не, устройств не много если по максимуму 50-100 шт. Я думаю modbus здесь будет уместен?

Да, вполне. Но учтите, что:

• Устройства перед тем как подключить в систему придется конфигурировать (как минимум прописать им адрес)
• ПК будет сама опрашивать все устройства по очереди. По собственному почину устройства не смогут ничего отправить в ПК

Если это устроит, то modbus вполне подходит

Если ссылаться на MODBUS (без расширений), то адрес задается байтовым полем, отсюда и максимальное количество устройств в сети.
Если ссылаться на RS485, то нагрузочная способность одного драйвера - 32 входа.


Еще как может и делает (потеря питания при обрыве кабеля).


Обычно устройство стартует со служебным адресом (например 0), пользователь отдельной программой которая работает со служебным диапазоном подключается по очереди к каждому устройству и в обязательном порядке конфигурирует его. (Рабочий адрес и уставки зависят от конкретного объекта который будет обслуживать это устройство). Очевидно, что уставка (допуск) например по температуре для печи будет отличаться от уставки (допуска) для жилого помещения, а устройства могут быть одинаковыми.

АРМ же работает со своим диапазоном рабочих адресов, обычно 1..253. (0, 254 - служебные, 255 - широковещательный адрес)