Оптимизация алгоритма обработки ДПКВ

[Serj_K]

А мне вот следующая мысль пришла.
Мы измеряем длительность таймером, потом вычисляем обороты, потом подставляем полученные обороты в таблицы для интерполяции.
Работать с величиной оборотов очень наглядно и понятно.
Но если работать напрямую с измеренной длительностью, то не нужно будет вообще делать деление. То есть в таблицах вместо оборотов будут соответствующие значения длительности из таймера ICR.
Премиущества:
1) Очень быстро, так как полностью исключает длительную операцию деления.
2) Алгоритм не меняется и универсальность не пропадает
Недостатки:
1) Это очень не наглядно
2) Вычисление оборотов будет только в менеджере или в БК ( уменя останется в секу, так как блок индикации пассивный).

[Stranger21]

я тогда запутаюсь совсем ) у меня хотябы обороты видно четко как кто есть ) РХХ и прочее у меня по оборотам работают

[Serj_K]

У тебя обороты видно В МЕНЕДЖЕРЕ. Для отображения оборотов МЕНЕДЖЕР будет переводить длительность из секу в обороты, а для установки оборотов для некоторых параметров МЕНЕДЖЕР будет переводить обороты в длительность и передавать их в секу. Пользователю будет всё равно.
Это будет не наглядно и не удобно только в ТЕКСТЕ ПРОШИВКИ.

[Stranger21]

я про текст прошивки и имел ввиду ) я же там построил уже таблицу прогревочных оборотов , рхх переделываю .

[nikll]

Хм, а зачем вообще вычислять непосредственно обороты? в том же январе используется двухмерная таблица квантированния оборотов по 16ти режимным точкам, соответсвенно внутреннее представление данных совершенно другое.
Предлагаю подумать на тему того чтобы сделать таблицу квантированния оборотов на 32 точки. Во внутреннем представлении сразу использовать значения таймера.
Преимущество квантированния оборотов не через фиксированные шаги по оборотам или по таймеру а по точкам это то что в области низких оборотов мы можем делать маленькие шаги, к примеру 500 540 600 680 780 900 1020 1180 1300 1500 1800 2200 итд итп. Или же к примеру на высокооборотистых двигателях сблизить точки квантированния на оборотах макс момента (в спорте частый прием).

Serj_K, про обороты в менеджере +1. Внутреннее представление данных должно быть оптимально для мк, а не для пользователя. Преоброзованием удобного в требуемое долежна заниматься клиентская программа либо мозг программиста.

Stranger21, ну и используй дальше имеющщийся вариант с делением кто мешает то. А если тебе край необходимо сделать без деления то пересчитай обороты в таймер.

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

[Stranger21]

да я то подстроюсь )) примерно также как с АЦП - выкидыванием в менеджер "сырого числа" и смотря что показывает менеджер при этом )))) потом в екселе табличка какому число какое "человеческое " число соотвествует ) так что нет проблемм впринципе )

[STC]

Народ, вы пошли немного не в ту степь. Вычисление оборотов не является проблемой, так как оно делается в основном цикле (не в прерывании) и его можно делать не каждый раз. Алгоритм ДПКВ не имеет никакого отношения к оборотам (за исключением того, что функция вычисления оборотов находится внутри файла ckps.c).

[Serj_K]

Посмотрел детальне - таки да, не о том я начал.

[AleksandR K.]

То есть в таблицах вместо оборотов будут соответствующие значения длительности из таймера ICR.

У меня почти так реализовано. Т.е. в таблице время горения смеси в отсчётах таймера (250 кГц). Но обороты я всё равно вычисляю - так удобней.
При интерполяции вычислений больше из-за большей разрядности. Угол в градусах занимает байт, время - два. Но проблем с этим нет.

[STC]

Да, оптимизацию можно провести если заменить поняте "УОЗ" понятием "время" (как предлагает AleksandR K.). Но я это делать не буду, так как хочу использовать общепринятую модель.