Обсуждение схемы от Makar

Разработка впрыска топлива на базе SECU-3. Fuel injection related discussion.

Moderator: STC

nikll
LQFP144 - On Top Of The Game
Posts: 553
Joined: Sun Nov 06, 2011 9:20 pm
Location: Russia, Yekaterinburg
Contact:

Re: Обсуждение схемы от Makar

Post by nikll »

Qwertty wrote:Если бы я когда нибудь писал прошивку для ЭБУ, то я бы на ней и ездил. Вроде очевидно. Если это основание для веры человеку на слово, то выходит что тут только lsasha7 говорит истину. Ибо он тут похоже один, кто этим занимается. Я же попадаю в категорию балаболов. :D Утешением служит только то, что туда же попадают и все остальные. :D
Кстати в английском языке нет глагола делать в прошедшем времени. Там есть сделал, но нет - делал. Это важный момент :)
Может я и пионер в деле управления ДВС, но программы пишу уже 24 года. При этом последние лет 15 - для встроенных систем. И как распределять ресурсы при их ограниченном количестве я знаю хорошо. Кроме того я аргументирую свою позицию - рассказываю как 2 каналами таймера управлять 4-8 форсунками и почему это вообще возможно. Вместо возражений по делу в ответ какие то заклинания о том, как хорошо иметь кучу таймеров. Хорошо конечно, но совсем не обязательно. Может они впоследствии и пригодятся. А может и нет. Да не хочу я больше спорить - это бессмысленная трата времени. Делайте как считаете нужным. Хоть на кортексе, хоть на блекфине. :)
lsasha7, молодец :) но тем не мение он не бахвалялся впустую какой он крутой спец и сколько лет он програмирует... lsasha7 просто хорошо подумал головой, изучил имеющиеся алгоритмы, по непонятным ему вопросам проконсультировался с разными людьми (и со мной в том числе) и реализовал алгоритм который я разжевывал на форуме. В результате получился простенький ЭБУ на более-мение адекватном алгоритме. Несколько лет назад я на 16том пике делал впрыск, одноканальный, четыре форсунки одновременно под карбом :), сигнал брался с трамблера и ДАДа и оно работало :))) но без учета темпиратур, фактического наполнения, пульсаций давления... и в итоге откзаался от этого т.к. карб реально универсальней работал, в любую погоду при любых условиях выдавал заведомо рабочую смесь в отичие от недовпрыска.

Я вот только понять не могу зачем тебе надо упихивать код в примитивный камень когда по цене он сопостовим с современным? из лени изучения новой архетиктуры? ну тогда ты ССЗБ.
В хард-рилтайме опыта у меня действительно мало зато у меня многолетний опыт программирования сетевых демонов под *nix системы, и это не тупая форкующаяся херь а полноценный FSM с частью кода вынесенной в пространство ядра для ускорения валидации коннектов, иначе говоря однопоточная событейная система которая вытягивает до сотен тысяч! одновременных tcp коннектов. Из ближайших примеров подобной архетиктуры могу назвать nginx.

При большом желании можно впихивать довольно забористые алгоритмы в совершенно тупые камни, вон хотябы взять известную игровую приставку денди :) там камень чуть больше мегагерца, однако есть довольно серьезные игры. Я разбирал одну из простейших дендевских игр "BattleCity" - танчики по русски, так даже там целая куча изебизмов чтобы оно влезло в железо. Зачем переусложнять код только ради желания обойтись двумя таймерами когда можно взять практически за те же деньги камень в котором таймеров хоть жопой жуй?

Поверь я прекрастно представляю себе как можно через один таймер рулить всеми событиями привязанными по времени, но во первых придется писать диспетчер с очередью (у STC в коде есть пободное на общем таймере), во вторых камень будет делать довольно много лишней работы, в третих либо не получится вытеснять прерывания либо будут вытеснятся все прерывания с этого таймера, а нам нужна гибкая система приорететов. Ну и напоследок я надеюсь ты не будеш утверждать что диспетчер с очередью событий будет точней таймеров c прерываниями под одному на каждый канал?
nikll
LQFP144 - On Top Of The Game
Posts: 553
Joined: Sun Nov 06, 2011 9:20 pm
Location: Russia, Yekaterinburg
Contact:

Re: Обсуждение схемы от Makar

Post by nikll »

