Скорее всего мы не понимаем друг друга. CAN это не только физический уровень. Это ещё и протоколы высокого уровня, вот здесь и возникают проблемы. Нет единого общепринятого стандарта. Функционал описан в ISO 11898. На его базе строятся конкретные протоколы, но даже в них производители автомобилей могут включать PIDы под свои нужды, не говоря уже о том, что они могут использовать свой собственный отраслевой протокол, который является их собственностью и они не обязаны его раскрывать. Вы предлагаете что бы производитель реализовал CAN шину в ГУ и отдебажил протоколы всех производителей для написания собственного софта ? Думаю ему нехватит и нескольких лет для реализации такого грандиозного плана ))

Выход есть. Либо реализовать CAN интерфейс на базе ELM327 и предустановить туже Torque. Либо дать пользователю самому выбрать адаптер и прогу. Не возможно построить систему удовлетворяющую всем запросам.

Я предлагаю что бы они сделали на уровне китайцев. У них почему то с этим проблем нет. Многие китайские 2DIN под марку (они и называются так for WV, for Toyota) отлично понимают базовый набор CAN пидов.

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

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

Я пока не пойму что вы вообще хотите сказать?

То вы не видите проблем с CAN:
Через 2 поста:
Вы можете сформулировать ваше предложение более конкретно?

Мое предложение простое и понятное:

Доступ к сниферу CAN это хорошо и прикольно.
Но базовый функционал работы должен быть реализован для всех основных марок.

Кстати интересный вопрос по поводу CAN.
У меня штатное ГУ подключено по CAN, впрочем как и все современное авто.
Так вот модель ГУ будет одна, а моделей авто тысячи. Как можно будет связать штатные функции авто (vehicle settings) с этим ГУ. Готов даже на шаманства, но главное чтобы это можно было реализовать.

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

К стати CAN/K_Line сниферы под Андроид существуют и желающие могут поотлавливать специфические PIDы на своих машинах. А для обычных пользователей есть готовые программы, работающие с достаточно большим количествам автомобилей.

"Вы можете сформулировать ваше предложение более конкретно? "
"Но базовый функционал работы должен быть реализован для всех основных марок."
Я говорю о том, что полной универсальности не будет. Или вы предлагаете запиливать ГУ под каждую конкретную машину ? А базовый функционал уже реализован в той же Torque и ELM327

Конечно производитель при желании может пойти и по стопам той же Чекинжин. Реализовать интерфей и потом годами допиливать туда конкретные марки машин. Только нужно ли это ?

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

))) Вот и я о том же ))) Дать народу базовый функционал. Иначе мы и к новому году не дождёмся выхода девайса.

В Torque и ELM327 реализована "диагностика".
Речь идет о сети "комфорт".

Почитайте, много полезного узнаете:
https://drive.google.com/folderview?...Ek&usp=sharing

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

Марок машин много, протоколов не так много, я привел в пример протокол VAG
Реализовать его, это порядка 50 популярных марок.
Так же у GM протокол "комфорта" одинаковый для большинства моделей.

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

На текущий момент сложилась практика когда CAN адаптер поставляется отдельно от продукта. Так делают почти все. Адаптер слушает CAN шину а на выходе выдает уже осмысленную информацию:
"Блок климата изменил температуру", "Нажата кнопка" и.т.п.

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

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

Хотя в примере Парктроник, Климат, MaxiDOT, Кнопки нужна шина комфорта а там уже более приемлемая скорость: 60 кбит/с. Но все равно представьте что у вас висит сервис который постоянно анализирует поток 60 кбит/с.
Ну и само собой этот сервис должен уметь послать команду системе о нажатой кнопке, показать картинку климат контроля и.т.п.


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