Обсуждение универсального обработчика датчиков положения

Про байтики и логику ЭБУ
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Обсуждение универсального обработчика датчиков положения

Post by AndreyB »

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

Вводные данные:
На каждом двигателе есть минимум один датчик положения вала. Датчики ставят как на коленчатый, так и на распределительный вал - так что для обобщения я предлагаю оперировать просто термином "ВАЛ" - не уточняя, о каком именно вале идёт речь. Для целей определения положения валов тип датчика роли не играет - обработка электрического сигнала это отдельный вопрос, здесь мы обсуждаем исключительно алгоритм обработки.

Пока я вижу два варианта конфигурации датчиков:
1) колесо с пропуском зубьев: один сигнал, пример: 60/2 колесо - 58 зубьев, пропуск размером в два зуба. Пример двигателя: БЛАБЛА
2) двойной сигнал: одно колесо генерирует одно опорное событие за оборот вала, второе колесо выдаёт несколько равномерных сигналов. Пример двигателя: Ford Aspire (опорное событие + 4 равномерных сигнала)

Итак, собственно предлагаемая архитектура:
0) конкретные потребители событий о положении валов сами ничего не декодируют, а только регистрируют функцию обратного вызова - http://ru.wikipedia.org/wiki/Callback_%28%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%29
1) единый код централизованно обрабатывает датчики и оповещает потребителей данных о новом состоянии

Детали имплантации:
Точка входа: initShaftPositionInputCapture@hw_layer/shaft_position_input.c

Сигнатура функции обратного вызова, в простонародье callback'а:
ShaftPositionListener(ShaftEvents signal, int index)

Где ShaftEvents - это перечисляемый тип SHAFT_PRIMARY_UP/SHAFT_PRIMARY_DOWN/SHAFT_SECONDARY_UP/SHAFT_SECONDARY_DOWN), index - индекс события внутри оборота. Индекс события внутри оборота пробегает от нуля до суммарного количества зубьев * 2.

Инициализация оборудования и общий код: shaft_position_input.c
Имплантация колеса с пропуском зубьев: toothed_shaft_sensor.c
Имплантация двойного колеса с опорным сигналом: multi_shaft_sensor.c

FAQ:
1) нахрена мы так часто видим датчики сразу на обоих валах - и на коленчатом, и на распределительном? Надёжность или что-то функциональное? ответ: распред вал поворачивается на половину оборота за полный оборот коленчатого вала - поэтому по
положению только коленчатого вала положение распределительного вала не отпределить. Для индивидуального впрыска нужно знать точное положение распределительного вала - поэтому нужен датчик обязательно именно на РВ.

Открытые вопросы:
2) цепь или ремень: будет ли иметь место растягивание и рассинхронизация датчиков?
3) максимальное ускорение скорости вращения в течении одного оборота?
4) почему более точные датчики обычно на КВ (коленчатом вале)? просто из-за сложности ставить много мелких зубьев в окраниченных размерах датчиков РВ? Хотя есть исколючения - на ниссанах например бывают очень мелкие прорези на колесе для датчика РВ.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
Sergey89
contributor
contributor
Posts: 839
Joined: Wed Sep 25, 2013 5:30 pm
Location: Russia, Velikiy Novgorod

Re: Обсуждение универсального обработчика датчиков положения

Post by Sergey89 »

Не касаясь пока реализации.

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

Дачтиков фаз, кстати, может быть несколько, если установлены фазовращатели.

Постоянно синхронизироваться по датчику фаз нужно для надёжности и для отслеживания ошибки синхронизации.

Скорее всего нужно рассматривать не ускорение в течении оборота, а ускорение в течении зуба (точнее того интервала, который принят за базовый в качестве сигнала положения), потому что нужно заранее инициализировать задержку для событий между зубьями.
nikll
Posts: 186
Joined: Tue Oct 15, 2013 5:45 am

Re: Обсуждение универсального обработчика датчиков положения

Post by nikll »

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


