Приоритеты и потоки

[Sergey89]

Обсудим разделение и выполнение задач по приоритетам?

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

Первый тип задач имеет наивысший приоритет, второй тип задач менее приоритетный и третий тип задач наименее приоритетный.

Как это реализовал я.

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

Задачи с заданной периодичностью выполняются в прерывании ещё одного таймера с более низким приоритетом.

Задачи с наименьшим приоритетом выполняю в бесконечном цикле в main.

Задачи первого типа: открытие форсунки, начало накопления в кз, завершение накопления в кз, запуск и остановка интегратора канала детонации. Всего 4 задачи.

Задачи второго типа: управление хх, расчёт наполнения и времени впрыска, чтение состояния датчиков, расчёт обогащения при ускорении и т.д.

Задачи третьего типа: расчёт базового состава смеси, расчёт УОЗ, управление актуаторами и т.д.

[AndreyB]

Сложный вопрос. Меня смущает, что нет объективных средств диагностики.

Точнее скажем так: а насколько мы уверены, что проблема вообще есть? И как мы можем проблему _увидеть_, чтоб удостовериться, что мы её решили? Если мы не видим проблему, мы не увидим и решение.

Какие операции могут что-то замедлить и на сколько? Математика? Только если очень сложная и только если она блокирует прерывания. Работа с spi? вроде нет. DMA? Не знаю, вроде тоже нет.

С другой стороны, немного перестраховаться конечно стоит. Моё сбалансированное видение для меня: я поднимаю приоритет прерываний - потому что там самая важная логика. Ну и нужно очень аккуратно смотреть, чтоб нигде не было долгих блокировок с блокировкой прерываний. Для самоуспокоения этого достаточно, дальше копать кажется нужно будет только если будет явная проблема.

[Sergey89]

Один из вариантов это выполнять задачи в общем цикле (или как у тебя в потоках) в котором и отмерять нужные интервалы времени, а уже в конкретной функции определять точный интервал времени.

Мой вариант опять таки завязан на "железо", но он в принципе позволяет не думать о каких-то возможных задержках.

[Sergey89]

Ещё интерес вызывает периодичность вызова функций расчёта и управления. Можем ли мы сами качественно определить необходимые временные интервалы?

Например частота расчёта циклового наполнения. Считать постоянно или считать с какой-то периодичностью? В достаточно старой OEM системе (середина 90-х годов) я встречал частоту 100 Гц. Что если записать спектр изменения давления при быстром открытии дроссельной заслонки?

[AndreyB]

Можем ли мы сами качественно определить необходимые временные интервалы?

Например частота расчёта циклового наполнения. Считать постоянно или считать с какой-то периодичностью?

Что-то мне кажется, что у нас недостаточно информации, чтоб что-то считать аналитически - миллиард факторов Я думаю нужно просто писать код, а потом исследовать его поведение. Нужно встраивать мониторинг потребляемых ресурсов - в stm32 есть 64 битный регистр счётчик тактов DWT_CYCCNT, как вариант на нём нужно считать, сколько какая операция заняла времени - всё суммировать по всем категориям операция и просто следить, что нет перекосов.

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

[nikll]

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

[XDA]

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

[nikll]

Не reboot а перегруз. Нехватка ресурсов из за жирности кода и/или лени программиста в плане оптимизации. Январи и микасы подобным страдают в силу слабости камня и жесткого синхронного алгоритма, хотя maxi и Михееников чтото пытались переделывать оптимизировать и выносить максимум кода в основной цикл что позволяло пусть и со снижением точности но работать на высоких оборотах

[XDA]

линейка STM32 достаточно широка, чтобы при перегрузе взять следующей по производительности процессор

[AndreyB]

линейка STM32 достаточно широка, чтобы при перегрузе взять следующей по производительности процессор

У нас сейчас кажется второй по производительности? Есть еще совсем свежий 180MHz stm32f439 кажется.

Более быстрые - типа cortex-a8 - они не MPU, а уже CPU - там уже напряги с rtos, там уже линукс начинается.

