RS-232<->CAN адаптер

[Bar_boss]

Я от тоже не понимаю - нахрена контроллер? Если он как прокладка между трансивером САN и портом выполняет некие действия, то поясните, какие именно?

[kison]

Я от тоже не понимаю - нахрена контроллер? Если он как прокладка между трансивером САN и портом выполняет некие действия, то поясните, какие именно?

Что подразумевается под "трансивер CAN"? Если это mcp2515 или sja1000 то контроллер действительно не нужен. Если драйвер физ линии типа PCA82C250 то без контроллера шины не обойтись.

[Bar_boss]

kison спасибо за ответ. Честно говоря, особо не вникал в суть дела, но хотелось бы разобраться. Нашёл схемку (прикрепляю), там MAX232 - ну это понятно, PIC18F2680 и "трансивер CAN" MCP2551. Это, как я понимаю, аналог PCA82C250 или как Вы правильно его назвали драйвер физ линии. Получается, что эта микросхема выполняет такую же функцию со стороны линии CAN, как скажем например MAX232 со стороны СОМ порта - т.е. простое согласование? А сам протокол CAN формируется именно в пике?
На mcp2515 и sja1000 даташиты скачал, буду разбираться. Может подскажете практическую схему на этих чипах?

Прикрепленный файл: 4154095.pdf

[kison]

Получается, что эта микросхема выполняет такую же функцию со стороны линии CAN, как скажем например MAX232 со стороны СОМ порта - т.е. простое согласование? А сам протокол CAN формируется именно в пике?

Да, поддержка протокола прямо в пике.

На mcp2515 и sja1000 даташиты скачал, буду разбираться. Может подскажете практическую схему на этих чипах?

Практическая схема приведена прямо в даташите. На SJA1000 не слишком смотрите, я ее применял лет 8 назад, по нынешним временам она устарела. А так основной ньюанс это требуется или нет гальваническая развязка. Вообще по нынешним временам внешний контроллер CAN не слишком хорошее решение. Сейчас довольно распостранены встроенные блоки CAN внутри микроконтроллеров - и у Микрочипа и у Атмела и у NXP и т.д. Ваш пример с PIC18F2680 и драйвером шины вполне жизнеспособен. Правда развязку я бы все же добавил - компъютер штука недешевая, а CAN все же в основном промышленный интерфейс. Из личного опыта - мне прямо на шину на корабле подключили 220В. Электрик немного ошибся. Выгорели драйвер и DC/Dc, все остальное благодаря развязке осталось целым. Даже оптроны 6n137.

Прикрепленный файл: 4154095.pdf

[Bar_boss]

Сейчас довольно распостранены встроенные блоки CAN внутри микроконтроллеров - и у Микрочипа и у Атмела и у NXP и т.д. Ваш пример с PIC18F2680 и драйвером шины вполне жизнеспособен. Правда развязку я бы все же добавил - компъютер штука недешевая, а CAN все же в основном промышленный интерфейс. .

Понимаете, была у меня мысль попробовать собрать тот девайс, на который приводил ссылку выше. Там расписаны исходники на Асме, однако попытки скоплировать MPASMWIN-ом hex файл так и не увенчались успехом.
Видимо, проще будет купить готовое устройство, чем только ради одного девайса изучать структуру модуля CAN в пике
Большое Вам спасибо за ответы!

Прикрепленный файл: 4154095.pdf

[kison]

Понимаете, была у меня мысль попробовать собрать тот девайс, на который приводил ссылку выше. Там расписаны исходники на Асме, однако попытки скоплировать MPASMWIN-ом hex файл так и не увенчались успехом.
Видимо, проще будет купить готовое устройство, чем только ради одного девайса изучать структуру модуля CAN в пике
Большое Вам спасибо за ответы!

Купить всегда проще. Но учтите - штука недешевая. Я бы потратил пару дней на разбирательство с исходником. Тем более что здесь на форуме есть люди, которые наверняка смогут помочь. С контроллерами от Микрочипа много кто работает.

Прикрепленный файл: 4154095.pdf

[Bar_boss]

Что ж, может Вы и правы, тем более что опыт работы с пиками имеется. Попрбую как-нибудь повозится с исходниками. И если кто собирал уже рассмотренный девайс (DOMOCAN, ссылку на него я приводил), поделитесь опытом. А пока начну "курить" даташит на 18F2680

[dosdos622]

Может кто встречал софтину CAN-generator что бы отправлять пакеты в линию?
А для полного счастья если бы ещё и слушать линию могла для последующей отправки.

[Someone]

увеличина надежность, упрощен сам и скорость повыше.

Ой, насмешил. Почти всё наоборот. Физически кан более подвержен помехам, более требователен к качеству кабеля. Надёжность выше только относительно - протокол гарантирует доставку пакета, но не гарантирует время его доставки. И в условиях сильных помех, при неправильно подключенном экране кабеля один пакет может полчаса и больше долбиться в линию, подвешивая её. Про сложность выше говорили, арбитраж, мультимастерность и т.п. А про скорость я вообще молчу. Хотя конечно есть и скоростные версии кан, но то отдельный случай. ))) собственно, кому не интересно вникать в спецификации и стандарты, вот обобщение: http://www.triz-cable.ru/about/vse_n...or_not_to_can/

[Hann]

Может мне кто идею кинет?... Года два назад делали проект со связкой mcp2515+mcp2551. В сети было 9 CAN узлов, суммарная протяженность линии - метров 100. Работает до сих пор без проблем. Причем, тестовую проверку работы шины делал на бухте витой пары - 305 метров. Все ок. Сейчас делаю другой проект, та же связка mcp, прошивка микроконтроллера та же. Но шина работает макс на 20-30 см. При увеличении длины линии сразу из mcp2515 начинают сыпаться ошибки приема/передачи... В схемотехнике есть одно отличие - в текущем проекте отсутствуют оптроны. Но по логике их отсутствие не должно ухудшать ситуацию? В общем, я в тупике. Две недели не могу сдвинуться с мертвой точки