Оптимальное распределение ресурсов МК в прошивке
Moderator: STC
-
- LQFP144 - On Top Of The Game
- Posts: 553
- Joined: Sun Nov 06, 2011 9:20 pm
- Location: Russia, Yekaterinburg
- Contact:
Re: Оптимальное распределение ресурсов МК в прошивке
А как данные попапуд во внешний прибамбас? что в can что в sdio писать один хрен то же самое в плане ресурсов.
CAN? я только за, в железе предусмотрим но сам заморачиватся с ним не буду т.к. ни на одном траспортном средстве из имеющихся в моем распоряжении нету кана.
Линшие для управления мотором? а ктото тут вроде бы хотел полноценное самообучение... а без ведения логов такое в принципе не возможно
CAN? я только за, в железе предусмотрим но сам заморачиватся с ним не буду т.к. ни на одном траспортном средстве из имеющихся в моем распоряжении нету кана.
Линшие для управления мотором? а ктото тут вроде бы хотел полноценное самообучение... а без ведения логов такое в принципе не возможно
Re: Оптимальное распределение ресурсов МК в прошивке
Разница есть. По ресурсам то да - почти идентично. Но при внешнем интерфейсе данные с ЭБУ может использовать не только даталоггер или комп. К примеру их может использовать приборная панель. Или сигнализация. Или еще что. Причем для ЭБУ это неважно. CAN позволяет слать данные в никуда. Причем есть кто на шине или нет легко определяется. Если же писать на карточку, то эти данные больше никто не увидит. И если понадобится например еще БК - надо будет делать и то и то. Кроме того карточку из недр ЭБУ сложно доставать. Банально неудобно. Слот под карту в 99% случаев имеет бронзовые контакты. Они не любят влагу и окисляются. Памятники зеленые видел? Через год уже не попишешь логи - надо перепаивать слот. Когда слот на плате плату уже не покрыть влагозащитой. Если у обычных разъемов защищают штырьки и вперед - то с картой все очень сложно. И есть еще куча причин не ставить карту в ЭБУ. И только одна ставить - на мотоцикле так удобнее карты писать. Ничего, обойдутся внешней приблудой размером со спичечный коробок. С картой внутри. Приклеют на скотч или в карман положат.
Полноценное самообучение не потребует логов. Достаточно еще одного набора таблиц. Примерно как сделать я представляю. Точно узнаю когда поедет хоть как то. Самообучение в планах есть, но не на первом месте. Сначала и ручным обойдусь. Нельзя же сразу строить наполеоновские планы. Нужно решать поэтапно задачи. Попытка сделать все и сразу обречена на провал.
Полноценное самообучение не потребует логов. Достаточно еще одного набора таблиц. Примерно как сделать я представляю. Точно узнаю когда поедет хоть как то. Самообучение в планах есть, но не на первом месте. Сначала и ручным обойдусь. Нельзя же сразу строить наполеоновские планы. Нужно решать поэтапно задачи. Попытка сделать все и сразу обречена на провал.
-
- LQFP144 - On Top Of The Game
- Posts: 553
- Joined: Sun Nov 06, 2011 9:20 pm
- Location: Russia, Yekaterinburg
- Contact:
Re: Оптимальное распределение ресурсов МК в прошивке
Полноценное самообучение ПОТРЕБУЕТ ведения лога за достаточно большой промежуток времени (как минимум несколько часов) иначе нихрена пктного не выйдет. Как максимум без самообучения получится нечто наподобии алгоритма заложенного j5ls_v46 - это не самообучение, это временная поправка текущей режимной точки если двигатель в стационарном режиме (хх или едем по трассе).
По поводу окисляющихся контактов это конечно ты верно заметил, но я не планирую делать карту сьемной, я ее просто на плату запаяю и сделаю програмный интерфейс через юсб аля mass-storage после покатушек втыкаем ноут и работаем с полученным логом как если бы этот лог набирался на самом ноуте. Заодно на этой карте можно будет вести лог ошибок или какую либо статистику/аналитику. С учетом того что sd карта стоит копейки и в stm32 весь интерфейс реализован не вижу смысла отказываться от такой "плюшки".
Лог для настройки калибровок будет собиратся в режиме closed-loop (с ШДК или в крайнем случае с ДК) без поправок вообще, просто и тупо. После подключения к ноутбуку анализироваться программой типа мольта с генерацией приблизительных калибровок и с последующей ручной правкой до адекватного состояния зашиватся в прошивку. В том же мольте функцию сбора лога и реализацию closed-loop осуществляет сам мольт на ноутбуке подключенном к ШДК и ЭБУ.
CAN - будет, SD - будет, USB - будет, высокоомный вход для ШДК/ДК - будет. Плата от этого не сильно потяжалеет.
По поводу окисляющихся контактов это конечно ты верно заметил, но я не планирую делать карту сьемной, я ее просто на плату запаяю и сделаю програмный интерфейс через юсб аля mass-storage после покатушек втыкаем ноут и работаем с полученным логом как если бы этот лог набирался на самом ноуте. Заодно на этой карте можно будет вести лог ошибок или какую либо статистику/аналитику. С учетом того что sd карта стоит копейки и в stm32 весь интерфейс реализован не вижу смысла отказываться от такой "плюшки".
Лог для настройки калибровок будет собиратся в режиме closed-loop (с ШДК или в крайнем случае с ДК) без поправок вообще, просто и тупо. После подключения к ноутбуку анализироваться программой типа мольта с генерацией приблизительных калибровок и с последующей ручной правкой до адекватного состояния зашиватся в прошивку. В том же мольте функцию сбора лога и реализацию closed-loop осуществляет сам мольт на ноутбуке подключенном к ШДК и ЭБУ.
CAN - будет, SD - будет, USB - будет, высокоомный вход для ШДК/ДК - будет. Плата от этого не сильно потяжалеет.
Re: Оптимальное распределение ресурсов МК в прошивке
Вообще то при наличии ШДК самообучение вполне возможно. Блок может сам вгонять смесь в рамки определенные таблицей желаемой AFR. Логи для этого не нужны. Мы знаем режимную точку, знаем что должно быть и видим что имеем. Вполне реально прямо в онлайне без логов совместить желаемое и действительное. А логи это для точной подстройки либо если ШДК не доступен.
МП3 плеер еще не забудь - плата от него тоже тяжелей не станет. А карта уже будет... Ну когда логи не нужны - сможет музыку играть. Я так понимаю вопросы влагозащиты не волнуют совсем?
МП3 плеер еще не забудь - плата от него тоже тяжелей не станет. А карта уже будет... Ну когда логи не нужны - сможет музыку играть. Я так понимаю вопросы влагозащиты не волнуют совсем?
-
- QFP80 - Contributor
- Posts: 71
- Joined: Sat Dec 03, 2011 1:28 pm
- Location: Russia, Velikiy Novgorod
- Contact:
Re: Оптимальное распределение ресурсов МК в прошивке
ну вообще сейчас есть тенденция внедрения встроенной памяти в коммерческие эбу. правда ставят туда не карточки судя по всему, а микросхему flash памяти. 8 мб в so8 обойдётся в 3-4 доллара. если писать 20 байт 100 раз в сек, то хватит на час с небольшим. а если рассматривать мк как интерфейс для передачи данных с sd на компьютер, то целесообразность применения именно карточки под вопросом.
Re: Оптимальное распределение ресурсов МК в прошивке
У карточки есть жирный плюс - не надо комп таскать в авто. Вынул ее и пошел домой логи смотреть, думать.
Для этого карточка должна выниматься, а не быть припаянной к плате.
Для этого карточка должна выниматься, а не быть припаянной к плате.
-
- QFP80 - Contributor
- Posts: 71
- Joined: Sat Dec 03, 2011 1:28 pm
- Location: Russia, Velikiy Novgorod
- Contact:
Re: Оптимальное распределение ресурсов МК в прошивке
прямо в эбу делать карточку пусть и съёмную лично мне не удобно. потому что доступ к эбу не очень то и удобен. я бы сделал бортовой компьютер и через CAN передавал бы данные. а бортовой компьютер можно использовать уже для сохранения на флешку и для отображения данных на дисплее. можно его и как контроллер использовать для каких-то процедур сервисных.
-
- QFP80 - Contributor
- Posts: 92
- Joined: Wed Sep 21, 2011 5:49 pm
- Location: Minsk Belarus
- Contact:
Re: Оптимальное распределение ресурсов МК в прошивке
Возможно я ошибаюсь, но либо CAN либо USB на stm32f103. (это если аппаратно)nikll wrote:CAN - будет, SD - будет, USB - будет, высокоомный вход для ШДК/ДК - будет. Плата от этого не сильно потяжалеет.
Но можно чередовать.
https://github.com/denami/secu3_blueloger -- Open Source logger
-
- LQFP144 - On Top Of The Game
- Posts: 553
- Joined: Sun Nov 06, 2011 9:20 pm
- Location: Russia, Yekaterinburg
- Contact:
Re: Оптимальное распределение ресурсов МК в прошивке
На первоначальном этапе на влазозащиту как и на помехозащиту похер, лиж бы работало, потом уже со специалистом плясать под корпус с учетом всех требований, эбу будет и на мотоцикле тоже поэтому без хорошей влагозащиты никак.Qwertty wrote:Вообще то при наличии ШДК самообучение вполне возможно. Блок может сам вгонять смесь в рамки определенные таблицей желаемой AFR. Логи для этого не нужны. Мы знаем режимную точку, знаем что должно быть и видим что имеем. Вполне реально прямо в онлайне без логов совместить желаемое и действительное. А логи это для точной подстройки либо если ШДК не доступен.
МП3 плеер еще не забудь - плата от него тоже тяжелей не станет. А карта уже будет... Ну когда логи не нужны - сможет музыку играть. Я так понимаю вопросы влагозащиты не волнуют совсем?
1. нам не жалко ресурска ШДК и мы ездим постоянно с ним
2. мы знаем текущую режимную точку
3. мы знаем мы желаемую смесь
4. мы можем определить отклонение фактической смеси от желательной
и что мы с этим отклонением будем дальше делать? мозг подключи и прикинь сколько взаимосвязей там есть:
1. темпиратура заряда:
1.1. темпиратура движка
1.2. темпиратура воздуха
1.3. поток воздуха
2. наполнение:
2.1. абсолютное давление в коллекторе
2.2. коэфициент наполнения из таблицы VE
2.3. положение дроссельной заслонки
3. обогащение/обеднение по дельте наполнения в нестационарных режимах
4. состав топлива (может бензин сильно водой разбодяжен вот и отклонение)
5. состав атмосферы (при существенном изменении влажности меняется и состав смеси)
и КАК ты хочеш "простенько и без логов" сделат самообучение с учетом всего выше перечисленного? Я достаточно хорошо себе все это представляю поэтому и сказал что без логов полноценного самообучения НЕВЫЙДЕТ! Как максимум поправка смеси в текущей режимной точке для текущих значений датчиков, в последствии изменится любой показатель и полученная по ШДК поправка станет снова неверна. В алгоритме самообучения требуется как минимум вести нормальный лог с последующим его анализом по режимным точкам для отделения котлет от мух, иначе говоря требуется вычислить и разделить карты коэфициента наполнения и коэфициента темпиратуры заряда, иначе никак.
в F103 can и usb можно использовать только по очереди, начиная с F2 вместе, вся линейка эфок совместима по ногам начиная с f1 и до f4 включительно. Кому нужен кан тот может забить на юсб и сделать все через кан, или взять камень следующего поколения.
SD карту можно сделать и сьемной, припаивать не обязательно , но вот выносить ее в дыру в блоке врятли стоит т.к. требования к герметичности, как вариант подобрать корпус который достаточно легко разбирается, или подобрать корпус с герметичной крышечкой через которую можно будет снимтаь карту, ну или уж как вариант просто сделать боковой пропил под карту и поверх этого пропила крышку с резинкой на двух винтах но это уже на любителя
-
- QFP80 - Contributor
- Posts: 71
- Joined: Sat Dec 03, 2011 1:28 pm
- Location: Russia, Velikiy Novgorod
- Contact:
Re: Оптимальное распределение ресурсов МК в прошивке
Нашёл описание обучения своего ЭБУ:
Адаптация вводится для компенсации изменения характеристик форсунок и дмрв. Принцип простой. Есть два вида поправок. Кратковременная и долговременная. Кратковременная вычисляется по показаниям узкополосного ДК. Долговременная вычисляется как среднее значение кратковременных поправок. Выбирая постоянную времени мы может менять время адаптации.Mixture Ratio Self-learning Control
The mixture ratio feedback control system monitors the mixture ratio signal transmitted from the heated oxygen
sensor 1 (front). This feedback signal is then sent to the ECM. The ECM controls the basic mixture ratio
as close to the theoretical mixture ratio as possible. However, the basic mixture ratio is not necessarily controlled
as originally designed. Both manufacturing differences (i.e., mass air flow sensor hot film) and characteristic
changes during operation (i.e., injector clogging) directly affect mixture ratio.
Accordingly, the difference between the basic and theoretical mixture ratios is monitored in this system. This
is then computed in terms of “injection pulse duration” to automatically compensate for the difference between
the two ratios.
“Fuel trim” refers to the feedback compensation value compared against the basic injection duration. Fuel trim
includes short term fuel trim and long term fuel trim.
“Short term fuel trim” is the short-term fuel compensation used to maintain the mixture ratio at its theoretical
value. The signal from the heated oxygen sensor 1 (front) indicates whether the mixture ratio is RICH or LEAN
compared to the theoretical value. The signal then triggers a reduction in fuel volume if the mixture ratio is
rich, and an increase in fuel volume if it is lean.
“Long term fuel trim” is overall fuel compensation carried out long-term to compensate for continual deviation
of the short term fuel trim from the central value. Such deviation will occur due to individual engine differences,
wear over time and changes in the usage environment.