CAN шина и Linux

https://www.kernel.org/doc/Documentation/networking/can.txt

В последнем проекте поднял с нуля сеть между компом и кучей инфенионов через CAN. Меняю свои знания по CAN на знания по XBee. Если таковых знаний нет, то задавай вопросы по CAN, отвечу за так.

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

все манула в pdf жЫрные и подробные. ищи просто html-страницы с описанием.

В каком направлении копать по интеграции linux<-->CAN? (очень бы хотелось мануал с простенькими примерами)

Все зависит от того как ядро видит CAN-адаптер. У меня например это sysWorxx (usb-can). Когда втыкаешь, появляются два сетевых интерфейса (у меня двухканальный адаптер) can0 и can1. Дальше все как для сетевки:

/sbin/ip link set can0 type can bitrate 500000
/sbin/ifconfig can0 up

Потом просто открываешь сокет (можно тут в соседнем треде прикупить книжку про это: Продам книгу «UNIX разработка сетевых приложений») пишешь и читаешь как тебе угодно. Есть пара пакетов из которых можно надергать примеров кода:
can-tests
can-utils
там есть удобные утилсы для отладка, прослушка интерфейса на предмет всех пакетов, и отправка произвольного пакета.

Среды разработки/Дебагер

Чего? Вы с какой планеты?

В двух словах про CAN.
Это шина на которой сидят куча устройств. Обмен всегда широковещательный! Каждый пакет содержит дескриптор (11 или 29 бит) и от 0 до 8 байт данных (есть расширение до 64 байт что ли). Никакой адресации сегментации не предусмотрено. ОТправляешь пакет с дескриптором 0x0123. Он уходит в сеть. Все этот пакет принимают и хардварно подтверждают что приняли (аналогично шине i2c). Потом каждый решает что с этим пакетом делать: кто-то игнорирует, кто-то шлет ответный пакет и т.д.

Для userspace можно использовать это https://github.com/linux-can/can-utils

Минимальный тест:

To check if SocketCAN is supported:

# ifconfig -a
can0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          NOARP  MTU:16  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:60 Memory:e0008000-e0008fff 

To configure SocketCAN interface:

# ip link set can0 up type can bitrate 125000

To start SocketCAN interface:

# ifconfig can0 up

To receive messages on SocketCAN interface:

# candump can0

# cansend can0 500#1E.10.10

Ну и шину надо бы не забыть затерминировать вот так

Меняю свои знания по CAN на знания по XBee.

К сожалению знаний по XBee нет. Но если вы не против- в этом треде буду задавать вопросы.

все манула в pdf жЫрные и подробные. ищи просто html-страницы с описанием.

Я нашел еще вот этот ресурс (Необходимо разработать и по для МК, которые будут подключены к CAN)

Чего? Вы с какой планеты?

Возможно я вас ввел в заблуждение. Когда-то я активно занимался контроллерами PIC. И что бы постоянно не вливать прошивку в контроллер и не собирать на брэдборде тестовый стэнд я использовал Proteus, там рисовал принципиальную схему, добавлял нужный мне контроллер, в настройках добавлял прошивку, которая была скомпилирована в mplab и мог дебажить как мое устройство вцелом работает.

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

Вообще я за то, что бы перед покупкой физических устройств- все проверить виртуально.

Правильно ли я понимаю, что ifconfig -a покажет что-нибудь, если у меня уже будет подключен контроллер CAN (например через usb), а без него я ничего подобного не увижу?

CAN - говно.

Спека, которую в общем-то все и пользуют: http://www.kvaser.com/software/7330130980914/V1/can2spec.pdf

Юзабельных универсальных датчиков и девайсов подключаемых к CAN крайне мало. В основном это узкозаточенные под конкретную даже не марку, а вариант модели автомобиля девайсы. Также есть чуть более универсальныу промышленные датчики и исполнительные устройства с соответствующей невменяемой стоимостью.

В общем случае тебе придётся не только контроллер датчика или девайса с нуля разрабатывать, но и протокол общения по CAN.