Stranger21 wrote:что ДАЕТ этот алгоритм? .. не напыщенно - это правильный алго!! . а Реально - ЧТО дает ? время разгона? количество топлива для разгона? средний расход? что он мне даст? нива крок раскручивает Кв в Хх за 0.4 -0.6 секнды с 880 до 6500 , разгоняется только на 2й передаче с 10 до 80км в час за 7.2 секунды ...
расход на скорости 60 км в час 5.4л на 100 .
что мне даст этот алго? .
а я веть еще могу ДФ поставить и на фазированый впрыск перейти ....
так что лучше ? супер алго ? или дф ? )))
А что дает впрыск вообще? у меня мой мотоцикл с места до 70 разгоняется за 4 секунды (на первой быстрее не получается колесо тупо срывает в букс) или с места до 120кмч за 10сек не переключая передачь вообще (трогастя со второй и на ней же 120) :) там стоят два тупейших карбюратора даже без ускорительных насосов и зажигание у которого опережение аналоговое О_О из за свойств самого индукционного датчика. Но ведь едет же :) и хер ты его на ниве догониш (далеко не каждая машина способна не отстать).

Так вот, ЭБУ с нормальными аглоритмами и калибровками даст этому мотору необходимую стабильность смеси вне зависмости от темпиратуры двигателя и воздуха, даст адекватные углы в зависимости от оборотов и наполнения, даст максимальный кпд по всем диапазоне оборотов и нагрузок а не только в режиме полный газ от оборотов МКР до оборотов макс. мощности на прогретом движке и темпиратуре воздуха +20гр.

А угребищный алгоритм нихрена не даст, результат может выйти даже хуже чем с родными карбюраторами... Сейчас покрайней мере если я откручу ручку я точно знаю что мотоцикл прыгнет вперед как гепард из засады без всяких провалов и раздумий, в отличии от патриота с навороченным бошевским ЭБУ под евро3 с электронным дросселем и индивидуальными катушками, патрик вечно тупит и нихрена не тянет, разгон до сотни больше 20сек, при том что такой же патриот с таким же движком но с микас-спорт ест на треть меньше бензина и легко укладывается в 12сек до сотни без всяких там ДК и электронных досселей - вот это я понимаю толк от алгоритма :).
dimonfish
LQFP144 - On Top Of The Game
Posts: 365
Joined: Fri Aug 19, 2011 4:34 am
Location: Севастополь, UA

Re: Обсуждение схемы от Makar

Post by dimonfish »

от я говорю, зачем мешать реализовывать в железе нормальные алгоритмы впрыска? :-) со своими январями :-) пиписьки (сори :-) ) вываливать к сравнению. вот меня солекс на таврии устраивает (пока) и разгоняемся аки демон на 2й до 80, на 1й тапку ваще до пола нельзя давить бо оно резиной свистит :-) а если езди в "пинсионер стайл" то расход 4.5 траса\ 6 город. и что дальше? А дальше - нормальный впрыск со стремлением максимально выжать КПД из мотора во всех режимах и январь\микас на мой взгляд етому не соответсвует :-) так что, странгер, - не мешай, ато в большинстве своем токо тролиш. мы уже помню опсасывали слет спортивного ЕЕПРОМа ;-)
сори за офтоп, не сдержалсо :-)
User avatar
STC
LQFP144 - On Top Of The Game
Posts: 2420
Joined: Fri Oct 22, 2010 10:47 pm
Location: Ukraine, Kiev
Contact:

Re: Обсуждение схемы от Makar

Post by STC »

Вообще я наверное запрещу рекламировать тут всякие вражеские разработки типа Января. Это банальное неуважение к разработкам представленным на этом сайте, это плевок в лицо разработчикам. Замечу, что я различаю понятия "рекламировать" и "ссылаться". Stranger21, тебя касается. Я уже неоднократно тебя просил не делать этого, думаю что прйдется применять меры. Этот человек плюет в лицо участникам форума и при этом хочет чтобы его тут уважали и прислушивались к его мнению.
Author of the SECU-3 project. SECU-3 Engine control unit / Ignition control system
SECU-3.org (Русский)
SECU-3.org (English)
SECU-3 Club ВКонтакте
SECU-3 EMS Project Facebook
Qwertty
LQFP144 - On Top Of The Game
Posts: 252
Joined: Thu Jul 26, 2012 12:35 pm

Re: Обсуждение схемы от Makar

Post by Qwertty »

