Проблем вагон. Интегральный ДПДЗ- не просто потенциометр. а имс на эффекте Холла. может она будет работать от 3.3 а может нет - производитель заявляет ей 5 т.е с хорошей долей ДПДЗ пролетели!
ДАД и вообще любые датчики давления - только 5 и никак по другому.
частотный расходомер - 12в + ОК а HFMы опять же только 5!
короче без 5 никуда.



Только вот это не тот "круг".

Потом я чего то не понял - а ООП тенденция это типа только сейчас, что ли модно стало?!
Впрыск идет единично с начала 80-х а массово с начала 90-х.. И при всем прогрессе в индустрии в методиках написания кода там изменений плакал кот. В общем случае где то с asm на С просто перешли и очень специфичную RTOS прикрутили отдав ей менеджмент времени и событий и аппаратную абстракцию... а все остальное только в моделях - и вот в них уже такой скачок произошел как из каменного века в космос, программерам там и делать нечего... Сейчас у современной системы функциональное описание 2500 А4 листов мелкого текста с диаграммами - год уйдет просто на то чтоб его более менее понимать.

Да, про 5 вольт я уже осознал - без 5ти вольт никуда, 3.3 полностью не сделать, а делать частично очень противоречиво.

Меня радует, что есть 5ти вольтовый чип, на который мои исходники лягут сразу же - тот самый MPC5634M. Но этот вопрос не горит, сейчас stm32f4 важен тем, что он сильно доступнее - и очень ценно собрать критическую массу разработчиков под одной крышей. Так что сейчас у нас будет однозначно stm32f4, а потом - подумаем потом.

О! Наконец понял откуда ноги растут.
Есть такой эпический проект MegaSquirt
И похоже он не дает покоя огромному количеству кулибиных по всем автосервисам земного шара.
А самые шустрые не прочь и повторить успех на той же ниве.

Этакий проект "ардуино" среди авторемонтников.

Андрей, отсюда такая нелюбовь к Motorolla/Freescale ?

AlexandrY, я так понимаю у них просто любовь к арм и вера в то, что можно безболезненно переносить код при смене операционок и железа.

AlexandrY, пока Андрей спит.
Конечно же эпический проект известен, но главное отличие - открытость и ориентированность, всвязи с этим на простой код. От этого все ноги и растут. Ну и доступность, конечно же, должна быть. Железо должно быть дешевым, а код при этом простым. Конкретно к какой-то железяке любви нет. Если есть дешевая, мощная и доступная железяка - любовь может переключиться на нее. Запросто.

Да нет же, вы неправильно меня поняли - я с интересом смотрю на MPC5634M
Вот только TRK-MPC5634M не продаётся в любом ларьке как stm32f4discovery и стоит в шесть раз больше - $15 против $99. Я понимаю, что там субсидии и так далее - но я за полтора года сжёг уже три платы. Мне дешевле их жечь по $15, чем по $99.

Ну и я не совсем кулибин в автосервисе. Я самую малость программист финансов

вот об этом по подробнее - что с ними происходит и почему?

С ними происхожу я. Первые две - год назад я пробовал подавать 5в на АЦП. Последняя - отключил БП от АКБ но оставил USB подключение - оно начало питать всю машину через USB и плата не осилила. Короче, я программист всё-таки в первую очередь.


Это не вера, это моё профессиональное мнение. Если логика правильно изолирована от железа - то ей ну совсем всё равно. У меня некоторые файлы тестируются сборкой и запуском на windows/linux - они-то не знаю, что железо немного другое

А как же eTPU?
У Freescale библиотеки электронного впрыска для Qorivva сделаны исключительно на API eTPU. И как вы такой код перенесете?

Но eTPU можно заменить дополнительным микроконтроллером. Вот и приходим опять к мультипроцессорности.

RTOS MQX на сегодня единственная RTOS доступная на Cortex-M4 предоставляюшая сервис межпроцессорных прозрачных коммуникаций.
А не за горами Kinetis X с 1 МБат RAM-а на борту.

И зачем вообще конкурировать с MegaSquirt?
Не проще ли к нему присоединиться со своей программно-аппаратной платформой?

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

Плюс лицензия. Так что получается - чтоб что-то сделать немного по-другому, нужно всё сделать заново.


eTPU это закрытый шайтан - к нему по слухам компилятор стоит пятизначную сумму? В этой реальности eTPU для меня пока не существует, я не планирую завязыватсья на закрытый шайтан. Из-за eTPU уже сдулся другой проект открытой ЭБУ - товарищи на радостях чтения маркетинкомых материалов сделали много чего, а на этапе тестов их ждал большой сюрприз - прошивка eTPU требовала конкретную конфигурацию триггера (60-2) и плюс была жутко капризна к качеству сигнала. см. http://open5xxxecu.org/

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

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

Это называется HAL - hardware abstract layer, он должен уже быть. в выбранной нами rtos он есть. в другой ОС, если будет портирование, он тоже должен быть.

