Самодельная ЭСУД, Может кто-то захочет поучаствовать Опции

[Андрей239]

Скоро будет год, как я начал делать себе самодельный блок управления двигателем с использованием stm32 discovery и chibios. У меня есть работающий прототип, сейчас я пытаюсь всё это приблизить к юзабельному состоянию. Если вдруг кто-то захочет поучаствовать - буду рад

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

Видео прототипа - http://www.youtube.com/watch?v=GcxLY697WwM
Исходники живут https://sourceforge.net/projects/rusefi/
Сайт проекта - http://rusefi.com/

[ZASADA]

а смысл делать свой блок когда на двигателе уже стоит штатный?

[x-men]

а смысл делать свой блок когда на двигателе уже стоит штатный?

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

[Андрей239]

а смысл делать свой блок когда на двигателе уже стоит штатный?

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

[Punk]

Скоро будет год, как я начал делать себе самодельный блок

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

[Андрей239]

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

о! А родственная - это какая?
моя почта - arro239 на gmail

[Denisvak]

Так же есть интерес к разработке ECU
"Адрес arro239 собака gmail не существует или заблокирован."

Сообщение отредактировал Denisvak - Sep 25 2013, 08:14

[Lmx2315]

..тут никто к угонам авто отношения не имеет?

[ZASADA]

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

[Андрей239]

Так же есть интерес к разработке ECU
"Адрес arro239 собака gmail не существует или заблокирован."

gmail.com, чисто для уточнения?

я точно уверен, что именно arro239@ и так далее gmail.com

Ну можно написать мне приватное сообщение и в него почту Или скайп мой arro239 тоже

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

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

[Lmx2315]

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

..не специалист в этой области, но такое слышал. Замена заблокированного - на своё и можно ехать.

[Андрей239]

Так же есть интерес к разработке ECU
"Адрес arro239 собака gmail не существует или заблокирован."

пока ничего не получил - интерес еще есть?

[Denisvak]

да, уже все хорошо

[Андрей239]

https://www.youtube.com/watch?v=8qPSSUL4jlo

[Андрей239]

Мы с группой товарищие продолжаем во всё это играться - https://www.youtube.com/watch?v=M-qqHQ-quFg

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

Например http://svn.code.sf.net/p/rusefi/code/trunk...r_schematic.pdf

[Vasily_]

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

[Андрей239]

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

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

Посмотрел то что у вас выложено, если честно, просто ужас, так автомобильную электронику не строят.

Опять же - давайте чуть-чуть конструктивнее? Я буду очень благодарен за чуть-чуть более конкретные замечания. Ну и если Вы можете помочь вообще будет супер!

И в каком месте русефи? все на английском, русского ничего не увидел.

Возможно смотрели не очень внимательно?
http://www.rusefi.com/forum/viewforum.php?f=7

Сообщение отредактировал Андрей239 - Jan 6 2014, 00:07

[Vasily_]

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



Опять же - давайте чуть-чуть конструктивнее? Я буду очень благодарен за чуть-чуть более конкретные замечания. Ну и если Вы можете помочь вообще будет супер!



Возможно смотрели не очень внимательно?
http://www.rusefi.com/forum/viewforum.php?f=7

1. Можно и подробней, возьмите например Микас М11.3, там есть все что вам нужно, есть версия ЕТ для электронного дросселя.
2. Вы выбрали изначально тупиковый путь, контроллер 3х вольтовый, зачем-то изобретаете драйвера форсунок когда можно взять готовые с диагностикой, например TLE6220 TLE6240.
3. Да не досмотрел.

[Андрей239]

1. Можно и подробней, возьмите например Микас М11.3, там есть все что вам нужно, есть версия ЕТ для электронного дросселя.
2. Вы выбрали изначально тупиковый путь, контроллер 3х вольтовый, зачем-то изобретаете драйвера форсунок когда можно взять готовые с диагностикой, например TLE6220 TLE6240.

Попробую еще раз:

Микас - это прекрасный штатный блок, кажется привязанный к 4ём цилиндрам? А мы хотил сделать единую программную базу и под 1 цилинд, и под 12. А еще кроме СНГ есть большой мир, русскоязычнвми странами дело не заканчивается

У нас всё модульно - TLE6240 у меня уже куплены, нужно просто под них нарисовать версию испольнительного модуля. ТАк что если Вы бы были готовы помочь

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

[Vasily_]

Попробую еще раз:

Микас - это прекрасный штатный блок, кажется привязанный к 4ём цилиндрам? А мы хотил сделать единую программную базу и под 1 цилинд, и под 12. А еще кроме СНГ есть большой мир, русскоязычнвми странами дело не заканчивается

У нас всё модульно - TLE6240 у меня уже куплены, нужно просто под них нарисовать версию испольнительного модуля. ТАк что если Вы бы были готовы помочь

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

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

[Андрей239]

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

Очень может быть, что я себе неправильно представляю Микас. Так что можно я задам несколько вопросов?

Я думал, что это готовая плата в готовой коробочке? Как я смогу заинтегрировать её например с SD картой? Как я смогу подключить UART или SPI GPS модуль?

Есть ли там бесплатный С компилятор?

Есть ли какие-то бесплатные rtos под эту платформу, или как происходит управление планированием задач?

Правильное железо - Вы имеете ввиду силовые элементы, или процессор тоже обязан быть 5ти вольтовым? Моё личное требование к процессору - крайне желателен FPU, и сильно желателен rtos, В идеале - ChibiOS

Самой простой помощью было бы нарисовать модуль TL6240 под KiCad

Или тоже было бы круто начать новую ветку в http://rusefi.com/forum/viewforum.php?f=10 и рассказать чуть подробнее про Микас и защитишь его как самый правильный выбор платформы. Обсудить этот вопросы было бы очень полезно

[AlexandrY]

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

Микас это не стартеркит. На упомянутый Микас М11.3 даже схему найти трудно. О исходниках программы даже речи не идет.
А судя по МИКАС 7.2 их делают до сих пор на 51-ом ядре с 3 КБ RAM!
Ардуино даже круче этого МИКАС-а смотрится по аппаратным возможностям.

Хотя да, под I51 компиляторов море, и бесплатных тоже. Этой архитектуре лет 30 исполняется если не больше, радиолампы не намного старее

[Vasily_]

Микас это не стартеркит. На упомянутый Микас М11.3 даже схему найти трудно. О исходниках программы даже речи не идет.
А судя по МИКАС 7.2 их делают до сих пор на 51-ом ядре с 3 КБ RAM!
Ардуино даже круче этого МИКАС-а смотрится по аппаратным возможностям.

Хотя да, под I51 компиляторов море, и бесплатных тоже. Этой архитектуре лет 30 исполняется если не больше.

В М11 стоит ST10F273.
Схему точно не найти, но нарисовать можно, об исходниках речи и не ведется если народ способен писать свои исходники.
Микас 7.2, да на 51-ом, но сколько ему лет? А в микас 7.2+ ST10F273.
Во! давайте строить автомобили на ардуино.

Я думал, что это готовая плата в готовой коробочке? Как я смогу заинтегрировать её например с SD картой? Как я смогу подключить UART или SPI GPS модуль?

Есть ли там бесплатный С компилятор?

Есть ли какие-то бесплатные rtos под эту платформу, или как происходит управление планированием задач?

Правильное железо - Вы имеете ввиду силовые элементы, или процессор тоже обязан быть 5ти вольтовым? Моё личное требование к процессору - крайне желателен FPU, и сильно желателен rtos, В идеале - ChibiOS

Самой простой помощью было бы нарисовать модуль TL6240 под KiCad

Или тоже было бы круто начать новую ветку в http://rusefi.com/forum/viewforum.php?f=10 и рассказать чуть подробнее про Микас и защитишь его как самый правильный выбор платформы. Обсудить этот вопросы было бы очень полезно

Конечно это готовое изделие. Если нужна SD карточка, кто мешает её повесить на SPI внутри блока? я так вставляю туда даталоггер. Уарт там не нужен, есть две К линии, уарт в одно проводном исполнении, и CAN там есть. Зачем вешать GPS на spi, повесьте его на К линию.
Компилятор думаю что есть, камень ST10F273.
Да, процессор должен быть 5ти вольтовый и автомотиве.
К сожалению я работаю в PCAD.
У вас на форуме замечен один крутой специалист макси, вот он вам все расскажет.

[Андрей239]

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

Пока мы программируем, как раз и подойдут более быстрые пятивольтовые и аутомоутив. А отлаживаться проще в ситуации избытка ресурсов опять же.

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

[AlexandrY]

В М11 стоит ST10F273.
Схему точно не найти, но нарисовать можно,

