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

[andreika]

Приветствую всех!

This is a russian language version of Lada 1500 "Ryzhik" (powered by Prometheus) blog. Please visit Prometheus topic.

Это тематический мини-бортжурнал на русском языке, посвящённый установке rusEFI на плату Прометей на моей машине ВАЗ-2103 "Рыжик".
Тема будет вестись в формате новостного блога, с описанием всех этапов реализации и возникающих при этом проблем и их решений.

Здесь также можно будет прочитать последние неофициальные новости, планы и сплетни о проекте Прометей

* * *

ВАЗ-2103 "Рыжик" (1977):

small.jpg (47.7 KiB) Viewed 5314 times

Кратко о машине:

• машина выходного дня, "игрушка-конструктор";
• год выпуска 1977, пробег 67 тыс.км.;
• двигатель 1.65л бензиновый;
• коробка передач механика, 5-ст.;
• сделана замена почти всех запчастей на новые, плюс много доработок механизмов;

Краткая летопись разработки Прометея:
13.02.2017 Зарегистрировался на форуме и начал собирать информацию про rusEFI.
17.03.2017 Приступил к разработке платы "Прометей".
19.03.2017 Андрей @Russian попытался отговорить меня от этой безрассудной затеи .
22.03.2017 Схема готова!
07.04.2017 Разводка платы готова! Заказано производство первой партии плат.
13.04.2017 Создана англоязычная тема Прометея. Первая публичная презентация проекта.
15.04.2017 Заказали новые микропроцессоры STM32F469.
04.05.2017 Платы и детали приехали, можно приступать к сборке!
Продолжение следует...

Cсылки по теме:

• Официальная тема обсуждения проекта Прометей на форуме rusEFI, англ.яз.
• Вики-страница проекта Прометей (в разработке), англ.яз.
• Бортжурнал машины на drive2.ru
  ...

* * *
Напоследок хочу попросить всех, кому небезразлична эта тема (и проект Прометей), запастись терпением и не забегать наперёд с подробными расспросами и критикой, поскольку проект пока находится на начальной стадии. Информация и фотографии будут обязательно публиковаться по мере появления.

Спасибо за понимание и интерес,
andreika.

[andreika]

*** Это сообщение зарезервировано для добавления важной информации ***

[andreika]

Начинаем сборку первой платы Прометей! Запаял пока только блок питания, проц и USB-часть.
Включаем плату с программатором:

first_run_and_connect.jpg (751.34 KiB) Viewed 5298 times

Заливаем прошивку со конфигом для Прометея и коннектимся с ТюнерСтудио:

tunerstudio_first_connection.png (263.74 KiB) Viewed 5298 times

И с консолью тоже попробуем, а как же! Вот первый лог коннекта с консолью:

first-connect-log.txt

(19.5 KiB) Downloaded 383 times

Кстати, с CUSTOM_ENGINE оно работать не может - конфликтует. Я пока тупо по-хакерски задал в makefile произвольный номер для engine_type:

Code: Select all

DDEFS += -DDEFAULT_ENGINE_TYPE="((engine_type_e)100)"

Но хотелось бы сделать правильно - поэтому хочу попросить Андрея создать мне engine_type для моей машины!
Или хотя бы просто добавить EMPTY_ENGINE, который бы не мешал?

В конфигурации Прометея сейчас только базовая часть настроек. SPI тоже пока отключил, т.к. чипы не распаяны, и оно тормозило при загрузке, пытаясь с ними связаться.
В общем, начало положено, я доволен! Ещё раз огромное спасибо Андрею @Russian за помощь!

P.S. Выложил pull request - пришлось повозиться, пока нашёл этот подлый boardTestModeJumperPin...
P.S. Надо ли что-то написать в теме Прометея?..

[AndreyB]

поэтому хочу попросить Андрея создать мне engine_type для моей машины!

https://github.com/rusefi/rusefi/blob/m ... etheus.cpp

[andreika]

Спасибо! А оно не будет у меня затираться при каждом чекауте репозитория? Или мне лучше выкладывать pull-requests с прометеевскими правками - пусть будут и в основном codebase?

[AndreyB]

Затираться точно не будут.

[andreika]