Да, огромный кусок работы - но чужой работы

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

В нормальной версии не будет discovery платы, так что проблемы не будет целиком. А вот до финальной версии кстати да, нужно мне будет выяснить, как от этого защититься.

А что же у вас тогда в директории hw_layer, как не собственный HAL?
Просто название HAL ни о чем не говорит.
Там могут быть просто примитивные функции для определенных шаблонных операций с каким-то неполным набором периферии как в chibios,
а может быть высокоуровневая абстракция файлового ввода/вывода как в MQX.
Но в любом случае этого всегда не хватает. Всю периферию и многие ее режимы HAL не охватывает.
Всегда нужно отходить от HAL и работать с периферией напрямую. И все это делают. А потом начинаются конфликты с HAL.
Вот в RusEFI вижу откуда-то взятые тексты работы с внутренней FLASH. Явно были не в контексте RTOS там где их взяли и такие упрощеные, что я бы не рисковал ими воспользоваться.








Ну как простой.
В коде RusEFI комментарии наверно являются дурным тоном, да?
Никакой Doxygen не поможет если нет комментрариев. И какой толк выкладывать его отчет с голыми именами?
И как может быть у эффективной EFI простой код? На какую аудиторию вы рассчитываете?

К железке вы наверно все таки привязаны, а именно к платформам поддерживаемым chibios и его HAL.
Мне видится это вашим самым слабым местом.

директория hw_layer - это не HAL, она напрямую с железом (с исключеним флеша) не работает.


Я не идеален, времени на всё не хватает - вы могли заметить, я тут как раз помощи прошу
Какие-то комментарии есть, но давайте вместе напишем больше. Какой сегодня файл будем комментировать?

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

Но хуже, что автомобильные движки пока не моя тема. И входить в нее нужно не менеее месяца, я так представляю.
Я вам что нибудь предложу, может попозже. Когда сделаю свой модуль на Kinetis.

Мне казалось, что они как раз все единообразно отформатированны - или я ошибаюсь?


Например как?

Я жутко извиняюсь, но вы в какой IDE это всё открываете? А то что-то я в IAR быстро удобной навигации не нашёл - но я особо не искал, мне не нужно было. Будет ли вариантом Eclipse?

Вы их форматируете в стиле GNU.
А у меня свой стиль похожий на Allman style.

Я использую SlickEdit и Understand for C.
Eclipse тоже вариант, но SlickEdit быстрее работает.

IAR IDE только для компиляции.

А если не секрет, как Вы ето сделали ?
Artistic Style ?

Слабое место не в платформах а в том, что она не OSEK.

OSEK ето круто. А если вспомнить, что в формуле автомобильный двигатель уже крутится 15000 RPM и вроде Honda говорила, что хочется 30, то время реакции на событие с точностью 1 градус составляет 5 мкс. И еще надо детонацию анализировать. Говорю Вам, берите DaVinci... не пожалеете)))
А сколько тактов интересно длится переключение потока и обработка прерывания у RTOS MQX и Chibios ?

Потому и надо брать 32-х битный Cortex-M4 не меньше 150 МГц чтобы обеспечить engine synchronous (synchronous) and time synchronous (asynchronous) task scheduling.
Просто грубой силой.



Кнопка Beautify.




Скорость переключения задач зависит от типа объекта синхронизации которым вы остановили задачу.
У MQX варьируется от 2 до 0.5 мкс на 120 МГц ядре Cortex-M4 и внутренней RAM.
Автор Chibios заявляет где-то об 1 мкс, но не говорит как точно он переключал задачи и не дает исходников своих тестов.

Никакой силы маленького арма с жалкими 150 Мгц не хватит на анализ детонации по честному (Фурье, etc). В дешевом хундай солярисе двигатель крутится штатно до 7000 Rpm. Насколько я понимаю достаточно одного неудачного такта, чтобы двигатель сломать. Интересно как ета задача решается на mcs51 ? Видимо используются какие-то ну очень хитрые алгоритмы....
Мда, почитал. Если для анализа детонации использовать стандартный датчик, очевидно и 51 достаточно ("Датчик улавливает звонкие звуки")

Даже если 10000 Rpm. Получается 6 мс цикл. Это море времени для Cortex.

с использованием стандартного датчика детонации - да, вольготно. Если по 3000 тактов на sprintf не тратить конечно....

но тогда действительно подходит и mcs51)))

Москва не сразу строилась. Если хоть что-то делать, то можно прибливаться к чему угодно. Если не делать ничего - то точно само не сделается ничего Кто хочет что-нить сделать полезное?

У нас есть тикет попробовать другую RTOS - http://sourceforge.net/p/rusefi/tickets/7/
Я жду релиза ChibiOS 3.0, в которой HAL отделится от OS - в таком варианте меня интересует ChibiHAL + неЧибиОс