Конечно это готовое изделие. Если нужна SD карточка, кто мешает её повесить на SPI внутри блока? я так вставляю туда даталоггер. Уарт там не нужен, есть две К линии, уарт в одно проводном исполнении, и CAN там есть. Зачем вешать GPS на spi, повесьте его на К линию.

ST10, кстати, тоже нафталином попахивает.
И на это еще искать схему?
После чего по SPI к real-time системе подключать SD карту?
Вы все это серьезно?

С точки зрения стороннего разработчика МИКАС не более готов чем груда металлолома.

А отлаживаться проще в ситуации избытка ресурсов опять же.

Всё-таки для открытого проекта больше подходит открытый и живой софт.

Лучше было бы DDRAM ставить если действительно есть серьезное намерение логить быстрые сигналы в достаточном объеме. У Freescale есть Cortex-M4 миконтроллеры с поддержкой DDRAM.


А IAR как-то не тянет для открытого проекта.
Надо было бы уж тогда на GCC c эклипсой если по честному.

Но проект мне ваш нравится. Серьезный подход. Такие редкость.

[Vasily_]

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

http://ko.com.ua/kachestvo_vstraivaemogo_p...luchilsya_98518

[Андрей239]

Лучше было бы DDRAM ставить если действительно есть серьезное намерение логить быстрые сигналы в достаточном объеме. У Freescale есть Cortex-M4 миконтроллеры с поддержкой DDRAM.


А IAR как-то не тянет для открытого проекта.
Надо было бы уж тогда на GCC c эклипсой если по честному.

Но проект мне ваш нравится. Серьезный подход. Такие редкость.

IAR у нас в качестве запасного компилятора - основной компилятор как раз GCC внутри эклипса. http://rusefi.com/forum/viewtopic.php?f=5&t=9

У ST есть stm32f439 - там поддержка SDRAM, но нам пока хватает stm32f407 - у него намного более распространённая дешёвая отладочная плата.

Ну а про серьёзность - посмотрим Пока всё это заводило только один двигатель. Еще три двигателя на разной стадии - но всё не быстро. Если через год будет штук пять машин или мотоциклов - то можно будет считать что пока взлетает.

А так - тикеты http://sourceforge.net/p/rusefi/tickets/ а задачи по железу - например вот тут http://rusefi.com/forum/viewtopic.php?f=8&t=254

[Vasily_]

ST10, кстати, тоже нафталином попахивает.
И на это еще искать схему?
После чего по SPI к real-time системе подключать SD карту?
Вы все это серьезно?

С точки зрения стороннего разработчика МИКАС не более готов чем груда металлолома.

ST10 чем вам не угодил?
Пол мира катается на ST10 и производители не знают что процессоры в их блоках попахивают нафталином.
Согласен что он уже устарел, его хватает под эту задачу лет на 10 вперед.
Я разве вам предложил искать схему?
Когда мне понадобилась схема я её нарисовал, а не искал, да и нет её в открытом доступе.
Серьезно.
Вы в курсе что висит на SPI в автомобильных блоках управления?

[Андрей239]

и производители не знают что процессоры в их блоках попахивают нафталином.
Согласен что он уже устарел, его хватает под эту задачу лет на 10 вперед.

