[rusEfi] ВАЗ-2103 "Рыжик" (1977) :: Lada 1500 "Ryzhik" (1977) #37

[andreika]

Запостил основной PR бутлоадера.
Надеюсь, кому-то мои старания тоже пригодятся...

[AndreyB]

Крутая штука! Я медленно можно буду потихоньку вкуривать?

1) я тупо скопировал первые три файла. Можно тебя попросить попробовать merge from remote master в себя - цель отщипывать по одному файлику из PR, чтоб несколькими шагами всё очень подробно прочитать и понять?

2) dfu.h наводит меня на подозрения, что где-то есть документация на этот протокол? Можно тебя попросить прямо в dfu.h добавить ссылку, откуда идёт сакральное знание например #define DFU_GO_CMD 0x21?

3) меня бесит немного эта ST DFU поделка, она не поддерживает командную строку и вообще ужас-ужас. Если делать хорошо, то нам получается нужно сделать вкусный программатор на java в консоль? Или для начала ST поделку заставить работать с параметрами командной строки? Или она умеет, и я что-то упускаю?

А вообще - я прямо в шоке, как круто и хорошо!

[AndreyB]

PS: сейчас https://github.com/rusefi/rusefi/pull/434/files "Files Changed: 16", хочу попробовать сделать сначала 13, потом 12 и так далее?

[meXanicus]

Блин все так круто! Слежу с большим удовольствием за работой @andreika!

[andreika]

Крутая штука! Я медленно можно буду потихоньку вкуривать?
1) я тупо скопировал первые три файла. Можно тебя попросить попробовать merge from remote master в себя - цель отщипывать по одному файлику из PR, чтоб несколькими шагами всё очень подробно прочитать и понять?" сейчас "Files Changed: 16", хочу попробовать сделать сначала 13, потом 12 и так далее?

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

2) dfu.h наводит меня на подозрения, что где-то есть документация на этот протокол? Можно тебя попросить прямо в dfu.h добавить ссылку, откуда идёт сакральное знание например #define DFU_GO_CMD 0x21?

Да, есть документация на протокол. Добавил ссылку на соответствующий appnote.

3) меня бесит немного эта ST DFU поделка, она не поддерживает командную строку и вообще ужас-ужас. Или для начала ST поделку заставить работать с параметрами командной строки? Или она умеет, и я что-то упускаю?

Внутри FLASHER-STM32 (flash_loader_demo_v2.8.0) есть два исполняемых файла:
1) "STMFlashLoader Demo.exe" - это GUI, скриншоты с которого я опубликовал. Качество реализации действительно так себе, на уровне Demo...
2) "STMFlashLoader.exe" - версия для командной строки. Она полнофункциональна и умеет всё то же, что и GUI-версия - куча параметров!
Так что можно смело встраивать это дело в скрипты и т.п.
Кстати, сам протокол довольно хорошо описан и стандартизирован на уровне ST - его используют DfuSe (для USB), STM32Cube (Expansion_AN4852) и т.д.

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

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

Кстати, как я уже писал, свой программатор встроен и в TunerStudio. Но там, похоже, закрытый протокол, доступный только для MS3. Хотя, если немножко подсмотреть "в замочную скважину" , то можно и его раскрутить: он посылает команду 0xb7 (да, уже не текстовая!), а в ответ надо вернуть { 0xdc, 'M', 'S', '3' } и так далее...

[andreika]

Пока я томился в ожидании мержда бутлоадера , написал простенький код инициализации для модуля Bluetooth!
Точнее, он оказался не очень простенький, т.к. требует динамической смены битрейта UART-порта и временного отключения Консоли.
На этот раз заранее написал readme с описанием. Если вкратце, то код добавляет команду bluetooth_hc06 для инициализации модуля HC-06 (но предусмотрено добавление и других видов модулей в будущем). Команда просит юзера на время отключить шнурок связи по UART, после чего начинает общаться с модулем bluetooth по тому же самому UART, меняя при этом baudrate.
Код проверил в работе - всё ок. Но, по традиции, по умолчанию отключил его. Включается в efifeatures.h: "EFI_BLUETOOTH_SETUP=TRUE".

В общем, после PR с бутлоадером, Андрея уже ждёт следующий весёлый PR...