Для мало-мальски интенсивного обмена информацией выбирай Ethernet.

Для подключения датчиков - 1wire например.

Для подключения исполнительных устройств - вообще RS485 в варианте DMX512 например.

Кубик умеет CAN искаропки. Но это не повод пользовать CAN вне задачи подключения к существующему интерфейсу конкретного автомобиля.

Да, пока там не появятся CAN-интерфейсы можно и не пробовать остальные команды

Кстати, «ip link set can0 ...» из busybox скорее всего работать не будет, тогда нужно будет ставить нормальный «ip», в OpenEmbedded например он включен в пакет «iproute2»

нисколько не агитирую за CAN

В общем случае тебе придётся не только контроллер датчика или девайса с нуля разрабатывать, но и протокол общения по CAN.

Вы так говорите как будто это что-то плохое. В любом случае придется придумывать правила по каким будет идти обмен (хоть CAN, хоть modbus). Так же придется делать минимальную обвязку (благо сейчас она дешева и доступна). Во многих МК can уже стоит, надо только припаять трансивер. Если по схемотехнике, то особой разницы с тем же rs485 не будет (там тоже трансивер нужен). Хотя аппаратное подтверждение приема это очень приятно.

Спека, которую в общем-то все и пользуют: http://www.kvaser.com/software/7330130980914/V1/can2spec.pdf

указал ее в шапке темы. Слишком громоздко.

выбирай Ethernet.

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

1wire

отличный протокол. Долго на нем сидел, но есть несколько ключевых недостатков:

• работа только мастер-слэйв
• малая скорость
• крайне малая надежность (если мне не изменяет память кроме crc там больше ничего нет)

Как уже писал выше, CAN выбрал по причинам черезвычайной надежности, универсальности и популярности.

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

Я нашел еще вот этот ресурс (Необходимо разработать и по для МК, которые будут подключены к CAN)

CAN там аппаратный или программная реализация? Если программная то мне кажется геморрой приличный будет. Проще уж тогда rs485.

я использовал Proteus

Я почти догадался про протеус, но преподнесено было как-то альтернативненько.

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

Не надо ничего эмулировать, лучше все паять и осциллографом (а лучше лог.анализатором смотреть).

Вообще я за то, что бы перед покупкой физических устройств- все проверить виртуально.

Вроде как логично, но для меня основанием расходов на железо является «теоретически должно работать». А дальше просто заставить это работать.

Есть свои плюсы и минусы

Использовать или нет — зависит от требований к проекту

https://ru.wikipedia.org/wiki/Controller_Area_Network

Преимущества и недостатки

Преимущества

• Возможность работы в режиме жёсткого реального времени.
• Простота реализации и минимальные затраты на использование.
• Высокая устойчивость к помехам.
• Арбитраж доступа к сети без потерь пропускной способности.
• Надёжный контроль ошибок передачи и приёма.
• Широкий диапазон скоростей работы.
• Большое распространение технологии, наличие широкого ассортимента продуктов от различных поставщиков.

Недостатки

• Небольшое количество данных, которое можно передать в одном пакете (до 8 байт).
• Большой размер служебных данных в пакете (по отношению к полезным данным).
• Отсутствие единого общепринятого стандарта на протокол высокого уровня, однако же, это и достоинство. Стандарт сети предоставляет широкие возможности для практически безошибочной передачи данных между узлами, оставляя разработчику возможность вложить в этот стандарт всё, что туда сможет поместиться. В этом отношении CAN подобен простому электрическому проводу. Туда можно «затолкать» любой поток информации, который сможет выдержать пропускная способность шины. Известны примеры передачи звука и изображения по шине CAN (Россия). Известен случай создания системы аварийной связи вдоль автодороги длиной несколько десятков километров (Германия). (В первом случае нужна была большая скорость передачи и небольшая длина линии, во втором случае — наоборот). Изготовители, как правило, не афишируют, как именно они используют полезные байты в пакете.