Вы читали отчёт эксперта ( Barr's report on toyota ecu) во время слушаний по делу против Тоёты? Там в исходниках 11 000 глобальных переменных.

http://www.edn.com/design/automotive/44234...ts-consequences

То, что оно "здесь так принято" совсем не означает, что это не ужас-ужас. Но зачем мы спорим собсвенно? Пусть растёт миллион садов и милллион разных подходов

[Vasily_]

Вы читали отчёт эксперта ( Barr's report on toyota ecu) во время слушаний по делу против Тоёты? Там в исходниках 11 000 глобальных переменных.

Вы мою ссылку выше видели?

[AlexandrY]

ST10 чем вам не угодил?
Пол мира катается на ST10 и производители не знают что процессоры в их блоках попахивают нафталином.
Согласен что он уже устарел, его хватает под эту задачу лет на 10 вперед.
Я разве вам предложил искать схему?
Когда мне понадобилась схема я её нарисовал, а не искал, да и нет её в открытом доступе.
Серьезно.
Вы в курсе что висит на SPI в автомобильных блоках управления?

Какую задачу?
В теме речь идет об исследовательской задаче.
А то на чем ездит полмира решает совсем другую задачу - потребительскую.

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


Да , а что же висит на SPI в автомобильных блоках управления?

[Juray]

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

Например, ключи типа TLE6208.
(В блоках WABCO вроде как даже еще 5208 встречается)

Внешний CAN-контроллер типа MCP2510

[a123-flex]

Какую задачу?
В теме речь идет об исследовательской задаче.
А то на чем ездит полмира решает совсем другую задачу - потребительскую.

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


Да , а что же висит на SPI в автомобильных блоках управления?

м. почему ето исследовательской. Просто Андрей делает свое Ecu. Универсальное и с красивым кодом. Но гоняет он на нем на настоящей машине, а не на виртуальной, и было бы круто угнать на таком феррари. Чуть попозже, когда будет в блочном исполнении, а не россыпью) Андрей совершенно прав, время изменилось и теперь многие вещи надо делать по-другому, а не так как раньше. Главное не использовать в микроконтроллере stl11, как некоторые торопливые любители gcc.) Я обещал написать чего-нибудь, но меня попросили немного поработать и в праздники тоже( Насчет SPI тоже интересно.
TLE6208 - ето красиво. не думал что такое уже есть.

[AlexandrY]

Вы мою ссылку выше видели?

А сами то читали ее?
Самое интересное там это ссылка на отчет от Exponent, Inc.
Я его скачал и ложу здесь отдельно ибо это из разряда must-have для каждого инженера.
[attachment=82050:ETCSi_Re...pt242012.pdf]

Бросается в глаза опровержение мифов про 5 Вольт.
В ECU давно уже можно видель любой вольтаж микросхем от 5 В до 1.5 В

Второе, это мультипроцессорность. Производители уже не мыслят ECU меньше чем на двух микроконтроллерах, а лучше на трех. И не из-за сложности софта. Упорно ADC почему-то не делают на главном микроконтроллере.

Потому-то задача TC и является исследовательской. Сделать ECU на мощном но одном микроконтроллере это неизведанное направление.

[a123-flex]

ложу здесь ибо это must-have
Потому-то задача TC и является исследовательской. Сделать ECU на мощном но одном микроконтроллере это неизведанное направление.

Что все привязались к этой Toyota ? Ну попал деятельный идиот и бездарь на роль ведущего по модулю, закрепился и сгенерил кусок дерьма.... а потом уж никто его и выбить не смог. Видимо не только в российских компаниях системы управления деградируют. Вы, уважаемый AlexandrY, как вольный художник то ли не знаете, то ли забыли запах болота. Всякая крупная контора его имеет в себе хоть где-то.
Уверен, несмотря на отчет софт у Андрея будет на БИС.. А если толковый инженер поставит на аналоговом входе хороший полигон земли, 1206 резисторы делителя, 1206 керамический кондерчик, BAV99 и еще разрядник Epcos на случай самостоятельного управления ключами ecu катушками зажигания, то ничего не будет головному контроллеру и от использования его АЦП напрямую. По мне все ети исследования повод бабло пооткатывать да на телок в бикини в буфете попялиться за счет конторы....НА КОНФЕРЕНЦИИ Только что пришла в голову мысль.
Сертификаты очевидно призваны ухудшать технический уровень проектов, тк существенная часть денег проекта перераспределяется из кармана разработчиков в карман людей в галстуках, которые дефелируют на конференциях. Что приводит к оттоку качетсвенных специалистов на вольные хлеба или в места менее насышенные сертификатами. во
Такое кстати часто бывает... на хабре где-то баян был недавно как в самолете в СЕРТИФИЦИРОВАННОЙ по европейскому стандарту системе уаправления двигателем отключили функцию усреднения окном выборок скорости вращения шасси, и от этого двигатель в полете отключился, а шасси выпускаться отказалось, и пришлось садиться чуть ли не без того и другого. А изза секретности смотреть в телеметрию нельзя было. И спас ситуацию, естественно, как всегда ловкий айфон в роли видеокамеры. Андрей правильно выбрал нишу. Проект по мне очень интересный. и денежный....

И, вот спасибо AlexandrY, подогнал дополнительную мысль на халяву, возникает вопрос: а что, использование дополнительных процессоров улучшает ситуацию с надежностью блока при отгорании не головного проца, а лишь того, что занят вводом информации с аналоговых датчиков ? То есть как бы мы потеряли всю аналоговую инфу, но головной процессор от етого нам все равно очень нужен ? Типа двигатель после отгорания головного проца не заглохнет сам собой ? Или головной проц нам нужен после серьезного отказа для корректного и безопасного power-down всех систем автомобиля ? Так ecu - ето ж блок управления двигателем вроде, а не мозги всей машины, и при потере аналоговой инфы движок в любом случае заглохнет....короче как я ето понимаю, достаточно внешнего аппаратного watchdoga который при отмерании головного проца просто даст сигнал в коробку-автомат и мозги на предмет предоставления abs && bas && esp && ebd && ivd "двигло is off", а все ети многоядерные конфигурации от лукавого.

[Андрей239]

Итак, например такой простой практический вопрос: хочетсся перевести 5ти вольтовые сенсоры на 3.3 вольта. Кто видит какие проблемы?

Термисторы - просто термисторы. Датчик положения заслонки - просто потенциоментр, этим обоим всё равно от какого напряжения работать.

Сообщение отредактировал Андрей239 - Jan 7 2014, 13:32

[a123-flex]

Итак, например такой простой практический вопрос: хочетсся перевести 5ти вольтовые сенсоры на 3.3 вольта. Кто видит какие проблемы?

Термисторы - просто термисторы. Датчик положения заслонки - просто потенциоментр, этим обоим всё равно от какого напряжения работать.

вопрос непонятен. Есть датчики 5 В и контроллер на 3,3 - треба обеспечить интерфейс ?
пижонский способ SN74VMEH22501DGGR но дорого, блин
по дешевому - резисторы и диоды.
или они аналоговые... а что, в таком случае просто делитель нельзя использовать ?

[Андрей239]

Нет, вопрос совсем другой. Вопрос: можно ли избавиться от 5ти вольт полностью и перейти на 3.3 вольта

Термисторы - это просто резисторный делитель, ему всё равно какое напряжение делить. Делил 5 - будет делить 3.3

Датчик положения дроссел - просто потенциометр, аналогичное - ему всё равно, что делить.

Датчик холла - там либо заземление либо висящий провод, ему вроде всё равно 5 или 3.3

Вот и вопрос - какие есть контр-аргументы против полного перевода с 5ти на 3.3?

[a123-flex]

Нет, вопрос совсем другой. Вопрос: можно ли избавиться от 5ти вольт полностью и перейти на 3.3 вольта

термистор и дроссель - нет проблем, насчет холла я бы смотрел конкретный datasheet.
уменьшение в 1.5 раза полной шкалы увеличивает в 1.5 раза влияние шумов, которые остаются неизменными.
учитывая что на дросселе должен быть кальман, то увеличение пульсаций на него влиять не должно. Термистор насколько я понимаю используется как бинарный (температура больше/меньше порога) прибор, а не как термометр. Ему тоже все равно.

[Андрей239]

Термистор насколько я понимаю используется как бинарный (температура больше/меньше порога) прибор, а не как термометр. Ему тоже все равно.

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

[a123-flex]

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

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

[dlman]

несколько процессоров в КСУД используются исключительно в целях безопасности - в случае программных/аппаратных сбоев в основном процессоре процессор безопасности глушит двигатель (а программные сбои весьма вероятны ввиду сложности программного обеспечения).
Все компоненты должны иметь automotive сертификацию с температурным диапазоном -40...+125.
Процессор лучше изначально выбирать из тех которые предназначены для применения в ECU - Infineon XC167, XE2000, Freescale MPC56xx Monaco.
В качестве основы для "чистого и понятного" кода смотрите AUTOSAR.
И никаких лишних наворотов типа SD карточки, GPS и .др. Для всего этого есть CAN. Про динамическую память тоже забудьте, исключительно SRAM (если нужна, конечно).

[a123-flex]

несколько процессоров в КСУД используются исключительно в целях безопасности - в случае программных/аппаратных сбоев в основном процессоре процессор безопасности глушит двигатель (а программные сбои весьма вероятны ввиду сложности программного обеспечения).
Все компоненты должны иметь automotive сертификацию с температурным диапазоном -40...+125.
Процессор лучше изначально выбирать из тех которые предназначены для применения в ECU - Infineon XC167, XE2000, Freescale MPC56xx Monaco.
В качестве основы для "чистого и понятного" кода смотрите AUTOSAR.
И никаких лишних наворотов типа SD карточки, GPS и .др. Для всего этого есть CAN. Про динамическую память тоже забудьте, исключительно SRAM (если нужна, конечно).

я уже сказал что нужно. аппаратный watchdog за 1$ и для особопугливых управление всеми выходами через элементы и/или (еще 1$), по срабатыванию watchdog-а генерирующие на выходе ecu состояние выходов, соответствующее заглушенному двигателю. Процессор конечно же нужен 1 мощный ARM. Действительно полезно было бы найти automotive ARM. Freescale MPC- выбор лузера для лузера. Насчет динамических памятей мысль особо мощная - но в свете последних событий, немного, устаревшая... В довольно серьезном real-time проекте недавно видел на ARM контроллере управляющий код под STL11 - вот ето действительно перебор, по моему. Однако продажам товарищей ето вроде, не мешает.

[dlman]

я уже сказал что нужно. аппаратный watchdog за 1$ и для особопугливых управление всеми выходами через элементы и/или (еще 1$), по срабатыванию watchdog-а генерирующие на выходе ecu состояние выходов, соответствующее заглушенному двигателю. Процессор конечно же нужен 1 мощный ARM. Действительно полезно было бы найти automotive ARM. Freescale MPC- выбор лузера для лузера. Насчет динамических памятей мысль особо мощная - но в свете последних событий, немного, устаревшая... В довольно серьезном real-time проекте недавно видел на ARM контроллере управляющий код под STL11 - вот ето действительно перебор, по моему. Однако продажам товарищей ето вроде, не мешает.

от алгоритмических ошибок hw watchdog вас не спасет. Процессор безопасности как раз и нужен для того, чтобы не случилось как в тойоте - педаль газа отпущена а форсунка все равно открыта.
Вот про Freescale MPC можно поподробнее? В данном случае как раз Cortex-M будет не совсем удачным решением для ECU.

[AlexandrY]

от алгоритмических ошибок hw watchdog вас не спасет. Процессор безопасности как раз и нужен для того, чтобы не случилось как в тойоте - педаль газа отпущена а форсунка все равно открыта.
Вот про Freescale MPC можно поподробнее? В данном случае как раз Cortex-M будет не совсем удачным решением для ECU.

Нормально все будет с Cortex-M. Если надо потом быстро перейдут на TMS570 c lockstep и всеми мыслимыми ECC.
Проблемы аппаратной надежности не вызывают беспокойства.

Но я вот прокомпилировал сам проект. Так немного разочарован.
54 серьезных варнинга! Это еще не изучая архитектуру софта в целом.

Сам проект не был готов к компиляции. Надо было выискивать неподключенне файлы.

[a123-flex]

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

от алгоритмических ошибок спасает отладка, и прямой хорошо структурированный простой как только возможно код. Или как Вы собрались обезопасить себя от алгоритмической ошибки посредством второго процессора ? Написать весь алгоритм управления полностью другой командой ? а если оба ошибутся ? тогда 3 команды независимых программистов и троированная система ? А какова будет вероятность получить целую кучу сбоев и багов в такой системе ? спасет сертификация ? тогда все получится как раз как в тоете...

Вот про Freescale MPC можно поподробнее?

в жизни я имел дело с моторолой дважды. С 8-разрядным контроллером и с многоголовым коммуникационным 32-разрядным монстром. Юзабилити ниже плинтуса. Вы когда-нибудь видели что такое WindRiver ? Когда 10 лет назад после него я поставил IAR и запустил еще атмельский ARM - чуть не умер от счастья. Повторю не свое мнение, но с которым я полностью согласен - моторола лузер рынка, все направления которые моторола поднимала когда-либо - замечу, госбаблом, она все их похоронила...
Поетому я говорю продукт лузер для лузеров...
и насчет динамических памятей. видел немало больших ответственных систем (кластеры обычно) почему-то там динамикой не брезгуют.

[ZASADA]

ставьте сразу TI с встроенным аппаратным дублированием.

а про моторолу вы зря. с WindRiver не работал, но коммуникационный 32-разрядным монстр под CodeWarrior-ом использавать было приятно. и встроенный аппаратный эмулятор был.

[dlman]

от алгоритмических ошибок спасает отладка, и прямой хорошо структурированный простой как только возможно код. Или как Вы собрались обезопасить себя от алгоритмической ошибки посредством второго процессора ? Написать весь алгоритм управления полностью другой командой ? а если оба ошибутся ? тогда 3 команды независимых программистов и троированная система ? А какова будет вероятность получить целую кучу сбоев и багов в такой системе ? спасет сертификация ? тогда все получится как раз как в тоете...


в жизни я имел дело с моторолой дважды. С 8-разрядным контроллером и с многоголовым коммуникационным 32-разрядным монстром. Юзабилити ниже плинтуса. Вы когда-нибудь видели что такое WindRiver ? Когда 10 лет назад после него я поставил IAR и запустил еще атмельский ARM - чуть не умер от счастья. Повторю не свое мнение, но с которым я полностью согласен - моторола лузер рынка, все направления которые моторола поднимала когда-либо - замечу, госбаблом, она все их похоронила...
Поетому я говорю продукт лузер для лузеров...
и насчет динамических памятей. видел немало больших ответственных систем (кластеры обычно) почему-то там динамикой не брезгуют.

а вы представляете, насколько сложные алгоритмы заложены в контроллерах управления двигателем, чтобы пройти по нормам ЕВРО3, ЕВРО4, ЕВРО5? настолько сложные, что с чистым кодом работать практически невозможно. В МИКАСах и Январях при разработке используются DSPACE и MATLAB для графической разработки алгоритмов, которые затем генерируют С код. В Тойоте, по всей видимости, использовался такой же подход, откуда и взялись эти 16 тыс глобальных переменных. Никакая отладка не даст гарантии 100% что у вас нет косяка в коде, который будет проявляться при определенных условиях с вероятностью 0.001. А любой косяк в ECU - это уже потенциальная угроза жизни. Процессор безопасности, при всей своей примитивности реализации, перепроверяет основной процессор на предмет корректности алгоритмов управления. как говорится - 100 раз отмерь и 1 раз отрежь.

Ну как-бы мотороллы уже давно нет. А у фрискейла PowerPC успешно развивается, как automotive, так и QorIQ. Да, CodeWarrior IDE пару лет назад был так себе, но по сравнению с IAR - приблизительно одно и то же. Что касается automotive компонентов - в этом фрискейл, безусловно, лидер, в отличие от инфинеона. К линейке iMX вообще никаких претензий - BSP, документация, поддержка - такого TI с их OMAPами и не снилось.

А что вы под "ответственными системами" понимаете? В данном случае контроллер управления двигателем отвечает прежде всего за жизнь человека, отсюда и все пляски вокруг него. Не дай бог заложить в нем не automotive компонент - и при любой проблеме будет виновато предприятие-изготовитель. А с динамической памятью, как и с импульсными преобразователями, будут проблемы на ЭМС.

[Андрей239]

Нормально все будет с Cortex-M. Если надо потом быстро перейдут на TMS570 c lockstep и всеми мыслимыми ECC.
Проблемы аппаратной надежности не вызывают беспокойства.

Но я вот прокомпилировал сам проект. Так немного разочарован.
54 серьезных варнинга! Это еще не изучая архитектуру софта в целом.

Сам проект не был готов к компиляции. Надо было выискивать неподключенне файлы.

У нас там три способа компиляции - gcc/Makefile, gcc/eclipse и iar для пиратов Есть косяк - бывает, что iar оттстаёт, сейчас пойду починю. Конечно же комплироваться должны все три версии, раз мы их анонсируем.

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

[a123-flex]

а вы представляете, насколько сложные алгоритмы заложены в контроллерах управления двигателем, чтобы пройти по нормам ЕВРО3, ЕВРО4, ЕВРО5? настолько сложные, что с чистым кодом работать практически невозможно. В МИКАСах и Январях при разработке используются DSPACE и MATLAB для графической разработки алгоритмов, которые затем генерируют С код. В Тойоте, по всей видимости, использовался такой же подход, откуда и взялись эти 16 тыс глобальных переменных. Никакая отладка не даст гарантии 100% что у вас нет косяка в коде, который будет проявляться при определенных условиях с вероятностью 0.001. А любой косяк в ECU - это уже потенциальная угроза жизни. Процессор безопасности, при всей своей примитивности реализации, перепроверяет основной процессор на предмет корректности алгоритмов управления. как говорится - 100 раз отмерь и 1 раз отрежь.

сложные алгоритмы - ето таблицы что ле ?
с чистым кодом невозможно... ето что то новенькое. А с чем возможно ? вы ебу баснями функции объясняете по картинкам в матлабе ?
слышал отзывы о кодогенерации с матлаба работников софтлайна. Они далеки от дифирамбов, а код получается однозначно неоптимальный. Правда отзывы были ПОСЛЕ конференции.

вроде американцы говорили, что у них управления беспилотником 3 млн строк кода. Наверно у них беспилотник не такой сложный как у Вас ебу, что они таки код пишут, кретины ?

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

под "ответственными системами" я понимаю системы, от корректной работоспособности которых зависит жизнь многих людей

[Андрей239]

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

Только вот сейчас особо нечего переносить, так что лучше бы сначала сделать хоть что-то А переделывать уже потом. Вот AlexandrY святой человек хотя бы код скачал - может быть сейчас с warning ситуацию улучшим. Конкретная помощь намного лучше абстрактной фразы, что мы заранее обречены на неудачу. Это не совсем так

[dlman]

сложные алгоритмы - ето таблицы что ле ?
с чистым кодом невозможно... ето что то новенькое. А с чем возможно ? вы ебу баснями функции объясняете по картинкам в матлабе ?
слышал отзывы о кодогенерации с матлаба работников софтлайна. Они далеки от дифирамбов, а код получается однозначно неоптимальный. Правда отзывы были ПОСЛЕ конференции.

вроде американцы говорили, что у них управления беспилотником 3 млн строк кода. Наверно у них беспилотник не такой сложный как у Вас ебу, что они таки код пишут, кретины ?



под "ответственными системами" я понимаю системы, от корректной работоспособности которых зависит жизнь многих людей

сложные алгоритмы это сложные алгоритмы. я не буду рассказывать ни про цикломатическую сложность ПО, ни про метрику, ни про время вывода продукта на рынок и затраты на разработку ПО в человеко-часах. Это всем понятно. Да, кодогенерация крайне неоптимальна, но тем не менее такие проекты как DSPACE и ETAS широко используются при разработке ECU во всем мире.
Я как-то работал над проектом который достался от NVIDIA. Что касается coding standards там все было по-правильному, но что касается архитектуры - так годы, за которые этот проект развивался, превратили ее в спагетти. В какой-то момент NVIDIA закрыла проект, так и не решив многих проблем, и которые пришлось решать мне. Проблемы весьма тривиальные, но вот на их решение, ввиду сложности кода, приходилось тратить недели.
3 млн строк вообще не показатель сложности проекта. Если проект разбивается на отдельные функционально независимые модули, каждый из которых может отлаживаться отдельно, то количество строк это прежде всего показатель трудоемкости проекта.

P.S Господа, я делюсь реальным опытом, как оно все обстоит на самом деле. Люди, которые разрабатывают автоэлектронику, далеко не пальцем подкованные, так что не будем выставлять их кретинами, включая тех, кто разрабатывал ECU для тойоты.

[Андрей239]

Я думаю достаточно про тоёту. История там тёмная, мы всю историю всё равно не угадаем - а в реалиях японской компании они нам не расскажут.

У меня работа в проекте на 2 миллиона строк кода - так что я в курсе, что такое спаггеди и что такое старый код. Тому проекту 8 или 9 лет - и по коду это конечно же видно. Итак, давайте ближе к телу rusEfi

Итак, я закоммитил починенный IAR проект. Основной сборщик у нас gcc/Makefile, кстати у нас есть continues integration - http://jenkins.rusefi.com/ - и даже немного юнит тестов, так что стараемся можно.

несколько warning я убрал, самые плохие с моей точки зрения были про enum/int.

Осталось очень много
implicit conversion from floating point to integer
я к нему противоречиво отношусь, может быть его просто глобально выключить?
Ну и классический
statement is unreachable
в конце методов-потоков while(true), тоже не уверен как лучше с этим поступить. Как лучше?


Update:
посмотрел на примеры "mplicit conversion from floating point to integer", нашёл две баги. Так что это предупреждение конечно же полезное - пойду сейчас везде починю.

[ZASADA]

implicit conversion from floating point to integer

для начала можно определится надо ли вообще данную переменную держать в float
и никто не мешает в коде в явном виде преобразовывать float в int

[Андрей239]

Спасибо, я в курсе явного преобразования - вопрос был как правильнее поступить - забить, фиксить или еще скрывать. В итоге понял, что забивать или скрывать нельзя и и правда нужно фиксить

Сделал лучше:


Осталось в основном unreachable statement после while(1)
Есть вариант делать while(!chThreadTerminated()), но это лишние байтики ради ворнинга. Есть ли варианты лучше?

Сообщение отредактировал Андрей239 - Jan 8 2014, 22:01

[a123-flex]

Люди, которые разрабатывают автоэлектронику, далеко не пальцем подкованные, так что не будем выставлять их кретинами, включая тех, кто разрабатывал ECU для тойоты.

Хорошо, если Вам не нравится слово идиоты, то я назову ето по другому. Люди которые БЕЗДУМНО вставляют в управляющую программу МИКРОКОНТРОЛЛЕРА ВЫПОЛНЯЮЩЕГО ВЫСОКООТВЕТСТВЕННОЕ ПРИЛОЖЕНИЕ В ЖЕСТКОМ РЕАЛЬНОМ ВРЕМЕНИ результат кодогенерации в матлабе или в другом софте(однозначно менее качественном, т.к. инвестиции в тот спецсофт на порядки меньше, чем в матлаб) возможно не идиоты. Возможно они преступники и сознательно пытаются убить пользователей их "продукта".
А профессиональные разработчики в таких случаях обычно используют матлаб и другие инструменты для моделирования, а результат - таблицы, коэфф полиномов и т.д. вставляют затем ручками в свой исходник. Тогда все четко, и никаких 11000 глобальных переменных.

P.S Господа, я делюсь реальным опытом, как оно все обстоит на самом деле.

в свете таких реалий я чувствую надо поставить все машины на прикол, и срочно вливаться в проект Андрея. И потом ездить на своих "мозгах", а не на "профессиональных".
p.s. был бы премного благодарен за информацию в машинах каких марок следует ожидать электроники спроектированной с вот таким профессионализмом.

[ZASADA]

еще ваша входная аналоговая схема напрягает.

[a123-flex]

Осталось в основном unreachable statement после while(1)
Есть вариант делать while(!chThreadTerminated()), но это лишние байтики ради ворнинга. Есть ли варианты лучше?

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

У нас там три способа компиляции - gcc/Makefile, gcc/eclipse и iar для пиратов Есть косяк - бывает, что iar оттстаёт, сейчас пойду починю. Конечно же комплироваться должны все три версии, раз мы их анонсируем.

Андрей а здесь можно поподробнее - ты собрал проект 3 разными компиляторами ?
Т.Е. это не 3 разных проекта с синхронизируемыми исходниками, а именно 1 с разными makefile's и конф. файлами среды ?

скачал проект, случайно ткнулся в первый попавшийся модуль. Попал в crc. Ты его вычисляешь. Зачем ? для crc нужно делать таблицу, и получать его за 2 команды. как то так:

char CRC8(void *data,usint size_data){
uchar *a,crc=0;
usint i;
a=(uchar *)data;
for(i=0;i<size_data;i++){
crc=CrcTable[crc ^ *a];
a++;
}
return crc;
}

const uchar CrcTable[256]={0, 94, 188, 226, 97, 63, 221, 131, 194, 156,
126, 32, 163, 253, 31, 65, 157, 195, 33, 127, 252, 162, 64, 30, 95, 1,
227, 189, 62, 96, 130, 220, 35, 125, 159, 193, 66, 28, 254, 160, 225,
191, 93, 3, 128, 222, 60, 98, 190, 224, 2, 92, 223, 129, 99, 61, 124,
34, 192, 158, 29, 67, 161, 255, 70, 24, 250, 164, 39, 121, 155, 197,
132, 218, 56, 102, 229, 187, 89, 7, 219, 133, 103, 57, 186, 228, 6,
88, 25, 71, 165, 251, 120, 38, 196, 154, 101, 59, 217, 135, 4, 90,
184, 230, 167, 249, 27, 69, 198, 152, 122, 36, 248, 166, 68, 26, 153,
199, 37, 123, 58, 100, 134, 216, 91, 5, 231, 185, 140, 210, 48, 110,
237, 179, 81, 15, 78, 16, 242, 172, 47, 113, 147, 205, 17, 79, 173,
243, 112, 46, 204, 146, 211, 141, 111, 49, 178, 236, 14, 80, 175, 241,
19, 77, 206, 144, 114, 44, 109, 51, 209, 143, 12, 82, 176, 238,
50, 108, 142, 208, 83, 13, 239, 177, 240, 174, 76, 18, 145, 207, 45, 115,
202, 148, 118, 40, 171, 245, 23, 73, 8, 86, 180, 234, 105, 55, 213, 139,
87, 9, 235, 181, 54, 104, 138, 212, 149, 203, 41, 119, 244, 170, 72, 22,
233, 183, 85, 11, 136, 214, 52, 106, 43, 117, 151, 201, 74, 20, 246, 168,
116, 42, 200, 150, 21, 75, 169, 247, 182, 232, 10, 84, 215, 137, 107, 53};

[Андрей239]

еще ваша входная аналоговая схема напрягает.

Ну а можно немного констуктивнее? Ну как-бы мысли пока в текущем сообщении не очень много.
Чем именно напрягает? Как можно улучшить?
Я же более чем открыт к предложениям

Не совсем тремя компиляторами.

Двумя компиляторами - что-то там внутри IAR и GCC. Исходники одни, и три файла как бы проекта: 1) iar 2) Makefile (gcc) 3) Eclipse (gcc)