nikll wrote: lsasha7, молодец :) но тем не мение он не бахвалялся впустую какой он крутой спец и сколько лет он програмирует...
С тебя пример беру :mrgreen: Это ты тут уже дважды всем рассказал, что 8 лет программируешь и круче тебя только горы :mrgreen:
А я просто ответил на вопрос - знаю ли я о чем говорю, когда предлагаю разбить управление форсунками на 2 канала таймера, т.е. каждый канал обрабатывает много одинаковых событий разнесенных во времени. Это нормальная практика, скажу больше - именно такой метод используется на практике в 90% встроенных систем. АЦП тому яркий пример - ресурс один, вход у него один, но добавив мультиплексор и разнеся измерения по времени можно оцифровать множество сигналов. Если встроенного мультиплексора не хватает, а время в избытке - можно добавить еще и внешний мультиплексор. И т.д.
nikll wrote: Я вот только понять не могу зачем тебе надо упихивать код в примитивный камень когда по цене он сопостовим с современным? из лени изучения новой архетиктуры? ну тогда ты ССЗБ.
Я давно и успешно использую армы. В том числе и кортексы. Хотя и другого производителя - NXP. Мне они просто намного больше нравятся. Нормальными таймерами например - все таймеры 32 бита, 4 выхода и 4 входа обычно. Можно одновременно все использовать, и совпадение и захват. Т.е. для того же функционала вместо 1 таймера потребуется 4 таймера stm32f103. Один из таймеров вообще имеет 7 каналов, 6 на выход выведены 1- нет. И дополнительно два захвата. Можно на 1 таймере весь бензовпрыск построить на 4 цилиндра и два канала зажигания. Два входа захвата например ДПКВ и ДФ. Причем это без упаковки ресурсов по времени - тупо в лоб - 1 канал=1 форсунке. Но он тоже 3,3В, а я геморрой в схеме не люблю. Согласовывать как входы так и выходы, иметь три питания - два 5В и одно 3,3В и т.д. Если кто думает что толерантность к 5В позволит делать со входами то же, что и на 5В контроллерах, то сильно ошибается. Придется диодную защиту делать самому - в контроллере верхний п канальный мосфет включен последовательно с диодом. И не ограничивает напряжение на входе. Это позволяет подавать на вход 5В, но позволяет подавать и 15В. Поэтому защита обязательна. Да - это не дорого. 1 диод на вход по рублю. Но это место на плате, вторая шина 5В разведенная по всей плате - ведь надо куда то сливать энергию диодом. ИМХО - лишний геморрой. На выходах 3.3В кристаллов тоже не все в шоколаде. Стандартные решения типа uln2003 не проходят - там минимум 3,5В. Реально может и заработать, разброс параметров никто не отменял. Но у одного будет работать, у другого нет. Это плохой подход. Я еще понимаю если бы брался 32 битник предназначенный для ЭБУ. Та же ST выпускает таких аж два семейства. Достаточно шустрых и конечно :lol2: на 5В. Они наверно идиоты - ведь сами же кортексы предлагают причем в 2 раза дешевле и несколько шустрее. Но все почему то не берут кортекс, а берут специально заточенный под авто кристалл. Ну не дурни ли? :mrgreen: Или тут все с точностью до наоборот? :mrgreen:
Та же NXP одно время предлагала 3,3В кристалл для автоприменений. С рабочей температурой 125С. Но - не пользовался спросом и его просто сняли с производства. А он был шустрей тех автомобильных, что ST и сейчас выпускает. Да и таймерами LPC был побогаче - что то в районе 30 каналов сравнения на выход и около 15 на захват. Так что дело точно не в нехватке таймеров. Больше NXP попыток выкинуть арм на авторынок не предпринимает.
Да и даже выбранный мной кристалл более современный чем stm32f103 :mrgreen: - он банально позже появился. Так что на старье не я ориентируюсь, а наоборот - у меня самое современное ядро выходит :lol:
nikll wrote: При большом желании можно впихивать довольно забористые алгоритмы в совершенно тупые камни
А тут типа навороченный алгоритм? Мне его кстати еще придумать предстоит, но не думаю что изобрету нечто монументальное. И дело не в том - потянет ли выбранный процессор вычисления. На один расчет при 6000 оборотов приходится чуть меньше 80000 тактов. Сложно придумать такой расчет чтоб это время стало недостаточным. Я - точно этого не смогу. Делать систему на вырост и добавлять к ней потом ненужные мне штуки я тоже не собираюсь. 4 цилиндра и точка. Может пятый канал все же добавлю и верну моновпрыск на свой мотор. Он там раньше стоял, но задолбал глюками и был демонтирован. Но я его не выбросил :lol: - лежит в пакете вместе с проводкой. Вот ЭБУ я куда то дел - ну и фиг с ним.
nikll wrote: Ну и напоследок я надеюсь ты не будеш утверждать что диспетчер с очередью событий будет точней таймеров c прерываниями под одному на каждый канал?
Не буду ибо точность будет идентична. Разница может в 2-5 тактов погоды точно не сделает. А приоритетами просто надо уметь пользоваться. Несмотря на 1 вектор прерывания на все события захвата и совпадения вполне реально их разделить по приоритетам. Не в АВР конечно, там приоритетов просто нет. Единственно будет перерасход стека. Но что делать. Да и даже для всех 4 событий будет максимум три уровня вложенности. Пусть это 150 лишних байт на стеке - при доступных 6кб я это переживу. Опыт использования ARM7 тут сильно пригодится - там было всего два приоритета - IRQ и FIQ. Но можно было немного извратится и получить более приемлемую модель прерываний. Чем в общем то все и занимались :lol: Да и я не против stm32f103 - не мешаю же ничем. Кому нужна возможность при необходимости MP3 плеер в ЭБУ встроить может спокойно делать на нем. Спорить о элементной базе можно долго и без результата. Я этого не хочу. Надо закрыть тему обсуждения контроллеров. Толку с этого не будет, все останутся при своих мнениях. Тут и так три варианта уже - мега128 потому как она есть у тех кто на ней хочет, stm8a потому как его более чем достаточно и он именно для автоприменений, а также stm32f103 потому как у него таймеров много и 72МГц такта. Я могу подбросить еще вариантов, уже без стеба - LPC1768 (100МГц) или старенький LPC2148(60МГц). Они шустрые, много НОРМАЛЬНЫХ таймеров и они у меня уже есть. :mrgreen: Но они не автомобильные и на 3.3В питания. Или ПЛИС внедрить. Тот же EPM570 - чисто аппаратно обсчитает много таймеров и прошимит выходы. Он же и шкив 60-2 может обработать. Стоит 5$ всего. Но опять же 3,3В. Если мало есть спартан 3АN - обсчитает уже с 50 таймеров и штук пять шкивов 60-2. Ну и т.д. Только смысла во всем этом нет. Никто свой выбор не бросит. Я - могу, если предложат приемлемый вариант. Но у нас доступен только AVR32UC3C с ценой около 1000р. Меня он бы устроил - 5В, автомобильный, достаточно шустрый. Имеет FPU. И у меня есть под него отладчик :mrgreen: В общем то под все предлагаемые варианты отладчик у меня имеется. Но так думаю не у всех. Да и всеж стоит этот AVR32UC3C несколько дороговато. Хотя автомобильных дешевых и не бывает - там флеш дорогая. Надежно работать при 150С и не стираться не так и просто. За это всегда берут дополнительные деньги. Нормальными условиями считается +25С. Инустриальный кристалл значит допускает перегрев на 85-25 = 60С. А автомобильный 150-25 = 125С. Разница более чем в 2 раза. В общем давайте закончим про "любимый лунный трактор". В смысле о кристаллах. Еще конкретные алгоритмы обсуждать можно, а разговоры за жизнь надоели.
ender11
LQFP112 - Up with the play
Posts: 197
Joined: Sat Dec 11, 2010 4:05 pm

