PIC pic18f258 CAN-протокол

А вот это не смотрел?

И да, колись, что сооружаешь?

Да, это первым делом и скачал. Но «ниасилил»: как ни настраивал контроллер, все равно, собака, ничего не выдает.

Сооружать - пока ничего не сооружаю, разрабатываю работу с протоколом на будущее (т.к. с RS-232 по-человечески не поработаешь - если хочешь дуплекс, вешай только одну железяку; если хочешь много железяк - забудь о дуплексе).

Ну код выкладывай свой что ли куда, или так и будем вокруг да около ходить? :)

Пжалста

Сооружать - пока ничего не сооружаю, разрабатываю работу с протоколом на будущее (т.к. с RS-232 по-человечески не поработаешь - если хочешь дуплекс, вешай только одну железяку; если хочешь много железяк - забудь о дуплексе).

485 интерфейс и вперёд. CAN вещь хорошая, но тяжёлая.

485 ничуть не лучше 232. Разве что расстояние побольше. А навешать на него кучу железок, да с дуплексом - фигвам.

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

CAN — полудуплекс rs-232 — дуплекс/полудуплекс rs-485 — полудуплекс rs-422 — дуплекс

с MAC для ethernet'а много недорогих контроллеров lpc (nxp производитель). Нужен будет ещё PHY (бывают тоже решения за 8-10 долларов). Доступно множество готовых принципиальных схем сопряжения PHY и контроллера с rj разъёмом, стеков tcp/ip и других протоколов, примеров запуска mac и др..

Морока будет только в программной отладке — надежной работы в риал-тайм режиме (если нужно жесткое время).

А вообще rs-485 это надежный стандарт, если сверхскорости не нужны, то можно сделать хорошую, надежную вещь.

> А вообще rs-485 это надежный стандарт, если сверхскорости не нужны, то можно сделать хорошую, надежную вещь.

RS-485 Барахло полное и мрак в дровах по обработке прерываний . Плохая аппаратная наращиваемость, громоздкая гальваническая изоляция, нет никогда 100% совместимости между программными реализациями драйверов.


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

далее, CAN может работать по линии с открытым коллектором на скорости 500 ... 700 кБит на расстоянии ~60 ... 70 метров.

ethernet - не для микроконтроллеров, нет нормальных (и не Linux) открытых сетевых стеков. И на отладке можно угробить много времени.

ps: работал с CAN девайсами: Intel i82C527, i87C196CА,Atmel ATMegaCAN128,Microchip MCP2510, FUJITSU MB90Fxxx MB91xxx CAN

CAN — полудуплекс

Полудуплекс, зато если несколько устройств одновременно что-то захотят отослать, коллизий, как у RS-232 или 485 не возникнет.

>RS-485 Барахло полное и мрак

Вообще-то вы путаете теплое с мягким ;-) rs485 - это только физический уровень, CAN - физический и канальный. Отсюда вся эта чушь что вы тут написали. Если сравнивать кратко - rs485 более быстрый (10 Mbit/s против 1 Mbit/s CAN), более дешевый в реализации но требует больше времени и усилий для реализации протоколов верхнего уровня. Типичное использование rs485 - мастер/подчиненный, типичное для CAN - мультимастер.

> Отсюда вся эта чушь что вы тут написали.

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

Ведь реально будет интересовать скорость ДАННЫХ , а не теоретическая пропускная способность между двумя точками.

Типичное использование rs485 - мастер/подчиненный

даже на 1 Mbit/s для rs485, и в исполнении на микроконтроллерах,
программные проблемы могут оттенить решаемые прикладные задачи.

Меня скорость передачи данных волнует меньше всего. Сгодится даже 1кБ/с. Меня волнует возможность беспроблемной работы без коллизий в полудуплексном или дуплексном режиме нескольких железяк, сидящих на одной шине.

Ну именно для этого и сделали CAN

Выбрось перделки микрочиповские и поставь железяки с Linux :-) тут давно VW постарался с socket can:
http://en.wikipedia.org/wiki/SocketCAN

ДОРОГО!

>ДОРОГО!

Скупой платит дважды. Как я понял у тебя что-то для местного использования - потратишь ты сегодня на 10 тыр больше, завтра сможешь нарастить функционал системы без лишний вложений и сделаешь это за день, а не будешь мозги ибсти себе и другим с поиском бесплатных тулзов и библиотек разной степени кривизны.

Скупой платит дважды.

Когда железяка делается на заказ, и заказчик готов платить - проблем нет. А вот когда начинаешь с экспериментального стенда, а потом переносишь все в свой прибор, на который деньги выбиваются по копейкам, между десятком контроллеров по 100р за штучку и десятком по 2т.р. за штучку есть очень большая разница.

Научись код писать сначала. Вызов функций в обработчиках прерываний - говнокод. Да и сам обработчик сомнителен.

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

Научись код писать сначала.

Научи.

Насчет пиков со встроенным эзернетом - уже посмотрел. Но пока на руках только CAN, и хочется попытаться с ним научиться работать.

> а не будешь мозги ибсти себе и другим с поиском бесплатных тулзов