Итак, плату спаял, начинаю тестирование.

Вначале нужно разобраться с SPI. На нём у нас сидит карта памяти (SPI1), HIP (SPI3) и CJ (SPI3).
1) Начнём с карты памяти. Сходу не заработала. Начинаем разбираться.
Прежде всего, нужно пропатчить hardware.cpp:

Code: Select all

diff --git a/firmware/hw_layer/hardware.cpp b/firmware/hw_layer/hardware.cpp
index e75a28dd..448deffe 100644
--- a/firmware/hw_layer/hardware.cpp
+++ b/firmware/hw_layer/hardware.cpp
@@ -81,6 +81,9 @@ void unlockSpi(void) {
 }
 
 static void initSpiModules(board_configuration_s *boardConfiguration) {
+	if (boardConfiguration->is_enabled_spi_1) {
+		turnOnSpi(SPI_DEVICE_1);
+	}
 	if (boardConfiguration->is_enabled_spi_2) {
 		turnOnSpi(SPI_DEVICE_2);
 	}

2) Далее выясняем, что код виснет где-то внутри mmcConnect(&MMCD1). Т.е. не возвращает HAL_FAILED, а именно виснет. В циклах там везде счётчики-таймауты: некоторые из них, конечно, длинные (секунда-другая), но совсем зависнуть вроде не должен. Осциллограф при этом показывает, что карта памяти что-то отвечает. Пробовал на двух разных картах. Может быть, поиграться с SPI_BaudRatePrescaler?.. В общем, более глубоко пока не копал, это уже завтра...

3) Теперь попробуем HIP. Он тоже пока не отзывается. Кстати, showHipInfo(void) надо бы тоже чуток пропатчить, иначе он выдает пинауты только для SPI2, а у нас-то SPI3:

Code: Select all

	scheduleMsg(logger, "mosi=%s", hwPortname(getMosiPin(engineConfiguration->hip9011SpiDevice)));
	scheduleMsg(logger, "miso=%s", hwPortname(getMisoPin(engineConfiguration->hip9011SpiDevice)));
	scheduleMsg(logger, "sck=%s", hwPortname(getSckPin(engineConfiguration->hip9011SpiDevice)));

Для того чтобы HIP заработал на SPI3, нам, похоже, нужно вначале сделать что-то вроде этого:

Code: Select all

engineConfiguration->spi3SckMode = PAL_STM32_OTYPE_OPENDRAIN; // 4
engineConfiguration->spi3MosiMode = PAL_STM32_OTYPE_OPENDRAIN; // 4
engineConfiguration->spi3MisoMode = PAL_STM32_PUPDR_PULLUP; // 32

Но сделать мы этого не можем, т.к. этих переменных нет в rusefi_config.txt
И в turnOnSpi() (mpu_util.cpp), разумеется, тоже.

На этом пока всё...

[AndreyB]

немного покоммитил, спасибо за терпение

[andreika]

немного покоммитил, спасибо за терпение

Это тебе спасибо за апдейты!
После этих замечательных коммитов заработала и карта памяти, и чип детонации!
На карте памяти создаются лог-файлы. А чип детонации выдает по команде "hipinfo" следующее:

Code: Select all

enabled=Yes state=1 bore=87.50mm freq=6.54kHz PaSDO=6
band_index=39 gain 1.00/index=-1 output=PC0
integrator index=-1 knockVThreshold=4.00 knockCount=0 maxKnockSubDeg=20.00
spi=SPI_DEVICE_3 IntHold@PC14/2 response count=3 incorrect response=0 ok
CS@PD1 updateCount=0
hip 0.00v/last=2.26@PC0/max=0.00 adv=0

Правда, пришлось пока отключить CJ125 (boardConfiguration->isCJ125Enabled = false), т.к. он делает spiStart(driver, &cj125spicfg), и из-за этого перестаёт работать HIP (конфликт ssport/sspad?)..

Но, главное, можно двигаться дальше и продолжать тестировать.

[andreika]

