Comments 57
Отмечу, что для профессиональной разработки с использованием CAN стоит присмотреться к соответствующим продуктам, а не разрабатывать самостоятельно.
Например я использую USB-to-CAN Адаптер от Ixxat. Есть аналогичные от Vector, Марафон.
Во всех случаях такой адаптер поставляется с софтом, который обычно может гораздо больше, чем тот, что идет с различными no-name снифферами или самостоятельно разработанный. Также с адаптером идет отличный API для использования в любом софте.
Ну и естественно там нет проблем с производительностью или гальванической развязкой, если надо.
Самый дешёвый со своим API был от PCAN в своё время. :)
Всё никак не спрошу — а вы в итоге в automotive перешли? Или это игры с CANopen? :)
Кстати, вопрос: а сколько упомянутый адаптер от IXXAT стоит? Думаю, где-то 200-300 €?
Вы — молодец! Просто здорово! :)
itelma — блин, ну вот такого народ ждёт, а не стотысячную статью о миллионах строк и линуксе в мультимедиа… :/
Да, если есть возможность, то наиболее наглядной будет "комбинация приборов".
Можно попробовать, к примеру, кондиционерный блок или мультимедиаблок.
Ой как вовремя вы нашлись!
- Есть некий софт, который зовут readlogs. Древний, зато в нем в виде текстовых файлов лежат расшифровки pid и формул к ним.
- Ещё не придумал, но я вас в покое не оставлю :)
P.S. пытался вчера расковырять журнал opendiag с помощью этих pid, но времени пока не хватило.
И да, читал м86 от весты. Очень похоже на м74 can.
Посмотрите мои посты — может, чего накопаете. :)
Эх, может, наконец, дойдут на каникулах руки до статьи. :))))
Но, с другой стороны, вот вам подробности интересны… :)
Кстати, а что интересно?
Вот данная статья — про то, как человек наблюдает за CAN-шиной, а также объясняет что же такое ELM327 она мне была как бальзам на душу потому что в двух словах рассказано то, что размазано тонким слоем по половине рунета.
То есть мои исследования носят исключительно прикладной характер для борьбы с некоторыми неприятными повадками автомобиля, и данная статья дала очень неплохое направление в какую сторону копать дальше.
Что бы я от вас хотел узнать — не могу сказать, любой automotive будет интересен. Понимаете, я лет 15 не лез в автомобили, и только буквально вчера узнал про моментную модель управления двигателем, например. От того лично мне интересно всё, что появилось после bosch mp 7.0, в чём его ключевое отличие, и, главное, зачем :)
Тогда вам надо больше инфы по гибридам — там и двигатель по моменту, и электродвигатель во многих режимах. ;)
Постараюсь кой-чего поискать, как на работу прийду (у меня, сейчас только 08:02 утра :)
Кстати, а у вас с языками на чтение доков как? :)
всё, что появилось после bosch mp 7.0, в чём его ключевое отличие, и, главное, зачем :)
Вряд-ли вы эту инфу снимите с CANа. Да и в открытом доступе ее не будет.
kolu4iy Lingvo прав — тут смотря как глубоко вы хотите закопаться
в общем случае прошивок с исходными кодами в инете не найдете — может, даркнет, но тут я вообще не в курсе :)
Смотрите: из-за особенностей CAN-стандарта чем у телеграммы меньший номер, тем более высокий приоритет она будет иметь.
Соответственно, самые важные и критичные сигналы будут в телеграммах с маленькими номерами. Что вы и обнаружили для MCU.
Пятисотые телеграммы — то, скорее всего, телеграммы для системы кондиционирования, вентиляторов и пр.
Примерно там же относительно низко будут телеграммы стеклоподъёмников.
А под "двигательными телеграммами" должны быть телеграммы ABS, иммобалайзера и пр.
0x160 — педаль газа, дроссель
0x180 — обороты мотора, некоторые параметры по мотору
0x280 — приборы, скорость
0x481 — двери, световые приборы, подогревы
0x551 — приборы
0x555 — климат-контроль
0x560 — АКП
АБС точно не помню, кажется в районе 0x35x.
Еще, чтобы легче было находить пакеты можно строить графики по каждому ID, жмешь газ и видишь, на каком ID график полез вверх — это обороты коленвала.
Это сейчас программа, де-факто ставшая стандартом в разработке/отладке/тестировании сетей автомобиля. Стоит очень недёшево. :)
Вот, к примеру:
youtu.be/T4e5HQG2Vxk
Да, и поэтому я бы предложил — софт отдельно, железо отдельно. Если вы сделаете так, что ваш софт будет работать с распространенными CAN-адаптерами, а не только вашим — то это наверняка бы увеличило полезность вашего труда.
Чисто в качестве идеи
Вы, простите, готовы купить для автора "распространённые адаптеры"? Или предлагаете заниматься отладкой по переписке?
Ну на то они и "распространённые адаптеры", что имеются у многих. Например у меня и мог бы спокойно отладить его софт со своим железом у меня.
При том эти "распространённые адаптеры" сопровождаются дровами и документацией, так что их интеграция и отладка может занять гораздо меньше времени, чем даже возня с тем же ардуиновским вариантом.
Ну так отлаживайте, пожалуйста :-)
Там "протокол" в отдельный модуль выделен. В принципе, ничто не мешает его подменить.
Я вот свой велосипед пилю на эту же тему (правда, сейчас забросил...).
И вот совершенно непонятно, откуда у меня должно возникнуть желание поддерживать железо, которое я никогда не видел… Мотивация "может быть, кто-нибудь когда-нибудь будет использовать" какая-то слабая.
вы зря на lingvo так — у него действительно самые распространённое железо, которым пользуется большинство в немецком и европейском автостроении
можно всякого полезного из такой совместной работы сделать :)
Или лучше универсальный какой-то адаптер CAN-to-WiFi (или CAN-to-Bluetooth) посоветуйте, минимально с пайкой чтобы возиться.
CAN sniffer