По вопросам:
1. обычная схема 60-2 на кв и датчик на рв, дпкв дает точное положение коленвала с дискретностью в 3 градуса, дпрв дает понять фазу двигателя (впуск или уже сжатие в конретеном цилиндре), в принципе если впускной коллектор симметричен, количество цилиндров четное, и поршни в вмт приходят парами то можно обойтись без датчика фаз.
2. будет но не критичное, в принципе на 1-2 градуса по кв можно забить ну и не забывать вместе со сменой масла проверять точность установки датчика )
3. существенное, именно по этому и пременяют 60-2 а не по одному сигналу на цилиндр, точные данные сильно колебаются даже в пределах одного двигателя в зависимости от текущего режима и уоз, что уж говорить о разных движках. В принципе народ выкручивается подгоняя решение под ответ через правку карт, к примеру как обстоят дела с вемсом рабоающим от трамблера: в режиме макс назгрузки на оборотах мкр пульсации вращения кв достигают максимума, и хорошо заметно то что фактический уоз состовляет 21гр тогда как по карте он аж 29. Таким образом при откатке углов в эбу забиваются не реальные данные а оптимальные с точки зрения диностенда либо жопометра, а на тот факт что к реалным они отношения не имеют просто забивается.
denisvak
Posts: 403
Joined: Thu Oct 03, 2013 8:00 pm

Re: Обсуждение универсального обработчика датчиков положения

Post by denisvak »

В системах с реперным диском 60-2 на коленвале так же часто используется ещё один датчик - датчик фаз, устанавливается на распредвале. По нему можно узнать какой конкретно цилиндр сейчас на такте сжатия, а какой на всасывании. Им можно жертвовать но тогда у нас получится попарный впрыск - парно работают цилиндры 1-4 и 2-3. У парных одинаково происходит впрыск топлива и поджиг его свечами, соответственно все это происходит два раза за цыкл.

Вопросы - ответы
1)Про основной датчик коленвала ответ в ответе №3. про датчик фаз на распредвале тут http://rotorman.dtt-motorsport.ru/j5-sport/faq.html
2)100% будет, по этому для вторичного датчика нужно сделать некое "окно" в котором он должен плавать.
3)Нужно считать и эксперементировать, но думается что не малое :) Скорее всего коленвал крутится всегда неравномерно, тем более при ускорениях автомобиля. А если взять во внимание мотоцыклетные моторы? :) Они крутятся ещё легче и дальше. Тоже самое со спортивными "легкими" моторами. Потому чем чаще мы "видим" коленвал тем точнее мы сможем поддерживать заданный угол зажигания. Где-то даже делали блок регистрирующий ускорение коленвала и искали оптимальные углы :)
nikll
Posts: 186
Joined: Tue Oct 15, 2013 5:45 am

Re: Обсуждение универсального обработчика датчиков положения

Post by nikll »

denisvak wrote:Где-то даже делали блок регистрирующий ускорение коленвала и искали оптимальные углы :)
Делали, emmibox и делал который http://rotorman.dtt-motorsport.ru/j5-sport/faq.html писал. По факту производительности 8ми битника c509 нехватило для хоть какого-нибудь практического применения замеров ускорения кв.
User avatar
Sergey89
contributor
contributor
Posts: 839
Joined: Wed Sep 25, 2013 5:30 pm
Location: Russia, Velikiy Novgorod

Re: Обсуждение универсального обработчика датчиков положения

Post by Sergey89 »

Для начала неплохо бы собрать информацию по большому числу датчиков, чтобы применить универсальный подход.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Обсуждение универсального обработчика датчиков положения

Post by AndreyB »

Sergey89 wrote:Для начала неплохо бы собрать информацию по большому числу датчиков, чтобы применить универсальный подход.
И да и нет, объясню почему:

Сейчас три человека (Денис, ты и я) паралельно программируют с разной степенью интенсивности совершенно независимый код. Я вижу очень важной задачей попытаться объединить усилия. Эта задача-максимум по разным причинам непроста, но с чего-то нужно начинать :) Моя идея - попытаться сделать хотя бы код, совместимый с тремя нашими конфигурациями датчиков положений валов и предложить вам тестовый код дёрганья форсунок.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
nikll
Posts: 186
Joined: Tue Oct 15, 2013 5:45 am

