Оптимальное распределение ресурсов МК в прошивке

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

Moderator: STC

User avatar
STC
LQFP144 - On Top Of The Game
Posts: 2420
Joined: Fri Oct 22, 2010 10:47 pm
Location: Ukraine, Kiev
Contact:

Оптимальное распределение ресурсов МК в прошивке

Post by STC »

Общая тема для обсуждения архитектуры прошивок, вопросов распределения периферии, таймеров, эффективная обработка прерываний и событий, грамотное использование ключевого слова 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: Оптимальное распределение ресурсов МК в прошивке

Post by nikll »

1. максимальное задействование аппаратных возможностей МК
2. максимальная асинхронность кода
3. вынос всего возможного кода в основной цикл с простым диспетчером и приорететами выполнения
4. максимально возможная изоляция переменных и функций внутри обособленных модулей (инкапсуляция) и соответсвенно минимизация глобальных переменных (по сути в глобальной области остаются структура с состояниями, очереди и переменные используемые в прерываниях).
Qwertty
LQFP144 - On Top Of The Game
Posts: 252
Joined: Thu Jul 26, 2012 12:35 pm

Re: Оптимальное распределение ресурсов МК в прошивке

Post by Qwertty »

Оптимальное распределение ресурсов - уложить выбранный алгоритм в выбранный МК. Ни больше ни меньше. Если остаются лишние ресурсы - значит МК выбран не оптимально. Если не хватает ресурсов - то же самое.
Qwertty
LQFP144 - On Top Of The Game
Posts: 252
Joined: Thu Jul 26, 2012 12:35 pm

Re: Оптимальное распределение ресурсов МК в прошивке

Post by Qwertty »

STC wrote: Не забывай что у тебя 100% будут переменные, которые будут одновременно использоваться в нескольких прерываниях (не только в прерываниях и основном цикле).
Конечно. Использоваться != изменяться. Я пример очереди расписал. Там изменяется только одна переменная и она изменяется только в этом прерывании. И более того - больше нигде не используется. По сути - счетчик элементов.
STC wrote: И чем больше логики будет реализовано на программном уровне, тем больший рок-н-ролл у тебя будет.
Вроде все что будет софтом я описал. Это замена аппаратных каналов на программные. 0,1% загрузки. В остальном разницы нет. Вемсовцы от 8 цилиндров не захлебываются. У них проц медленней, приоритетов прерываний нет, аппаратного деления - нет, таймеров меньше, а мозг намного навороченнее Января. На котором кстати тоже неплохо ездит куча машин. Мне же не надо повторять Вемс со всеми его наворотами. Так что ресурсов у меня более чем достаточно. Можно еще чем порулить. Хотя на МП3 плеер и не хватит :)
STC wrote: Сними розовые очки, обломаешься потом, когда твоя прошивка захлебнется в прерываниях от ДПКВ. И скажи мне пожалуйста, ты когда свою "эффективную" очередь будешь заполнять/обновлять из основного цикла, что будет с прерываниями? Правильно, они будут запрещены - доп. задержка. И еще скажу, что не думай что тебе удасться так просто вынести логику из ДПКВ в основной цикл. Большая часть логики требует синхронной обработки по каждому зубу.
Вот у Вемсовцев наверняка что то типа очереди. И ДПКВ тоже имеется. Они не захлебываются! Там что - гении что ли? Или волшебная мега внутри на 128 бит и 100МГц? Когда теория конфликтует с практикой - теория ВСЕГДА проигрывает. Вемс ездит, на нем ездят нормально даже наддутые V8. Это автоматом обесценивает все твои страшилки. :lol2: И почитай что там есть еще, кроме зажигания и впрыска. Кстати обороты до 15000. То есть рассчитывали не на гражданские моторы далеко. У меня не 8 цилиндров и не 15000 оборотов. Так что требования к быстродействию в 5 раз скромнее. Но проц примерно в 2 раза шустрей. Итого - я должен уложиться в 10% загрузки :mrgreen: Ну это в вылизанном варианте, с асмовыми вставками наверняка. Без них, на чистом Си уложусь в 50% без сомнений.
Да, свою очередь я буду заполнять там же, где и таймер бы заполнял. Причем прерывания при этом будут не заблокированы. Все события разнесены по времени. Возьми блин карандашик, разрисуй диаграмму. Не нужны тут таймеры! Что нам Вемс блестяще и доказывает. Там кстати аппаратные выходы 16 битного таймера очень оригинально использованы. На них ШИМ для управления ШДК. Не форсунки, не зажигание! Вот так они к ним относятся. Весь Вемс сделан на 1 3-х канальном 16 битном таймере. Это напомню 8 форсунок, 8 каналов зажигания. Ребята ни то что не комплексуют от недостатка таймеров - они их практически разбазаривают. Видимо ценность таймеров считают невысокой. :lol:
nikll
LQFP144 - On Top Of The Game
Posts: 553
Joined: Sun Nov 06, 2011 9:20 pm
Location: Russia, Yekaterinburg
Contact:

