emmibox

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

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

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

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

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

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

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

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

Это я называю Bar-овщиной в чистом виде. Когда дилетанты приходят и указывают профессионалам как оно должно быть в свете общих тенденций и потому, что так проще им... В мире нет реальных систем не с использованием интерпретируемых языков (на уровне ECU) ни с ООП в наборе. Абстракции только на уровне RTOS для переносимости опять же в пределах переносимости RTOS.

Да не определяется порог вхождения ни сложностью кода ни сложностью его написания. Код - самое примитивное что там в принципе есть. в любой системе. любого производителя. Да и не пишут его уже руками давным давно - он почти весь транслируется из моделей матлаба. ЭСУД - чисто инженерная задача. с чисто инженерными заморочками. с очень маленькой долей электроники-програмиизма.

всегда можно тупо подкинуть процессор. - просто еще один под задачу. любой! в любом виде! и даже аргументировать состоятельность этого решения - "да тойота в стоке так делает"... Только вот 10 лет уже как то в реальной жизни обходимся.

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

Все примеры которые так или иначе есть - написаны обычными программистами. Просто тебе это кажется не понятным - хотя это обычный автоматный метод. Да им сейчас мало кто владеет - но специалисты есть. Мало того я считаю что производительность не заменит тебе владение им (хотя это мое субъективное мнение)...

Андрей. Проблема систем управления вообще не стоит в написании софта. Сейчас у нас уйма софта в примерах разного качества под что угодно. Проблема в адекватных алгоритмах - а вот с ними плохо очень. Над ними приходится работать потому что никто на халяву не скажет как и что надо делать. Это все приходит только через моторы-опыт-время. И реализация на быстром процессоре и на медленном только вопрос владения языком. У меня нет проблем с MCS51 - я работаю с ним с 1988 года - и мне проще написать на нем чем на чем угодно вообще. MaxiRPD это я. Я просто вспомнил что у меня тут давно есть аккаунт ;)

Груда металлолома управляет двигателем Субару. http://www.youtube.com/watch?v=r2dc_BvUXEc Груда металлолома управляет электронным дросселем http://www.youtube.com/watch?v=8AiVcbKKczw (пока только PI). надо ли объяснять что у груды металлолома нет ну ровным счетом никаких проблем ни с чем вообще!? и да - я сторонний разработчик!