Попробовал и наоборот: отключил HIP и включил CJ125. Затем запустил немного модифицированный cj125test, и чип мне вернул байт "62h", что, согласно даташита, соответствует версии CJ125BA! Общение налажено, можно будет продолжать знакомство...
Если будет время, можно также попробовать заставить их работать вместе на одном интерфейсе (пока топорным методом):
- к примеру, в cj125 перед селектом подменять конфиги spi, если не придумаем покрасивее:

Code: Select all

lockSpi(engineConfiguration->cj125SpiDevice);
const SPIConfig *savedConfig = driver->config;
driver->config = &cj125spicfg;
spiSelect(driver);
//...
spiUnselect(driver);
driver->config = savedConfig;
unlockSpi();

- подобавлять lockSpi() и в HIP9011 (в синхронную и асинхронную части): завернуть там селекты в wrappers с локами;
- можно заодно доработать lockSpi() и разделить мьютексы по интерфейсам, как и планировалось Андреем;
Продолжаем тестить...

[AndreyB]

жду вкусных pull request'ов

[andreika]

Проверил все аналоговые входы.
Взял потенциометр 1кОм, с аналоговой земли на +5В, и подключал ко всем входам, крутил ручку и смотрел на показометры в ТюнерСтудио.
Реагировали стрелки в:
- CLT
- IAT
- TPS
- MAP
- O2
- Voltage (показывало правильно с точностью до 0.1В!)
Так что оба операционника работают нормально, АЦП сконфигурированы правильно! На реальных датчиках буду проверять уже позже.
Тестируем дальше...

[andreika]

Было бы удобно, кстати, сделать в прошивке опцию (#define), чтобы, если нужно, на время тестирования не работала бы флеш-версия настроек (чтение/запись), а использовались только дефолтные настройки, заданные в resetConfigurationExt()... А то, бывает, скомпилил версию, прошил, пробуешь, а старые настройки мешают и уже неизвестно, изменились они или ещё нет...

А тем временем проверил чип MAX9926. Вывел сигнал triggerSimulatorPins[0] на специальный отладочный пятачок рядом с процом (PD8), и соединил проводком на вход CRANK+ - Тюнерстудио показывает обороты 1200! Только непонятно, как проверять датчик фаз - CAM+ (см.вопрос darxfame в его ветке)...

[puff]

что такое triggerSimulatorPins?
MAX нужно проверять на полноценном датчике и в боевых условиях.

имхо датчик фаз проверяется тем же способом, что и ДПКВ (или оно другого типа?)

[andreika]

что такое triggerSimulatorPins?

Это не я, это всё @Russian сделал!

MAX нужно проверять на полноценном датчике и в боевых условиях.

Это понятно, но до этого ещё очень далеко! Ещё плата не остыла после пайки, а её уже на машину ставить?! Так что мы потихоньку, пока тычем осциллографом, принюхиваемся... Потом начнём приучать плату к гаражу, а годика через три, глядишь, уже можно и к машине подходить...

[andreika]

Продолжаем тестирование.
1) Проверил силовые выходы:
- CE - ОК! (запускал встроенный тест)
- Fuel Pump - ОК! (запускал встроенный тест)
- ECF - ОК! (запускал встроенный тест)
- TACH - ОК! (выдаёт сигнал нормально)
- к сожалению, выводы PWR (главное реле) и STBL (блокировка стартёра) не проверил - встроенных средств для проверки не нашёл (точнее, просто поленился ).

2) Также проверил сигналы форсунок и катушек при включенном симуляторе ДПКВ и в режиме впрыска IM_SIMULTANEOUS и зажигания IM_INDIVIDUAL_COILS. Работают все 4 форсунки и 4 вывода катушек! (но сами BIPы я ещё не запаял).

3) Проверил цифровые входы. Назначил каждый вход на clutchDown и в ТюнерСтудии вывел его в показометр (с помощью "дизайнера"). Чётко работают. Правда, я подозреваю, что датчик скорости на них не назначить (похоже, в текущей прошивке ему требуется input capture таймера). Так что датчик скорости будет пока только у тех, у кого нет датчика фаз (или нужно допиливать прошивку, сделав опрос ножек входов по таймеру - вроде бы частоты несколько кГц должно хватить).