#2 - самый стабильный, потому что крутиться на jenkins. Я испольщую Eclipse проект - но там нюансы со сменой версии ARM plugin - так что мне нужно переехать на новую версию плагина в моём Eclipse проекте. Ну и IAR иногда отстаёт при добавлении новых файлов - но сейчас актуален.

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

Про произовдительность текущий нюанс например http://forum.easyelectronics.ru/viewtopic....f=7&t=17529

[a123-flex]

Не совсем тремя компиляторами.

Двумя компиляторами - что-то там внутри IAR и GCC. Исходники одни, и три файла как бы проекта: 1) iar 2) Makefile (gcc) 3) Eclipse (gcc)

#2 - самый стабильный, потому что крутиться на jenkins. Я испольщую Eclipse проект - но там нюансы со сменой версии ARM plugin - так что мне нужно переехать на новую версию плагина в моём Eclipse проекте. Ну и IAR иногда отстаёт при добавлении новых файлов - но сейчас актуален.

пасибки, ето нам очень понра...

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

ну как бы я не сказал что ето оптимизация. ето просто одна из форм записи функции
не думаю, что 256 байт флеша ето дорого. впрочем, я не настаиваю

Про произовдительность текущий нюанс например http://forum.easyelectronics.ru/viewtopic....f=7&t=17529

