rusefi.com

круто!
я пропустил, а входы тоже конфигурируются?
а есть защита от дурака? (проверка на "занятость" пина?)

не пропустил - через TS начали только что конфигурироваться, пока только через консоль было

с защитой от дурака - пока слабая достаточно

void prepareTimingMap(void) {
for (int k = 0; k < FUEL_LOAD_COUNT; k++)
timing_ptrs[k] = engineConfiguration->fuelTable[k];
initialized = TRUE;
}

Это, того... Нужно работать с кодом - кому-то нужно разобраться, что же я там напрограммил, и почтать. Будут вопросы - ну давайте добавлять больше документации. Потому что такие баги это п"№%"№ц

Второй двигатель быстрее раскручивается и пришлось под него улучшить управления зажиганием в переходных состояниях. Завёлся

[video][/video]

расскажи подробнее про обновленное управление зажиганием? скорость мотора по-прежнему определяется раз на оборот кв или уже по времени между зубьями?

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

Четыре двигателя завелись - вот теперь-то работы потенциально очень много, потому что на самом деле в прошивке сейчас нет почти ничего. И точность не очень до сих пор.

Так что я в печали - потому что те, кто я знаю мог бы попрограммировать - как-то не очень программируют...

@ крут - он починил экранчик!

А я ковыряю более правильный таймер.

Планировщик стал микросекундным и эффективным - сделан на базе 32битного 1МГц таймера, см SingleTimerExecutor.cpp

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

Сделал.

Время мы теперь считаем прямо в тиках процессора. Тики процессора переполняют int каждые 23 секунды, так что тики процессора считаем в 64 битовом таймере - для этого написал небольшой класс, который ловит переполнения аппаратного таймера. Аккуратно делим тики на 168 - и получаем микросекундный таймер. Соответственно сейчас я перевёл все обращения к таймеру на обращение к нашему личному-быстрому таймеру, и это позволило мне снизить частоту тиканья системного таймера операционной системы. Операционная система до этого тикала на 100KHz и это тяжёлая операция, это жрало почти весь проц - тики начинали тормозить, и тормозили они аж на 10%. Всё, снизил частоту тиканья системы до стандартных 1000Hz, и нам стало сильно лучше: генерация ШИМа перестала тормозить.

Завтра сделаю команду генерации тестового сигнала - можно будет тестировать генерации разных ШИМов параметров.

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

может поставить отдельные шим контроллеры?

ну это не глюк, точность повышать всегда планировалось рано или поздно

тут вот товарищ тем же вопросом интересовался?
http://forum.easyelectronics.ru/viewtopic.php?f=49&t=18744

puff wrote:тут вот товарищ тем же вопросом интересовался?
http://forum.easyelectronics.ru/viewtopic.php?f=49&t=18744

Там товарищ мало что успел сказать, там за него додумывают, чего же он хотел. Но таки да, похоже.

Как-бы добавил pwmtest FREQ команду, см. https://svn.code.sf.net/p/rusefi/code/trunk/firmware/controllers/PwmTester.cpp

Два нюанса: на билд сервере похоже старый компилятор, так что билд сервер не осилил, и похоже у меня всё-таки где-то бага в https://svn.code.sf.net/p/rusefi/code/trunk/firmware/controllers/system/SingleTimerExecutor.cpp - иногда видимо следующее срабатываение таймера оказывается не запланированным, и это генерацию сигналов останавливает. Вот бы кто нашёл баг, эххх....

Что-то я не могу осилить это баг, так что я пошёл на freelancer.com

https://www.freelancer.com/projects/C-Programming-Embedded-Software/stm-find-fix-bug-software.html

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

нет , там после секунды пропадает генерация шима .

тык там надо дебуг моде он, делать чекпоинты и трейсинить - небось быстрее, чем на фрилансере нанимать людей?

@, вот как тебе ответить, чтоб не обидеть, а?

лучше не надо)
так это pwm или просто меандр?

Вообще-то это ШИМ, но в данном случае он сконфигурирован как меандр - новое для меня слово.

Ууууууууууууффффф, вроде бы отладил



5 микросекунд максимум дрожжания, который я вижу - програмно получается генерить 2КГц, каждый может попробовать частоты выше - см. PwmTester.cpp

с победой! обошлось без фрилансера? в чем в итоге оказалась проблема?

puff wrote:в чем в итоге оказалась проблема?

проблема была где-то в коде работы с аппаратным таймером - перешёл на готовый драйвер и всё заработало.

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

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