[andreika]

написал простенький код инициализации для модуля Bluetooth!

Спасибо Андрею за оперативное добавление этой фичи! Заодно добавили код и для модуля HC-05.
Теперь осталось разобраться с бутлоадером. Мы уже проделали несколько итераций по улучшению кода, осталось только добавить всё это добро в основную ветку.

[puff]

круто!
там же надо какой-то дополнительный пин использовать для конфигурации?
главное - добавить доку, как выяснить, какой перед тобой модуль))

[andreika]

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

Да, вроде для некоторых модулей нужно ещё пин дёрнуть. Для HC-06, к счастью, не надо. По крайней мере, теперь у нас есть программная часть, в которую можно добавлять и другие модули.

P.S. Андрей, спасибо за мердж бутлоадера!

[AndreyB]

тебе спасибо за код

как твоя плата в целом, когда уже тыр-тыр?

[andreika]

как твоя плата в целом, когда уже тыр-тыр?

Гаражные испытания, по плану, на этой неделе.
Правда, нужно ещё управление питанием дописать. Иначе плата с существующей проводкой нормально работать не будет.
В текущей версии кода mainRelay включается, но не выключается А мне нужно, чтобы при пропадании напряжения vbatt он отключался.
Планирую сделать примерно так:
1) в system_fsio.txt добавить:

Code: Select all

MAIN_RELAY_LOGIC=(time_since_boot < 2) | (vbatt > 5)

2) в fsio_impl.cpp:

Code: Select all

// initFsioImpl() {
if (boardConfiguration->mainRelayPin != GPIO_UNASSIGNED)
		mainRelayLogic = sysPool.parseExpression(MAIN_RELAY_LOGIC);
//...
// runFsio(void) {
// instead of enginePins.mainRelay.setValue(true);
setPinState("main_relay", &enginePins.mainRelay, mainRelayLogic, engine);

3) Ну и обернуть это дело в дефайн, чтобы не сломать текущее поведение...

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

[AndreyB]

stopEngine точно работает

[andreika]

Спаял всю проводку платы:

pcb_harness.jpg (221.18 KiB) Viewed 4699 times

Также собрал все разъёмы для подключения к проводке:

harness_connectors.jpg (133.56 KiB) Viewed 4699 times

Разъёмы те же, что были в блоке SECU, за исключением нового разъёма ДАД, который решил вынести наружу корпуса:

map_sensor_with_connector.jpg (17.26 KiB) Viewed 4699 times

Теперь можно нормально подключать к плате все датчики. С ними-то и начались проблемы.

1. Во-первых, неправильно показывает ДАД. Должно быть около 100кПа, а TS показывает 88... Начал разбираться, в чём дело, и выяснилось, что неправильно считается напряжение по значению АЦП. В adc_math.h задана странная константа:

Code: Select all

#define ADC_VCC 3.0f

Почему именно 3.0, а не 3.3 (или 3.278 В, как у меня на плате) - непонятно... Как я понимаю, значение должно соответствовать напряжению на ножке VREF+, которое через НЧ-фильтр берётся с VDD, которое выдаёт линейный стабилизатор 3.3В (по схеме Frankenso стоит LM2937). Пришлось мне поставить в эту константу ADC_VCC = 3.3В, и ДАД стал показывать более-менее правильно - около 97 кПа. Скорее всего, я просто не до конца разобрался в ситуации, и надо как-то по-другому исправлять, потому что мне трудно поверить в то, что такую бяку никто не заметил...
Есть ещё мелкий нюанс: у меня датчик MPX4250A, а есть ещё другая разновидность, MPX4250, без буквы "А". Они немного отличаются характеристиками. Но в прошивке под видом "MPX4250" забиты значения, которые немного не соответствуют ни даташиту MPX4250, ни MPX4250A Правда, эта разница уже не критична (<0.5кПа).
В общем, после исправления ADC_VCC, значение MAP пока сойдёт для старта. Но вопрос по-прежнему остаётся: что с этим делать?..