Re: Обсуждение универсального обработчика датчиков положения

Post by nikll »

+1
Стоит задуматся об универсальном обработчике событий привязанных к положению коленвала.
Я когда прикидывал архетиктуру получил следующее:
нечто типа закальцованной очереди привязанной к к импульсам от коленвала (ну или другого датчика дающего сигналы синхронно с кв) состоящая из количества элементов равного количеству импульсов от датчика коленвала за один полный цикл двигателя (два оборота кв или один оборот рв)
каждый элемент очереди сделан ввиде списка в который добавляются структуры вида:
- callback - что вызвать
- задержка в микросекундах - для более точного позиционированния, к примеру надо точный угол в 7 градусов до ВМТ а ближайшая метка на кв перед этим углом в 9гр и расстояние между метками в 3гр, соответсвенно задержка будет равна 2/3 времени между метками

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

Обработка очереди будет производится в прерывании ДПКВ (ну или что там вместо него) с учетом ДПРВ (если он вообще есть), логика обработки помоему должна быть вполне понятной :)
Для 60-2 требуются два виртуальных вызова обработчика прерывания в углах пропущенных зубьев.

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

Я бы сам с радостью покодил вместе с вами, но я и так по работе по 10-12 часов в день мозги напрягаю, вечером уже тупо нет ни желания ни сил.
User avatar
Sergey89
contributor
contributor
Posts: 839
Joined: Wed Sep 25, 2013 5:30 pm
Location: Russia, Velikiy Novgorod

Re: Обсуждение универсального обработчика датчиков положения

Post by Sergey89 »

Задержку можно считать не просто для текущего зуба, но и с учётом ускорения КВ между зубьями. При равноускоренном движении уменьшит ошибку.

Я выделил всего 4 события требующих синхронизации с положением:
  • Открыть форсунку;
  • Запустить накопление в катушке;
  • Выдать искру;
  • Открыть и закрыть фазовое окно контроля детонации.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Обсуждение универсального обработчика датчиков положения

Post by AndreyB »

Sergey89 wrote:Задержку можно считать не просто для текущего зуба, но и с учётом ускорения КВ между зубьями. При равноускоренном движении уменьшит ошибку.

Я выделил всего 4 события требующих синхронизации с положением:
  • Открыть форсунку;
  • Запустить накопление в катушке;
  • Выдать искру;
  • Открыть и закрыть фазовое окно контроля детонации.
Таааак, держимся заданной темы! Сейчас я начну тебе рассказывать, что еще есть начало интеграции АЦП и наверняка есть что-то еще, и мы совсем отойдём от оригинальной темы - какой должна быть универсальная артитектура начиная от входных прерываний таймера до выхода обработанного сообщения в следующие уровни кода.

Ну хорошо, я тоже немного отойду от темы :) Если признать универсальным подходом вызов обратной функции с параметром 'внутрений индекс события', то дальше мне кажется унивесальным подходом к обработке будет таблица "signal_id >> action_handler"

т.е. например таблица будет задана:
вызвать обработчкик подачи топлива в цилиндр 1 в момент сигнала номер 15.
вызвать обработчкик подачи топлива в цилиндр 4 в момент сигнала номер 30.

При этом обработчик будет знать, на сколько ему надо он должен сначала заснуть перед тем как действительно включить форсунку.

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

Таким образом мне кажется в ДАЛЁКОЙ ПЕРСПЕКТИВЕ можно будет написать единый код, который будет настраиваться на любой двигатель просто набиванием конфигурации маппинга событий в обработчики.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
Sergey89
contributor
contributor
Posts: 839
Joined: Wed Sep 25, 2013 5:30 pm
Location: Russia, Velikiy Novgorod

Re: Обсуждение универсального обработчика датчиков положения

Post by Sergey89 »

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

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

То есть начать нужно не с реализации, а с предъявления требований к реализации.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Обсуждение универсального обработчика датчиков положения