Re: Обсуждение схемы от Makar

Post by ender11 »

Qwertty wrote:Но у нас доступен только AVR32UC3C с ценой около 1000р.
скока-скока? :o я покупал в efo.ru at32uc3c2512 за $9,85
Qwertty
LQFP144 - On Top Of The Game
Posts: 252
Joined: Thu Jul 26, 2012 12:35 pm

Re: Обсуждение схемы от Makar

Post by Qwertty »

Автомобильный - от 31$. В ЭФО нет вообще. Смотрел AT32UC3C1512C-AZT или AT32UC3C1512C-AZR. Буковка Z должна иметь место быть. Не U!
nikll
LQFP144 - On Top Of The Game
Posts: 553
Joined: Sun Nov 06, 2011 9:20 pm
Location: Russia, Yekaterinburg
Contact:

Re: Обсуждение схемы от Makar

Post by nikll »

Qwertty, там не несколько тактов разницы будет, посущественней.
Вот смотри твой вариант по прерываниям:
1. ДПКВ - вытесняет все, отрабатывает тактов за 300
2. таймер очереди - отрабатывает 1000-2000 тактов (на обработку очереди, т.к. очередь в прерывании то соответсвенно volatile и каждая операция размазывается существенно)
если прервания очереди сделать приоретентей ДПКВ то это будет плохо т.к. очередь довольно долго относительно ДПКВ отрабатывает (что приведет к неправельному замеру времени между зубьями), если на оборот то получаем погрешность кроме того что в самой очереди еще и время прерывания ДПКВ.

