rusefi.com

Maxi wrote:

nikll wrote:То что я видел из серии как дад подружить с фазовращалками, отстраивалось тупо многократными прогонами, за каждую итерацию сдвигали немного угол vvti и калибровали движок по новой. Прогоняли по всем углам от и до, набиралась статистика, дальше по ней смотрели в каких режимах какой угол оптимальней, соответсвенно строилась карта управления фазами и уже под нее откатывали еще раз. В общем подгон под результат и никаких физ моделей расчета изменения наполнения от фаз небыло.

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

где можно взять сей мануал?

XDA wrote:

Maxi wrote:

nikll wrote:То что я видел из серии как дад подружить с фазовращалками, отстраивалось тупо многократными прогонами, за каждую итерацию сдвигали немного угол vvti и калибровали движок по новой. Прогоняли по всем углам от и до, набиралась статистика, дальше по ней смотрели в каких режимах какой угол оптимальней, соответсвенно строилась карта управления фазами и уже под нее откатывали еще раз. В общем подгон под результат и никаких физ моделей расчета изменения наполнения от фаз небыло.

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

где можно взять сей мануал?

на nefmoto

Maxi wrote: на nefmoto

а более адресно можешь выдать? ссылку на документ или хотя бы тему.

XDA wrote:

Maxi wrote: на nefmoto

а более адресно можешь выдать? ссылку на документ или хотя бы тему.

мне самому искать надо.

Maxi wrote:на nefmoto

О! А какие еще есть тематические форумы, которые ждут немного спама об этом проекте?

Возвращаясь к теме топика. Поженить ежа с ужом не так сложно, если пытаться таки поженить.

Сейчас на форуме достаточно информации, чтобы даже неподготовленному поставить IDE, компилятор, выкачать из репозитория код и разобраться что к чему. Надюсь russian подкрепит ссылками, а если что и разъяснит лично. Очень здоровский шаг для поворота в конструктивное, а главное привязанное к реальности русло. Попробуйте, на это надо часа полтора отсилы. На переливание из пустого в порожнее потрачено в рамках даже этого небольшого форума куда больше времени . Давайте ближе к телу, будет больше толка.

Я научился резать и двигать темы и выделил вопрос RTOS в http://rusefi.com/forum/viewtopic.php?f=6&t=219

Выскажу своё мнение. Не нужно сейчас бросаться всем и писать какую-то одну реализацию. У нас нет опыта написания систем управления ДВС, чтобы сразу принимать верные решения. Мой опыт заканчивается на реверс инжиниринге заводского ЭБУ и переносе части алгоритмов на STM32, которых уже достаточно чтобы просто завести мотор. Поэтому для начала можно тестировать какие-то алгоритмы на своей реализации. Боевое тестирование нужно просто для того, чтобы не потерять интерес к разработке, потому что просто писать код и не видеть результат не интересно.

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

нужно сделать качественный фундамент -
в виде HAL, RTOS, шедулеров, таймров, ввод всех датчиков,
зажигание, впрыск, PWM на клапан наддува и т.д.

следом идёт общая архитектура - блок воздуха, блок топлива, блок зажигания, блок запроса момента, блок контроля и диагностики и т.д.

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

Получается есть условно говоря 10 направлений работы. Эти 10 направлений должны двигаться вперёд более менее равномерно, с одной стороны не отставая - с другой стороны не сильно убегая вперёд.

HAL. Кто попробует посмотреть на новый изолированный HAL из chibi 3? потому что аналогов того hal мы пока не знаем, а писать рукописный не очень ясно какой смысл.

По поводу rtos - мне кажется мы для текущего этапа имеем достаточно нормальный вариант.

А вот логики бензонасоса у нас нет никакой ну а турбо вещи кажется рано трогать вообще.

Вообще нужны какие-то требования к системе. Иначе как вообще можно что-то выбрать?

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

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

Sergey89 wrote:Вообще нужны какие-то требования к системе. Иначе как вообще можно что-то выбрать?

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

Ура ура! Пришли к тому, о чем шла речь на первых страницах. С требований надо начать.

XDA wrote:

Sergey89 wrote:Вообще нужны какие-то требования к системе. Иначе как вообще можно что-то выбрать?

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

Вообще-то требования есть в первом сообщении этой ветки.

Мы ходим кругами.

XDA wrote:если хочешь логику работы бензонасоса, то я могу тебе её предоставить на основании реальной машины

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

Коллега XDA, у меня начинает закратываться мысль, что Вы вражескмй диверсант.

Где мы и где can шина? ЗАЧЕМ ОНА НАМ СЕЙЧАС?

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

Жду патча логики бензонпсоса, готов ревьюить и коммитить.