4) Проверил РХХ. Работает! При старте выдаёт правильные сигналы. Но штатная кнопка "test" для idle почему-то не работала. Зато прекрасно работала команда "blipidle" - так и потестировал. В Прометее нет отдельной ножки проца на Enable драйвера шагового двигателя. Зато есть схема эмуляции Enable на транзисторе, которая тоже работает! При отсутствии управляющих сигналов напряжение на моторе отключается - всё окей!

5) Наконец, гвоздь программы - CAN! Взял маленький ELM327 (Bluetooth-версия), взял разъём OBD-II с проводами для него и подсоединил выводы CANL/CANH и питание с землёй. А на планшет установил Torque Pro. Вот что получилось:

can-test.jpg (568.62 KiB) Viewed 5164 times

Можно сказать, что CAN заработал (правда, обороты показывал почему-то неверные). В конфиге я выставил CAN_BUS_MAZDA_RX8 - не знаю, хорошо ли это для теста или нет...

Кстати, заметил маленькую опечатку в engine_configuration.cpp строчка "engineConfiguration->canNbcType" встречается два раза подряд с разными значениями (переопределяется). Это может запутать...

6) Осталось проверить Bluetooth. Этим я займусь в другой раз.

* * *

Итак, базовый этап тестирования платы Прометея завершён.
Были проверены:
- блок питания: ОК
- проц: ОК
- USB-часть: ОК
- карта памяти: ОК
- контроллер детонации: ОК (связь)
- контроллер ШДК: ОК (связь)
- контроллер триггеров: ОК (1 канал на тестовом сигнале)
- аналоговые входы: CLT, IAT, MAP, TPS, O2, Voltage: ОК (INA не проверял)
- силовые выходы: ОК (проверены частично)
- выходы катушек и форсунок: ОК (без нагрузки)
- цифровые входы: ОК
- драйвер шагового двигателя: ОК (без нагрузки)
- контроллер CAN: ОК (связь)

Плата в целом рабочая, и можно приступать к пайке проводки и подготовке к следующему этапу тестирования.
По итогам работы с платой был замечен только один серьёзный недостаток: рвётся связь с компом. Проявляется и в ТюнерСтудио, и в Консоли. Видимо, уровень помех высоковат, плюс используется схема с объединением сигналов Tx (диоды+резистор - a la секу). Нужно будет попробовать убрать диод и сделать UART напрямую. А также попробовать Bluetooth. Или внешний UART-USB кабель, для теста (Rx/Tx выведены наружу).
Причём, что интересно, консоль более устойчиво работает на битрейте 57600 (связь почти не рвётся), а ТюнерСтудио больше нравится 38400. Почему так - не знаю.

To be continued...

[puff]

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

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

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

RX8 - ура!
Глянь, кстати, в can_hw.cpp, там тоже переопределяется пакет в этом RX8 - есть подозрение, что что-то так и остаётся неотправленным.

[AndreyB]

выводы PWR (главное реле) и STBL (блокировка стартёра) не проверил - встроенных средств для проверки не нашёл (точнее, просто поленился ).

главное реле - просто всегда включено
STBL - просто нет в rusEfi сейчас

[AndreyB]

заметил маленькую опечатку в engine_configuration.cpp строчка "engineConfiguration->canNbcType" встречается два раза подряд с разными значениями (переопределяется). Это может запутать...

починил, спасибо

[andreika]

один серьёзный недостаток: рвётся связь с компом. Видимо, уровень помех высоковат, плюс используется схема с объединением сигналов Tx (диоды+резистор - a la секу).

Исследовал проблему плохой связи с компом. Довольно интересная "детективная" история получилась - короче, садитесь поудобнее и слушайте!

Вначале нужно было определить, действительно ли связь плохая из-за самой платы, т.е. помех или неудачной схемы или разводки платы. Для этого я написал маленькую тестовую прошивку на ChibiOS, которая слушает UART4 на битрейте 115200 и в эхо-режиме выдаёт все полученные байты обратно. И больше ничего не делает. За основу взял настройки и мейкфайлы rusEFI.