[Sergey89]

Я не верю, что вообще получится исчерпать ресурсы stm32f407. Если только по I/O.

[nikll]

"640 килобайт будет достаточно всем" ))))

Исчерпать можно что угодно, появятся идеи по автоподстройке движка через эвристический самообучающийся алгоритм на основе нейронной сети и ппц любым ресурсам
C509 в январях хватает только только и то при жесточайшей оптимизации (я хорошо поковырялся идой в j5ls). Но меня терзают смутные сомения что при разработке января инженеры считали что камня более чем достаточно

[Maxi]

Да ерунду ты несешь. В 2.5mips с509 хватает на все и еще остается! 60-2 10кrpm 36-2 16krpm. таких моторов в реальной жизни просто не бывает.

кооперативка с таймслотами на часть функций в LS была всунута потому что bosch у себя в ercos-е так делает и это реально круто. Вообще конечно нужна osek система а не вытеснение из while (true) - оверхед шедуллера дичайший.

[nikll]

Обороты растут и точность падает, а и то чтобы докрурить до десятки ты переписал много кода и тщательно оптимизировал, тот же микас-спорт выше 8000 не раскрутить и это на четырех горшках, а если горшков пять или восьем или вообще 12? Да и размреность карт довольно скромная. Для своего времени январь с j5ls был более чем крут но сейчас этого мало.
Osek это конечно интересно но как насчет stm32f4 "из корбоки"? Как там с портируемостью?
про эту ось http://citforum.ru/operating_systems/rtos/16.shtml

[Sergey89]

тут http://erika.tuxfamily.org/drupal/ заявлена поддержка Cortex-M4 и STM32F4xx в частности

[nikll]

Хм, надо будет вечером поизучать что там и как, тут покрайней мере есть смысл в ОС

[nikll]

Неудержался и скачал у них с сайта их 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

[frig]

По поводу максимальных оборотов. Есть же мотоциклетные движки, они вполне себе крутятся 15к в стоке. А там тоже надо что-то делать, родные мозги ковыряют неохотно, колхозят всякого рода power commander-ы.

[nikll]

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

[XDA]

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

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

[Maxi]

Обороты растут и точность падает, а и то чтобы докрурить до десятки ты переписал много кода и тщательно оптимизировал, тот же микас-спорт выше 8000 не раскрутить и это на четырех горшках, а если горшков пять или восьем или вообще 12? Да и размреность карт довольно скромная.

размерности 32x16 для любых задач хватает.
что касаемо угла - покури из моментной модели хотя бы "эффективность по УОЗ".
2 градуса вообще ничего не решают ни на каких оборотах! Транспортные задержки опять же никуда не денутся на любых тригерах и их обработчиках - да даже на том же разрыве тока в катушке. Их компенсируют совсем другими методами. а точность которая сейчас есть на порядок превышает ту что была бы достаточной.

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

Для своего времени январь с j5ls был более чем крут но сейчас этого мало.

этого будет достаточно еще лет 30 минимум пока все двигатели не заработают на других физических принципах...

Osek это конечно интересно но как насчет stm32f4 "из корбоки"? Как там с портируемостью?

ARM порт там есть конечно. сопроцессор не нужен - библиотеки целочисленные.

[Maxi]

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

это 5 выходов на катушки и 5 форсунок.
даже на уровне железа делать 5 катушек смысла 0....

[nikll]

это 5 выходов на катушки и 5 форсунок.даже на уровне железа делать 5 катушек смысла 0....

А 8 есть смысл делать? А если не делать индивидуальные выходы то что делать с 1uz-fe ?
Я имел ввиду не забивать жестко в плату и софт данные под 16ц движок крутящийся на 20000об ))))) я имел ввиду разумные пределы к которым имеет смысл стремится. Перефирию (драйверы катушек форсунок шаговиков релюшек) вообще надо делать на отдельной плате, иначе придется делать несколько плат под разные движки, да и гибкость существено снизится.
Про УОЗ я уже писал что разброс в пару градусов почти не заметен, разброс в доли градуса вообще без спец оборудования не ощутить.

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