в операционках всегда жуткие тормоза с printf. в qnx на x86 упирались в то же самое...
я бы предложил буферизовать/логгить во внешнюю ферритовую память. Обожаю Everspin. 30$/16 Мбайт, НО:

память энергонезависимая (типа флеш)
есть spi/параллельный интерфейс
бесконечное количество циклов записи
запись/чтение в память происходит не как во флеш, а со скоростью статики

MR4A16B - параллельная память 16 Мбайт 30$ в Америке цикл 35 нс
MR25H40 - последовательная SPI 4 Мбайт 11$ в Америке частота интерфейса 40 МГц
кстати если решишься на логгинг туда, то есть довольно неплохая (на мой взгляд) реализация кольцевого буффера во флеши. не моя, честно краденая, но код мне там понра, а хозяин буде рад

[AlexandrY]

Про произовдительность текущий нюанс например http://forum.easyelectronics.ru/viewtopic....f=7&t=17529

va_start/va_arg/va_end отвечают просто за перемещение указателя стека для выборки неявных параметров функции.
Никаких тормозов вызвать не могут. Быстродействие их может зависеть только от количества дополнительных параметров.
А ввод/вывод чисел с плавающей запятой действительно очень долгий. Ибо тогда в printf идет много делений и умножений.
В этом смысле библиотеки компиляторов по производительности различаются кардинально.
IAR для ARM-Cortex хороший выбор. У него самые быстрые библиотеки в целом и printf в частности.

Кстати странно, что такие вопросы возникают. Вы разве не используете профайлер в IAR с JTAG/SWD отладчиком?

А вот зачем вы там используете тулс под названием TunerStudio?
Какую пользу он вам приносит?
Это ведь просто визуализатор логов, никих алгоритмов, апроксимаций, интерполяций, а тем более моделей управления он не подсказывает, не так ли?

Да, и куда новый софт залили? Смотрю на http://sourceforge.net/projects/rusefi/fil...oad?source=pdlp. Там лежит все тот же проект. Ничего не изменилось.

[Андрей239]

Торможит chprintf - это имплементация из ChibiOS, в том топике есть ссылка - к стандартным либам отношения не имеет. И там замеряется конкретный вызов который печатает строки - так что %f тут явно не при чём

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

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

Изменения всё-таки в SVN - кототорый тоже на SF, http://svn.code.sf.net/p/rusefi/code/trunk/firmware/
Я сейчас в поле, мне тут не проверить head - так что новый tag делать не могу.

[AlexandrY]