Re: Оптимальное распределение ресурсов МК в прошивке

Post by nikll »

Да не верно ты расписал, там нихрена не 0,1%, 0,1% это только обработка одной очереди, не забывай что там еще много всего потребуется. У вемса 2 канала, там нет индивидуально управляемых форсунок... Наддутый виэйт и с одним каналом на форсунки будет ездить, просто на низких нагрузках будет гораздо хуже работать. STC прекрастно понимает всю соль твоего предложения и говорит о том же о чем и я, уж если я не являюсь для тебя авторитетом то хоть его послушай.
По поводу лишних ресурсов МК, экономически не оправданно ставить убогий stm8 вместо stm32 при разнице в стоимости конечного устройства в пару процентов. Зато твое высказывание чертовски напоминает: "Всем хватит одного мегабайта!!!". И если в 90стые когда разрабатывались янврарь и микас c509 явно выигрывал по соотношению цена/приозводительность/переферия то спустя 15 лет ставить такие примитивные МК без существенной экономии средств просто бред. Был бы мегаскрит на арме или на мипсе меня бы здесь небыло... Был бы недорогой и распространенный готовый ЭБУ на нормальном МК (пусть даже и с закрытой архетиктурой но с 8 каналами на форсунки и хотябы 4 на зажигание) меня бы тут тоже небыло. Но нихрена нет, то что есть стоит неадекватно дорого...
KOT
LQFP112 - Up with the play
Posts: 188
Joined: Fri Apr 06, 2012 6:59 pm
Location: Ukrainian, Zaporozhye
Contact:

Re: Оптимальное распределение ресурсов МК в прошивке

Post by KOT »

У вемса 2 канала, там нет индивидуально управляемых форсунок..
Может я что-то не то нашел?
http://www.vems.hu/wiki/index.php?page= ... FSchematic

В чем-то Qwertty прав, ведь управляеть VEMS 8-мю форсунками, и мега128, если б у меги 128 было 30 таймеров с ШИМ то я бы все равно голосовал за что-то типа арма, прикручивать внешнее USB, CAN, SD карточну не обязательно, но многие захотят, а в меге этого нет.
nikll
LQFP144 - On Top Of The Game
Posts: 553
Joined: Sun Nov 06, 2011 9:20 pm
Location: Russia, Yekaterinburg
Contact:

Re: Оптимальное распределение ресурсов МК в прошивке

Post by nikll »

под каналами я имел ввиду индивидуальность управления ими, там же просто обвязка на восемь форсунок. С таким же успехом можно и сотню форсунок на один канал таймера повесить и рулить ими одновременно.
Qwertty
LQFP144 - On Top Of The Game
Posts: 252
Joined: Thu Jul 26, 2012 12:35 pm

Re: Оптимальное распределение ресурсов МК в прошивке

Post by Qwertty »

