[a123-flex 0]

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

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

 

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

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

Поетому я говорю продукт лузер для лузеров...

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

[ZASADA 0]

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

 

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

[dlman 0]

от алгоритмических ошибок спасает отладка, и прямой хорошо структурированный простой как только возможно код. Или как Вы собрались обезопасить себя от алгоритмической ошибки посредством второго процессора ? Написать весь алгоритм управления полностью другой командой ? а если оба ошибутся ? тогда 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 компонент - и при любой проблеме будет виновато предприятие-изготовитель. А с динамической памятью, как и с импульсными преобразователями, будут проблемы на ЭМС.

 

 

 

[andrey239 0]

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

Проблемы аппаратной надежности не вызывают беспокойства.

 

Но я вот прокомпилировал сам проект. Так немного разочарован.

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

 

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

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

 

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

[a123-flex 0]

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

 

сложные алгоритмы - ето таблицы что ле ?

с чистым кодом невозможно... ето что то новенькое. А с чем возможно ? вы ебу баснями функции объясняете по картинкам в матлабе ?

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

 

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

 

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

 

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

[andrey239 0]

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

 

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

[dlman 0]

сложные алгоритмы - ето таблицы что ле ?

с чистым кодом невозможно... ето что то новенькое. А с чем возможно ? вы ебу баснями функции объясняете по картинкам в матлабе ?

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

 

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

 

 

 

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

 

сложные алгоритмы это сложные алгоритмы. я не буду рассказывать ни про цикломатическую сложность ПО, ни про метрику, ни про время вывода продукта на рынок и затраты на разработку ПО в человеко-часах. Это всем понятно. Да, кодогенерация крайне неоптимальна, но тем не менее такие проекты как DSPACE и ETAS широко используются при разработке ECU во всем мире.

Я как-то работал над проектом который достался от NVIDIA. Что касается coding standards там все было по-правильному, но что касается архитектуры - так годы, за которые этот проект развивался, превратили ее в спагетти. В какой-то момент NVIDIA закрыла проект, так и не решив многих проблем, и которые пришлось решать мне. Проблемы весьма тривиальные, но вот на их решение, ввиду сложности кода, приходилось тратить недели.

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

 

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

 

 

 

[andrey239 0]

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

 

У меня работа в проекте на 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 0]

implicit conversion from floating point to integer

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

и никто не мешает в коде в явном виде преобразовывать float в int

[andrey239 0]

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

 

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

 

Осталось в основном unreachable statement после while(1)

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

Изменено 8 января, 2014 пользователем Андрей239

[a123-flex 0]

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

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

А профессиональные разработчики в таких случаях обычно используют матлаб и другие инструменты для моделирования, а результат - таблицы, коэфф полиномов и т.д. вставляют затем ручками в свой исходник. Тогда все четко, и никаких 11000 глобальных переменных.

 

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

 

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

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

[ZASADA 0]

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

[a123-flex 0]

Осталось в основном 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};

 

 

 

[andrey239 0]

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

Ну а можно немного констуктивнее? Ну как-бы мысли пока в текущем сообщении не очень много.

Чем именно напрягает? Как можно улучшить?

Я же более чем открыт к предложениям :)

 

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

 

Двумя компиляторами - что-то там внутри 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 0]

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

 

Двумя компиляторами - что-то там внутри 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 МГц

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