Что-то мне подсказывает что ты не прав ))
Для начала ему придется еще раскошелится на железяку (этот минимум 30$) с CAN под Linux и раз 20 пересобрать ведро с налетом на подобные грабли. И сама платформа под Linux - минимум 30$.
Далее:
Общие размеры и потребление - больше на порядки.
Ремонтопригодность и повторяемость - где-то в районе мусорника.

>Вызов функций в обработчиках прерываний - говнокод.

Поясните?

Кстати, двухпортовый PCI-ный CAN-контроллер стоил около 15т.р. =)

Завел я его почти без проблем (ничего даже не пришлось править, лишь добавить insmod в /etc/rc.local).

> только розетку допаять.

- розетка не простая нужна там, а с фильтрами и трансформаторами.
- обязательный секас дровами протоколами. Оживить UDP ну как за счастье.
- сразу внешний свич для > 2 девайсов, больше шнурков для связи.
- это будет всегда больше потреблять и стоить.

> Кстати, двухпортовый PCI-ный CAN-контроллер стоил около 15т.р. =)

)) ну это индастриал
там любое барахло для PCI от 100 $ (

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

Какой, нафиг, индастриал? Обычный CAN-контроллер, для «домашних» компьютеров.

В данном случае может и пофиг, но обычно в мк используется гораздо больше источников прерываний. Вложености и приоритетов прерываний в пик18 тоже нет, один (два) вектора на все прерывания, потому обработка прерывания должна длиться минимальное количество времени. Обычно в обработчике ставиться флаг, и затем в основном цикле уже обрабатывается.

AdLink PCI 7841

Обычно в обработчике ставится флаг, и затем в основном цикле уже обрабатывается.

Так делать нельзя: а если у меня будет одно за другим два события, а основной цикл тем временем будет занят чем-то своим?

Ну тогда PeliCAN Philips на LPT порт, будет не дорого и сердито.

Розетка с трансформатором не является проблемой. Какие дрова у пик18 с эзернетом? Не болтайте ерундой. Стек tcp/ip от того же микрочипа вполне юзабелен, там есть и udp, и tcp и другие протоколы.

А если 3 пока работает обработчик? Как отработает тогда?

Я же говорю: для компьютера контроллер уже есть. А про LPT порт даже не говорите: вы давно видели мамки с LPT? USB->LPT рабочий достать почти невозможно.

> Какой, нафиг, индастриал?

Собственно, весь CAN - это индастриал от рождения.
А за 2-е гальванические развязки будут драть цены.

Обработчик плюет на прерывания (т.к. отключает их). И работает он достаточно быстро, так что такое вряд ли произойдет.

Собственно, весь CAN - это индастриал от рождения.

Это понятно. Но «промышленные» компьютеры сейчас никто не использует. Дешевле раз в несколько лет покупать обычный десктоп. Или неттоп, смотря что от компьютера нужно.

> вы давно видели мамки с LPT?

а что, проблемы найти внутренний LPT порт на мамке ?))

А внешний LPT :
http://hard.rozetka.com.ua/ru/products/details/32679/index.html

изображение устойчивое ))

>Что-то мне подсказывает что ты не прав ))

Тут надо смотреть - какие задачи стоят. Я бы например взял что-нибуть на arm cortex mX и не парился. Для них кучи примеров и библиотек от производителей есть, бесплатные и открытые ОСРВ, компиляторов вагон и тележка.

А внешний LPT : http://hard.rozetka.com.ua/ru/products/details/32679/index.html

старье

Ладно, хватит флудить. Помочь кто-нибудь может по теме?

> хватит флудить.

<вырезанно цензурой>, это как кота фашистом называть ...

Помочь кто-нибудь может по теме?

для этого нет никакой тут конкретности,
а посылать на официальные и бесплатные микрочиповские инструменты
и документацию считаю как лишним , ибо очевидно.

Дык в той документации черт ногу сломит. Вообще не понимаю, к чему такие обширные настройки, если «компьютерный» CAN имеет всего две настройки: уровень сигнала в шине и частоту, ну и всякие там настройки фильтрации...

> Дык в той документации черт ногу сломит.

Тут я внимательно посмотрел на свою ногу )

У мелкочипа отличные доки и в отличие от другой братии

Стандартные ошибки:
настройки портов
настройки тактовой синхронизации передающих модулей
игнорирование сообщений о ошибках в CAN.
ошибки монтажа железки
облом читать доки

В общем, взял я «мелкокристалловую» библиотечку для работы с CAN и начал ужимать (в ее оригинальном виде ею пользоваться невозможно: элементарная настройка порта и чтение/запись отъедают всю память контроллера, ни на что больше места не остается).

Все заработало. Некоторые функции из Microchip'овской библиотечки не работали на sdcc (возможно, из-за излишней оптимизации - не знаю). Буду собирать свою мини-библиотечку для работы с CAN.

> Вызов функций в обработчиках прерываний - говнокод.

Сникерсни, чувак. Это промышленный контролёр, а не линуксовое ядро.

> Обычно в обработчике ставиться флаг, и затем в основном цикле уже обрабатывается.

Это если есть, чего делать в основном цикле, кроме реакции на прерывания, ага.