ФУОЗ по дешману

Скачал файл без MAP.

Вот теперь появился смысл в глобальности переменной diffTime, потому что мы начали её использовать в двух разных функциях (язвительную часть из коммента к данной переменной можно смело убирать, что ты и сделал в строке 17 :-))

... и финальный шаг оптимизации в этой функции - два машинных и один человечий:
0. Повышаем точность вычисления.
1. Избавляемся от одной лишней операции.
2. Убираем из кода непонятные магические числа.

Возьмём для примера состояние, обозначенное в строке 196:
058340 мкс - ВМТ - oldModulator = 1, modulator = 0, ignitionFlag = 0, nextIgnition = 15899, ignitionFlagWithOffset = 0, oldtime = 8340
VMTtime = 58340
diffTime = 50000
rpm = 1200
ignitionDegree = map(1200, 1000, 2000, 22, 150) = 47

nextIgnition = 58340 + 50000 - (50000 / 360 * 47 / 10)
nextIgnition = 58340 + 50000 - (138 * 47 / 10)
nextIgnition = 58340 + 50000 - (6486 / 10)
nextIgnition = 58340 + 50000 - 648
nextIgnition = 108340 - 648 = 107692
Итого 5 операций (на самом деле, больше, потому что ATMega имеет восьмибитную архитектуру, и не умеет без костылей оперировать 4-байтовыми данными, но это уже ограничения архитектуры и от них особо никуда не деться, по крайней мере, с моими знаниями)

107692 мкс - это 4,66 градуса до ВМТ. Отлично, практически попали в цель. Формулу можно считать верной, но в ней есть два "магических числа" - 360 и 10, и одна лишняя операция деления, тратящая машинное время и вносящая путаницу в мозг того, кто пытается разобраться в коде.

Избавиться от них очень просто.
Для начала сократим выражение - объединим две последовательные операции деления и запишем формулу как
nextIgnition = VMTtime + diffTime - (diffTime/3600*ignitionDegree);

Оп! Сразу стало меньше на одно магическое число и на одну математическую операцию!
Для проверки пересчитаем:
nextIgnition = 58340 + 50000 - (50000/3600*47)
nextIgnition = 58340 + 50000 - (13*47)
nextIgnition = 58340 + 50000 - 611
nextIgnition = 108340 - 611 = 107729
Итого 4 операции.

Но 107729 мкс - это 4,4 градуса до ВМТ. Промахнулись на 3 десятки против 4 соток в предыдущем варианте. Почему же мы так сильно потеряли в точности?
Потому что, как объяснял ранее, при целочисленных операциях деления дробная часть отбрасывается.
Поэтому стоит сначала производить все операции умножения с оглядкой на тип данных, и только по завершении операций умножения производить деление, чтобы отбрасываемый остаток был минимальным.

Поэтому запишем формулу как
nextIgnition = VMTtime + diffTime - (diffTime*ignitionDegree/3600);

И произведём контрольный расчёт.
nextIgnition = 58340UL + 50000UL - (50000UL*47U/3600)
nextIgnition = 58340UL + 50000UL - (2350000UL/3600)
nextIgnition = 58340UL + 50000UL - 652UL
nextIgnition = 108340UL - 652UL = 107688UL
Итого 4 операции, как и было на предыдущей итерации, а 107688 мкс - это 4,69 градуса до ВМТ. Практически в яблочко!

Как можно заметить, у некоторых чисел появились суффиксы. Они нужны, чтобы наглядно оценить тип данных и не встретиться с переполнением.
Тип данных задаётся при объявлении константы или переменной. В нашем случае объявлены 3 глобальные переменные и 1 локальная константа:
unsigned long VMTtime (4 байта, беззнаковая, диапазон 0...4294967295, суффикс UL от Unsigned Long)
unsigned long diffTime (аналогично)
word ignitionDegree (2 байта, беззнаковая, диапазон 0...65535, суффикс U от Unsigned int)
3600 (по умолчанию тип int16 - 2 байта, знаковая, диапазон -32768...32767, суффикс отсутствует)
При выполнении математических операций с двумя переменными разных типов компилятор автоматически приводит в соответствие размеры переменных, но за типами данных лучше следить самостоятельно, потому что 5000 * 20 = -31072, а никак не ожидаемые 100000 - возникло переполнение типа int16, т.к. данные типа int16 не приведены явно к int32.
Правильно и предсказуемо будет вычисление 5000UL * 20 = 100000UL, или 5000L * 20 = 100000L.
Но в нашем случае всё в порядке, переменные изначально имеют нужные типы.

Теперь осталось дело за малым - избавиться от последнего магического числа в коде

В самом начале кода объявим константу:
#define DEC_DEGREES 3600 // Количество десятичных долей градуса в полном обороте, потому что все расчёты углов мы ведём в десятичных долях

И теперь мы можем записать формулу как
nextIgnition = VMTtime + diffTime - (diffTime*ignitionDegree/DEC_DEGREES);