2. Во-вторых, обнаружилось, что я не могу задать свои кривые для датчиков ДТОЖ (CLT) и ДТВ (IAT), как в СЕКУ. Похоже, что rusEFI просто линейно интерполирует по трём фиксированным точкам... Причём, можно задать только значения сопротивлений датчиков, а не измеряемых напряжений (что было бы удобно для калибровки кривых "на лету", при подключенном датчике).
Забавно, но мне казалось, что раз у rusEFI гораздо больше RAM, то тут должна быть более гибкая настройка с большим количеством таблиц/графиков, чтобы свести к минимуму погрешности измерений. Так что в этом направлении тоже нужно будет поработать. А пока кое-как задал по точкам, с погрешностью в несколько градусов...

[AndreyB]

Красиво сделал!

1. т.е. зависит от компонентов на плате, чип-то работает в диапазоне значений. значит должно стать настраиваемым значением https://github.com/rusefi/rusefi/issues/442 - вот только это будет несовместимое изменение, значит на переходное вмемя всё-таки компилировать будем.

2. ай как обижаешь, "линейно по трём точкам" А ведь прямо вверху https://github.com/rusefi/rusefi/blob/master/firmware/controllers/sensors/thermistors.cpp есть ссылка на https://en.wikipedia.org/wiki/Steinhart%E2%80%93Hart_equation. Мне кажется, что эта модель как раз точнее большого массива с интерполяцией?

[andreika]

1. т.е. зависит от компонентов на плате, чип-то работает в диапазоне значений. значит должно стать настраиваемым значением https://github.com/rusefi/rusefi/issues/442 - вот только это будет несовместимое изменение, значит на переходное вмемя всё-таки компилировать будем.

Согласен. Давай тогда пока сейчас сделаем как-то так:

Code: Select all

--- a/firmware/hw_layer/algo/adc_math.h
+++ b/firmware/hw_layer/algo/adc_math.h
@@ -9,7 +9,9 @@
 #define ADC_MATH_H_
 
 // it is important that this constant is a float, not double literal
+#ifndef ADC_VCC
 #define ADC_VCC 3.0f
+#endif
 #define ADC_MAX_VALUE 4095
 
 #define adcToVolts(adc) (ADC_VCC / ADC_MAX_VALUE * (adc))

А я себе ADC_VCC вынесу в свой efifeatures.h...
А у вас там на плате действительно стабилизатор на 3.0В стоит? Просто на схеме Frankenso чётко написано 3.3В...

2. ай как обижаешь, "линейно по трём точкам" Мне кажется, что эта модель как раз точнее большого массива с интерполяцией?

Виноват, в реализацию ещё не заглядывал. Увидел три пары значений в TS и, думаю, "ну всё"...
С датчиками есть определённые трудности. Есть обычные резистивные, с кривульками, которые логарифмически аппроксимируются. А есть полупроводниковые, с квазилинейной характеристикой. Я ещё более подробно про них напишу, чуть позже...

[AndreyB]

сделал

А у вас там на плате действительно стабилизатор на 3.0В стоит? Просто на схеме Frankenso чётко написано 3.3В...

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

Точнее в схеме дискавери, потому что по факту - дискавери. Там мутно - схема говорит U1 LD3985M33R - а вольтметр показывает 3.0? Может диоды? Я программист

С датчиками значит я сталкивался пока только с обычными.

[andreika]

Вот, например, один из хитрых ДТОЖ, о которых я говорил выше.
Датчик 19.3828 от Волги ГАЗ 31105: http://car-exotic.com/gaz-cars/gaz-31105-engine-management-system-8.html
Там, по ссылке приведена его характеристика. Я её построил, вот (в табличке одна опечатка):

GAZ-19.3828.png (3.81 KiB) Viewed 4687 times

Она квазилинейна, потому что рабочий элемент там не термистор, а двуханодный стабилитрон:

[AndreyB]

Если он линеен, то нужно проверить как https://en.wikipedia.org/wiki/Steinhart%E2%80%93Hart_equation отреагирует на три точки на одной прямой.

[andreika]

Если он линеен, то нужно проверить как https://en.wikipedia.org/wiki/Steinhart%E2%80%93Hart_equation отреагирует на три точки на одной прямой.

К сожалению, он плохо реагирует - возникают экстремумы:

steinhart_linearization_test.png (8.61 KiB) Viewed 4670 times