Для большинства других подобных интерфейсов гораздо проще найти готовые датчики и исполнительные устройства которые нужно только подключить к шине. Самые удобные в этом смысле - 1wire и I2C. Есть масса законченных девайсов, для подключения которых не требуется никаких лишних телодвижений. I2C - как бы межблочный интерфейс, поэтому топикстартеру, наверно, не подойдёт, а вот 1wire - вполне.

Даже для RS485 доступна куча готовых девайсов в виде приборов понимающих DMX512.

Если есть задача врубится в сеть автомобиля - то да, без CAN не обойтись. Если задача иная - то выбирать CAN только потому, что на том же кубике в Allwinner SoC уже есть CAN интерфейс - как минимум глупо.

Как уже писал выше, CAN выбрал по причинам черезвычайной надежности, универсальности и популярности.

Да не парьтесь, пойдет вам и CAN. Просто обычно с ним проблема только в том, что не везде есть аппаратные модули. Во всяких дешевых avr, stm его нет. А там где есть это automotive который до радиолюбителей обычно не доходит.

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

Да щаз. Нет никакого «широкого ассортимента». В этом-то и проблема.

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

Если для подключения датчика температуры к 1wire мне не нужно ничего, кроме как тупо прикрутить в нужном месте какой-нибудь DS18S20, то для CAN придётся тот же самый DS18S20 прикручивать к МК, ставить трансивер (производители МК как всегда поленились поставить трансивер прямо в МК) и писать софт для того, чтобы из 1wire транслировать данные в CAN.

Если есть задача врубится в сеть автомобиля

А кто сказал что автору нужно в автомобиль воткнуться?

Для большинства других подобных интерфейсов гораздо проще найти готовые датчики и исполнительные устройства

Да ладно, где мы видим у автор потребность в стандартных датчиках? Ясно же сказано:

не люблю arduino

Значит только хардкор!

А кто сказал что автору нужно в автомобиль воткнуться?

Я вроде ясно выразился - C CAN стоит связываться только если есть необходимость подключаться к сети автомобиля.

Да ладно, где мы видим у автор потребность в стандартных датчиках? Ясно же сказано:

А что, автору нужно интерферометры к шине подключать? Сомнительно. 99% что потребуются совершенно банальные кнопки, температура, давление и всё такое.

Значит только хардкор!

С каких это пор всякие PIC стали хардкором?

С каких это пор всякие PIC стали хардкором?

Я имею ввиду что никаких готовых шилдов с датчиками от ардуины :)

В остальном ваши доводы неубедительны. Про датчики мы тоже ничего не знаем, хорошо если это ds18xx в паре-десятков метров. А если хитрый датчик угла или лазерный гироскоп или еще какая хрень? А если в условиях мощных помех? А на расстоянии сотен метров. Без ТЗ давать советы по выбору интерфейсов, это конечно в стиле ЛОР-а, но может не усугублять?

Возможность работы в режиме жёсткого реального времени.

замечу, что «жёсткое реальное время» - понятие относительное.
очень много работали с CAN на прошлой работе. выявили некоторые недостатки: CAN расчитан на мелкие сообщения, сливать по нему данные/прошивки и т.д. очень медленно. когда на шине много девайсов, шина тормозит. ещё, помнится, был таракан: сброс контроллера на одном из девайсов вызывал сбои в потоке данных. тогда так и не поняли, из-за чего был такой эффект.

CAN расчитан на мелкие сообщения

показания датчиков, управление устройствами

когда на шине много девайсов, шина тормозит.

точней низкоприоритетные посылки отменяются. Так будет с любой последовательной шиной. Только в CAN есть аппаратный контроль всего этого, а в rs485 придется городить свой огород с таймслотами/опросом и т д.

брос контроллера на одном из девайсов вызывал сбои в потоке данных. тогда так и не поняли, из-за чего был такой эффект.

А вот это очень интересно, хотя многоканальный логанализатор, должен было враз показать где собака порылась.