Торможит chprintf - это имплементация из ChibiOS, в том топике есть ссылка - к стандартным либам отношения не имеет. И там замеряется конкретный вызов который печатает строки - так что %f тут явно не при чём

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

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

Изменения всё-таки в SVN - кототорый тоже на SF, http://svn.code.sf.net/p/rusefi/code/trunk/firmware/
Я сейчас в поле, мне тут не проверить head - так что новый tag делать не могу.

Да варнингов стало 29.

Но самые опасные, на мой взгляд, такие: Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement C:\Temp\RUSEFI\chibios\os\hal\platforms\STM32\OTGv1\usb_lld.c 606
Если тип volatile выбран не без оснований, то где во первых мьютексы (или что-либо другое для защиты), во вторых действительно такие переменные надо читать с особой осторожностью.
Последствия таких ошибок как правило сразу не проявляются. Могут вылезти когда кажется все уже отлажено.

Потом сообщения типа: Warning[Pe068]: integer conversion resulted in a change of sign C:\Temp\RUSEFI\console\status_loop.c 53
тоже очень плохие. Не следите за знаками? Присваиваете беззнаковому типу отрицательное значение?

Неужели GCC этих предупреждений не показывает?

[Андрей239]

Будете смеяться - но да, совершенно осознанно присваивают беззнаковому отрицательное значение, потому что присвоить я хочу (MAX_VALUE - 1000) - и присваиваю его как раз как -1000. Так что именно тут всё в порядке.

Про volatile сейчас посмотрю, это сорцы rtos - но им можно написать.

Если мы хотим педантично от ворнингов избавиться - то нужно что-то делать с unreachable statement. Какие будут предложения?

[AlexandrY]

Если мы хотим педантично от ворнингов избавиться - то нужно что-то делать с unreachable statement. Какие будут предложения?

Убрать все эти return-ы.
А зачем они нужны если реально из циклов перед ними нету выхода?

Поток варнингов при компиляции замыливает глаз. Очень легко пропустить что-то серьезное.

[Андрей239]

Спрятал эти return от IAR - потому что GCC они нужны. И да, у GCC нет ворнингов в этих местах и как-то выглядит, что у IAR с ворнингами ситуация круче.

Остались ворнинги, по которым надо думать - так что завёл тикет, чтоб не забыть: https://sourceforge.net/p/rusefi/tickets/39/



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

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

[AlexandrY]

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

Ну как понимаете, реверсить 18 тыс. строк кода не такая быстрая задача.
Но интереса ради посмотрел только начало.

Консоль сделана оригинально. Где подсмотрели идею регистрировать обработчики консоли динамически?
Только вот вопрос зачем?
У вас ведь не появятся новые обработчики пока работает одна и та же программа. (и загрузчика нет, ну может пока )
Т.е. все обработчики и так ясны на этапе компиляции. Почему бы их было не собрать в одном массиве в одном месте?

А в результате что получилось:
Заметьте, что консоль это отдельная задача.
Самой задаче выделили 384 байт стека.
Стек очень маленький. И вот по всем исходникам там и тут начинаете динамически регистрировать обработчики (узнаю стиль линукса ) .
Постепенно забывая где и какие обработчики зарегистрировали, насколько они сложны и сколько требуют стека.
В коментах к обработчикам нет никаких грозных предупреждений, что они работают в такой-то задаче с таким маленьким стеком.
Хуже того, забывая что эти обработчики в отдельной задаче вы не ставите мьютексы или семафоры или другую синхронизацию для защиты общих для задач переменных.
Спокойно читаете АЦП и проч. в консоли в то время как какая-то другая задача может туда писать.
Что еще трагично, RTOS chibios держит управляющую структуру задачи в том же стеке задачи.
Т.е. пропатчить RTOS и использовать встроенный в Cortex-M механизм защиты памяти скорее всего не получится .
Инверсия приоритетов хоть и кажется далекой абстракцией на самом деле при таких обработчиках встанет в полный рост.
А смешанный с управляющими структурами стек может привести к особо тяжелым сбоям.

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

[Андрей239]

о! очень хорошие вопросы постараюсь ответить на каждый по порядку:

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

Добавил немного комментариев в https://svn.code.sf.net/p/rusefi/code/trunk...console_logic.c
Стек маленький - это относится не только к потоку консоли, это относится ко всем потокам rusEfi. Там везде программирование в таком стиле, чтоб стек особо не был нужен. Не знаю, хорошо это или плохо - это не догма, просто пока стек большего размера нигде не был нужен.
По поводу контроля стека - там есть
#define CH_DBG_ENABLE_STACK_CHECK TRUE
которая включает ChibiOS механиизм контроля. Как он сделан я не знаю, но я на практике видел, что он работает - и я его пока доверился.

У этой консоли все задачи очень простые по определению - какой-то параметр поменять, что-то отладочное вывыести. Хоть консоль и не критическое место, но обработчки пишутся осознанно очень простыми - в том числе за счёт этого и не особо нужна явная синхронизация. Например, типисный обработчик setRevolutionPeriod - да, там выставляются две переменные и выставляются они не атомарно. Но там и нет проблемы в этом особо - т.е. синхронизации мало, потому что мало мест где она нужна (update: зарефакторил этот обработчик - одна переменная и не нужна была в виде глобальной переменной, всё стало еще честнее)
Ил вот printFullAdcReport - да, там не атомарности вывода состояния всех АЦП каналов. Так она там и не нужна. А атомарность чтения каждой 32 битной переменной у нас надеюсь гарантирована 32битной архитектурой?

Тот же volatile - я более чем в курсе, кто он и зачем. Но такой вопрос - а в нашей конкретной реализации stm32f407 volatile вообще актуален? Там есть промежуточные кеши, которые могут у разных потоков разойтись внутри единсвенного ядра? Хотя даже без кешей volatile на порядок операций конечно может влиять. И в теории хочется код конечно правильный в общем, без конкретно stm32f407. Ну, я не бог - где-то приходится срезать углы и писать good enough код.

А можно про idle_thread и слежение за загруженностью поподробнее? Буду рад совету на эту тему.
Сейчас ситуация такая: основной код в обработчиках прерываний, а текущая ChibiOS собирает статистику только по потреблению CPU потоками. (см. команду ths и метод cmd_threads) в следующей ChibiOS обещают собирать статистику по прерываниям.

А пока у меня есть своя доморощенная https://svn.code.sf.net/p/rusefi/code/trunk...til/histogram.c в которую через hsAdd замеряются два самых важных обработчика.
(Блин, давно пора заставить себя переименовать main_loop в main_event_handler)

Сообщение отредактировал Андрей239 - Jan 9 2014, 22:19

[AlexandrY]

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

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

Ваша задача заставить приложение работать надежно и для этого вам нужно защитить потоки от разрушений.
Это легче сделать когда все процедуры потоков у вас в одном файле и не требуют бесконечных поисков по сорсам.
Второе вспомогательное средство это анализатор дерева вложений IAR-а.
Опять же из-за того что вы широко используете run-time инициализацию указателей на обработчики, у вас эта фича не работает.
Получается вы создали архитектуру котороая блокирует многие мощные инструменты анализа кода и исправления ошибок.
И это элегантность?

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

Иначе чем объяснить вот такое явление:
 Callback_struct.png ( 32.11 килобайт ) Кол-во скачиваний: 52


Это структура вызовов в обработчике вызываемом в прерывании. Как видно дело доходит до того что, обработчик критического прерывания вызывает print!!!
Это тот который у вас до сих пор необъяснимо медленно работает. Хотя все объяснимо. Там же дальше за put идет еще длинная цепочка слоя эмуляции COM порта через USB c вообще непредсказуемыми задержками.
И это явно. А неявно там еще callbacks есть, которые могут указавать на еще более монструозные цепочки, но они нам не видны.

Знаете, что ключевым моментов в системе непрерывного виброконтроля на Саяно-Шушенской ГЭС был интерфейс USB. И ее тогда так и не ввели в нормальную эксплуатацию. И все рвануло.

Обращение к драйверу USB и вообще к любым print из прерываний надо убрать категорически.

[Андрей239]

Это структура вызовов в обработчике вызываемом в прерывании. Как видно дело доходит до того что, обработчик критического прерывания вызывает print!!!
Это тот который у вас до сих пор необъяснимо медленно работает. Хотя все объяснимо. Там же дальше за put идет еще длинная цепочка слоя эмуляции COM порта через USB c вообще непредсказуемыми задержками.
И это явно. А неявно там еще callbacks есть, которые могут указавать на еще более монструозные цепочки, но они нам не видны.

Знаете, что ключевым моментов в системе непрерывного виброконтроля на Саяно-Шушенской ГЭС был интерфейс USB. И ее тогда так и не ввели в нормальную эксплуатацию. И все рвануло.

