Микропроцессорная система зажигания для ПЛМ

[BECHA]

Всем привет.
В продолжении моего поста от 26.10.22.

в чем преимущества предложенного алгоритма? замена умножения интерполяцией?

 

[С.Н.]

в чем преимущества предложенного алгоритма? замена умножения интерполяцией?

Нет конечно.
По большому счету (математически на бумаге) это одно и тоже.
Ни в коем случае не претендую на авторство. Это лишь модификация, которая на порядок уменьшает время работы расчетной части, и вообще позволяет это сделать на простейших МК. Всё что написал это тем, кто хочет и может сам написать программу например для TCI или CDI МПСЗ или под два цилиндра с раздельным искрообразованием.
Остальные, уж извините за прямоту, копируйте или покупайте платки и качайте чужие прошивки.
Ну правда, зачем среднестатистическому нормальному человеку голову забивать проблемами написания программы для вычисления выражения 0,01678*6000000/1034 - 678,234?

 

[BECHA]

которая на порядок уменьшает время работы расчетной части,

на порядок это в 10 раз. вы сравнивали время выборки угла в проекте на который ссылаетесь и в вашем алгоритме?
У вас написано "Время выполнения расчетной части алгоритма ФУОЗ при частоте кварца 16МГц составило от 2 до 14мкс".
а на DigiSpark сколько?

 

[С.Н.]

на порядок это в 10 раз. вы сравнивали время выборки угла в проекте на который ссылаетесь и в вашем алгоритме?
У вас написано "Время выполнения расчетной части алгоритма ФУОЗ при частоте кварца 16МГц составило от 2 до 14мкс".
а на DigiSpark сколько?

А как Вы думаете, сколько времени надо на эмуляцию десятка операций с плавающей запятой на языке Си (взаимный пересчет одной величины в другую) по сравнению с 2 операциями с целыми числами, правда двухбайтовыми, на ассемблере МК - на Тиньке в 10 раз точно! А с аппаратным умножителем ATmega можно и к 100 подойти. Могу осциллограмму прислать прямо в формате осциллографа (софт для просмотра тоже), как эта вещь работает на 20000 оборотах двигателя. В общем дело Ваше. Наше дело предложить и фактически подарить алгоритм.
Однако, как я говорил, хитрый алгоритм еще не ключ к успеху. Надежное питание и датчик более важны, тем более для применения на лодочных двигателях.

 

[ovchinnikov 1966]

Граждане. Зачем спорить?. Вашим продуктом воспользуются 00000.1 процент пользователей. И самое интересное- это особые фанаты,они сами это могут создать. запрос на проц. зажигание-три-четыре в год !!! При озвучивании цены,все эти заказчики- сливаются.При стоимости самого гибрида, Вихря,и т.д. им это нужно за рубль. Жаль китайцы не понимают наших цен. При условии доставки собранной на смд в Россию- цельный гемор..Остыньте,не та временная пора в данное время.

 

[С.Н.]

Граждане. Зачем спорить?. Вашим продуктом воспользуются 00000.1 процент пользователей. И самое интересное- это особые фанаты,они сами это могут создать. запрос на проц. зажигание-три-четыре в год !!! При озвучивании цены,все эти заказчики- сливаются.При стоимости самого гибрида, Вихря,и т.д. им это нужно за рубль. Жаль китайцы не понимают наших цен. При условии доставки собранной на смд в Россию- цельный гемор..Остыньте,не та временная пора в данное время.

".. а потом пришел лесник и всех к черту разогнал.. "

 

[BECHA]

При озвучивании цены,все эти заказчики- сливаются.

про коммерцию здесь и речи нет.

А как Вы думаете, сколько времени надо на эмуляцию десятка операций с плавающей запятой на языке Си (взаимный пересчет одной величины в другую) по сравнению с 2 операциями с целыми числами, правда двухбайтовыми, на ассемблере МК - на Тиньке в 10 раз точно!

выходит вы сделали вывод о скорости обработки алгоритма выборки угла не убедившись в его правильности?

 

[С.Н.]

выходит вы сделали вывод о скорости обработки алгоритма выборки угла не убедившись в его правильности?

Интересный вывод! А для чего приводил данные по работе реального устройства, построенного по моей модификации? Неужели не понятно, что там осциллограмма с живого МК приведена и оценка точности в 0,2 градуса?

 

