Оптимизация вычислений

[rus084]

грозит ли мне проблема нехватки времени для обрабатывания сигнала с триггера ?
я так понял что нет ( в 1/150 секунды можно обработать всё)

[puff]

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

[AndreyB]

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

Красота кода тут не при чём. Читем имплементацию вокруг initializeIgnitionActions в http://rusefi.com/docs/html/main__trigger__callback_8cpp_source.html и я открыт к любым идеям, как это заимплементировать лучше.

еще можно было поподробнее остановиться на необходимости пропускать половину сигналов в случае индукционного датчика - с какой целью?

У индукционного датчика кажется один из фронтов стабильный, а второй гуляет в зависимости от оборотов. Опиратсья нужно только на один из них.

[puff]

ой ли. не у сигнала ДПКВ, а у обработчика сигнала ДПКВ. и не гуляет, а его можно задавать - либо четко по zero-crossing, либо через rc -цепочку (хотя может я чего-то путаю, но в своё время чтение даташита на lm1815 именно такую картину в голове сложило)

про имплементацию - мало чего понял, но на всякий случай скажу: "ох уж это стремление к универсальности…"
todo строчкой выше про add some check for dwell overflow - а еще выше - там где в obd ошибка логируется (если я правильно понял) - только и всего? при этом логика не меняется? я думал, это уже починено.

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

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

[AndreyB]

Всё, поборол!

Пришлось ужаться много где - вместо вызовов методов стали макросы, вместо указателей - глобальные переменные. Огромным фактором похоже был немного неверно заданный параметр ширины пропуска в 60/2 триггере (было 2.5+-25%, а должно быть be 3+-25%). https://sourceforge.net/p/rusefi/tickets/115/ закрыт

2014-11-26 17_36: EngineState: isError No/total errors=79 ord_err=3/total revolutions=176872/self=No
2014-11-26 17_36: EngineState: sn=Yes ignitionMathTime=1380 schTime=1409 triggerMaxDuration=21524
2014-11-26 17_36: EngineState: maxLockTime=8417 / maxTriggerReentraint=0
2014-11-26 17_36: EngineState: maxEventQueueTime=2465

79 ошибки на 176872 цикла нормально в принципе. triggerMaxDuration можно и нужно будет уменьшить, но тоже в принципе пока сойдёт.

[Maxi]

ни один мозг ТАМ ничего не вычисляет.
все уже вычислено до этого.

на первом зубе каждого цикла:
1) рассчёт времени накопления на текущих оборотах - линейная интерполяция
2) 3D интерполяция угла опережения зажигания - это три линейные интерполяции
3) на основании углов зажигания на всех цилиндах - бинарный поиск индекса зуба триггера, на котором собсвенно должно произойти зажигание в конкретном цилинде

кроме 3 ничего не нужно.

[AndreyB]

кроме 3 ничего не нужно.

А поподробнее?

рассчёт времени накопления - без интерполяции или не рассчитывается на каждый оборот? а как же тогда?
опережение зажигания - без интерполяции или не рассчитывается на каждый оборот? а как же тогда?

[Maxi]

кроме 3 ничего не нужно.

А поподробнее?

рассчёт времени накопления - без интерполяции или не рассчитывается на каждый оборот? а как же тогда?
опережение зажигания - без интерполяции или не рассчитывается на каждый оборот? а как же тогда?

зачем это рассчитывать по углу поворота если это можно рассчитывать по времени.

[AndreyB]

зачем это рассчитывать по углу поворота если это можно рассчитывать по времени.

Имеешь ли ты ввиду, что вместо рассчёта один раз за оборот, это значение рассчитывается с какой-то периодичностью в абсолютном времени? Какая конкретно периодичность встречается - 1Гц? 10Гц? 100Гц?

[Maxi]

для разных садач в разных ситемах разная. самые распространенные кванты 1 5 10 20 50 100 1000мс

[AndreyB]

для разных садач в разных ситемах разная

какие типичные кванты у самых интересных задач - угол зажигание и кол-во топлива?

[Maxi]

5-20

[puff]

то есть это некие таймеры, обработчики которых будут раз в 5 и 20 мс считать рассчитывать зубья/смещения внутри зуба для зажигания и впрыска? вне зависимости от скорости мотора?
если я тут в ночи правильно считаю, при расчете скорости коленвала один раз за оборот, на 6000 RPM скорость будет обновляться каждые 10мс. и если на этих оборотах оставить планировщик в начале каждого оборота (как сделано сейчас) - то в нынешнем подходе точность будет выше. с другой стороны, если уронить обороты до 1000rpm, то делать так часто апдейты планировщиков зажигания резона нет, ибо скорость мотора один фиг определяется реже, чем происходит перерасчет. м?