Мне кажется, что нужно планировать на будущее. Мы можем посмотреть какой функционал есть у oem и aftermarket систем, чтобы представлять что можно реализовать. Мы не изобретаем ничего нового по сути, а просто повторяем уже то, что есть у остальных на открытой платформе.

Sergey89 wrote:Мне кажется, что нужно планировать на будущее. Мы можем посмотреть какой функционал есть у oem и aftermarket систем, чтобы представлять что можно реализовать. Мы не изобретаем ничего нового по сути, а просто повторяем уже то, что есть у остальных на открытой платформе.

Сергей, существует несколько методолгий планирования.

Waterfall проповедует детальное и полное планирование всего до конца до начало работы. Сейчас эта методолигия вышла из моды и замещается менее формалным и более инкрементальным планированием.

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

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

frig wrote:Нужна интересная задача

Ага, аналогично у линукса очень долго не было драйверов принтера. Кто будет писать драйвера принтера, когда можно писать журналируемую файловую систему.

80% этого и любого проекта рутина, если интересны только интересные задачи - проект не взлетит.

russian, я так понимаю есть задача привлечь к проекту людей, верно? Делать это рутинными задачами - глупо. Потом, после старта и знакомства это уже другое дело.

frig wrote:russian, я так понимаю есть задача привлечь к проекту людей, верно? Делать это рутинными задачами - глупо. Потом, после старта и знакомства это уже другое дело.

И да и нет. У меня не очень много идей о небанальных и при этом не огромных и изолированных задачах.

Датчик детонации - нарисовать плату?
по коду есть задача свести два логгинга к единоми виду.
Есть задача разобраться в ERIKA

Если бы был план - было бы проще обсуждать такие вопросы.

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

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

russian wrote:

Sergey89 wrote:Мне кажется, что нужно планировать на будущее. Мы можем посмотреть какой функционал есть у oem и aftermarket систем, чтобы представлять что можно реализовать. Мы не изобретаем ничего нового по сути, а просто повторяем уже то, что есть у остальных на открытой платформе.

Сергей, существует несколько методолгий планирования.

Waterfall проповедует детальное и полное планирование всего до конца до начало работы. Сейчас эта методолигия вышла из моды и замещается менее формалным и более инкрементальным планированием.

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

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

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

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

Я совсем тебя не понимаю

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

Сейчас скажу очень противоречиво: у меня правда есть опыт и квалификация судить о вопросах программирования, проектирования IT систем и управления IT проектами. Ну не знаю, как это доказать. Я учился в очень сильной математической спец-школе и программировал наивно графическую файловую оболочку на ассемблере в девятом классе школы. Первую визу в США я получил для поездки на финал мирового командного чемпионата по программированию с командой своего вуза, который этот мировой чемпионат выигрывал уже раза четыре. Свою работу в США я получил после того, как спас проект в роли кризисного управляющего подготовкой к выходу в продакшен. Сейчас по работе я программирую аналитику в финансовой системе - там распределённые два модуля дробят цифры, у одного четыре сервера по 24 процессора, у другого модуля вроде шесть серверов по 16 процессоров. Короче, я сейчас пытаюсь очень наивно кинуть понты чтоб озвучить одну мысль: с проектированием ПО я прошу поверить, что мой подход достаточно правильный. В этом вопросе я более чем разбираюсь.

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

Есть кстати такая интересная штука, называется AUTOSAR. Это стандартизированная программная архитектура для автомобильных систем управления.

Russian, твоя квалификация на разработке прикладного ПО не вызывает сомнений.
но тут два отличия. 1. это СИСТЕМНОЕ программирование и 2. это программирование микроконтроллеров.

XDA wrote:Russian, твоя квалификация на разработке прикладного ПО не вызывает сомнений.
но тут два отличия. 1. это СИСТЕМНОЕ программирование и 2. это программирование микроконтроллеров.

Во-первых, я не уверен, что тут системное программирование. Система у нас есть, пока ChibiOS, возможно будет другая. Так что ой.

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

Sergey89 wrote:Определить типы задач, приоритеты, источники событий, события, способы взаимодействия между модулями, стандарты кодирования, способы конфигурирования системы, способы взаимодействия с PC и т.д.

Все текущие задачи висят в трекере https://sourceforge.net/p/rusefi/tickets/
Стандарты кодирования - приличный отформатированный код. Взаимодействие с PC - любое, это деталь имплантации, может быть сколько угодно протоколов. Сейчас есть два протокола.

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

Чуть больше конкретики по моему текущему плану - вот http://rusefi.com/forum/viewtopic.php?f=6&t=221

Sergey89 wrote:Есть кстати такая интересная штука, называется AUTOSAR. Это стандартизированная программная архитектура для автомобильных систем управления.

Добавил ссылки, почитаю.