Post by AndreyB »

Sergey89 wrote:Кол-во событий которые нужно привязать к положению влияет и на архитектуру. Скажем если мне известно, что событий всего 4 и больше не надо, то это значит что я могу использовать аппаратные возможности в виде таймера и 4 каналов сравнения для максимально точного выполнения события с заданной задержкой (как у меня сейчас и сделано)
Я принципиально считаю, что пока не ДОКАЗАННО обратное, экономить тики ВРЕДНО. Понятно, что специально разбазаривать ресурсы тоже не стоит - но всё-таки лишние 100 тактов на обработку сигнала даже 10KHz _никакой_ разницы не сделают. Ни-ка-кой.

Если мы хотим начать джихад на тему "можно ли использовать прокладки, или же только харкор регистров", то заходить в этот вопрос нужно с противоположной стороны: 10000 оборотов в минуту, плюс нужно решить какая нам требуется угловая точность. Решив, какая нам нужна угловая точность - можно уже запускать тесты и смотреть, получается ли такая точность или нет. Что я собственно и сделал :) И мои замеры меня убедили, что мы можем себе позволить программный ШИМ.

Если мы хотим точность в 1 градус на 10К оборотов, - 166Hz умножить на то это 360 градусов, 60KHz. Это 0.016666 мс на градус. На скорости 168MHz, это 2800 инструкций на градус.

2800 инструкций - это очень много. Я считаю, что тут немного можно потратить на прокладки.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
Sergey89
contributor
contributor
Posts: 839
Joined: Wed Sep 25, 2013 5:30 pm
Location: Russia, Velikiy Novgorod

Re: Обсуждение универсального обработчика датчиков положения

Post by Sergey89 »

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

Да я не считаю свой подход каким-то единственно верным. Очевидный недостаток его в том виде в котором он сейчас реализован это жёсткая завязка на платформу. Но ошибкой я его не считаю. Ошибка для открытого проекта это скорее выбор какого-нибудь сложнодоставаемого камня с какими-то специфическими возможностями. А stm32 это обычный ширпотреб.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Обсуждение универсального обработчика датчиков положения

Post by AndreyB »

Sergey89 wrote:а я хочу по максимуму сделать всё аппаратно
А почему? Почему ты хочешь всё сделать максимально аппаратно?
Вот вышла новая версия дискавери уже - STM32F4x9 discovery, 180MHz. В ней еще есть шанс, что регистры будут те же. Но через год-то явно выйдет новая плата stm32f5 - и там уже совместимости не будет. Не веришь - обрати внимание, что F1 и F4 не совместимы по регистрам.

В моём случае, я перепишу пару конфигов - ChibiOS за меня отладит всё и за меня смигрирует. А в твоём случае - ты жёстко привязываешься к именно stm32f407.

Посмотри на freeems - они привязались к конкретному процу. Прошло пять лет, мы с тобой прошиваем по USB - а они до сих пор прошивают специальным прощивальщиком, потому что они остались в технологиях 200х годов. Время идёт быстро.

Ну и напомню - в мире есть двигатетели с 5тю, 6тью, восемью и даже с 12тью целиндрами. Аппаратных таймеров именно этой платформы всё, уже не хватит.

Я искренне пробовал программить всё это на регистрах. Какое-то время у меня было параллельно две версии - на регистрах и на ЧибиОС. Потом в какой-то момент я увидел, насколько с прокладкой ОС получается проще, а значит я успеваю написать больше кода за то же время и успеваю дальше продвинуться вперёд.

Формунки подёргать - это всё важно, но не сложно. Но в какой-то момент тебе должно захотеться сделать консоль, должно захотеться начать писать логи в файл или вообще сделать управление по Блютуфу. Вся эта обвязка для удобства работы тоже очень важна, а её проще писать на основе готового кода.

Вот у меня есть serial-over-USB. Я сильно подозреваю, что для этого нужно иметь потоки - иначе это программить ад. Программить этот на регистрах? Искать пример конкретно под stm32f4? Зачем? Лучше я это время потрачу на программирование логики работы форсунок.
А stm32 это обычный ширпотреб.
Через 5 лет stm32f4 будет сложнодоставаемым камнем.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Обсуждение универсального обработчика датчиков положения