nikll wrote:Да не верно ты расписал, там нихрена не 0,1%, 0,1% это только обработка одной очереди, не забывай что там еще много всего потребуется.
Ясное дело - много всего. Я написал только разницу из за уплотнения таймеров. Остальное одинаково.
nikll wrote: У вемса 2 канала, там нет индивидуально управляемых форсунок... Наддутый виэйт и с одним каналом на форсунки будет ездить, просто на низких нагрузках будет гораздо хуже работать.
Вемсавцам это расскажи - они поржут. Там фазы настраиваются и есть по форсуночная коррекция. Это не мегаскирт. Я так понимаю 8 выходов на зажигание в твоем понимании тоже у них запараллелены? :mrgreen:
nikll wrote: STC прекрастно понимает всю соль твоего предложения и говорит о том же о чем и я, уж если я не являюсь для тебя авторитетом то хоть его послушай.
У него совсем другой взгляд на то что правильно и неправильно. В итоге у людей на процессоре в 2 раза медленней регулятор УОЗ способен обработать большие обороты коленвала. В Январе кстати ДПКВ обрабатывается софтом, волшебного таймера поддержки шкива 60-2 там нет. Процессор тормозной шо пипец. Но работает и на 15 тысячах оборотов от прерываний по ДПКВ не захлебывается.
Можно поднимать скорость процессора, а можно пересмотреть подход к алгоритмам.
nikll wrote: По поводу лишних ресурсов МК, экономически не оправданно ставить убогий stm8 вместо stm32 при разнице в стоимости конечного устройства в пару процентов.
4-х слойная плата стоит дорого :mrgreen: Обвязка лишняя - не бесплатная. Больше плата - больше корпус. Корпус тоже чем больше, тем дороже. И т.д.
nikll wrote: Зато твое высказывание чертовски напоминает: "Всем хватит одного мегабайта!!!". И если в 90стые когда разрабатывались янврарь и микас c509 явно выигрывал по соотношению цена/приозводительность/переферия то спустя 15 лет ставить такие примитивные МК без существенной экономии средств просто бред. Был бы мегаскрит на арме или на мипсе меня бы здесь небыло... Был бы недорогой и распространенный готовый ЭБУ на нормальном МК (пусть даже и с закрытой архетиктурой но с 8 каналами на форсунки и хотябы 4 на зажигание) меня бы тут тоже небыло. Но нихрена нет, то что есть стоит неадекватно дорого...
Бери правильный проц, хоть 64 разрядный - слова против не скажу. На 5В и желательно автомобильный. Хоть кортекс, хоть любой другой. А пока мне кажется бредом пихать в ответственный узел дешевый ширпотреб типа stm32. Мотивируя это тем, что он быстрее. Скорость в первую очередь зависит от алгоритма. Так что 8-ми битный может обогнать 32 битный. Причем в разы несмотря на меньшую в 4 раза разрядность и в 3 раза меньшую частоту. Опять же смотри Вемс. Уверен что кортекс со всеми его наворотами справится? Не абстрактный конечно, а конкретный и под твоим руководством? А на самом деле кристалл перекрывающий задачу по производительности минимум вдвое, позволяющий существенно упростить печатную плату и сертифицированый именно под автоприменения мне лично кажется куда более правильным выбором. Я не хочу 5 раз плату разводить, делать ее больше необходимого и т.д. - то что придется делать с кортексом. Для любительской разработки это все в принципе простительно. Сам собрал, на обгоне заглючило, убился - претензии предъявлять не к кому. :lol2: Если бы это была даже маленькая фирмочка с 3 сотрудниками, то вопрос бы так вообще не стоял. Кортекс? Автомобильный? Нееет??? Забудь о нем. :mrgreen:
Qwertty
LQFP144 - On Top Of The Game
Posts: 252
Joined: Thu Jul 26, 2012 12:35 pm

Re: Оптимальное распределение ресурсов МК в прошивке

Post by Qwertty »

KOT wrote:прикручивать внешнее USB, CAN, SD карточну не обязательно, но многие захотят, а в меге этого нет.
В мегах все это есть. Просто не в 128-ой. SD карту пихать в мозг смысла нет никакого, хотя к меге она так же запросто подключается. При наличии любого выведенного интерфейса сделать внешний даталоггер совсем не сложно. И он будет в разы удобней. USB в мозге - баловство. Этот интерфейс способен завесить даже комп. Ни в одном современном ЭБУ нет USB. И никогда не будет. Внешний шнурок вполне решает все задачи и он может использоваться на нескольких авто. Шансы сбоя там намного меньше, если мост прямо у разъема USB расположен.
В общем в сети есть много "лестного" про USB. Вот к примеру - http://caxapa.ru/323301.html?todo=full
Еще - http://forum.ixbt.com/topic.cgi?id=48:8436
Если с гуглем дружишь - найдешь еще с сотню. А вот попробуй найти о глючащем CAN или RS485. Или эзернете.
KOT
LQFP112 - Up with the play
Posts: 188
Joined: Fri Apr 06, 2012 6:59 pm
Location: Ukrainian, Zaporozhye
Contact:

Re: Оптимальное распределение ресурсов МК в прошивке

Post by KOT »

Опять же распределение ресурсов, в STM32 общение с SD на аппаратном уровне, в меге по SPI и программно.
USB - ну хрен с ним но подключатся было бы удобно.
Я вобще "железячник" с меня программист незнаю какой, пишу - работает иногда глючит убираю глюки итд, поэтому софтварные юсарты(или им подобные задачи), очередь управления форсунками итд немного трудноватые задачи, тем более что я не владею СИ, хотя без СИ и на STM32 лезть не стоит.
Post Reply