Разработка схемы впрыскового блока (Develop injection unit)

[nikll]

Все что превязанно к событиям и таймерам работает в прерываниях, остальное вызывается в основном цикле.
А то что предлогаеш ты не совсем верно, отдельные процессы тут не только не нужны но и вредны т.к. по сути данный функционал уже реализованн аппоратно через систему прерываний.
В самих прерываниях следует по возможности минимизировать время выполнения, все не привязанное жестко к времени к примеру расчет наполнения делать в основном цикле (на январе вынос всего возможного в основой цикл дал прирост с 7000 до 10200 оборотов).
По сути получается простейшая асинхронная событейная система.

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

На мой взгяд следует придерживаться следующщего:
1. минимизация кода по времени выполнения внутри прерываний
2. максимальное использованние асинхронного подхода, к примеру УОЗ расчитывается в основном цикле когда нет прерываний, в прерывании ДПКВ идет обработка всего что жестко привязанно к положению коленвала например запуск АЦП ДАД и проверка на достижение нужного зуба для запуска таймера на очередное событие (дать искру или открыть форсунку через столько то тактов после определенного зуба).
3. Хорошо продумать схему прерываний, правильно задать "вес" нужным прерываниям дабы они могли перекрывать мение важные для своего выполнения.

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

[ender11]

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

[nikll]

Нахрена все так усложнять? Какую роль будет играть rtos сформулируй.

Совершенно не понял где ты увидел конфликт между прерываниями и основным потоком. В основном потоке производится проверка флага необходимости расчета наполнения времени впрыска и УОЗа, флаг взводится в прерывании ДПКВ (два раза за оборот КВ для 4ц три раза для 6ц и четыре раза для 8ц моторов), если влаг взведен то запускается вся матетематика и результаты расчетов складываются в структуру - глобальную переменную (типа что делать на каком зубе какое действие и доп таймер для точного задавания угла по кв). В прерывании ДПКВ структура с данными проверяется на наличие действий на текущщем зубе и если они есть то сответсвенно производится установка и запуск таймеров (например таймер на открытие или закритие форсунки). Где тут ограничение "только пол-оборота двигателя"? При повышении оборотов прерывания будут вызываться чащще, соответсвенно времени на работу основного цикла будет оставаться меньше в итоге расчет математики будет производится больше одного оборота КВ, да точность и отзывчивость будет падать но жесткого ограничения по оборотам не будет, просто данные с предыдущщего цикла будут использоваться и дальше если новые еще не расчитанны.
Где и что ты хочеш синхронизировать и какими данными между чем и чем обмениваться раз за оборот и зачем оно надо?

в avr или arm? на счет avr не скажу т.к. практически не знаком с ними, в stm32 переключение контекста при обработке прерываний реализованно аппаратно, причем реализованно очень шустро с минимальным оверхедом.

Свой код я запускаю на stm32f100 и stm32f4, пока что это не полноценный ЭБУ а по сути стенд с эмулятором мотора, аппаратная часть пока что не горит т.к. запускать по сути еще нечего, есть только основной скелет и часть математики. В данный момент изобретаю профилированние по времени, придумал интересный изврат, при кажом входе в любое прерывание запоминается состояние отдельного пина, пин взводится в еденицу, при выходе из прерывания пин возвращщается к исходному состоянию, тоже самое в основном цикле когда есть что выполнять, к этому пину в железе цепляется вольтметр через RC цепь, в итоге просто по напряжению я вижу на сколько реально загруженн проц. Таких пинов можно сделать целую пачку по одному пину на каждый кусок кода и соответсвенно в живую анализировать поведение программы при различных входных условиях (обороты, показания датчиков). Вот такой вот занимательный профайлинг для МК

[AleksandR K.]

В данный момент изобретаю профилирование по времени, придумал интересный изврат,

А работа стоит ...

[nikll]

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

P.S. а stm32F4 всетки интересная штука, FPU и MMU в ядре позволяют охеренно разкачать довольно сложную математику.

[AleksandR K.]

Эх смайлика не вижу где об стену бьется, какая работа стоит?

Тут кто-то обещал карту УОЗ по наполнению-оборотам.

... Простой классический вариат с одной трехмерной картой УОЗ по наполнению/оборотам. Именно по наполнению а не по какому либо другому параметру...

Дальше разговоров дело пойдёт?

[Makar]

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

[nikll]

Makar, куда применить dsp в эбу и что это нам даст? можно и ПЛИС припаять вот только не вижу зачем.

[Makar]

На мой взгяд следует придерживаться следующщего:
1. минимизация кода по времени выполнения внутри прерываний
2. максимальное использованние асинхронного подхода, к примеру УОЗ расчитывается в основном цикле когда нет прерываний, в прерывании ДПКВ идет обработка всего что жестко привязанно к положению коленвала например запуск АЦП ДАД и проверка на достижение нужного зуба для запуска таймера на очередное событие (дать искру или открыть форсунку через столько то тактов после определенного зуба).
3. Хорошо продумать схему прерываний, правильно задать "вес" нужным прерываниям дабы они могли перекрывать мение важные для своего выполнения.

Вот за этим.
Кстати, ты считал сколько понадобится таймеров? В 103V их всего пять.

[nikll]

Makar, таймеров хватит, они там далеко не простые, по сути на каждый таймер можно повесить четыре счетчика с прерываниями по переполнению.