Как расплывчато вы пишите, в стандарте описано 1М максимум и тут уж нечего говорить, что тормозит. Каждый решает сам при проектировании, что ему нужно, куча точек, скорость или длина линии. CAN примечателен реализацией модели OSI

Трансмиттер не потушили, ноги мк при старте не регламентированы в коде. Стандартные грабли, о которых начинаешь думать только когда тараканы поползли

Трансмиттер не потушили, ноги мк при старте не регламентированы в коде. Стандартные грабли, о которых начинаешь думать только когда тараканы поползли

Да это понятно, вариантов-то не много. Удивляет, что не поняли из-за чего.

Только в CAN есть аппаратный контроль всего этого, а в rs485 придется городить свой огород с таймслотами/опросом и т д.

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

А вот это очень интересно, хотя многоканальный логанализатор, должен было враз показать где собака порылась.

мы тогда копались довольно долго. девайс был самопальный USB-CAN, но на обычных контроллерах Atmel AT90CAN128, ничего такого особенного в реализации. и вроде всё должно было быть пучком, но когда один из девайсов передёргивался по питанию - на шине проходил какой-то странный сбой. выражалось это в том, что приходили «битые» пакеты на верхнем уровне. на физическом уровне данные просто терялись. хотя теоретически на CAN есть гарантия доставки пакета до всех девайсов на шине. для тестирования подключали 8 девайсов на шину и гнали данные, при этом передёргивали один из девайсов. ошибка повторялась. для верхнего уровня это не было критично (была проверка и перепосылка пакетов), но тем не менее этот баг мне запомнился.

Сейчас кстати появился CAN FD:

Developed by Bosch, CAN with Flexible Data-Rate (CAN FD) is an extension to the original CAN protocol as specified in ISO 11898-1 that responds to increased bandwidth requirements in automotive networks. CAN FD has the support of semiconductor chip manufacturers and end users alike, with Infineon, NXP, Daimler and GM among the companies behind the new standard. An overview:

A standard CAN network is limited to 1 MBit/s, with a maximum payload of 8 bytes per frame. CAN FD increases the effective data-rate by allowing longer data fields – up to 64 bytes per frame – without changing the CAN physical layer. CAN FD also retains normal CAN bus arbitration, increasing the bit-rate by switching to a shorter bit time only at the end of the arbitration process and returning to a longer bit time at the CRC Delimiter, before the receivers send their acknowledge bits. A realistic bandwidth gain of 3 to 8 times what’s possible in CAN will particularly benefit flashing applications

реально там до 1M не доходит, если девайсов на шине много.

но когда один из девайсов передёргивался по питанию

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

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

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

http://ww1.microchip.com/downloads/en/DeviceDoc/20005284A.pdf
От такое щупал, правда камушек не чиповский к нему.

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