(Красный цвет - заданная прямая, Синий цвет - график Стейнхарта, построенный по коэффициентам заданной прямой).
Так что, похоже, надо добавлять в thermistor_conf_s параметр temperature_sensor_type (0="thermistor", 1="linear zener")... По умолчанию он будет 0 у всех, правильно? Андрей, сделаешь?
А потом уже допилить thermistors.cpp и добавить туда сэмплинг ломаной...

* * *

Был в гараже:
- Датчики ДТОЖ и ДТВ пока показывают температуру на Марсе. Просто подогнал параметры так, чтобы хотя бы при текущей температуре они показывали более-менее правду. Но с ними надо что-то делать. У меня ДТОЖ как раз линейный, от ГАЗа (см.выше).
- ДПДЗ работает сносно, пока оставлю как есть.
- ДАД показывает терпимо, но потом нужно будет перепроверить. К сожалению, у меня нет точного вакуумметра - не с чем сравнить.
- ДФ, ДД и лямбду пока не проверял.
- ДПКВ буду проверять завтра.

Вот что меня беспокоит - это РХХ (шаговый):
- двигается медленно (раза в 3-4 медленнее, чем в СЕКУ).
- движется не в ту сторону (инверсии направления в прошивке нет?), но это не смертельно;
- не умеет двигаться в нулевое положение ("парковаться") при отключении питания.
В общем, с ним надо будет ещё разбираться...

Кстати, о питании. Сделал простейшее управление главным реле по напряжению (см.выше). Работает! Но на данный момент просто обрубает питание блока, пока без деинициализации. Это нехорошо, но пусть хотя бы так будет - иначе вообще при отключении зажигания ничего не будет происходить, и движок продолжит молотить, пока не сдёрнуть фишку ДПКВ.
Выложить PR?

[andreika]

Вот что меня беспокоит - это РХХ (шаговый):
- двигается медленно (раза в 3-4 медленнее, чем в СЕКУ).

Посмотрел, какая скорость была в СЕКУ и выставил идентичную:

Code: Select all

#define ST_DELAY_MS 2

И всё заработало чётко и быстро!
Это означает, что нам нужно бы добавить в engineConfiguration соответствующий параметр (idleStepperPulseDuration?), чтобы юзер мог задать скорость для своего РХХ.
Ну а пока что, по аналогии с ADC_VCC, желательно принять также и временные меры, чтобы я смог оверрайдить это значение:

Code: Select all

+#ifndef ST_DELAY_MS
+// todo: migrate to engineConfiguration->idleStepperPulseDuration
#define ST_DELAY_MS 10
+#endif /* ST_DELAY_MS */

Также нужно будет добавить параметр для направления (инверсии stepperDirectionPin) - я, кажется, даже видел какой-то issue, с этим связанный...

[AndreyB]

https://github.com/rusefi/rusefi/issues/351

stepper кажется не использует никто, так что про него мне не страшно делать несовместимое изменение.

https://github.com/rusefi/rusefi/commit/4e91b721c366f68680a1a971c2f298fa578b14ed и https://github.com/rusefi/rusefi/commit/0893e5094928667b386eab4437232c8bf55003d4
https://github.com/rusefi/rusefi/commit/ec47e857ef3e1ce792836279468811d710f6f60b

про useLinear - можно начнём с порнографии использования странным образом существующих полей конфигурации странным образом?

У меня этот июнь необычно геморройный месяц, извиняюсь за лаконичность.

[meXanicus]

О отлично. У меня с ДАД и термисторами, тоже были непонятности. Я вбивал известные мне тарировки из Января, на котором и ездил мой Ситроен. Но цифры температур и давлений которые показывал русЕФИ были кривыми. Я грешил на делители в схеме. Пытался подбирать пары резисторов поточнее, цифры улучшились, но совсем проблема не решилась. Хорошо, что появился такой человек как Ты, кто может посмотреть код и сделать тесты внутри софта. Я не могу. Спасибо!

[puff]

andreika, скажи про шаговик, что нужна галочка инверсии хода (ведь в секу наверняка есть!?)
тьфу. прочитал issue - я еще в январе об этом говорил)
тьфу, а это и есть январское!

[andreika]

