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

[frig]

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

[Maxi]

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

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

[frig]

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

[Maxi]

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

Вот тут как раз торопится не надо.
кодов написанных уже как грязи - но результата хорошего с этих кодов в единичных случаях получают..

[frig]

Нужен баланс. Понятно, что бездумно строчить ради того, чтобы строчить - глупо. Но и проектирование ради проектирования также смысла лишено. Хорошо бы все таки от теорий переходить ближе к практике. Итеративная разработка позволяет балансировать и совершенствовать, нет смысла пытаться вспроектировать все досконально. Водопадная модель вряд ли сработает хорошо, да и кто будет этим всем заниматься?
Есть конерктый фронт работ, есть конкретные потребности и даже небольшая цель. Зачинатель безобразия изначально сильно радеет за здоровую архитектуру и абстракцию от железа. Это хорошо скажется на поддержке и развитии, так что я как раз больше переживаю за уход в деление шкуры неубитого медведя, преждевременные оптимизации, когда еще ни строчки не написано. Это путь вникуда.

[XDA]

Полностью поддерживаю макси.
Каков фундамент - таково и здание.
Переделать фундамент под зданием невозможно.

Поэтому вначале - фундамент. И все силы должны быть брошенны именно на него

[frig]

XDA, давайте конкретнее. Чем плохо то, что есть сейчас и что вы предлагаете с этим делать?

Касательно замены фундамента. Нормально написанный код без жестких привязок к железу, без жестких привязок к ОС и другим вещам пускай и будет иметь бОльшый оверхед, но в отличии от монолитов вроде зданий на фундаментах очень даже подвергается оптимизации, рефакторингу и замене блоков. Интерфейсы надо прорабатывать - да. Архитектуру в общем - да. Сейчас уже есть кое что и есть смысл говорить предметно о том, что есть.

[AndreyB]

в частности проблемы AVR8 заложенные на старте никаким кодом не исправить уже.

А какие там, просто для общего развития?

[Maxi]

в частности проблемы AVR8 заложенные на старте никаким кодом не исправить уже.

А какие там, просто для общего развития?

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

[AndreyB]

Что-то мне не нагуглить ECU на ключевое слово AVR8, гуглится только сам процессор восьмибитый.

[nikll]

Maxi имел ввиду VEMS который работает на этом МК

[XDA]

Что-то мне не нагуглить ECU на ключевое слово AVR8, гуглится только сам процессор восьмибитый.

Имеется в виду мегасквирт

[Sergey89]

megasquirt на freescale камнях всегда был. а вот megasquirtavr это клон на atmega. и сейчас это VEMS.

так как таймеров в атмеге не хватает, то они сделали программную очередь в виде heap структуры, потому что очередь нужно сортировать при добавлении нового события. в итоге это всё приводит к фазовым дрожаниям сигналов. насколько сильным не знаю. но atmega это 8 бит, 16 mips без аппаратного деления и умножением только 8x8.

кому интересно могу скинуть прошивку датируемую 2005 годом. я не знаю переписали они её с того времени или нет.

[alex1100]

Да ребята... сразу видно, что вы кучу моторов собрали и откатали на Мегасквиртах и Вемсах... )))
и мне, простому практику и не программисту как-то совсем не понятно. зачем ЭБУ рассчитывать наполнение? может еще заставить его делать полный расчет всех параметров согласно теории ДВС?

ИМХО: все гениально - просто... не надо ничего усложнять, не надо заставлять проц трудиться над расчетом кучи ненужных параметров и все будет четко работать...
Я конечно понимаю, что могу быть не прав с точки зрения написания кода, но с ДВС и топливными системами я работаю больше 15 лет и расчеты большего количества параметров в ЭБУ нужны только для диагностики и понтов типа режима "вали домой"...

Написать код - это одно, а заставить его работать - совсем другое...
Я очень уважаю вашу инициативу и стремление поэтому поделюсь своими мыслями...

Как я вижу решение вопроса...
лучший вариант размерности карт для гражданского атмо и турбо - 32Х32 и запас по оборотам 25000, этого более чем...
карты привязать к конкретным датчикам по осям в данном случае, по одной оси будут обороты, по второй или ДАД с поправкой на ДПДЗ или наоборот...
для отсчета по оборотам и расчета угла КВ использовать таймер и все основные операции по впрыску и углам привязывать к углу КВ... (ну это само собой...)
измерение параметров и общение с компом в оставшееся время...

Проца этого более чем достаточно, чтобы на нем спроектировать ЭБУ ДВС, КПП, и АБС вместе...
Если посчитать то 25000 об/мин - это 416,6666666666667 об./сек, а один оборот займет 0,0024сек. итого мы имеем 384000 операций на обработку одного оборота двигателя, может я неправильно посчитал, но неужели этого мало, если у меги в лучшем случае 20MIPS и при этом все работает...
Более того, как много гражданских ДВС работают в таком диапазоне оборотов? Мотики максимум 18000... Автомобильный дико натюненый мотор 12000...

[AndreyB]

@, ты во многом прав. Вопрос выбора алгоритма топлива тут немного религиозный и ему по-моему придаётся в целом слишком много внимания. Я 100% согласен с тобой, что начинать нужно со стабильности и откатки и обкатки простой табличной подачи топлива.

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

stm32f4discovery, схема ввода-вывода, и давай отлаживать работу с 32x32 и 12000 оборотов