Приоритеты и потоки
Приоритеты и потоки
Обсудим разделение и выполнение задач по приоритетам?
Я выделяю три типа задач. Первые это задачи, которые нужно выполнять в соответствии с угловым положением КВ. Вторые это задачи, которые нужно выполнять с заданной периодичностью. Третий тип задач это задачи, которые можно выполнять в любое время.
Первый тип задач имеет наивысший приоритет, второй тип задач менее приоритетный и третий тип задач наименее приоритетный.
Как это реализовал я.
Задачи по угловому положению выполняются в прерывании таймера задержки (между зубьями) с высоким приоритетом. При этом если требуется выполнить какое-то более продолжительное событие (например обработка сигнала с интегратора канала детонации) я устанавливаю флаг и программно генерирую прерывание другого таймера с более низким приоритетом для того, чтобы не занимать прерывание таймера задержки, но при этом не пропустить обработку этого события.
Задачи с заданной периодичностью выполняются в прерывании ещё одного таймера с более низким приоритетом.
Задачи с наименьшим приоритетом выполняю в бесконечном цикле в main.
Задачи первого типа: открытие форсунки, начало накопления в кз, завершение накопления в кз, запуск и остановка интегратора канала детонации. Всего 4 задачи.
Задачи второго типа: управление хх, расчёт наполнения и времени впрыска, чтение состояния датчиков, расчёт обогащения при ускорении и т.д.
Задачи третьего типа: расчёт базового состава смеси, расчёт УОЗ, управление актуаторами и т.д.
Я выделяю три типа задач. Первые это задачи, которые нужно выполнять в соответствии с угловым положением КВ. Вторые это задачи, которые нужно выполнять с заданной периодичностью. Третий тип задач это задачи, которые можно выполнять в любое время.
Первый тип задач имеет наивысший приоритет, второй тип задач менее приоритетный и третий тип задач наименее приоритетный.
Как это реализовал я.
Задачи по угловому положению выполняются в прерывании таймера задержки (между зубьями) с высоким приоритетом. При этом если требуется выполнить какое-то более продолжительное событие (например обработка сигнала с интегратора канала детонации) я устанавливаю флаг и программно генерирую прерывание другого таймера с более низким приоритетом для того, чтобы не занимать прерывание таймера задержки, но при этом не пропустить обработку этого события.
Задачи с заданной периодичностью выполняются в прерывании ещё одного таймера с более низким приоритетом.
Задачи с наименьшим приоритетом выполняю в бесконечном цикле в main.
Задачи первого типа: открытие форсунки, начало накопления в кз, завершение накопления в кз, запуск и остановка интегратора канала детонации. Всего 4 задачи.
Задачи второго типа: управление хх, расчёт наполнения и времени впрыска, чтение состояния датчиков, расчёт обогащения при ускорении и т.д.
Задачи третьего типа: расчёт базового состава смеси, расчёт УОЗ, управление актуаторами и т.д.
- AndreyB
- Site Admin
- Posts: 14381
- 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: 14381
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Приоритеты и потоки
Что-то мне кажется, что у нас недостаточно информации, чтоб что-то считать аналитически - миллиард факторовSergey89 wrote:Можем ли мы сами качественно определить необходимые временные интервалы?
Например частота расчёта циклового наполнения. Считать постоянно или считать с какой-то периодичностью?
![Sad :(](./images/smilies/icon_e_sad.gif)
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 достаточно широка, чтобы при перегрузе взять следующей по производительности процессор ![Smile :)](./images/smilies/icon_e_smile.gif)
![Smile :)](./images/smilies/icon_e_smile.gif)
Теория хороша в том и только том случае, если она может достоверно предсказать результаты каждого нового опыта
- AndreyB
- Site Admin
- Posts: 14381
- 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). Но меня терзают смутные сомения что при разработке января инженеры считали что камня более чем достаточно![Rolling Eyes :roll:](./images/smilies/icon_rolleyes.gif)
Исчерпать можно что угодно, появятся идеи по автоподстройке движка через эвристический самообучающийся алгоритм на основе нейронной сети и ппц любым ресурсам
![Wink ;)](./images/smilies/icon_e_wink.gif)
C509 в январях хватает только только и то при жесточайшей оптимизации (я хорошо поковырялся идой в j5ls). Но меня терзают смутные сомения что при разработке января инженеры считали что камня более чем достаточно
![Rolling Eyes :roll:](./images/smilies/icon_rolleyes.gif)
читать всем: 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ц к примеру)
![Wink ;)](./images/smilies/icon_e_wink.gif)
там майкрософт программу для ЕЦУ пишет, конкурент серьёзный - вряд ли перебить получится....
![Smile :)](./images/smilies/icon_e_smile.gif)
Теория хороша в том и только том случае, если она может достоверно предсказать результаты каждого нового опыта
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 и акпп он рулить не умеет, значит он говно. Если подходить с твоей точки зрения то вообще впрыск нахрен не нужен, пока не изменятся физические принципы ДВС можно на карбюраторах ездить
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Формулу нахрен, там совсем другие требования и другой подход. А вот мотоцикл у которого на 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 цилиндра. будь это в требованиях - сразу было бы понятно
![Smile :)](./images/smilies/icon_e_smile.gif)
дело в том, что основной цикл расчёта топлива обсчитывает не оборотам, а число рабочих тактов в секунду. а их - число оборотов помноженное на число цилиндров. поэтому 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:Хм, я не понял, ты предлагаеш расчитывать наполнение для каждого цилиндра персонально в синхронном с коленвалом режиме? Зачем такие сложности?
пегергузке чем!?Максимум расчетов в низкопреоритетный асинхронный режим, ну будет при перегрузке расчитывать не для каждого а раз в два оборота смесь ну и что с того?