я не уверен что даже грубой силой удастся. Поэтому неплохо бы дождаться перехода проекта в относительно работоспособное состояние.
Однако скорее всего в следующей итерации от производителей мы будем иметь CORTEX 300mhz+ - так что уж еще более грубой силой все точно прокатит.




Пойми - придется почти полностью переписать весь код.
В конечном - это будет автоматный код. (не читаемый по твоему мнению).

зато он на 30мгц полетит....


нет не достаточно. Даже скажу вам так - детектирование детонации занимает для каждого цилиндра не менее 2-х тактов (т.е. не менее 2х полных циклов). Чтоб сломать что то надо значимое множество таких циклов (нагрев кромки поршня) - как правило несколько секунд. Существуют ДВС где физически невозможно при непрерывной детонации что то сломать (площадь-объем поршня/удельная мощность двигателя) - т.е. они с ней могут работать бесконечно.

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

Скажем проще.
Пока RusEFI не на Cortex-A8 он просто применяет HIP9011

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

Имеется в виду BARовщина (дилетантизм).

В кратце - во всем мире стандарты создания П.О. для авто вовсе не те которыми их хочет представить самоназванный эксперт Bar.
спагетти код и 100500 глобальных переменных - общепризнанные мировые методики!

А как многому можно научиться, если присоединиться к проекту... ооо!

Это не автора ли тех нетленок из http://www.barrgroup.com/ вы имеете в виду?
А мне его статьи нравятся.

Да. его. Нетленку протокол суда автор у себя на сайте стер - там самый жир.

Это или очень тонкий сарказм, или саботаж

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

Судя по набору факторов, может быть речь шла о том, что в этом сценации детонация наиболее ВЕРОЯТНА? Это просто моё предположение, но октановое число - это явно фактор ВЕРОЯТНОСТИ детонации, а не УЩЕРБА от неё.

конечно вероятности.
статья http://blogi.autonews.ru/?r=entry/view&id=488666

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

такое положение вещей сильно упрощало бы жизнь разработчика ЭСУД, и повышало бы шансы на жизнь мотора.

Нет все в целом верно. Кроме холодного двигателя.



Температуры поршня - в общем случае не причина а следствие. Наиболее влияют температура воздуха (смеси) качество топлива и правильность УОЗ.

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



И да, это тоже только промежуточный этап - просто этап. С такой платой уже намного комфортабельнее писать софт, не думая про висящие провода. Так что это исключительно инженерная плата. Full bundle

Наступил релиз кандидат платы:



По функционалу это
12 каналов аналоговых входов через оп-усилители - LMV324ID
12 каналов low side - VNS14NV04
6 каналов hi side
VR вход - MAX9926
CAN шина - SN65HVD230
микроSD слот & USB TTL - FT232RL

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

Архив KiCad и схематика

Кто-нить какие-нить очевидные косяки видит?

Плата на производстве, жду с нетерпением.

Сегодня пользователь спросил, как пожертвовать проекту денег - и пожертвовал. Было жутко приятно

Плата спаялась со второго раза и заработала с первого!

https://www.youtube.com/watch?v=HnJM9Edid8E



Теперь всю эту красоту нужно запрограммировать. Через пять лет будет круто

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

https://www.youtube.com/watch?v=VxisTpoe88I
https://www.youtube.com/watch?v=t2y3h8rGKXQ
https://www.youtube.com/watch?v=5wkH4HVtc50

сделали платку для теста схематики и попробовать каково это, паять TQFP100

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

А я вот с тех пор разработал вот такую плату на K60 и K70. Такая как бы концепция back-end (hard realtime) и front-end (soft realtime) контроллеров.
Нажмите для просмотра прикрепленного файла

Специально адаптирована для сбора подробной телеметрии в реальном времени.
Через один кабель HS USB оба контроллера со своих UART или SPI на скорости до 30 мбит/сек каждый могут передавать в компьютер информацию.
И через тот же кабель оба могут быть перепрошиты.
Т.е. контроллеры могут не содержать стек USB чтобы передавать информацию.

Хотя есть на плате и другие каналы: CAN-ы, UART-ы, SPI, I2C, Ethernet, Wi-Fi /n и т.д.
Более 100 конфигурируемых сигналов выходит на внешние разъемы.

Будет открыта без всяких лицензий.

Выглядит очень взросло, но кажется такую плату спаять самому будет еще сложнее?

А что за необходимость обязательно самому спаять? Времена уже не те... Да и много сэкономить на этом не получится.

Это Add-on плата, ей можно заменить дискавери. Материнскую конечно надо будет перепроектировать.
Но зато сигналов доступно раза в три больше чем на дискавери, а главное полная свобода логов.
Поскольку есть 128 МБайт DDRAM и 256 МБайт NAND SLC.

Можно перестать экономить память и поставить более развитую RTOS c интегрированными отладочными сервисами и утилитами типа FreeMaster для сбора данных в реальном времени.

Просто по факту всё это хобби - в формате хобби многие хотят спаять сами.



Пойду в личку попробую написать, хотелось бы голосом поговорить