Вариант с индивидуальными прерываниями:
1. ДПКВ - вытесняет все кроме форсунок и катушек
2. пачка индивидуальных таймеров на форсунки и катушки, в прерывании происходит толко смена состояния пина и если это срабатывание на открытие то взвод таймера на следующее срабатывание для закрытия - время 10-30 тактов и то если програмно рулить, в том же январе форсунки рулятся через аппаратный ШИМ который конфигурируется каждые пол оборота в основном цикле после расчета времени впрыска и соответсвенно не занимают времени прерываний и ресурсов вообще... В stm32f103v каналов таймеров с шимом вполне достаточно...
User avatar
STC
LQFP144 - On Top Of The Game
Posts: 2420
Joined: Fri Oct 22, 2010 10:47 pm
Location: Ukraine, Kiev
Contact:

Re: Обсуждение схемы от Makar

Post by STC »

Да, подтверждаю. C прерыванием от ДПКВ туго дела обстоят, особенно если зубьев болльше 60. По каждому зубу нужно производить проверку на разные события, которые привязываются к углу поворота коленвала (нужна обязательно аппаратная реализация деления). Логика прерывания довольно сложная. Все это вместе на SECU-3 занимает в среднем 50мкс и более. Есть еще другие прерывания...
Куча volatile переменных + логика синхронизации. Прерывание раздувается не на шутку. После определенных оборотов программа просто захлебывается.
Author of the SECU-3 project. SECU-3 Engine control unit / Ignition control system
SECU-3.org (Русский)
SECU-3.org (English)
SECU-3 Club ВКонтакте
SECU-3 EMS Project Facebook
nikll
LQFP144 - On Top Of The Game
Posts: 553
Joined: Sun Nov 06, 2011 9:20 pm
Location: Russia, Yekaterinburg
Contact:

Re: Обсуждение схемы от Makar

Post by nikll »

В январях/микасах та же проблема, время выполнения забивается прерываниями и после определенных оборотов происходит сброс по watchdog. В j5ls_v46 emmibox решал эту проблему по средством "рассинхронивания" кода путем выноса всего возможного в основной цикл.
У себя код я проектирую изначально на минимизацию времени прерываний и максимальную асинхронность.

Краткое описание:
Все что завязанно на ожидание железа (к примеру АЦП) делается через прерывания, к примеру запускаем преобразование АЦП для ДТОЖ с настроенным прерыванем и работаем дальше, как АЦП отработает вызовется прерывание в котором уже мой код сохранит результат в нужную volatie переменную.
Сами прерывания как можно короче по времени. Все что возможно делать асинхронно делается асинхронно.

В прерываниях взводятся флаги на вызов определеных функций в основном цикле, к примеру:
1. запросы с различных АЦП
2. шаг подстройки РХХ
3. расчет наполнения, времени впрыска
5. расчет угла зажигания (и времени накопления если используется)
итд итп

В основном цикле висит диспетчер по флагам и за каждый цикл вызывает одну фунцкию в соответсвии с флагами разрешения, вызов функций в диспетчере распологаются в порядке важности, результаты работы функций хранятся в volatie структуре с которой уже работают прерывания отвечающие за управление перефирией.
К примеру ничего страшного если на 10000об наполнение будет расчитываться лиж раз в несколько тактов, или УОЗ будет перерасчитываться раз в два десятка оборотов КВ, главное чтобы УОЗ был точно в нужном угле котоырй мы расчитали в последний раз, или время впрыска соответсвовало расчитанному в последний раз. На высоких обротах УОЗ как и время впрыска мнгновено не меняются, даже если резко закрывать дроссель за пару циклов наполнение почти не изменится т.к. просто ногу так быстро с педали не поднять :) (или вы можете нажать на педаль газа со сверхзвуковой скоростью?)
Порядковая приотерезация в диспетчере позволит сдвигать менее важные функции в конец и соответсвенно они будут отрабатывать только после того как затребованные более важные отработают, уж лудьше shift-light (или что там Stranger21 хотел) перестанет работать после 12000 чем УОЗ перестанет расчитываться, или логи перестанут записываться вместо существенного опаздания расчета наполнения.

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

К тому же такая архетиктура позволит достаточно легко и безболезненно расширять функционал просто добавляя флаги в диспетчер и расширяя структуру состояния новыми полями.
Post Reply