Хорошо.
А в чём тогда проблема?
У Вас есть CAN-анализатор? Без него Вы вряд ли разберётесь, не думаю, что VW публикует стандарты по управлению устройствами.
Если разберётесь — то, насколько я понимаю принцип работы сети, каждое из устройств может отправить команду любому устройству.
Если не будет гонки команд (педаль говорит «Дроссель на 10%», а Ваше устройство — «Дроссель на 50%»), то проблем я не вижу, только некоторый объём работ.
Молодец в том, что код есть, собирается и уже модульный.
Без тестирования на машинке что могу сказать: вся табличка выводов процессора должна быть выведена в какие-нибудь заголовочники (даже так придётся вникать, что PD7 процессора — это его 123я нога в TQFP144, она выведена на 41й вывод макетки, тот соединён с 7-м аналоговым каналом, на котором висит MAP… уф).
На мой взгляд, в эот заголовочник нужно вывести абсолютно всё, включая serial console. (вспомню один проект, GRBL, правда, он для AVR — да земля ему будет нулём).
И да, меня несколько удивили шесть силовых выходов.
То ли у Вас распределённый впрыск и зажигание с трамблёром, то ли моновпрыск с нормальными свечными катушками, то ли это просто шесть ключей.
Вообще, если можно, расскажите, пожалуйста, про выбор схемотехнических решений — MCP3208, OP2340 и минимально необходимый для работы системы камень, в смысле mainMCU
Тоже верно, если тестировать на живой машине.
Я вот вспоминаю расположение ЭБУ на своих машинах и предпочёл бы работать на каком-нибудь отдельном движке ;)
Давайте лучше зафиксируем поддерживаемое железо и составим план улучшения core product.
Код на SF прикольный уже сформировался, Вы молодец, хотя мне не всё нравится :)
Я бы предложил создать в репозитории два каталога — current и releases, текущее содержание репозитория положить в releases (в смысле, старые версии), а в current складывать мало-мальски запускающийся рабочий код, чтобы упростить синхронизацию задач.
Примерно в том и проблема.
Лучше отточить алгоритмы, дать исходники и понимание принципов работы, а конкретный шилд под свой двигатель придётся всем делать с полным осознанием дела.
Я вообще за то, чтобы зафиксировать пару распространённых кейсов (мне приходит в голову переделка какого-нибудь VW Golf 2 на такой КСУД, благо подобная схема — разве что с распределённым впрыском — стоит на всех ВАЗах).
Во-первых, дроссель не однозначно определяет скорость движения. Дело даже не в передаче (хотя и в ней тоже), но и в профиле дороги, например.
Поэтому собирать нужно сразу и данные про скорость, и обороты двигателя.
Вообще проекты круиз-контроля есть в Сети. На Казусе, помнится, даже сделали (в противоположность «делали» :)). Добавить в прошивку предустановки не так сложно, если уже написан регулятор скорости.
Во-вторых, педаль газа электронная? Или есть тросик?
Интересно, MFA нет, a СAN есть. Это пассат четвёртый, что ли?
В начале 90-х в ЭБУ применялись исклюительно 8051 и на них до сих пор тысячи корчей ездят :)
Впрочем, ни в коем случае не повод в 2013 году начинать так.
С другой стороны, если есть понимание на программном уровне, можно оценить сложность алгоритма и портировать куда надо.
С третьей стороны, при цене STM8 примерно как Cortex M0 от них же, смысл мучаться?
А что с разъёмами?
Могу вспомнить разъёмы ЭБУ Bosch и Magneti Marelli со своих машин — они были заметно крупнее нарисованного Вами.
Но мне кажется, мы повесимся поддерживать каждое новое ЭБУ.
Для того, чтобы завести мотор, нужно обеспечить зажигание вовремя и впрыск топлива (если у нас не карбюратор, хехе). Подключить катушки, датчик положения коленвала, узнать, когда он выдаёт импульс, и выдать искру. А, РХХ дёрнуть при необходимости.
Остальные датчики можно довешивать потом, интеграция может занять чуть ли не больше времени, чем разработка. :)
На Лянче в косе на ЭБУ у меня шёл даже провод от кондиционера. :)
Глобально — с удовольствием помог бы, чем смог.
Конкретно сейчас я, наверное, буду бесполезен: за последние полтора года мытарств у меня в руках не было толком ни одного ДВС.
А код сейчас где? Есть и публичный репозиторий?
Мне в целом нравится модель Smoothie — открытый код без каких-либо гарантий переносимости, но и без привязки к железу. Благо для управления тяжёлой железкой по таблицам до 15-20 тыс. оборотов хватает даже атмеги, по формулам — где ж их ещё взять :)
Из кода МотоБК я бы хотел позаимствовать работу с таблицами (для Вашей системы, наверное, это может быть модулем) и вывод куда-нибудь на шину оборотов показаний прицепленных датчиков.
Ещё есть вкусная тема — задавать программно число, порядок и ориентацию цилиндров, тогда при правильных формулах можно будет прицепить такой софт на любой движок, работающий по циклу Отто.
Форсунками не управлял, а с зажиганием побороться получилось: www.moto.com.ua/forum.php?id=104999
Код в том проекте ужасный, но мне очень помогла понять принцип работы опережения зажигания табличка (экселевская, кажется) для расчёта задержек.
Удачи с проектом :) Постарайтесь от написания специфичных костылей перейти к созданию универсального кода, с подгрузкой настроек.
Успешные примеры есть, правда, в других областях (я про MultiWIi для коптеров и smoothie для управления CNC-станками).
А я согласен и с тем, что мир меняется, и с Вами.
Причем меняется довольно интересно. Появляются специальные люди, которые ищут тонкости в сложившихся условиях, и начинают генерировать минимально приемлемый по качеству продукт за полную стоимость. Благодаря снижению качество достигается ускорение процессе и, как следствие, повышение оборота такого бизнеса. Следующим шагом такие игроки, благодаря более высокой рентабельности, начинают теснить старых.
На примерах — литературных артелей вида «Донцова + литературные негры» публикуется больше, чем серьёзных, вдумчивых писателей, SEO вытесняет качественный копирайтинг, да что там, Ашан вытесняет небольшие магазинчики, и в Ашане колбаса из картона, судя по объёму на витринах, более популярна, чем более качественная.
Не берусь судить о причинах таких явлений (просто сказать «пипл хавает же» мало, нужно учитывать всю статистику: возможно, для значительной доли людей колбаса из картона — хоть какое-то мясо, которого не было у них раньше), но тенденция до сих пор идёт в сторону укрупнения сущностей и «оптимизации» процессов.
А в чём тогда проблема?
У Вас есть CAN-анализатор? Без него Вы вряд ли разберётесь, не думаю, что VW публикует стандарты по управлению устройствами.
Если разберётесь — то, насколько я понимаю принцип работы сети, каждое из устройств может отправить команду любому устройству.
Если не будет гонки команд (педаль говорит «Дроссель на 10%», а Ваше устройство — «Дроссель на 50%»), то проблем я не вижу, только некоторый объём работ.
Без тестирования на машинке что могу сказать: вся табличка выводов процессора должна быть выведена в какие-нибудь заголовочники (даже так придётся вникать, что PD7 процессора — это его 123я нога в TQFP144, она выведена на 41й вывод макетки, тот соединён с 7-м аналоговым каналом, на котором висит MAP… уф).
На мой взгляд, в эот заголовочник нужно вывести абсолютно всё, включая serial console. (вспомню один проект, GRBL, правда, он для AVR — да земля ему будет нулём).
И да, меня несколько удивили шесть силовых выходов.
То ли у Вас распределённый впрыск и зажигание с трамблёром, то ли моновпрыск с нормальными свечными катушками, то ли это просто шесть ключей.
Вообще, если можно, расскажите, пожалуйста, про выбор схемотехнических решений — MCP3208, OP2340 и минимально необходимый для работы системы камень, в смысле mainMCU
Я вот вспоминаю расположение ЭБУ на своих машинах и предпочёл бы работать на каком-нибудь отдельном движке ;)
Хотя… После BOSCHа на японцах…
Мне ближе (привычнее ;)) примерно такие вот динозавры: images.thesamba.com/vw/gallery/pix/724709.jpg
Давайте лучше зафиксируем поддерживаемое железо и составим план улучшения core product.
Код на SF прикольный уже сформировался, Вы молодец, хотя мне не всё нравится :)
Я бы предложил создать в репозитории два каталога — current и releases, текущее содержание репозитория положить в releases (в смысле, старые версии), а в current складывать мало-мальски запускающийся рабочий код, чтобы упростить синхронизацию задач.
Лучше отточить алгоритмы, дать исходники и понимание принципов работы, а конкретный шилд под свой двигатель придётся всем делать с полным осознанием дела.
Я вообще за то, чтобы зафиксировать пару распространённых кейсов (мне приходит в голову переделка какого-нибудь VW Golf 2 на такой КСУД, благо подобная схема — разве что с распределённым впрыском — стоит на всех ВАЗах).
Союз союзом, а экономическое пространство другое.
Поэтому собирать нужно сразу и данные про скорость, и обороты двигателя.
Вообще проекты круиз-контроля есть в Сети. На Казусе, помнится, даже сделали (в противоположность «делали» :)). Добавить в прошивку предустановки не так сложно, если уже написан регулятор скорости.
Во-вторых, педаль газа электронная? Или есть тросик?
Интересно, MFA нет, a СAN есть. Это пассат четвёртый, что ли?
Впрочем, ни в коем случае не повод в 2013 году начинать так.
С другой стороны, если есть понимание на программном уровне, можно оценить сложность алгоритма и портировать куда надо.
С третьей стороны, при цене STM8 примерно как Cortex M0 от них же, смысл мучаться?
А что с разъёмами?
Могу вспомнить разъёмы ЭБУ Bosch и Magneti Marelli со своих машин — они были заметно крупнее нарисованного Вами.
Но мне кажется, мы повесимся поддерживать каждое новое ЭБУ.
Для того, чтобы завести мотор, нужно обеспечить зажигание вовремя и впрыск топлива (если у нас не карбюратор, хехе). Подключить катушки, датчик положения коленвала, узнать, когда он выдаёт импульс, и выдать искру. А, РХХ дёрнуть при необходимости.
Остальные датчики можно довешивать потом, интеграция может занять чуть ли не больше времени, чем разработка. :)
На Лянче в косе на ЭБУ у меня шёл даже провод от кондиционера. :)
Конкретно сейчас я, наверное, буду бесполезен: за последние полтора года мытарств у меня в руках не было толком ни одного ДВС.
А код сейчас где? Есть и публичный репозиторий?
Мне в целом нравится модель Smoothie — открытый код без каких-либо гарантий переносимости, но и без привязки к железу. Благо для управления тяжёлой железкой по таблицам до 15-20 тыс. оборотов хватает даже атмеги, по формулам — где ж их ещё взять :)
Из кода МотоБК я бы хотел позаимствовать работу с таблицами (для Вашей системы, наверное, это может быть модулем) и вывод куда-нибудь на шину оборотов показаний прицепленных датчиков.
Ещё есть вкусная тема — задавать программно число, порядок и ориентацию цилиндров, тогда при правильных формулах можно будет прицепить такой софт на любой движок, работающий по циклу Отто.
А рисовали таблицей или графикой?
Код в том проекте ужасный, но мне очень помогла понять принцип работы опережения зажигания табличка (экселевская, кажется) для расчёта задержек.
Удачи с проектом :) Постарайтесь от написания специфичных костылей перейти к созданию универсального кода, с подгрузкой настроек.
Успешные примеры есть, правда, в других областях (я про MultiWIi для коптеров и smoothie для управления CNC-станками).
Причем меняется довольно интересно. Появляются специальные люди, которые ищут тонкости в сложившихся условиях, и начинают генерировать минимально приемлемый по качеству продукт за полную стоимость. Благодаря снижению качество достигается ускорение процессе и, как следствие, повышение оборота такого бизнеса. Следующим шагом такие игроки, благодаря более высокой рентабельности, начинают теснить старых.
На примерах — литературных артелей вида «Донцова + литературные негры» публикуется больше, чем серьёзных, вдумчивых писателей, SEO вытесняет качественный копирайтинг, да что там, Ашан вытесняет небольшие магазинчики, и в Ашане колбаса из картона, судя по объёму на витринах, более популярна, чем более качественная.
Не берусь судить о причинах таких явлений (просто сказать «пипл хавает же» мало, нужно учитывать всю статистику: возможно, для значительной доли людей колбаса из картона — хоть какое-то мясо, которого не было у них раньше), но тенденция до сих пор идёт в сторону укрупнения сущностей и «оптимизации» процессов.
В этом и весь challenge — что в итоге будет в программе и сверх неё.