Обращение к драйверу USB и вообще к любым print из прерываний надо убрать категорически.

Вы права, но есть нюансы - я не идиот
Обратите внимание - стек print включает в себя вызов метода chDbgPanic. Этот метод - это действительно panic, если он вызвался - то у нас проблемы посерьёзнее цепочки вызова put

А еще не путает котлету print с мухой printf, производительность которой у меня вызывает вопрос. Первая печатает в консоль, вторая - печатает в буффер памяти. Так что не всё так просто объяснимо

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

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

[AlexandrY]

Вы права, но есть нюансы - я не идиот
Обратите внимание - стек print включает в себя вызов метода chDbgPanic. Этот метод - это действительно panic, если он вызвался - то у нас проблемы посерьёзнее цепочки вызова put

А еще не путает котлету print с мухой printf, производительность которой у меня вызывает вопрос. Первая печатает в консоль, вторая - печатает в буффер памяти. Так что не всё так просто объяснимо

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

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

Не понял.
Не вы ли здесь жаловались на медлительность chvprintf?
А print ее как раз и вызывает.
Еще она вызывается в обработчиках через callbacks. Собственно прослеживая callbacks я на это место и вышел.

И что в вашем контексте хуже: мухи или котлеты ?

Честно говоря, я тоже использую форматированную печать в обработчиках исключений.
Но при этом пишу прямо в периферию фиксированного UART-а.
Никаких HAL, printf и прочих прослоек не использую . Шансов что все это будет живое после возникновения исключения почти никаких. Даже стек сразу переопределяю.

[Андрей239]

Я потерял нить

Итак, было сомнение в работе с оборудованием из обработчика событий - тут прояснили, что проблемы нет, потом что вызов только из panic

Сомнение в использовании HAL из panic - UART великолепно отрабатывает, потому что HAL это просто цепочка вызовов в данном случае не взаимодействующая с ОС видимо. В случае USB консоли - да, panic сообщение теряется. Это бы хотелось однажны побороть - так что хорошая идея завести тикет: https://sourceforge.net/p/rusefi/tickets/40/

По поводу chprintf в обработчкике: я пока не вижу причин его не использовать. Да, сейчас там что-то не так с перфомансом - ну так нужно взять и разобраться, почему именно. Я не вижу оснований, почему бы он был обязательно должен быть тормозным, когда дойдут руки - либо пофиксим перфоманс, либо когда точно будет понятно, что его не пофиксить - отойдём от chprintf. Тикет https://sourceforge.net/p/rusefi/tickets/35/ есть - значит проблема не забутиться.

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

[AlexandrY]

Я потерял нить

Я говорил, что поинтер callbacks в обработчике прерывания указавает на функцию которая тоже использует chvprintf.
chvprintf в свою очередь работает с блокирующим! вызовом put.

Кстати, зачем метод put надо было так хитро завертывать в макрос? (это не вам, а создателю chibios )
Очень неприятно когда макросы мимикрируют под функции. Усложняет исследование сорсов значительно.

Использование блокирующих вызовов в прерываниях - грубейшее нарушение принципов RTOS.

Я не накаляю, просто субъективные замечания по вашим исходникам.
Понимаю сколько сил надо было чтобы разобраться в этой chibios.

У меня кардинальное предложение.
А почему бы вам пока ваш проект достаточно маленький не перейти на другую платформу?
Я имею в виду микроконтроллеры серии K7x, например K70P256M150SF3.
Модуль так и быть, я бы вам нарисовал.
Получили бы гораздо более мощную бесплатную RTOS - MQX. Там и поддержка серьезней.
С портирвание вашего алгоритма помог бы.


Микроконтроллеры Freescale семейства Kinetis имеют такую замечательную фичу как аппаратный настраиваемый фильтр входных цифровых сигналов.
Такие интерфейсы как I2C, SPI, UART часто могут уходить в ступор при наличии глитчей на линиях. А Kinetis их успешно фильтрует.
Незаменимая вещь в условиях сильных помех. Сегодня меня буквально выручил.

[Андрей239]

Я говорил, что поинтер callbacks в обработчике прерывания указавает на функцию которая тоже использует chvprintf.
chvprintf в свою очередь работает с блокирующим! вызовом put.

Не совсем понимаю, давай(те) уточним.

Я вижу chvprintf которому передаются разные имплементации потоков вывода через chSequentialStreamPut. Мне кажется, что в обработчиках (кроме ситуации panic) передаётся неблокирующая имплементация

static msg_t put(void *ip, uint8_t {
MemoryStream *msp = ip;

if (msp->size - msp->eos <= 0)
return RDY_RESET;
*(msp->buffer + msp->eos) = b;
msp->eos += 1;
return RDY_OK;
}

Я здесь ничего страшного не вижу. Я где-то заблуждаюсь?

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

[a123-flex]

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

Таки, момент истины. я предлагаю плату с TI Integra. Там просто Linux, и вообще все круто)

Чтото уважаемый AlexandrY стал нагнетать...

Микроконтроллеры Freescale семейства Kinetis имеют такую замечательную фичу как аппаратный настраиваемый фильтр входных цифровых сигналов. Такие интерфейсы как I2C, SPI, UART часто могут уходить в ступор при наличии глитчей на линиях. А Kinetis их успешно фильтрует. Незаменимая вещь в условиях сильных помех. Сегодня меня буквально выручил.

Я конечно не великий гуру программирования. Но не объясните ли мне плз, как ето UART может перейти в ступор ?

[Андрей239]

Таки, момент истины. я предлагаю плату с TI Integra. Там просто Linux, и вообще все круто)

Поезд смены платы ушёл. Линукс это круто, но не для управлением форсунки - в линуксе нужно дико шаманить в сторону OS реального времени.

[a123-flex]

Поезд смены платы ушёл. Линукс это круто, но не для управлением форсунки - в линуксе нужно дико шаманить в сторону OS реального времени.

пожелаем поезду успехов.

[AlexandrY]

Я здесь ничего страшного не вижу. Я где-то заблуждаюсь?

Ладно, еще покритикую если никто не против.

Я вот в коде выше вижу много "страшного". Буффер молча игнорирует данные и никого ни о чем не предупреждает в случае если в нем нет места.
Но вообще автор оси написал, что этот вызов должен быть блокирующим. Кстати put при пересылке через USB как раз блокирующий.
Ну ладно, скажем здесь автор сам не знал че хотел.

Но почему же в приикладном коде вообще не используются сервисы этой самой RTOS?
Ни мьютексы, ни семафоры, ни очереди. ничего!
Зачем тогда вообще эту ось выбрали. Только ради Serial-over-USB?

Но зато тут же начали изобретать велосипед в виде буфферизированных логеров (прекрасно решается очередями), вызовом блокировки прерываний (а по уму делают мьютексами) и т.д.
Кста, там нагородили с приоритетами в mcuconf.h. Посмотрите макрос CORTEX_PRIORITY_MASK , он явно не позволяет делать проритет больше 8.

Такое чувство что вы не доверяете доморощенной ОС-и? Правильно, я бы тоже не доверял.
Скажу больше.
Хоть автор там и уверяет, что его переключение контекста самое быстрое, но тем не менее примитивно сохряняет все возможные регисты ядра включая сопроцессор.
В то же время MQX селектирует задачи и для тех кто не использует сопроцессор, зря регистры не гоняет в стек и обратно.

Далее проблема стека. Все будут смеяться когда узнают, как chibios следит за стеком.
Там на самом деле нет функций монитороинга за свободным пространством стека, но зато есть проверка (только при переключении контекста) не вышел ли стек за свою границу.
И самое смешное после этого ось не меняя указателя стека начинает вовсю юзать свои сервисы пытаясь через USB драйвер нам сообщить об этом событии.
Это все равно как после кораблекрушения продолжать крутить штурвал.

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


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

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

[Андрей239]

Ладно, еще покритикую если никто не против.
...
Ведь проект этот просто по сути логгер имеющий мало отношения к риалтайму и надежности.

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

Критика ОС в перемежку с критикой rusEfi - немного каша. Господи, что за зацикленность на MQX? У меня догма мозга чуть меньшая - я понимаю, что ОС всегда можно поменять на переправе, если на то будут весомые причины. Я считаю, что мне не нужно сделать идеально - мне нужно сделать хорошо. И я считаю, что я делаю хорошо

Но я открыт к помощи и предложениям. Я буду очень рад патчу, переводящему всё этот на MQX. Сложно не будет, потому что я сознательно минимизирую завязку на любую OS как раз для простоты портирования. Кстати, как там именно с лицензией, если отрезюмировать? В википедии вижу "royalty-free licensing" и "License: Proprietary"

Сообщение отредактировал Андрей239 - Jan 13 2014, 15:31