У меня этот июнь необычно геморройный месяц, извиняюсь за лаконичность.

Спасибо, что находишь время на проект и на мои "хотелки"!

я еще в январе об этом говорил

Да, именно твой issue я и видел.
И как раз написал небольшой PR на эту тему!
Правда, в самих настройках его пока нет (я туда не лезу - боюсь сломать совместимость - это лучше Андрею делать), но сам функционал инверсии я добавил, и он уже работает!

[andreika]

И как раз написал небольшой PR на эту тему!

Спасибо Андрею, что оперативно добавил поддержку stepperDirectionPinMode!
Также большая просьба добавить ещё один параметр в rusefi_config - starterBlockPin, по аналогии с mainRelayPin (И заодно, если найдётся свободное место, starterBlockPinMode).
Я завтра под это дело хотел бы написать соответствующий PR...

[AndreyB]

А нужны ли для таких необычных дел выделенные стандартные пины? это очень похоже на fsio пины настраиваемые?

[andreika]

А нужны ли для таких необычных дел выделенные стандартные пины? это очень похоже на fsio пины настраиваемые?

Я исходил из того, что это стандартная фича платы, под которую изначально закреплён выделенный пин. Т.е. на плате есть универсальные Out1 и Out2, которые юзер как раз может назначать через fsio, а есть mainRelay, ECF (fan), starterblock, fuelpump. Т.е. я отношу starterBlock именно к стандартным фичам, в отличие от, скажем, shift light, потому что стартёр есть практически у всех, и все его используют. Это востребованная фича, практически без недостатков. Да и для управления втягивающим реле стартёра достаточно всего лишь обычного реле - это доступно многим. Кроме того, управление реле стартёра относится непосредственно к компетенции ЭСУД, т.к. оно завязано на пороговое сравнение rpm и cranking_rpm.

Конечно, я согласен, что fsio, по задумке, идеально подходит для таких вещей. Но у текущей реализации, на мой взгляд, есть несколько недостатков:
- fsio пока не полностью представлен в GUI. Выбор пинов есть, но ввод формул - только через команды Консоли; Как мне добавить этот новый fsio, без резета моего текущего конфига? Через команды. А что будет в случае резета конфига? Они потеряются. Значит, нужно дублировать их и в коде.
- если формула зашита программно в прошивке (типа "setFsio(1, GPIOE_6, COMBINED_WARNING_LIGHT)"), то как её потом отредактировать (дописать) в настройках Консоли/TS? А как временно отключить, не потеряв маппинг пина?..
- нет удобной возможности посмотреть, какой функционал уже назначен на какие fsio-пины (в Консоли нужна обратная конвертация из RPN в human readable форму?);
- у формул (выражений) и пинов нет кастом-имён, и неискушенный сторонний юзер может не понять (вспомнить), к чему относится тот или иной пин/выражение;
- нет готовых презетов выражений с описаниями (или хотя бы с говорящими именами), которые юзер мог бы просто выбрать из списка (combo-box), чтобы не вводить руками;
Сразу оговорюсь, что я не критикую, а излагаю свои примитивные представления о ситуации (которые вполне могут быть ошибочны ).

Хотя, если подумать, то проблема кроется не столько в fsio, сколько в текущей реализации конфигурации (настроек) как таковой... Похоже, что недостаточная гибкость в представлении данных (и их сериализации) несколько затрудняет добавление новых фичей. Например, нет банальной возможности зашить мои текущие настройки в качестве дефолтного конфига в .hex прошивки (или в качестве исходников a la config/engines/). В общем, ситуация неоднозначная и, как говорится, at your discretion...

[AndreyB]

Очень хорошие идеи, их надо реализовывать невозможно реализовать в прошивке все сценарии, настраиваемые ввод-вывод очень потенциально полезны. https://github.com/rusefi/rusefi/issues/369

в моих розовых мечтах и стратегия рассчёта топлива, и еще много, много чего могли бы писаться на своём предметно-ориентированном языке

[andreika]

настраиваемые ввод-вывод очень потенциально полезны.

По такому случаю я позволил себе легонько доработать блокировку стартёра через fsio - см. соответствующий PR.

[AndreyB]

Красота Последние три недели ты пишешь кода больше, чем я