Post by AndreyB »

Sergey89 wrote:Нужно ли делать всё софтом, когда столько функций уже сделано аппаратно.
Может мы просто не слышим друг друга. Да, ты прав - таймеры мощная штука и у них действительно богатая функциональность. Почему же я против использования всего потенциала таймеров?

1) чтоб таймер начать использовать, нужно совершить какие-то совершенно магические действия. Тактирование шины, господи, и так далее. Да, всё это нужно сделать только один раз и всё сделать можно - но всё это попахивает дурно. Этот API не для людей. Я верю, что для обработки потокового видео и записи этого потока без этого никак, и люди там должны выжимать всё, что могут. Но у нас-то задача на несколько порядков менее ресурсоёмкая, нам-то зачем себя мучать?

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

3) таймеров более чем ограниченное число.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
Sergey89
contributor
contributor
Posts: 839
Joined: Wed Sep 25, 2013 5:30 pm
Location: Russia, Velikiy Novgorod

Re: Обсуждение универсального обработчика датчиков положения

Post by Sergey89 »

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

F1 и F4 это разные линейки STM32. Это как tiny и mega у AVR.

По моему мнению, проблема freeems в том, что они взяли автомобильный камень который кроме как в сша нигде не купишь свободно. Такой подход пригоден для коммерческих проектов у которых ограниченный срок поддержки.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Обсуждение универсального обработчика датчиков положения

Post by AndreyB »

Sergey89 wrote:Я считаю, что при софтварной реализации упрёшься где-нибудь в ограничения и начнутся пляски с бубном, когда проект перейдёт из стадии рассчитал время впрыска и загрузил значение в таймер.
Вот когда упрёшься - тогда и съоптимизируешь. А преждевременная оптимизация - это корень всех проблем, и это не я сказал, а умный дядя http://ru.wikipedia.org/wiki/%D0%9A%D0%BD%D1%83%D1%82,_%D0%94%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%B4_%D0%AD%D1%80%D0%B2%D0%B8%D0%BD

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified" — Donald Knuth
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
Sergey89
contributor
contributor
Posts: 839
Joined: Wed Sep 25, 2013 5:30 pm
Location: Russia, Velikiy Novgorod

Re: Обсуждение универсального обработчика датчиков положения

Post by Sergey89 »

Может мы просто не слышим друг друга. Да, ты прав - таймеры мощная штука и у них действительно богатая функциональность. Почему же я против использования всего потенциала таймеров?
Но мы то делаем не гирлянду из светодиодов. В первую очередь ЭБУ должен быть максимально надёжным, потому что планируется его повседневная эксплуатация. И использование аппаратных возможностей несколько успокаивает, т.к. реализация заданного функционала получается полностью открытой, а не спрятанной за абстракциями.
nikll
Posts: 186
Joined: Tue Oct 15, 2013 5:45 am

Re: Обсуждение универсального обработчика датчиков положения

Post by nikll »

+1 за таймеры!!!
нафиг нафиг считать руками задержку и реализовывать ее через засыпание потоков.

Как минимум следует повторить подход vems где на одном таймере работают все форсунки а на другом все катушки. Алгоритм конечно посложнее чем под одному тайеру на канал но задо гораздо универсальней.

Преждевременная переоптимизация корень проблем, а если кодить без продумывания архетиктуры то в последтсвии уперевшись в производительность потребуется не оптимизация а полное переписыванние кода в связи с изменением архетиктуры и логики обработки.
Стоит задуматся об универсальном обработчике событий привязанных к положению коленвала.
Я когда прикидывал архетиктуру получил следующее:
нечто типа закальцованной очереди привязанной к к импульсам от коленвала (ну или другого датчика дающего сигналы синхронно с кв) состоящая из количества элементов равного количеству импульсов от датчика коленвала за один полный цикл двигателя (два оборота кв или один оборот рв)
каждый элемент очереди сделан ввиде списка в который добавляются структуры вида:
- callback - что вызвать
- задержка в микросекундах - для более точного позиционированния, к примеру надо точный угол в 7 градусов до ВМТ а ближайшая метка на кв перед этим углом в 9гр и расстояние между метками в 3гр, соответсвенно задержка будет равна 2/3 времени между метками

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