а что происходит с квантом 1мс?

[Maxi]

смещение внутри зуба внутри зуба и считается.
двигатели не кончаются на 6000rpm они бывает и 12000 и 16000 и 18000 крутятся. Естественно никто в них не считает угол раз за оборот.

Далее - на кой собачий пес нужна например ОСРВ если вы банально не можете разделить задачи по углу с задачами по времени так чтоб не нужно было ВСЕ ПРОСЧИТАТЬ В 1 ЗУБЕ а потом 59 зубов ничего не делать!

про квант 1мс - все есть у Гирявеца.

[puff]

ну так о том и толкую: на 18К тем более будет точнее планировать раз в оборот, а не раз в 5 и в 20 мс.

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

ps думаю, если бы у разработчиков января (или что там приводилось в пример) были запасы по производительности - они бы может и не парились бы с абсолютной периодичностью расчетов, а считали бы всё раз за оборот)

[Maxi]

Они все сделали правильно - потому что как раз из той школы когда не было никакой производительности. Они на одном контроллере решили ту же самую задачу тогда когда bosch-gm их ставили по два. Чем сэкономили миллионы денег и избавились от лишних глюков межпроцессорной коммуникации. Потому, что главное над чем они работали, и чего никогда нет у афтермаркетов - АРХИТЕКТУРА СИСТЕМЫ! не удобный процессор не красивый говнокод, а именно то что и как и на каком зубе должно быть рассчитано и, что из этого можно по времени рассчитать не торопясь а что по углу и сразу. По итогу сейчас они пускают свой код на процессорах которые инфинеон делает для дверных замков - и тем не менее решают на нем все задачи управления двигателем...

[puff]

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

[AndreyB]

Далее - на кой собачий пес нужна например ОСРВ если вы банально не можете разделить задачи по углу с задачами по времени так чтоб не нужно было ВСЕ ПРОСЧИТАТЬ В 1 ЗУБЕ а потом 59 зубов ничего не делать!

Во-первых, ОСРВ на этом уровне уже давно не успевает - у нас личный 1МГц таймер и планировщик в рамках этого таймера.

В первом зубе мы считаем, на каких зубьях собсвенно будут события. Точнее - каждый раз, когда мы считаем какой у нас будет угол зажигания, мы сразу считаем, на какие зубья это зажигание ляжет. Бинарный поиск оттуда я выпилил - теперь там просто таблица ЦЕЛОЧИСЛЕННЫЙ УГОЛ <> ИНДЕКС ЗУБА.

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

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

Итого: ждём теста на реальном двигателе с 60-2 триггером. Надо будет улучшать - начнём прореживать рассчёт.

PS: кто может найти конкретную страницу-минуту Гирявеца на эту тему?

[puff]

ну что. не поленился. погуглил гирявеца. нашел вот это
http://ftp.clubvolvo.ru/OTHERS/DVS_Theory_Management.pdf
в доке попробовал найти упоминания тех квантов 1-5-10-20мс - не нашел
либо отсканировано криво, либо оно в графиках (плохо себе представляю такие графики), либо кое-кто немного не туда направил…

russian, а ты целиком прочел эту книгу? там вообще куча интересного.

вот, например

Эти наблюдения позволяют сделать
принципиальный вывод о том, что
колебания абсолютного давления во впускной системе, несущие информацию об изменении циклового
наполнения вызванном изменением положения дроссельной заслонки и определяемые скоростью
заполнения впускной системы, сосредоточены в полосе частот от 0 до 20 Гц, а колебания с частотой
выше 20 Гц не связаны с изменением циклового наполнения, и являются помехой при определении его
величины. Полученный вывод дает возможность сформулировать требования к быстродействию системы
управления рабочим процессом двигателя: система управления рабочим процессом должна иметь бы-
стродействие, обеспечивающее обработку сигналов, характеризующих изменение циклового наполнения
двигателя, вызванное управляющим воздействием на дроссельную заслонку, в полосе частот от 0 до 20
Гц.

то есть те же показания ДАДа нужно каким-то образом "выравнивать" что ли..