[BECHA]

Интересный вывод! А для чего приводил данные по работе реального устройства, построенного по моей модификации? Неужели не понятно, что там осциллограмма с живого МК приведена и оценка точности в 0,2 градуса?

в вашей статье вы написали сколько времени тратит ваш алгоритм на получения значения опережения для заданной частоты вращения но не написали сколько тратит алгоритм от Custom Cult на digispark .
Потом предположили что "на порядок" т.е. в 10 раз. Правильно я вас понял?

 

[С.Н.]

в вашей статье вы написали сколько времени тратит ваш алгоритм на получения значения опережения для заданной частоты вращения но не написали сколько тратит алгоритм от Custom Cult на digispark .
Потом предположили что "на порядок" т.е. в 10 раз. Правильно я вас понял?

Точность формул оригинального алгоритма не подлежит сомнению. Оригинальный алгоритм на вычисление времени активации сигнала управления тратит много времени. Это время требуется для проведения вычислений в формате с плавающей запятой на МК, не поддерживающим их аппаратно. То есть, все вычисления (несколько "нехороших" делений и умножений) проводятся с помощью длинной программной эмуляции. Оценку этого времени сделать могу, но не считаю необходимым. Поверьте это на тактовой частоте Тиньки миллисекунды как минимум. Однако, из-за этого применимость его для других систем зажигания и количество цилиндров - упс!
Мой алгоритм всего 12 мкс (16МГц кварц) с почти той же точностью общих вычислений - целочисленных вычислений и без деления! Какие тут могут быть сомнения? А вот как это будет работать в совокупности с остальными частями прошивки зависит только от Вас (от Вашей программы).
Например, для иллюстрации работоспособности просто в разработанную мною ранее систему SetUpCtrl встроил быструю математику модифицированного мною алгоритма ребят из команды Custom Cult. SetUpCtrl и так ранее тратил всего ~60 мкс на свои вычисления и тоже с интерполяцией. Так вот, 12 мкс это уже в 5 раз меньше, чем было у меня, а вот сравнить с миллисекундой уже страшно.

 

[BECHA]

Оригинальный алгоритм на вычисление времени активации сигнала управления тратит много времени.

т.е. я прав? ваши выводы умозрительны?

PS в наше время нет проблем в производительности - вы повторяете подвиг Дон Кихота.

 

[С.Н.]

т.е. я прав? ваши выводы умозрительны?

PS в наше время нет проблем в производительности - вы повторяете подвиг Дон Кихота.

Вот я это делаю это ради развлечения. А в чем Ваш интерес? Опровергните мои заключения Вашими измерениями.
Я могу аппарат предъявить, который работает на оборотах 20000 и можем УОЗ сверить с расчетным. Запустим Ваш алгоритм?

 

[BECHA]

Вот я это делаю это ради развлечения.

это я понял

А в чем Ваш интерес?

я поделился в теме интересным и доступным проектом CustomCult.
И смотрю что стало подгорать от того, что можно за 100р получить этот ФУОЗ. время вычисления не понравилось. у ПЛМ обороты 20 тысяч давно?

 

[С.Н.]

это я понял


я поделился в теме интересным и доступным проектом CustomCult.
И смотрю что стало подгорать от того, что можно за 100р получить этот ФУОЗ. время вычисления не понравилось. у ПЛМ обороты 20 тысяч давно?

Так у ПЛМ и коммутатора ВАЗ нет и энергии для его работы, в общем случае, тоже нет, а CustomCult на другом не работает.
У меня богатый опыт нахлобучивания МПСЗ на мотоциклы - работают без проблем. Однако на ПЛМ вечно какие-то нюансы вылезают. Тут надо тщательнее подходить, а не по "дешману". Иначе вероятность весельного путешествия резко возрастает!

 

[BECHA]

Так у ПЛМ и коммутатора ВАЗ нет и энергии для его работы,

Customcult открытый проект - можно добавить и работу от магнитного датчика и "подхват" после пуска с нулевым опережением.

вы ушли от темы с временем. давно ли ПЛМ понадобились обороты в 20000?

 

[С.Н.]

Customcult открытый проект - можно добавить и работу от магнитного датчика и "подхват" после пуска с нулевым опережением.

вы ушли от темы с временем. давно ли ПЛМ понадобились обороты в 20000?