Обработка очереди будет производится в прерывании ДПКВ (ну или что там вместо него) с учетом ДПРВ (если он вообще есть), логика обработки помоему должна быть вполне понятной
А теперь опишу логику.

Прерывания:
1. прерывание ДПКВ - по переднему и заднему фронту сигнала ДПКВ + виртуальный вызов этого прерывания из таймера симулирующего пропущенные зубья
2. прерывание таймера-обработчика - взводится в прерывании ДПКВ по наименьшему таймеру из списка событий текущего зуба дпкв

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

Как я это вижу:
В основном цикле происходит расчет углов начала впрыска и УОЗ, эти данные забиваются в закольцованную очередь на нужный зуб с требуемой задержкой времени запуска.
Попадаем в прерывание ДПКВ, заносим время прошедшее с предыдущего прерывания в переменную, берем из списка событий на текущем зубе событие с наименьшим временем, если время не равено нулю то взводим таймер на это время а в таймере уже вызываем функцию обработчик списка событий, иначе если время равно нулю то сразу вызываем функцию обработчик списка событий.
В обработчике событий смотрим текущее событие и выполняем его с последующим удалением записи.

К примеру работа одной форсунки на диске 60-2:
В основном цикле расчитали что время впрыска 10мс и начало впрыска в -11гр ВМТ, находим в основной очереди список относящийся к -4тому от ВМТ зубу, в эту очередь заносим событие открытия форсунки с временем прохождения одного градуса.
Когда ДПКВ вызовется на -4 зубе от ВМТ основной обработчик увидит событие открытия форсунки назначенное на время прохождения одного градуса от время вызова прерывания -4 зуба, соответсвенно взведет таймер, и добавит в статическую переменную основного обработчика указатель на назначенное событие.
Таймер вызовет основной обрабочик, обработчик возьмет указатель на событие, выполнит событие и удалит его (ну там занулит или флаг повесит тут думать надо), после чего снова проверит текущий список событий.
При выполнении события открытия форсунки будет открыватся форсунка и взводится другой таймер отвечающий за закрытие форсунок, он не зависим от ДПКВ.

Ну вот как то так, прошу простить за слабоструктурированный поток мыслей, просто я на работе сижу кодю очередную хрень и пока никто не видит отвекся на вас )
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Обсуждение универсального обработчика датчиков положения

Post by AndreyB »