Затем я откопал на простотах инета старую программку Андрея на джаве "TwoWayTester", немного изменил её и пересобрал. Программка эта шлёт в COM-порт строки длиной ~20 символов и сравнивает с ними выдаваемые с порта данные (посимвольно). И печатает количество совпадений или ошибок. Как раз сгодится для теста нашей "эхо-прошивки".
И что бы вы думали? ВСЕ данные передаются туда-обратно чётко, без потерь и ошибок! За более чем 15 минут ни одного бита не потерялось - и это со впаянными диодами и резистором-подтяжкой! Так что к аппаратной части Прометея претензий быть не может!

Значит, дело в самой прошивке. Выясняем. Вначале нужно перенести наш тестовый "эхо-код" в прошивку rusEFI. Имеющийся там EFI_UART_ECHO_TEST_MODE почему-то не хотел работать, да и нам уже интереснее возиться с новым бинарным протоколом TS. Итак, код эха вставил прямо внутрь runBinaryProtocolLoop(). После запуска оказалось, что потери байт есть! Причем, не порча данных, а именно потеря 1-2 байт в некоторых входящих пакетах. Стала также понятна причина постоянных дисконнектов ТюнерСтудио: таймаут чтения TS_READ_TIMEOUT задан слишком большой - аж 3 секунды. Достаточно потерять 1 байт, и прошивка будет ждать целых 3 секунды, не выдавая ничего в ответ (это подтверждают и осциллограммы) - и этого времени как раз хватает, чтобы отвалился TS. Короче, уменьшил TS_READ_TIMEOUT до 1 секунды - стало полегче!

Ясное дело, что уменьшение TS_READ_TIMEOUT лечит последствия, а не саму "болячку". Надо "копать" дальше! Перемещаем эхо-код в самое начало прошивки и стопорим её дальшейнее выполнение - мы снова получаем идеальную работу UART - "ни единого разрыва"! Стало понятно, что на работу UART влияет какой-то другой код, выполняющийся параллельно. И он был найден: это функции periodicFastCallback() и periodicSlowCallback(). Если их убрать - потерь нет. Точнее, виноват оказался не код этих функций, а сам виртуальный таймер, который их вызывает!

Почему виноват таймер? Потому что приоритет этого таймера (SCHEDULING_TIMER_PRIORITY=4) оказался выше, чем приоритет прерывания UART (STM32_SERIAL_UART4_PRIORITY=12)! И поэтому во время чтения очередной команды могло возникнуть прерывание таймера и "украсть" один-два байта!

Для проверки этой гипотезы решил для Прометея поменять приоритеты:

Code: Select all

#define STM32_SERIAL_UART4_PRIORITY 4
#define SCHEDULING_TIMER_PRIORITY 5
#define STM32_CAN_CAN1_IRQ_PRIORITY 4

Таймер можно смело подвинуть на приоритет 5, т.к. I2C, который сидит там, практически не используется. И тогда на 4 можно садить UART.
Главное, что мы не трогаем критичные ICU_PRIORITY и DMA-приоритеты!

И знаете, что? Связь с компом заработала как часы! Ни единого потерянного байтика за полчаса! Я очень доволен, что проблема эта оказалась именно программная, а не аппаратная. Даже удивительно, почему она так слабо проявляется на 407-й конфигурации у других пользователей...

Кстати, приоритет CAN тоже на всякий случай поменял на 4 - ну а чем он хуже UARTa? Может, теперь и он постабильнее будет - надо будет попробовать...
И, поскольку с диодным объединением сигналов UART спокойно работает на битрейте 115200, можно свободно использовать и USB-UART подключение, и попробовать Bluetooth! Это уже в следующий раз...

Вот такая история!

[AndreyB]

О как! Очень ценная информация.

только нюансы - у нас форсунки и катушки управляются из этого виртуального таймера, поэтому высокий приоритет.

Задержки uart какого порядка в секундах-миллисекундах? Т.е. кто и почему в виртуальном таймере так долго выполняется?

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

Нужно оживлять замер и мониторинг времени выполнения функций внутри виртуального буффера.

[puff]

О как! Может и проявляющийся только у меня глюк можно починить?
Только я не понял. Тут глюк в прошивке, причем на одном камне есть, на другом - нет.
А у меня, похоже, в девконсоли: на той же операционке тюнерстудия пашет без дисконнектов.
Может, тюнерстудия большие пакеты не гоняет, в отличие от консоли. Или умеет синхронизироваться лучше?