Конечно на ПЛМ обычных людей 20000 нет. Двадцать тысяч - это численная иллюстрация быстродействия.
"Можно добавить" - добавляйте. Вот тока беда - "всезнающих" доброжелателей много, "паяльщиков" чуть-чуть, а программистов едва больше 0.
Время лишнее (освобожденное от глупых операций) в программе для того и нужно, чтобы иметь возможность добавить какие-то функции.
Однако два случая ~20000 лично у меня есть на практике. Первый - трехцилиндровый американский снегоход с оборотами 10000. Трехкратное применение ФУОЗ от цилиндра к цилиндру эквивалентно 30000. Надо признать, что так заказчик раздельно, можно было искрить и по всем цилиндрам сразу. Второй - один из гоночных байков (в ТЗ от заказчика) - 18000 оборотов, вот ему то и поставлю модифицированный алгоритм.

 

[BECHA]

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

переходите на STM 32 - там маленькие SO8 или TSSOP20 процессора имеют частоту ядра до 64МГц и флэш памяти до 64 кБ - можно таблицу опережения с шагом 1 об/мин в память записать и вообще ничего не вычислять!

трехцилиндровый американский снегоход с оборотами 10000.

разве нужно каждому цилиндру считать опережение раздельно?

 

[yoric]

переходите на STM 32 - там маленькие SO8 или TSSOP20 процессора имеют частоту ядра до 64МГц и флэш памяти до 64 кБ - можно таблицу опережения с шагом 1 об/мин в память записать и вообще ничего не вычислять!

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

 

[С.Н.]

разве нужно каждому цилиндру считать опережение раздельно?

Наверное не нужно.
В то время, когда это делал, был выбран единый подход построения программы всех двигателей: Единое для всех Ядро и индивидуальные периферийные программы. Для многоцилиндровых двигателей одно и тоже Ядро применялось последовательно от цилиндра к цилиндру. Поэтому вычисления все равно проводились по сигналу датчика (датчиков).
По моему мнению, может и не правильному - это вообще вопрос почти философский. То, что есть сейчас это ПД регулирование (дифференциальное - пропорциональная мгновенная реакция на изменение измеряемой величины). Можно построить программу, где УОЗ вычисляется даже на не каждом обороте. Это будет ПИ (интегральное) регулирование. Философски правильный подход - ПИД регулирование!

 

[BECHA]

Я лично за оптимизацию алгоритмов, к чему и всех призываю))

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

 

[С.Н.]

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

И это будет Ваш метод. Осталось установить датчик, запрограммировать алгоритм измерения частоты вращения с учетом того, что сигнал датчика подвержен импульсным помехам, которые будут вызывать ложное срабатывание программы в целом и формировать искру в неположенном месте.
Самое главное, за что получал много критики на разных форума. Типичные вопросы:

1. Зачем нам еще один Саруман?
2. Зависимости только от оборотов не достаточно - надо иметь возможность прикрутить ДПДЗ или МАР датчик чтобы обеспечить двухкоординатную регулировку УОЗ.
3. А где брать питание на работу такой чудесной вещи?
4. Самый убойный вопрос - Зачем всё это нашему Рязанскому колхозу?

 

[yoric]

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

Иногда простота хуже воровства)) Вроде есть такая поговорка. А впрочем, каждый сам по себе. Ну Вам не нать, другим пригодится.

 

[Георг Ом]

Иногда простота хуже воровства))

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

То, что есть сейчас это ПД регулирование (дифференциальное - пропорциональная мгновенная реакция на изменение измеряемой величины). Можно построить программу, где УОЗ вычисляется даже на не каждом обороте. Это будет ПИ (интегральное) регулирование. Философски правильный подход - ПИД регулирование!

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

 

[С.Н.]

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

"ПИД" это по философски только. Имел в виду аналогию. Ну зря прикрутил, ну пусть будет так или иначе.

 

[Сергей Б]

Когда то давно, 84-85 год, делал автомат УОЗ на 133-134 микросхемах, аналог 155-х, но мелкие и в керамике с золотом, 176 и 561 были зело дефицитными. На выходе была 133ИД3, два датчика, и 16 ступеней. Чем больше оборотов, тем до меньшего числа успевала досчитать ИД3, тем раньше проскакивала искра. Одна из схем на виду, переставляется с мотора на мотор, уже 37 !!! лет.