nikll wrote:+1 за таймеры!!!
нафиг нафиг считать руками задержку и реализовывать ее через засыпание потоков.
Через засыпание потоков нужной точно не получается :( Нужная точность получается при использовании одного 1MHz таймера и програмном управлении выходами.

Совсем не важно, таймеры или програмно. К сожалению, мы докатились до спора "ассемблер или C", который потом назывался "С или Java". Если программировать плохо, можно проебать полимеры на любом языке на любой архитектуре. Если программировать хорошо, платформы более высокого уровня обычно упрощают и ускоряют разработку.

В нормально написанном коде переход от одной имплементации работы с форсунками к другой имплементации полного переписывания вызывать не должен. Если писать с rtos, её всегда можно не использовать там, где её лучше не использовать. А вот наоборот не получиться - если писать на регистрах, то получить немного комфорта только в одном месте уже не получится - нужно будет писать на регистрах везде.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
Sergey89
contributor
contributor
Posts: 839
Joined: Wed Sep 25, 2013 5:30 pm
Location: Russia, Velikiy Novgorod

Re: Обсуждение универсального обработчика датчиков положения

Post by Sergey89 »

Вообще есть ещё куча других вопросов которые надо решить помимо универсального обработчика датчиков положения. Я так понимаю у нас уже есть какие-то свои реализации обработчиков, которые можно использовать, поэтому я бы сосредоточился на разработке алгоритмов не зависящих от платформы.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Обсуждение универсального обработчика датчиков положения

Post by AndreyB »

Sergey89 wrote:Вообще есть ещё куча других вопросов которые надо решить помимо универсального обработчика датчиков положения. Я так понимаю у нас уже есть какие-то свои реализации обработчиков, которые можно использовать, поэтому я бы сосредоточился на разработке алгоритмов не зависящих от платформы.
Ты абсолютно прав - создал топик обсуждения собсвенно вариантов совместной работы http://rusefi.com/forum/viewtopic.php?f=6&t=205
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
Maxi
Sr Consultant
Sr Consultant
Posts: 786
Joined: Wed Oct 23, 2013 4:25 pm

Re: Обсуждение универсального обработчика датчиков положения

Post by Maxi »

nikll wrote:
denisvak wrote:Где-то даже делали блок регистрирующий ускорение коленвала и искали оптимальные углы :)
Делали, emmibox и делал который http://rotorman.dtt-motorsport.ru/j5-sport/faq.html писал. По факту производительности 8ми битника c509 нехватило для хоть какого-нибудь практического применения замеров ускорения кв.
Это по какому такому факту? ;))
User avatar
XDA
Posts: 441
Joined: Wed Oct 23, 2013 7:28 pm

Re: Обсуждение универсального обработчика датчиков положения

Post by XDA »

из практики: в большей точности, чем 0.1 градус нет необходимости.
Теория хороша в том и только том случае, если она может достоверно предсказать результаты каждого нового опыта
nikll
Posts: 186
Joined: Tue Oct 15, 2013 5:45 am

Re: Обсуждение универсального обработчика датчиков положения

Post by nikll »

да и 0,1 это как то слижком точно ) если сигнал снимать с распредвала или даже трамблера то там тупо механические люфты легко достигают пары градусов. У себя на трамблерном движке намерил 4градуса по коленвалу :twisted:
User avatar
XDA
Posts: 441
Joined: Wed Oct 23, 2013 7:28 pm

Re: Обсуждение универсального обработчика датчиков положения

Post by XDA »

0.1 градуса это необходимая и достаточная точность :)))
Теория хороша в том и только том случае, если она может достоверно предсказать результаты каждого нового опыта
frig
contributor
contributor
Posts: 569
Joined: Wed Oct 23, 2013 8:05 pm

Re: Обсуждение универсального обработчика датчиков положения

Post by frig »

XDA, вот тут http://rotorman.dtt-motorsport.ru/j5-sport/j5vsmotec.htm

Точность реализации УОЗ (угловых минут) вычислительная при условии абсолютной точности триггеров оборотов. 15 2 на 1000rpm, 20 на 10000rpm 0.5 на 1000rpm 5 на 10000rpm
Можно от этого еще отталкиваться. Если есть возможность заложить выше точность - хуже от этого не будет.
skype: frig_frig
User avatar
XDA
Posts: 441
Joined: Wed Oct 23, 2013 7:28 pm

Re: Обсуждение универсального обработчика датчиков положения

Post by XDA »

в градусе содержится 60 угловых минут. 2 угловых минуты это точность 0.05 градуса.
Теория хороша в том и только том случае, если она может достоверно предсказать результаты каждого нового опыта
frig
contributor
contributor
Posts: 569
Joined: Wed Oct 23, 2013 8:05 pm

Re: Обсуждение универсального обработчика датчиков положения

Post by frig »

Да я о том и говорю. 0.1 - не предел.
skype: frig_frig
User avatar
XDA
Posts: 441
Joined: Wed Oct 23, 2013 7:28 pm

Re: Обсуждение универсального обработчика датчиков положения

Post by XDA »

при этом обратите внимание, что на самых нужных режимах -максимальных оборотах, точность падает в 10 раз!
с моей точки зрения - это неприемлемо. нужна точность 0.1 градуса.
Теория хороша в том и только том случае, если она может достоверно предсказать результаты каждого нового опыта
Post Reply