[AndreyB]

А можно тестовый код в виде патчика? (git diff) или надо чинить то, что там есть

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

@ - USB это совсем другая история. Может и совпали проблемы, но всё-таки огромная разница - и поэтому он стабильный у меня.

[andreika]

А где там катушки управляются внутри этого таймера, я что-то не нашёл?
Я писал именно про periodic-таймеры. Насколько я вижу, periodicFastTimer вызывается с частотой всего 50 Гц ("MS2ST(20)").
При этом внутри periodicFastCallback() мы имеем:
- чтение RPM и аналоговых датчиков (самый быстрый из которых MAP);
- чтение времени с помощью getTimeNowNt() (кстати, довольно медленная функция, ведущая к gettimeofday() и заморочкам с RTC, которого у меня нет (из-за #define EFI_RTC тоже были проблемы));
- расчёт накопления, коррекций и параметров для генерации сигналов впрыска и зажигания;
По идее, эти все функции должны выполняться настолько часто, насколько меняются обороты и показания датчиков, и 50 Гц там вполне хватает.
И я не вижу здесь непосредственное управление катушками/форсунками и требований к прецизионному таймингу.
Если сравнить с прерыванием UARTа, то ему для чтения 1 байта на скорости 115200 нужно, грубо говоря, 100 мкс (плюс-минус накладные расходы). Именно настолько будет задержан вызов наймера periodicFast(), если поставить приоритет повыше.
Я не знаю про остальные таймеры, я говорю только про periodicFast и periodicSlow. Я замерял их влияние. Включённый fast + slow приводит к потере байт, в среднем, в 1.8% пакетов UART. А если оставить только один slow, без fast, то портится 0.2% пакетов. С пустыми periodicFast/Slow - нет потерь вообще.

[andreika]

А можно тестовый код в виде патчика? (git diff)

Пожалуйста:

Code: Select all

diff --git a/firmware/config/stm32f4ems/mcuconf.h b/firmware/config/stm32f4ems/mcuconf.h
index 300751e7..135fc9fb 100644
--- a/firmware/config/stm32f4ems/mcuconf.h
+++ b/firmware/config/stm32f4ems/mcuconf.h
@@ -20,7 +20,7 @@
 #include "efifeatures.h"
 #include "rusefi_enums.h"
 
-#define SCHEDULING_TIMER_PRIORITY 4
+#define SCHEDULING_TIMER_PRIORITY 5
 #define ICU_PRIORITY 3
 
 /*
@@ -263,12 +263,12 @@
 #define STM32_SERIAL_USE_UART4              FALSE
 #define STM32_SERIAL_USE_UART5              FALSE
 #define STM32_SERIAL_USE_USART6             FALSE
-#define STM32_SERIAL_USART1_PRIORITY        12
-#define STM32_SERIAL_USART2_PRIORITY        12
-#define STM32_SERIAL_USART3_PRIORITY        12
-#define STM32_SERIAL_UART4_PRIORITY         12
-#define STM32_SERIAL_UART5_PRIORITY         12
-#define STM32_SERIAL_USART6_PRIORITY        12
+#define STM32_SERIAL_USART1_PRIORITY        4
+#define STM32_SERIAL_USART2_PRIORITY        4
+#define STM32_SERIAL_USART3_PRIORITY        4
+#define STM32_SERIAL_UART4_PRIORITY         4
+#define STM32_SERIAL_UART5_PRIORITY         4
+#define STM32_SERIAL_USART6_PRIORITY        4
 
 /*
  * SPI driver system settings.
diff --git a/firmware/console/binary/tunerstudio.cpp b/firmware/console/binary/tunerstudio.cpp
index afd88f0f..d3f1cbea 100644
--- a/firmware/console/binary/tunerstudio.cpp
+++ b/firmware/console/binary/tunerstudio.cpp
@@ -94,8 +94,8 @@ extern persistent_config_container_s persistentState;
 
 extern short currentPageId;
 
-// that's 3 seconds
-#define TS_READ_TIMEOUT MS2ST(3000)
+// that's 1 second
+#define TS_READ_TIMEOUT MS2ST(1000)
 
 /**
  * note the use-case where text console port is switched into

[AndreyB]

нее, я про код которым ты тестировал пропадение?

Code: Select all

/**
 * This is about SingleTimerExecutor - rusEfi 1MHz precise scheduling timer
 * this is not about ChibiOS virtual timer which rusEfi uses for
 * periodicFastCallback and periodicSlowCallback
 */
#define PRECISE_SCHEDULING_TIMER_PRIORITY 4

переименовал в PRECISE_SCHEDULING_TIMER_PRIORITY - это вообще как-бы не связанно с eriodicFastCallback and periodicSlowCallback? т.е. не понятно, как смена этого улучшила то. Или я запутался?

[andreika]

нее, я про код которым ты тестировал пропадение?

Code: Select all

diff --git a/firmware/console/binary/tunerstudio.cpp b/firmware/console/binary/tunerstudio.cpp
index afd88f0f..c5f91a3c 100644
--- a/firmware/console/binary/tunerstudio.cpp
+++ b/firmware/console/binary/tunerstudio.cpp
@@ -565,6 +565,24 @@ static THD_FUNCTION(tsThreadEntryPoint, arg) {
 	(void) arg;
 	chRegSetThreadName("tunerstudio thread");
 
+//!!!
+#if 1
+	event_listener_t elSerData;
+	chEvtRegisterMask((event_source_t *)chnGetEventSource(TS_SERIAL_UART_DEVICE), &elSerData, EVENT_MASK(1));
+	for (;;) {
+		chEvtWaitOneTimeout(EVENT_MASK(1), MS2ST(10));
+		eventflags_t flags = chEvtGetAndClearFlags(&elSerData);
+		if (flags & CHN_INPUT_AVAILABLE) {
+			msg_t charbuf;
+			do {
+				charbuf = chnGetTimeout(TS_SERIAL_UART_DEVICE, TIME_IMMEDIATE);
+				if (charbuf != Q_TIMEOUT)
+					chSequentialStreamPut(TS_SERIAL_UART_DEVICE, charbuf);
+			} while (charbuf != Q_TIMEOUT);
+		}
+	}
+#endif
+
 #if EFI_PROD_CODE || defined(__DOXYGEN__)
 	startTsPort();
 #endif

И вот:

TwoWayTester.zip

(254.19 KiB) Downloaded 42 times

это вообще как-бы не связанно с eriodicFastCallback and periodicSlowCallback? т.е. не понятно, как смена этого улучшила то. Или я запутался?

Тогда, видимо, periodic сидят на каком-то другом таймере, которые все "#define STM32_GPT_TIMx_IRQ_PRIORITY 7"? Получается, что можно сделать UARTx_PRIORITY=5 (5<7), а SCHEDULING_TIMER не трогать?

[AndreyB]

Обрати внимание

Code: Select all

#define STM32_GPT_USE_TIM1                  FALSE
#define STM32_GPT_USE_TIM2                  FALSE
#define STM32_GPT_USE_TIM3                  FALSE
#define STM32_GPT_USE_TIM4                  FALSE
#define STM32_GPT_USE_TIM5                  TRUE
#define STM32_GPT_USE_TIM6                  FALSE
#define STM32_GPT_USE_TIM7                  FALSE
#define STM32_GPT_USE_TIM8                  FALSE
#define STM32_GPT_USE_TIM9                  FALSE
#define STM32_GPT_USE_TIM11                 FALSE
#define STM32_GPT_USE_TIM12                 FALSE
#define STM32_GPT_USE_TIM14                 FALSE

т.е. эти вообще не используются кажется. я что-то потерял, где именно определяется chibios systick event handler параметры - кажется мы на базе systick живём?

В чиби 2 это кажется был COMMON_IRQ_PRIORITY

А вот что это в чиби 3 я как-то немного потерялся. Возможно у нас какой-то магический параметр по-умолчанию?

[andreika]

А вот что это в чиби 3 я как-то немного потерялся. Возможно у нас какой-то магический параметр по-умолчанию?

Думаю, что это STM32_ST_IRQ_PRIORITY 8.

[AndreyB]

Ага, ты прав - добавил комментарии в https://github.com/rusefi/rusefi/blob/m ... /mcuconf.h