[AlexandrY]

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

Я так и понял.
Но это обманчивая простота, поскольку вы начали дублировать сервисы оси.
А эти сервисы, поверьте, не на пустом месте возникли.

MQX бесплатна пока вы применяете ее на микронтроллерах Freescale.
Патч не поможет, нужно все писать заново и начинать с bootloader-а.

[Андрей239]

MQX бесплатна пока вы применяете ее на микронтроллерах Freescale.
Патч не поможет, нужно все писать заново и начинать с bootloader-а.

Как, в MQX нет bootloader-а? Ну тогда спасибо не надо.
Ну и завязываться на Freescale я не планирую. А простота конечно же просто простота - никакой магии нет. В многопоточном программировании я более чем разбираюсь, все эти приметивы мне проще сделать самому и иметь над ними полный контроль - я считаю, что использовать сервисы каждой конкретной ОС нужно ровно в необходимых количествах, ОС не должна заменять мозг.

[AlexandrY]

Как, в MQX нет bootloader-а? ... В многопоточном программировании я более чем разбираюсь,...

bootloader есть у меня.

Многопоточное программирование и realtime системы это разные вещи.
Я сам программировал многопоточные приложения на PC.
Это не сказал бы что легче чем realtime, но совсем другая специфика.

А в вашем проекте с реалтаймом ну полный провал.
У вас для критических секций используется исключительно запрещение прерываний уровня ядра.
Это так в линуксе можно. В RTOS так делают чтобы защитить максимум присвоение пары переменных.
А у вас и printf с запретом прерываний, или вот видел место где запрещаете прерывания и начинаете делать strlen и strcat на 5-и килобайтном массиве!
Ну хорошо еще что у вас там алгоритм без DSP обработки. События достотчно редкие. CAN интерфейс никакой.
USB правда есть, но уже и проблемы как бы с ним.
А если бы решили сделать фильтрацию (в референс дизайне от Freescale для одного цилиндра используют 7! фильтров) или ту же детонацию без внешней микросхемы или VR сенсор на внутренних ресурсах микроконтроллера (во! удешевили бы..) то бысто бы поняли, что на одних только обработчиках прерываний далеко не уедешь. Нужно разделять во времени прием данных и их обработку. Но запрещение прерываний ядра сильно уменьшает ресурсы времени.

А в MQX между прочим вы можете передавать события и сообщения в ядро прямо из обработчиков прерываний.

А если считаете свой дизайн "священной коровой", то зачем сделали его открытым?

[Андрей239]

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

Золотые слова про приём и обработку. Это 100% верно и мне действительно вероятно придётся эти места улучшать.

Именно для того, чтоб получить вот такую, ОЧЕНЬ ценную в целом критику, я и сделал всё открытым.

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

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

Итого: пошёл думать, какой именно тикет завести по итогам этого комментария.
Всё-таки MQX не вариант потому что Freescale не очень вариант. Уверен, что ChibiOS пока не тянет нас на глубину.

Еще раз хочу попросить поучаствовать программированием, но и за мысли уже огромное спасибо - мысли очень хорошие.

[emmibox]

С точки зрения стороннего разработчика МИКАС не более готов чем груда металлолома.

Груда металлолома управляет двигателем Субару. http://www.youtube.com/watch?v=r2dc_BvUXEc

Груда металлолома управляет электронным дросселем http://www.youtube.com/watch?v=8AiVcbKKczw (пока только PI).

надо ли объяснять что у груды металлолома нет ну ровным счетом никаких проблем ни с чем вообще!?

и да - я сторонний разработчик!

[Андрей239]

Я не квалифицирован судить о блоке МИКАС - я знаю, что процессор там слабый. Я знаю, что писать софт под быстрый процессор - проще, чем под медленный. Давайте в этом топике обсуждать в основном rusEfi

MaxiRPD кстати зарегестрирован на нашем форуме и даёт очень хорошие советы.

[emmibox]

Я знаю, что писать софт под быстрый процессор - проще, чем под медленный. Давайте в этом топике обсуждать в основном rusEfi

Андрей. Проблема систем управления вообще не стоит в написании софта. Сейчас у нас уйма софта в примерах разного качества под что угодно. Проблема в адекватных алгоритмах - а вот с ними плохо очень. Над ними приходится работать потому что никто на халяву не скажет как и что надо делать. Это все приходит только через моторы-опыт-время. И реализация на быстром процессоре и на медленном только вопрос владения языком. У меня нет проблем с MCS51 - я работаю с ним с 1988 года - и мне проще написать на нем чем на чем угодно вообще.

MaxiRPD кстати зарегестрирован на нашем форуме и даёт очень хорошие советы.

MaxiRPD это я. Я просто вспомнил что у меня тут давно есть аккаунт

[Андрей239]

Андрей. Проблема систем управления вообще не стоит в написании софта. Сейчас у нас уйма софта в примерах разного качества под что угодно. Проблема в адекватных алгоритмах - а вот с ними плохо очень. Над ними приходится работать потому что никто на халяву не скажет как и что надо делать. Это все приходит только через моторы-опыт-время. И реализация на быстром процессоре и на медленном только вопрос владения языком. У меня нет проблем с MCS51 - я работаю с ним с 1988 года - и мне проще написать на нем чем на чем угодно вообще.

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

MaxiRPD это я. Я просто вспомнил что у меня тут давно есть аккаунт

Я завидую твоей памяти. Аккаунту 10 лет, а ты про него 'ВСПОМНИЛ'?

[emmibox]

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

Все примеры которые так или иначе есть - написаны обычными программистами. Просто тебе это кажется не понятным - хотя это обычный автоматный метод. Да им сейчас мало кто владеет - но специалисты есть. Мало того я считаю что производительность не заменит тебе владение им (хотя это мое субъективное мнение)...

[frig]

Хех, у меня тоже акк тут есть
emmibox, когда хочется/нужно что-то попробовать и предстоит ковырять чей то кривой (или просто очень оптимальный) код, то может оказатся, что трудозатраты этого просто не стоят. Железо дешевле труда программистов, так что сейчас уже можно позволить себе писать понятный код. Не максимально оптимизированный, не супер производительный, а понятный. Без понятного кода жизни не будет - проект будет доступен единицам. Ведь есть дизассемблированные прошивки, автором которых выступаете и вы. Но они надежно защищены

[emmibox]

Хех, у меня тоже акк тут есть
emmibox, когда хочется/нужно что-то попробовать и предстоит ковырять чей то кривой (или просто очень оптимальный) код, то может оказатся, что трудозатраты этого просто не стоят. Железо дешевле труда программистов, так что сейчас уже можно позволить себе писать понятный код. Не максимально оптимизированный, не супер производительный, а понятный. Без понятного кода жизни не будет - проект будет доступен единицам.

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

[frig]

Дизассемблирование - очень дешевый путь получения ответов.

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

Очень дешевый путь получения ответов, пускай, есть. Вот нужен дешевый путь проверки и реализации.

[Андрей239]

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

Итого: блин, где же мне найти буквально одного умного программиста, а то почти одному тяжко тикеты стынут

[emmibox]

Это да. Но потом эти ответы куда девать? Как проверять догадки? Одно дело когда жесткий дефицит производительности и это может послужить причиной отказа от какого-то решения вообще или долгих и мучительных поисков упрощения, другое дело, когда можно просто взять и попробовать.

всегда можно тупо подкинуть процессор. - просто еще один под задачу. любой! в любом виде!
и даже аргументировать состоятельность этого решения - "да тойота в стоке так делает"...
Только вот 10 лет уже как то в реальной жизни обходимся.

[Андрей239]

Только вот 10 лет уже как то в реальной жизни обходимся.

Потому что 10 лет опыта пропить сложно. Но сколько вас таких с таким опытом? Единицы. rusEfi пытается снизить порог вхождения. Хорошо это или плохо - отдельный вопрос

[frig]

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

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

[emmibox]

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

[Андрей239]

Что-то я запутался. У нас то ассемблер, то матлаб? Но я так, просто мысль вслух.

Я добавил информации в общее описание - оно живёт по адресу http://rusefi.com/docs/html/

Сообщение отредактировал Андрей239 - Jan 14 2014, 15:55

[frig]

Да не определяется порог вхождения ни сложностью кода ни сложностью его написания.

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

он почти весь транслируется из моделей матлаба.

Вот и порог входа. Больше на стену похоже.

[emmibox]

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

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

В мире нет реальных систем не с использованием интерпретируемых языков (на уровне ECU) ни с ООП в наборе. Абстракции только на уровне RTOS для переносимости опять же в пределах переносимости RTOS.

[frig]

Я никому не указываю как оно должно быть. Я говорю о тенденциях вокруг и о том, что rusefi этим тенденциям вполне соответствует.