Приоритеты и потоки
Приоритеты и потоки
Обсудим разделение и выполнение задач по приоритетам?
Я выделяю три типа задач. Первые это задачи, которые нужно выполнять в соответствии с угловым положением КВ. Вторые это задачи, которые нужно выполнять с заданной периодичностью. Третий тип задач это задачи, которые можно выполнять в любое время.
Первый тип задач имеет наивысший приоритет, второй тип задач менее приоритетный и третий тип задач наименее приоритетный.
Как это реализовал я.
Задачи по угловому положению выполняются в прерывании таймера задержки (между зубьями) с высоким приоритетом. При этом если требуется выполнить какое-то более продолжительное событие (например обработка сигнала с интегратора канала детонации) я устанавливаю флаг и программно генерирую прерывание другого таймера с более низким приоритетом для того, чтобы не занимать прерывание таймера задержки, но при этом не пропустить обработку этого события.
Задачи с заданной периодичностью выполняются в прерывании ещё одного таймера с более низким приоритетом.
Задачи с наименьшим приоритетом выполняю в бесконечном цикле в main.
Задачи первого типа: открытие форсунки, начало накопления в кз, завершение накопления в кз, запуск и остановка интегратора канала детонации. Всего 4 задачи.
Задачи второго типа: управление хх, расчёт наполнения и времени впрыска, чтение состояния датчиков, расчёт обогащения при ускорении и т.д.
Задачи третьего типа: расчёт базового состава смеси, расчёт УОЗ, управление актуаторами и т.д.
Я выделяю три типа задач. Первые это задачи, которые нужно выполнять в соответствии с угловым положением КВ. Вторые это задачи, которые нужно выполнять с заданной периодичностью. Третий тип задач это задачи, которые можно выполнять в любое время.
Первый тип задач имеет наивысший приоритет, второй тип задач менее приоритетный и третий тип задач наименее приоритетный.
Как это реализовал я.
Задачи по угловому положению выполняются в прерывании таймера задержки (между зубьями) с высоким приоритетом. При этом если требуется выполнить какое-то более продолжительное событие (например обработка сигнала с интегратора канала детонации) я устанавливаю флаг и программно генерирую прерывание другого таймера с более низким приоритетом для того, чтобы не занимать прерывание таймера задержки, но при этом не пропустить обработку этого события.
Задачи с заданной периодичностью выполняются в прерывании ещё одного таймера с более низким приоритетом.
Задачи с наименьшим приоритетом выполняю в бесконечном цикле в main.
Задачи первого типа: открытие форсунки, начало накопления в кз, завершение накопления в кз, запуск и остановка интегратора канала детонации. Всего 4 задачи.
Задачи второго типа: управление хх, расчёт наполнения и времени впрыска, чтение состояния датчиков, расчёт обогащения при ускорении и т.д.
Задачи третьего типа: расчёт базового состава смеси, расчёт УОЗ, управление актуаторами и т.д.
- AndreyB
- Site Admin
- Posts: 14343
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Приоритеты и потоки
Сложный вопрос. Меня смущает, что нет объективных средств диагностики.
Точнее скажем так: а насколько мы уверены, что проблема вообще есть? И как мы можем проблему _увидеть_, чтоб удостовериться, что мы её решили? Если мы не видим проблему, мы не увидим и решение.
Какие операции могут что-то замедлить и на сколько? Математика? Только если очень сложная и только если она блокирует прерывания. Работа с spi? вроде нет. DMA? Не знаю, вроде тоже нет.
С другой стороны, немного перестраховаться конечно стоит. Моё сбалансированное видение для меня: я поднимаю приоритет прерываний - потому что там самая важная логика. Ну и нужно очень аккуратно смотреть, чтоб нигде не было долгих блокировок с блокировкой прерываний. Для самоуспокоения этого достаточно, дальше копать кажется нужно будет только если будет явная проблема.
Точнее скажем так: а насколько мы уверены, что проблема вообще есть? И как мы можем проблему _увидеть_, чтоб удостовериться, что мы её решили? Если мы не видим проблему, мы не увидим и решение.
Какие операции могут что-то замедлить и на сколько? Математика? Только если очень сложная и только если она блокирует прерывания. Работа с spi? вроде нет. DMA? Не знаю, вроде тоже нет.
С другой стороны, немного перестраховаться конечно стоит. Моё сбалансированное видение для меня: я поднимаю приоритет прерываний - потому что там самая важная логика. Ну и нужно очень аккуратно смотреть, чтоб нигде не было долгих блокировок с блокировкой прерываний. Для самоуспокоения этого достаточно, дальше копать кажется нужно будет только если будет явная проблема.
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: Приоритеты и потоки
Один из вариантов это выполнять задачи в общем цикле (или как у тебя в потоках) в котором и отмерять нужные интервалы времени, а уже в конкретной функции определять точный интервал времени.
Мой вариант опять таки завязан на "железо", но он в принципе позволяет не думать о каких-то возможных задержках.
Мой вариант опять таки завязан на "железо", но он в принципе позволяет не думать о каких-то возможных задержках.
Re: Приоритеты и потоки
Ещё интерес вызывает периодичность вызова функций расчёта и управления. Можем ли мы сами качественно определить необходимые временные интервалы?
Например частота расчёта циклового наполнения. Считать постоянно или считать с какой-то периодичностью? В достаточно старой OEM системе (середина 90-х годов) я встречал частоту 100 Гц. Что если записать спектр изменения давления при быстром открытии дроссельной заслонки?
Например частота расчёта циклового наполнения. Считать постоянно или считать с какой-то периодичностью? В достаточно старой OEM системе (середина 90-х годов) я встречал частоту 100 Гц. Что если записать спектр изменения давления при быстром открытии дроссельной заслонки?
- AndreyB
- Site Admin
- Posts: 14343
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Приоритеты и потоки
Что-то мне кажется, что у нас недостаточно информации, чтоб что-то считать аналитически - миллиард факторов Я думаю нужно просто писать код, а потом исследовать его поведение. Нужно встраивать мониторинг потребляемых ресурсов - в stm32 есть 64 битный регистр счётчик тактов DWT_CYCCNT, как вариант на нём нужно считать, сколько какая операция заняла времени - всё суммировать по всем категориям операция и просто следить, что нет перекосов.Sergey89 wrote:Можем ли мы сами качественно определить необходимые временные интервалы?
Например частота расчёта циклового наполнения. Считать постоянно или считать с какой-то периодичностью?
ChibiOS в текущем виде содержит опциональные готовые счётчики времени, затраченного на каждый поток. К сожалению, сама она пока не считает время внутри обработчиков прерываний - это можно или дописать, или дождаться их следующего большого релиза, где они это обещают.
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: Приоритеты и потоки
В stm32 ресурсов чуть больше чем дохрена.
Переодичность расчетов по наполнению и времени впрыска можно привязать через флаг на каждый цилиндр, но сами расчеты должны производится в общем цикле - это позволит в случае перегрузки камня хоть и с пониженной точностью но работать не уходя в зависание. Типа на больших обротах система будет расчитывать наполнение и время впрыска не на каждый цилиндр а раз за несколько оборотов.
В общем на мой взгляд в основной цикл следует выносить как можно больше всего и уже в основном цикле проверять флаги-разрешения на действия.
К примеру в прерывании ДПКВ увидили что скоро понадобится время впрыска для очередного цилиндра, повесили флаг о том что нам надо обновить переменную хранящую текущее наполнение, и благополучно об этом забыли.
В основном цикле на очередной итерации увидели что флаг на расчет наполнения взведен и соответсвенно сосчитали все что надо, когда придет время открывать форсунку у нас либо будут свежие данные о времени впрыска либо в худшем варианте данные от предыдущего цикла.
Переодичность расчетов по наполнению и времени впрыска можно привязать через флаг на каждый цилиндр, но сами расчеты должны производится в общем цикле - это позволит в случае перегрузки камня хоть и с пониженной точностью но работать не уходя в зависание. Типа на больших обротах система будет расчитывать наполнение и время впрыска не на каждый цилиндр а раз за несколько оборотов.
В общем на мой взгляд в основной цикл следует выносить как можно больше всего и уже в основном цикле проверять флаги-разрешения на действия.
К примеру в прерывании ДПКВ увидили что скоро понадобится время впрыска для очередного цилиндра, повесили флаг о том что нам надо обновить переменную хранящую текущее наполнение, и благополучно об этом забыли.
В основном цикле на очередной итерации увидели что флаг на расчет наполнения взведен и соответсвенно сосчитали все что надо, когда придет время открывать форсунку у нас либо будут свежие данные о времени впрыска либо в худшем варианте данные от предыдущего цикла.
читать всем: http://rusefi.com/forum/viewtopic.php?t=213#p336
Re: Приоритеты и потоки
перезагрузка в момент работы - это событие чуть больше, чем экстраординарное.
это режим LimpHome (доковыляй до дому) с зажиганием чекжнджина, ограничением нагрузки и прочих радостей.
это режим LimpHome (доковыляй до дому) с зажиганием чекжнджина, ограничением нагрузки и прочих радостей.
Теория хороша в том и только том случае, если она может достоверно предсказать результаты каждого нового опыта
Re: Приоритеты и потоки
Не reboot а перегруз. Нехватка ресурсов из за жирности кода и/или лени программиста в плане оптимизации. Январи и микасы подобным страдают в силу слабости камня и жесткого синхронного алгоритма, хотя maxi и Михееников чтото пытались переделывать оптимизировать и выносить максимум кода в основной цикл что позволяло пусть и со снижением точности но работать на высоких оборотах
читать всем: http://rusefi.com/forum/viewtopic.php?t=213#p336
Re: Приоритеты и потоки
линейка STM32 достаточно широка, чтобы при перегрузе взять следующей по производительности процессор
Теория хороша в том и только том случае, если она может достоверно предсказать результаты каждого нового опыта
- AndreyB
- Site Admin
- Posts: 14343
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Приоритеты и потоки
У нас сейчас кажется второй по производительности? Есть еще совсем свежий 180MHz stm32f439 кажется.XDA wrote:линейка STM32 достаточно широка, чтобы при перегрузе взять следующей по производительности процессор
Более быстрые - типа cortex-a8 - они не MPU, а уже CPU - там уже напряги с 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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: Приоритеты и потоки
Я не верю, что вообще получится исчерпать ресурсы stm32f407. Если только по I/O.
Re: Приоритеты и потоки
"640 килобайт будет достаточно всем" ))))
Исчерпать можно что угодно, появятся идеи по автоподстройке движка через эвристический самообучающийся алгоритм на основе нейронной сети и ппц любым ресурсам
C509 в январях хватает только только и то при жесточайшей оптимизации (я хорошо поковырялся идой в j5ls). Но меня терзают смутные сомения что при разработке января инженеры считали что камня более чем достаточно
Исчерпать можно что угодно, появятся идеи по автоподстройке движка через эвристический самообучающийся алгоритм на основе нейронной сети и ппц любым ресурсам
C509 в январях хватает только только и то при жесточайшей оптимизации (я хорошо поковырялся идой в j5ls). Но меня терзают смутные сомения что при разработке января инженеры считали что камня более чем достаточно
читать всем: http://rusefi.com/forum/viewtopic.php?t=213#p336
Re: Приоритеты и потоки
Да ерунду ты несешь. В 2.5mips с509 хватает на все и еще остается! 60-2 10кrpm 36-2 16krpm. таких моторов в реальной жизни просто не бывает.
кооперативка с таймслотами на часть функций в LS была всунута потому что bosch у себя в ercos-е так делает и это реально круто. Вообще конечно нужна osek система а не вытеснение из while (true) - оверхед шедуллера дичайший.
кооперативка с таймслотами на часть функций в LS была всунута потому что bosch у себя в ercos-е так делает и это реально круто. Вообще конечно нужна osek система а не вытеснение из while (true) - оверхед шедуллера дичайший.
Re: Приоритеты и потоки
Обороты растут и точность падает, а и то чтобы докрурить до десятки ты переписал много кода и тщательно оптимизировал, тот же микас-спорт выше 8000 не раскрутить и это на четырех горшках, а если горшков пять или восьем или вообще 12? Да и размреность карт довольно скромная. Для своего времени январь с j5ls был более чем крут но сейчас этого мало.
Osek это конечно интересно но как насчет stm32f4 "из корбоки"? Как там с портируемостью?
про эту ось http://citforum.ru/operating_systems/rtos/16.shtml
Osek это конечно интересно но как насчет stm32f4 "из корбоки"? Как там с портируемостью?
про эту ось http://citforum.ru/operating_systems/rtos/16.shtml
читать всем: http://rusefi.com/forum/viewtopic.php?t=213#p336
Re: Приоритеты и потоки
тут http://erika.tuxfamily.org/drupal/ заявлена поддержка Cortex-M4 и STM32F4xx в частности
Re: Приоритеты и потоки
Хм, надо будет вечером поизучать что там и как, тут покрайней мере есть смысл в ОС
читать всем: http://rusefi.com/forum/viewtopic.php?t=213#p336
Re: Приоритеты и потоки
Неудержался и скачал у них с сайта их ide. Чтобы под фрей заработало надо довоткнуть с портов /usr/ports/java/linux-sun-jdk16 и запускать: JAVA_HOME=/usr/local/linux-sun-jdk1.6.0 ~/Evidence/eclipse/eclipse
разобрался как подключить их же плагины к их же поделке на базе эклипса, все прикрутилось, пооткрывал готовые демки, код красивый мне понравился ) В общем вджобинг не ждет а с этим поиграюсь вечером.
самый кайф что архетиктура этой оси хорошо документированна и есть описанние на русском http://citforum.ru/operating_systems/rtos/16.shtml
разобрался как подключить их же плагины к их же поделке на базе эклипса, все прикрутилось, пооткрывал готовые демки, код красивый мне понравился ) В общем вджобинг не ждет а с этим поиграюсь вечером.
самый кайф что архетиктура этой оси хорошо документированна и есть описанние на русском http://citforum.ru/operating_systems/rtos/16.shtml
читать всем: http://rusefi.com/forum/viewtopic.php?t=213#p336
Re: Приоритеты и потоки
По поводу максимальных оборотов. Есть же мотоциклетные движки, они вполне себе крутятся 15к в стоке. А там тоже надо что-то делать, родные мозги ковыряют неохотно, колхозят всякого рода power commander-ы.
skype: frig_frig
Re: Приоритеты и потоки
В обороты упиратся глупо. Следует сразу закладывать до 16 цилиндров и до 20тыс оборотов, так же следует закладывать поддержку несимметричных двигателей (5ц к примеру)
читать всем: http://rusefi.com/forum/viewtopic.php?t=213#p336
Re: Приоритеты и потоки
в формулу-1 метишьnikll wrote:В обороты упиратся глупо. Следует сразу закладывать до 16 цилиндров и до 20тыс оборотов, так же следует закладывать поддержку несимметричных двигателей (5ц к примеру)
там майкрософт программу для ЕЦУ пишет, конкурент серьёзный - вряд ли перебить получится....
Теория хороша в том и только том случае, если она может достоверно предсказать результаты каждого нового опыта
Re: Приоритеты и потоки
размерности 32x16 для любых задач хватает.nikll wrote:Обороты растут и точность падает, а и то чтобы докрурить до десятки ты переписал много кода и тщательно оптимизировал, тот же микас-спорт выше 8000 не раскрутить и это на четырех горшках, а если горшков пять или восьем или вообще 12? Да и размреность карт довольно скромная.
что касаемо угла - покури из моментной модели хотя бы "эффективность по УОЗ".
2 градуса вообще ничего не решают ни на каких оборотах! Транспортные задержки опять же никуда не денутся на любых тригерах и их обработчиках - да даже на том же разрыве тока в катушке. Их компенсируют совсем другими методами. а точность которая сейчас есть на порядок превышает ту что была бы достаточной.
единственная другая задача - непосредственный впрыск.. только и тут есть проблема - когда нужна мощность от него нету толку.
этого будет достаточно еще лет 30 минимум пока все двигатели не заработают на других физических принципах...Для своего времени январь с j5ls был более чем крут но сейчас этого мало.
ARM порт там есть конечно. сопроцессор не нужен - библиотеки целочисленные.Osek это конечно интересно но как насчет stm32f4 "из корбоки"? Как там с портируемостью?
Re: Приоритеты и потоки
это 5 выходов на катушки и 5 форсунок.nikll wrote:В обороты упиратся глупо. Следует сразу закладывать до 16 цилиндров и до 20тыс оборотов, так же следует закладывать поддержку несимметричных двигателей (5ц к примеру)
даже на уровне железа делать 5 катушек смысла 0....
Re: Приоритеты и потоки
А 8 есть смысл делать? А если не делать индивидуальные выходы то что делать с 1uz-fe ?Maxi wrote:это 5 выходов на катушки и 5 форсунок.даже на уровне железа делать 5 катушек смысла 0....
Я имел ввиду не забивать жестко в плату и софт данные под 16ц движок крутящийся на 20000об ))))) я имел ввиду разумные пределы к которым имеет смысл стремится. Перефирию (драйверы катушек форсунок шаговиков релюшек) вообще надо делать на отдельной плате, иначе придется делать несколько плат под разные движки, да и гибкость существено снизится.
Про УОЗ я уже писал что разброс в пару градусов почти не заметен, разброс в доли градуса вообще без спец оборудования не ощутить.
Вот мне j5ls совершенно не достаточен, виэйтом с vvti и акпп он рулить не умеет, значит он говно. Если подходить с твоей точки зрения то вообще впрыск нахрен не нужен, пока не изменятся физические принципы ДВС можно на карбюраторах ездить
Формулу нахрен, там совсем другие требования и другой подход. А вот мотоцикл у которого на 400 кубиков четыре горшка с коротким ходом огромными клапанами и широченными фазами... вот это задачка. Хотел бы я увидить январь на дукатти с двумя горшками в развале 90гр и десмодромным приводом клапанов ))) да хотябы на какойнибудь бешенной чесотке с красной зоной в районе 18000об.XDA wrote:в формулу-1 метишь
16 каналов на форсунки заложить програмно? два ряда на виэйте и усе закончались каналы. Нахрена оно на виэйте? Дак делают потому что ))) мне и одного ряда до жопы хватит конечно, но в жизни всякое бывает.
читать всем: http://rusefi.com/forum/viewtopic.php?t=213#p336
Re: Приоритеты и потоки
для этого либо делают отдельный спец мозг нужный одному человеку из 1000 либо тупо ставят 2 4-х цилиндровых (в стоке делают 2 4-х цилиндровых в один кузов).nikll wrote:А 8 есть смысл делать? А если не делать индивидуальные выходы то что делать с 1uz-fe ?Maxi wrote:это 5 выходов на катушки и 5 форсунок.даже на уровне железа делать 5 катушек смысла 0....
расход текстолита...Я имел ввиду не забивать жестко в плату и софт данные под 16ц движок крутящийся на 20000об )))))
Re: Приоритеты и потоки
Я уже предлагал отделить переферию от базовой платы, какраз с целью избежать излишней сложности и дороговизны для банальных рядных четверок, но при этом оставить возможность делать кастомные платы с переферией буквально "на кухне". Задачи разные бывают, много каналов, специфические вещи типа низкоомных форсунок или нескольких рядов форсунок, управление закисью или впрыском воды, да хоть подобие иммобилайзера )
Я честно говоря удивлен что досихпор в ЭБУ не применяется подобный подход, пример развития PC с ISA шиной, или Arduino вполне показывает преимущества систем с открытой архетиктурой для расширения аппаратной части.
Я честно говоря удивлен что досихпор в ЭБУ не применяется подобный подход, пример развития PC с ISA шиной, или Arduino вполне показывает преимущества систем с открытой архетиктурой для расширения аппаратной части.
читать всем: http://rusefi.com/forum/viewtopic.php?t=213#p336
Re: Приоритеты и потоки
как бы 20к оборотов и 10 цилиндров это показатели как раз формулы-1nikll wrote:Формулу нахрен, там совсем другие требования и другой подход. А вот мотоцикл у которого на 400 кубиков четыре горшка с коротким ходом огромными клапанами и широченными фазами... вот это задачка. Хотел бы я увидить январь на дукатти с двумя горшками в развале 90гр и десмодромным приводом клапанов ))) да хотябы на какойнибудь бешенной чесотке с красной зоной в районе 18000об.XDA wrote:в формулу-1 метишь
16 каналов на форсунки заложить програмно? два ряда на виэйте и усе закончались каналы. Нахрена оно на виэйте? Дак делают потому что ))) мне и одного ряда до жопы хватит конечно, но в жизни всякое бывает.
а ваш десмодромный мотоцикл - всего 2 цилиндра. будь это в требованиях - сразу было бы понятно
дело в том, что основной цикл расчёта топлива обсчитывает не оборотам, а число рабочих тактов в секунду. а их - число оборотов помноженное на число цилиндров. поэтому 18000 оборотов и два цилиндра - тоже самое, что 9000 оборотов и 4 цилиндра или 6000 оборотов для 6 цилиндров.
а 16 цилиндров и 20 000 оборотов - это как бы 320 000 (триста двадцать тысяч) рабочих тактов в секунду. это чудовищный, никому в реальности не нужный запас производительности.
Теория хороша в том и только том случае, если она может достоверно предсказать результаты каждого нового опыта
Re: Приоритеты и потоки
а это как раз не надежно - сопливые разъемы добавляются...nikll wrote:Я уже предлагал отделить переферию от базовой платы, какраз с целью избежать излишней сложности и дороговизны для банальных рядных четверок,
как вариант делать базовую на 4 а остальное как extended...
Re: Приоритеты и потоки
Хм, я не понял, ты предлагаеш расчитывать наполнение для каждого цилиндра персонально в синхронном с коленвалом режиме? Зачем такие сложности? Максимум расчетов в низкопреоритетный асинхронный режим, ну будет при перегрузке расчитывать не для каждого а раз в два оборота смесь ну и что с того? Уж лудьше так чем в зависание ) А детально расчитывать все по времени каждый раз переживая влезет не влезет это соовсем не вариант. Поэтому и обозначил такие цели, понятно что на практике такой двигатель не встретится, но вот запас ресурсов очень прегодится когда захочется вкодить чтото более серьезное.
По платам сюда пожалуйста: http://www.rusefi.com/forum/viewtopic.php?f=6&t=216
По платам сюда пожалуйста: http://www.rusefi.com/forum/viewtopic.php?f=6&t=216
читать всем: http://rusefi.com/forum/viewtopic.php?t=213#p336
Re: Приоритеты и потоки
именно так, и никак иначе. расчёт топлива и угла зажигания в синхронном режиме или затея не стоит реализации, потому что с остальным прекрасно справится мегасквирт на атмеге.
Теория хороша в том и только том случае, если она может достоверно предсказать результаты каждого нового опыта
Re: Приоритеты и потоки
простите - у вас 160mips как насчет того что это не сложно при 2.6mips (с сопроцессором)?!nikll wrote:Хм, я не понял, ты предлагаеш расчитывать наполнение для каждого цилиндра персонально в синхронном с коленвалом режиме? Зачем такие сложности?
пегергузке чем!?Максимум расчетов в низкопреоритетный асинхронный режим, ну будет при перегрузке расчитывать не для каждого а раз в два оборота смесь ну и что с того?