Всё, функция оптимизирована.
Но поле для дальнейшей оптимизации и причёсывания кода ещё непаханое.

Если ты таким образом пытался избежать хлопка в карбюраторы при включении зажигания на уже крутящемся моторе, то, ИМХО, логичнее было бы чуть изменить алгоритм старта - первые две искры подавать точно в ВМТ, а расчёт скорости вращения и угла опережения начинать только со второй ВМТ. Основываясь на разнице времени между двумя ВМТ, уже можно считать обороты и входить в основной алгоритм.

Peacedeath подкрался незаметно, но слышен был издалека

Может реализовать как у Сарумана - смену графиков в зависимости от типов ДВС и нагрузки?
___________________________________________________________________
"Человека можно уничтожить, но его нельзя победить" (Э. Хемингуэй)

Ну так Сарумановская схема была отлажена для работы без МАР от того то и сделали там 3 графика.
Предлагаю такую концепцию:
1. Схема без МАР - реализуем те же 3 графика как у Сарумана - колясыч, одичка и условно "спорт". Хотя городить третий график не вижу большого смысла
2. Схема МАР - прошивка подгоняется под конкретный датчик из недорогих и доступных. Вакуум берется через пресловутую переплюйку.
Режим прогрева свечей считаю функцией бесполезной, так как при нормально работающем ДВС это не нужно.
Сдвигать график туда сюда наверное не логично, а вот сдвиг участков графика в диапазонах определенных оборотов логичен.
___________________________________________________________________
"Человека можно уничтожить, но его нельзя победить" (Э. Хемингуэй)

Откатал на стенде прошивки с коммутатором 95.3734, искра при старте будет всегда, это особенность платы, при старте стартует бутлотер который и дает сигнал на ногу выхода, и это не победить будет Бах при включении зажигания. Подправил прошивку под вырез, так же программно на пины входа подтягиваем +, дает более стабильную реакцию на датчик холла.
осталось обкатать на мотоцикле. все свежие скечи по ссылкам в посту выше , аналог сарумана называется sketch-461_NO_MAP...

так же на вход датчика мап надо подтягивать отдельным резистором на 10кОм gnd иначе при отключеном датчике на порту начинаются самопроизвольные показания и угол коррекции начинает плясать. подтягивание встроенным резистором толку не дает.

Поглядел эту версию.

Не понял, зачем ты выпилил внедрённую тобой же защиту от обратной вспышки при включении зажигания на вращающемся моторе.
Ну и плюс есть поле для оптимизации. ИМХО, надо сначала закончить с этой версией, добившись максимальной производительности и минимального веса, а потом уже внедрять MAP.

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

Кстати, шаг в 1000 об/мин не большеват ли, как считаешь?
Нет желания уменьшить его до 500, а в идеале - до 200 об/мин?
Потребуется, конечно, более детально прописать графики и потратить дополнительно 36...120 байт, но, может, овчинка стоит выделки, чтобы приблизиться к целевому графику от текущей ломаной линии?

Peacedeath подкрался незаметно, но слышен был издалека

А что там в первичной цепи катушки-то?
Коммутатор с Холлом или контакты?

Если коммутатор с Холлом, то пойдёт, но количество правок зависит от расположения шторки, её формы и расположения фронта.

Peacedeath подкрался незаметно, но слышен был издалека

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

А кстати да , будет работать. если ты искру бегунком трамблёра будешь раздавать по котлам

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

Кстати, а как ты вычислял промежуточные значения для графика?
Я посмотрел на Сарумановские графики и увидел там шаг 1000 об-мин, а всё, что между ними - прямая линия, которая описывается функцией MAP

Peacedeath подкрался незаметно, но слышен был издалека

А как ты переключение графиков реализовал физически, какой вывод платы нужно на землю замыкать?
___________________________________________________________________
"Человека можно уничтожить, но его нельзя победить" (Э. Хемингуэй)

А какого вида шторка? Вырез или пластина? Ну и в целом, как настраивать, сам процесс?

обрати внимание особенно на режимы от 700 до 1500. жду результатов.

Ты только скажи какой MAP-sensor был взят и как его цеплять к контроллеру. Ветка разрослась и не у всех хватит умения все внимательно прочесть.
___________________________________________________________________
"Человека можно уничтожить, но его нельзя победить" (Э. Хемингуэй)

по описанию плата переваривает до 17В так что можно питать из любого места ,но у меня именно так и сделано как ты предлагаешь , плюс разъемы сделаны так что можно соединить напрямую коммутатор с датчиком если вдруг ФОЗУ выйдет из строя (еще для сарумана это делал).

Это дань, которую приходится платить за возможность прошивки по USB.
При подаче питания запускается bootloader, который ожидает связи по USB и поступления данных в порт. При отсутствии данных в течение 5 секунд - запускает основную программу, зашитую пользователем.

Peacedeath подкрался незаметно, но слышен был издалека