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

[klin-2006]

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

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

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

 

[klin-2006]

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

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

 

[rezident]

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

[klin-2006]

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

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

[XVR]

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

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

[klin-2006]

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

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

Сообщение отредактировал klin-2006 - Jun 3 2009, 14:28

[XVR]

А какой протокол вы бы посоветовали взять для rs485?

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

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

Без. В RS485 их просто некуда воткнуть, даже если бы захотелось

[klin-2006]

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

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

Сообщение отредактировал klin-2006 - Jun 3 2009, 15:15

[rezident]

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

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

[XVR]

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

Устройство к ПК подключается одно или их несколько?
Устройство по собственной инициативе может передавать данные на ПК, или инициатором всегда выступает ПК?

И расстояние 1000м.

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

[klin-2006]

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

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

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

Сообщение отредактировал klin-2006 - Jun 4 2009, 14:15

[rezident]

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

Это уже "мультимастер" получается. Для которого сеть RS485 не совсем подходит.

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

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

[XVR]

Это уже "мультимастер" получается. Для которого сеть RS485 не совсем подходит.

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

[klin-2006]

klin-2006, вам надо сначала разработать протокол взаимодействия устройств и ПК, остальное приложится

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

Сообщение отредактировал klin-2006 - Jun 4 2009, 15:49

[XVR]

протокол modbus не годится?

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

[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.

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

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

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

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

[XVR]

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

Я с ними не связан, но тоже согласен, что 'мультимастер здесь не нужен'
Осталось убедить в этом автора топика

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

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

Плюс ко всему мультимастер усложнит систему в разы, что пагубно отразится на ее надежности.

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

По поводу PnP:

Зачем знать адреса и количество? Прекрасно получится Plug&Play.

Получится, но в ограниченном объеме

ПК - делает опрос всех адресов, находит и идентифицирует все устройства в сети.

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

[klin-2006]

Я с ними не связан, но тоже согласен, что 'мультимастер здесь не нужен'
Осталось убедить в этом автора топика
'Все' - это сколько? Если их может быть 10-20 шт, то все ок. А если десятки тысяч, то 'все' ему будет сложно перебрать

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

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

 

[XVR]

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

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

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

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

[defunct]

'Все' - это сколько? Если их может быть 10-20 шт, то все ок. А если десятки тысяч, то 'все' ему будет сложно перебрать

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

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

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

Кроме того, каждое устройство должно иметь уникальный (и НЕБОЛЬШОЙ) адрес. PnP подразумевает - взял устройство из коробки, воткнул в сеть (без настроек) и оно заработало.

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

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