в формулу-1 метишь

Формулу нахрен, там совсем другие требования и другой подход. А вот мотоцикл у которого на 400 кубиков четыре горшка с коротким ходом огромными клапанами и широченными фазами... вот это задачка. Хотел бы я увидить январь на дукатти с двумя горшками в развале 90гр и десмодромным приводом клапанов ))) да хотябы на какойнибудь бешенной чесотке с красной зоной в районе 18000об.

16 каналов на форсунки заложить програмно? два ряда на виэйте и усе закончались каналы. Нахрена оно на виэйте? Дак делают потому что ))) мне и одного ряда до жопы хватит конечно, но в жизни всякое бывает.

[Maxi]

это 5 выходов на катушки и 5 форсунок.даже на уровне железа делать 5 катушек смысла 0....

А 8 есть смысл делать? А если не делать индивидуальные выходы то что делать с 1uz-fe ?

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

Я имел ввиду не забивать жестко в плату и софт данные под 16ц движок крутящийся на 20000об )))))

расход текстолита...

[nikll]

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

[XDA]

в формулу-1 метишь

Формулу нахрен, там совсем другие требования и другой подход. А вот мотоцикл у которого на 400 кубиков четыре горшка с коротким ходом огромными клапанами и широченными фазами... вот это задачка. Хотел бы я увидить январь на дукатти с двумя горшками в развале 90гр и десмодромным приводом клапанов ))) да хотябы на какойнибудь бешенной чесотке с красной зоной в районе 18000об.

16 каналов на форсунки заложить програмно? два ряда на виэйте и усе закончались каналы. Нахрена оно на виэйте? Дак делают потому что ))) мне и одного ряда до жопы хватит конечно, но в жизни всякое бывает.

как бы 20к оборотов и 10 цилиндров это показатели как раз формулы-1

а ваш десмодромный мотоцикл - всего 2 цилиндра. будь это в требованиях - сразу было бы понятно
дело в том, что основной цикл расчёта топлива обсчитывает не оборотам, а число рабочих тактов в секунду. а их - число оборотов помноженное на число цилиндров. поэтому 18000 оборотов и два цилиндра - тоже самое, что 9000 оборотов и 4 цилиндра или 6000 оборотов для 6 цилиндров.

а 16 цилиндров и 20 000 оборотов - это как бы 320 000 (триста двадцать тысяч) рабочих тактов в секунду. это чудовищный, никому в реальности не нужный запас производительности.

[Maxi]

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

а это как раз не надежно - сопливые разъемы добавляются...
как вариант делать базовую на 4 а остальное как extended...

[nikll]

Хм, я не понял, ты предлагаеш расчитывать наполнение для каждого цилиндра персонально в синхронном с коленвалом режиме? Зачем такие сложности? Максимум расчетов в низкопреоритетный асинхронный режим, ну будет при перегрузке расчитывать не для каждого а раз в два оборота смесь ну и что с того? Уж лудьше так чем в зависание ) А детально расчитывать все по времени каждый раз переживая влезет не влезет это соовсем не вариант. Поэтому и обозначил такие цели, понятно что на практике такой двигатель не встретится, но вот запас ресурсов очень прегодится когда захочется вкодить чтото более серьезное.

По платам сюда пожалуйста: http://www.rusefi.com/forum/viewtopic.php?f=6&t=216

[XDA]

именно так, и никак иначе. расчёт топлива и угла зажигания в синхронном режиме или затея не стоит реализации, потому что с остальным прекрасно справится мегасквирт на атмеге.

[Maxi]

Хм, я не понял, ты предлагаеш расчитывать наполнение для каждого цилиндра персонально в синхронном с коленвалом режиме? Зачем такие сложности?

простите - у вас 160mips как насчет того что это не сложно при 2.6mips (с сопроцессором)?!

Максимум расчетов в низкопреоритетный асинхронный режим, ну будет при перегрузке расчитывать не для каждого а раз в два оборота смесь ну и что с того?

пегергузке чем!?