yax123, Stanson,
Без подробностей и весьма абстрактно: Нужно собирать инфорацию с порядка 100-150 датчиков (включая, но не ограничиваясь: датчики положения, нажатия (не бинарные), температуры, инфракрасные датчики приближения, гироскопы; управлять ~80 сервоприводами с точностью до 2048 положений. Длинна шины не более 30 метров. Необходима работа в риалтайме + возможны помехи от сервоприводов

Ошибка проектирования, не? Раз не посчитали сразу, что не пролезете в канал и нужно несколько
По поводу ошибки на линии, держи еще финт ушами, помимо блокировочной емкости у питания трансивера, туда еще и десяток другой микроб нужно, если схема питается от импульсника и заточена под энергосбережение. Питание проваливается в момент начала работы шины и поганит фрэйм. Дождаться пока банка насасется и только потом будить передатчик. Либо разгонять импульсник, чтоб успевал подхватить питание, когда жрать начинам или увеличивать его массогабариты, чтоб хватало на пожрать железу.

смотря с какой частотой вы будете слать команды. сервопривод дёргать слишком часто не нужно, как правило. а вот данных может быть много. так что для 150 девайсов лучше прикинуть, сколько данных вы будете прокачивать, например, в секунду.

Краткий и сзажий, но информативный мануал

https://i.point.im/m/k/kostett/bc/1b/9745/informativnost-.png

в ТЗ нет времени реакции (или как там в ТАУ это называется). Нет объема посылок. Нет частоты посылок от преобразователей физических величин (температуру нет смысла мерить чаще чем в 30 сек, а вот гироскопы лучше на 10-100 герц). Вообще вам бы в матлабе модель вашей системы запилить, просто так делать в лоб смысла нет, шишек набьете.

80 сервоприводов

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

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

CAN - говно.

CAN - ништяк, а Linux говно - для CAN мало пригоден, потому что нужен реалтайм

Кубик умеет CAN искаропки

ты уверен ? чета я драйверов не наблюдаю

замечу, что «жёсткое реальное время» - понятие относительное.

Это да, для корабля например «жёсткое реальное время» может означать реакцию на событие в течении нескольких минут

Для automotive applications чаще всего что-то вроде 100ms цикла — событие в цикле n реакция в течении n+1. Для такого CANа вполне достаточно. Ну а на airbag все равно что-то специальное поставят

CAN - ништяк, а Linux говно - для CAN мало пригоден, потому что нужен реалтайм

Открой для себя AMP (Asymmetric Multi-Processing) и FPGA, например Xilinx Zynq

Это да, для корабля например «жёсткое реальное время» может означать реакцию на событие в течении нескольких минут

хватит бредить - мы не на корабле

http://www.ibm.com/developerworks/ru/library/l-real-time-linux/index.html

Все прально, на соседних и портим проваливая линию просевшими подтягами. Ладно забью, разговор какой-то странный.

airbag на can и болтается, а то и вовсе k-line, только отдельной шиной. Кое где встречал и все в одном, включая подухи, живет и здравствует, вся фишка в старшинстве девайсов, да и время реакции в автомобилестроении весьма большое.

ну, для совсем крутого риалтайма нужны микроконтроллеры. строго говоря, осей под риалтайм не бывает. обычно самые критические по скорости операции на делают на харде, а софт уже решает какие-то более медленные задачи.
Линюкс хоть и не риалтайм по определению, но для своих задач вполне хорош. не буду даже сравнивать с офтопиком и некоторыми другими системами. и в автоматизации Линюкс занимает далеко не последнее место. не зря автомобильные корпорации в Linux Foundation развивают его под свои нужды.

Оси под микроконтроллеры еще как бывают (:
Жесткий рилтайм на прерывания, совсем жесткий только хардварь, программно только мониторинг и медленное управление.

Фото робота могу скинуть на почту :)

Фото робота могу скинуть на почту :)

Дык он у вас на фото, загримированный правда под жалкого человечишка.
«Убить всех человекав! Слава робатам!»

Полноразмерный человекоподобный робот

Сходил по ссылке а там:

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

Ну вот на корабле «время, когда готовы результаты вычислений» может составлять несколько минут

Что-то не вижу противоречий, может объяснишь подробнее ?

Жесткий рилтайм на прерывания, совсем жесткий только хардварь, программно только мониторинг и медленное управление

Да, всякие кэши довели до того что какой-нибудь 8086 может оказаться более реалтаймовым чем современные Интел процессоры общего назначения если смотреть по пиковому времени реакции на прерывание

airbag на can и болтается, а то и вовсе k-line, только отдельной шиной. Кое где встречал и все в одном, включая подухи, живет и здравствует, вся фишка в старшинстве девайсов, да и время реакции в автомобилестроении весьма большое

Я думаю это все-таки фичи типа диагностики etc, сами сенсоры ускорения и механизм принятия решения на сработку или вмонтированы прямо в подушки или соединины чем-то побыстрее чем CAN, все-таки на скорости 250 км/ч машина проезжает 70 м/с а у CANа только пересылка сообщения на максимальном битрейте 1мбит займет не менее 47 микросекунд если верить калькулятору, а его еще надо сгенерировать и обработать