есть для спорта софт с дискретом управления по всем каналам 1.5мкс и ошибкой в пределах 1 дискрета. Нет проблем если вдруг такое понадобится.
в 2Т когда никакого ETEC у ротакса в проекте не было - эта схема была реализована в 2000-м году на той же априлии SR50 и пигаро "не помню что" (digitech). Где все задачи прекрасно решала 8-ми битная древняя моторола 68HC908AZ60. А диагностировалась и прошивалась эта система вообще с специального картриджа к еще более 8ми битному gameboy color (на еще более древнем Z80). Этот мотор и комплектная система управления у меня есть живьем вместе с всеми вариантами ее прошивок и калибровок!
В 2Т двигателях применение лямбды тупо бессмысленно.
Настраивать на нюх собрались или методом тыка? Продувка без проблем учитывается.
Основное управление идет по MAP сенсору и датчику детонации.
На двигателях с числом цилиндров меньше тактовости никакого основного управления по мапсенсору нет и быть не может! Там померить разрежение в задроссельном пространстве реально проблема - и она значительно более серьезная чем производительность систем. Мапсенсор там используется только в режиме барокоррекции. А управление топливом всегда прямое по оборотам и положению дроссельной заслонки. Как и датчик детонации лишь чуть чуть корректирует карты прямого управления УОЗ.
В реальном мире 2.5mips хватает чтоб управлять двигателями 6 цилиндров, 1050 сил, на 9000 оборотах, если отсутствие быстродействия и мощности компенсировать отсутствием 3-х делений в атомарной функции линейной интерполяции в трехмерных картах - т.е. архитектурой ПО.
Опять же проц в rusefi не имея и сотни таких карт уже затыкается на интерполяции, ибо там она просто написана в лоб да еще на плавающей точке. Код современного серийного ЭБУ содержит около 8000 таких карт - и не затыкается! Вопрос - где быстродействие и мощность?! ответ - она в серийных ЭБУ! Ведь в них интерполяция давным давно уже стала машинной командой специализированного процессора для ЭБУ, и так в любом узком месте. И специализированный процессор с тактовой условно в 5 раз меньше окажется в реальном изделии в сотни раз быстрее.
С точностью все тоже очень плохо - точность определяется не только и не столько ЭБУ, а датчиками и исполнительными механизмами. Даже в моменте точность определяется тем, как точно лямбда может померить смесь и как точно на стенде можно попасть в УОЗ. Так вот точность даже в 2 градуса по углу и 2% по смеси недостижима для любого доступного стенда и любой доступной лямбды соответственно. А подобная точность у систем была достигнута еще в 90-е. Т.е. да проблема есть - но она совсем не в ЭБУ.
Разработчики встраиваемых систем давно программируют в симулинке решение задачи. А вы до сих пор описываете «как оно там было в святые 90-е» V-model писание кода руками. вот это вот все…
Не далее как вчера ищу «фигню» — маркет показывает — цена от 1349 до 1900
нажимаю «открыть» сортировка по ценам — лучшее предложение от маркета за 1499 — т.е. ровно +10% накинули и далее список еще дороже. И что не жми — нет варианта предложения за 1349 — хотя где то внутри оно знает что так можно.
гуглом набрал «фигня» цена 1349 — сразу нашел магазин где она по этой цене и купил. В выдаче яндекса его вообще не было естественно.
Если это будет в виде научной статьи — вы можете показывать потрошки и куски исходников полученных методом реверс инженеринга. Поскольку ГК напрямую разрешает дизассемблирование для ПО которым вы законно владеете, а потрошки показываются лишь в рамках необходимого объема цитирования в научной статье — следовательно никакого нарушения авторских прав не происходит.
С паролем тоже все просто — если вы его напрямую публикуете это прямая информация для взлома 100500 устройств — если вы пишите, что от там ЕСТЬ и показываете скажем 1-ю и последнюю букву а остальное замылено — это научная статья на тему «ваша защита говно» и вы ничего не нарушаете.
Нет тут никакого управления движением. Обычный набор датчиков для активного круиза и автопарковки под углом 90градусов с черепашьей скоростью — т.е. просто поставили всю требуху что 10 лет как стояла в S классах ауди в B-класс фольксваген.
А дыра в безопасности там не V2X а телематика. Которая мало того, что сливает на сервера VW хрен знает что, включая координаты машины, да еще и стучит в случае если вы решили, что вы можете сами машину продиагностировать или не дай бог еще вдруг ПРОШИТЬ — и сразу прощай гарантия.
Нет. Всего лишь выполнять требования стандартов проектирования автомобильной электроники. Ознакомьтесь на досуге — говорят полезно для общего развития. Например: DIN-EN-60068-2-2
6 ЭБУ из партии берутся случайным образом — корпуса вскрываются и непосредственно к компонентам подводится горячий воздух. Температура воздуха внутри корпуса в течении всего теста не должна опускаться ниже +105 градусов. Возможности иного теплообмена со средой кроме как с этим воздухом при этом нет. ЭБУ обязаны отработать в режиме полной, как токовой (по выходам), так и загрузки всех процессоров по выполняемому тестовому коду, в течении 1000 часов непрерывно. Если любой из 6 не выполняет требование — тест не пройден для всей партии.
Процессор при это работоспособен при температуре среды до +125 градусов непрерывно или до +150 градусов кратковременно.
Впрочем и тест «где вода превращается в пар» в наборе тоже есть...DIN-EN-60068-2-78
Для автопилотов (если они вдруг lдействительно случатся) нужны производительные чипы с пассивным охлаждением и рабочими температурами в 150-170 градусов… Это отдельный класс техпроцессов и Интел наверно стоит последний в списке тех, кто такие сможет предложить…
Потому, что это писк со дна рынка автомобильного ПО от каких то мышей. Вот этот Электробит — найдите у нее в партнерах хоть одну автомобильную компанию… А нет там их! Потому, что у серьезных авто производителей эти перспективы давно закрыты и никаких проблем нет от слова вообще — мелкой компании им нечего предложить. Проблемы были в середине 90-х, когда был переход с OSless методик разработки. А сейчас этих Autosar RTOS — как грязи, для любых камней и периферии, на любые вкусы и задачи, причем, как своих собственных так и сторонних, включая сложные и специфические, о которых «мыши» даже не догадываются.
Нет никаких вариантов. Синтаксис команд ассемблера определяется исключительно разработчиком микропроцессора! Не нравится — выберите другого разработчика.
Вождение авто, в большинстве случаев, есть ни что иное как однообразная механическая работа,
Бу го га. Вождение авто — это не однообразная механическая работа. Это решение задачи распознавания на дороге ребенка, включая случай, когда он едет на велосипеде задом наперед, сидя задницей на руле и вращая педали руками и размахивая ногами в воздухе — естественно с вероятностью в 100%. И эта задача решения не имеет ни в настоящий момент, ни через 10 лет иметь не будет.
Про с++ там где этот скачок произошел — он уже давно произошел. А там где нет — уже вряд ли не произойдет. Просто большинство embedded систем обладают конечной сложностью которая не растет исходя из самой задачи которую они выполняют и в лучшем случае там за 20лет раздуют С код на 10-20% — да и черт с ним.
Когда эти квалифицированные специалисты фантазируют о замене таксистов автопилотами в их ближайшем светлом будущем — это нормально и всячески приветствуется. Когда же им намекают, что их самих уже давным давно заменили, причем технологиями, куда как более примитивным чем автопилот — у них возникает батхерт просто невообразимого масштаба. Как так?! А нас за что?! Мы же любимые — «всегда стоим денег» а таксисты они бесплатные.
А Сколько Dragon построено в SpaceX?! Если Dragon рухнет из за ошибки ПО — то ЧТО?!
Если ваш истребитель через 0-ю высоту перелетит — то ЧТО!?
5G это уже что то серьезное из вашего примера. — но все равно — откажет и ЧТО!?
В любом проекте ГДЕ-ТО всегда используется С++ — какая нибудь унылая прикладуха всегда на нем написана. Только вот, когда от кода начинают зависеть жизни миллионов людей — то C++ резко там не наблюдается, потому, что все его преимущества вдруг резко превращаются в недостатки.
То с чем ваш преподаватель игрался — стандарт индустрии. embedded софт давно уже пишется в связке Matlab-Simulink-Ascet а не в VS и тп… И программирование руками осталось лишь как трюково-кроильное (когда надо сэкономить ресурсы)…
Space-X кстати LabView как минимум использует. (9 слайд) А он тоже сам генерит код на С.
А это не важно.
Важно что С++ нет и не будет — ибо не нужен. Потому, что это не развивало индустрию а притягивало в нее лишний велосипед, раздувающий штат программистов. Развитие же наоборот сократило штат, увеличив объемы код на порядок.
С проблемами которые вы описываете OEM производители embedded софта столкнулись 20 лет назад — да все верно проект на N строк на M языке не поддерживаемый. Так же они прекрасно знали, что объем кода (собственно число строк близкий показатель) удваивается за полгода-год. И они не перешли на язык M++ — потому, что переход на язык М++ просто отодвигал эту проблему на момент когда число строк = N++ — т.е. максимум на пару лет. а следовательно — проблему не решал…
Они просто отказались от писания кода на С руками!
Какой в «8 триллионов рынок»… Рынка нет и быть не может — потому, что нет продукта! Есть отдельные демонстраторы принципа, и влажные мечты вокруг них, которые пока так ни во что не воплотились…
Для определения 2х максимумов вычисление корней — лишняя операция. Разницы нет, использовать массив значений, или массив корней из этих значений. Мы с Пашей как то даже спорили по этому поводу — я ему доказывал что таблицу корней надо выкинуть нафиг (она была), он согласился потом.
есть для спорта софт с дискретом управления по всем каналам 1.5мкс и ошибкой в пределах 1 дискрета. Нет проблем если вдруг такое понадобится.
в 2Т когда никакого ETEC у ротакса в проекте не было - эта схема была реализована в 2000-м году на той же априлии SR50 и пигаро "не помню что" (digitech). Где все задачи прекрасно решала 8-ми битная древняя моторола 68HC908AZ60. А диагностировалась и прошивалась эта система вообще с специального картриджа к еще более 8ми битному gameboy color (на еще более древнем Z80). Этот мотор и комплектная система управления у меня есть живьем вместе с всеми вариантами ее прошивок и калибровок!
Настраивать на нюх собрались или методом тыка? Продувка без проблем учитывается.
На двигателях с числом цилиндров меньше тактовости никакого основного управления по мапсенсору нет и быть не может! Там померить разрежение в задроссельном пространстве реально проблема - и она значительно более серьезная чем производительность систем. Мапсенсор там используется только в режиме барокоррекции. А управление топливом всегда прямое по оборотам и положению дроссельной заслонки. Как и датчик детонации лишь чуть чуть корректирует карты прямого управления УОЗ.
В реальном мире 2.5mips хватает чтоб управлять двигателями 6 цилиндров, 1050 сил, на 9000 оборотах, если отсутствие быстродействия и мощности компенсировать отсутствием 3-х делений в атомарной функции линейной интерполяции в трехмерных картах - т.е. архитектурой ПО.
Опять же проц в rusefi не имея и сотни таких карт уже затыкается на интерполяции, ибо там она просто написана в лоб да еще на плавающей точке. Код современного серийного ЭБУ содержит около 8000 таких карт - и не затыкается! Вопрос - где быстродействие и мощность?! ответ - она в серийных ЭБУ! Ведь в них интерполяция давным давно уже стала машинной командой специализированного процессора для ЭБУ, и так в любом узком месте. И специализированный процессор с тактовой условно в 5 раз меньше окажется в реальном изделии в сотни раз быстрее.
С точностью все тоже очень плохо - точность определяется не только и не столько ЭБУ, а датчиками и исполнительными механизмами. Даже в моменте точность определяется тем, как точно лямбда может померить смесь и как точно на стенде можно попасть в УОЗ. Так вот точность даже в 2 градуса по углу и 2% по смеси недостижима для любого доступного стенда и любой доступной лямбды соответственно. А подобная точность у систем была достигнута еще в 90-е. Т.е. да проблема есть - но она совсем не в ЭБУ.
нажимаю «открыть» сортировка по ценам — лучшее предложение от маркета за 1499 — т.е. ровно +10% накинули и далее список еще дороже. И что не жми — нет варианта предложения за 1349 — хотя где то внутри оно знает что так можно.
гуглом набрал «фигня» цена 1349 — сразу нашел магазин где она по этой цене и купил. В выдаче яндекса его вообще не было естественно.
С паролем тоже все просто — если вы его напрямую публикуете это прямая информация для взлома 100500 устройств — если вы пишите, что от там ЕСТЬ и показываете скажем 1-ю и последнюю букву а остальное замылено — это научная статья на тему «ваша защита говно» и вы ничего не нарушаете.
А дыра в безопасности там не V2X а телематика. Которая мало того, что сливает на сервера VW хрен знает что, включая координаты машины, да еще и стучит в случае если вы решили, что вы можете сами машину продиагностировать или не дай бог еще вдруг ПРОШИТЬ — и сразу прощай гарантия.
6 ЭБУ из партии берутся случайным образом — корпуса вскрываются и непосредственно к компонентам подводится горячий воздух. Температура воздуха внутри корпуса в течении всего теста не должна опускаться ниже +105 градусов. Возможности иного теплообмена со средой кроме как с этим воздухом при этом нет. ЭБУ обязаны отработать в режиме полной, как токовой (по выходам), так и загрузки всех процессоров по выполняемому тестовому коду, в течении 1000 часов непрерывно. Если любой из 6 не выполняет требование — тест не пройден для всей партии.
Процессор при это работоспособен при температуре среды до +125 градусов непрерывно или до +150 градусов кратковременно.
Впрочем и тест «где вода превращается в пар» в наборе тоже есть...DIN-EN-60068-2-78
Бу го га. Вождение авто — это не однообразная механическая работа. Это решение задачи распознавания на дороге ребенка, включая случай, когда он едет на велосипеде задом наперед, сидя задницей на руле и вращая педали руками и размахивая ногами в воздухе — естественно с вероятностью в 100%. И эта задача решения не имеет ни в настоящий момент, ни через 10 лет иметь не будет.
Про с++ там где этот скачок произошел — он уже давно произошел. А там где нет — уже вряд ли не произойдет. Просто большинство embedded систем обладают конечной сложностью которая не растет исходя из самой задачи которую они выполняют и в лучшем случае там за 20лет раздуют С код на 10-20% — да и черт с ним.
А Я вам пишу о проектах с 10млн юнитов и в 2 млн строк кода в каждом. Да чтоб их руками написать — вас таких 2 непрокормимых армии нужны…
Если ваш истребитель через 0-ю высоту перелетит — то ЧТО!?
5G это уже что то серьезное из вашего примера. — но все равно — откажет и ЧТО!?
В любом проекте ГДЕ-ТО всегда используется С++ — какая нибудь унылая прикладуха всегда на нем написана. Только вот, когда от кода начинают зависеть жизни миллионов людей — то C++ резко там не наблюдается, потому, что все его преимущества вдруг резко превращаются в недостатки.
То с чем ваш преподаватель игрался — стандарт индустрии. embedded софт давно уже пишется в связке Matlab-Simulink-Ascet а не в VS и тп… И программирование руками осталось лишь как трюково-кроильное (когда надо сэкономить ресурсы)…
Space-X кстати LabView как минимум использует. (9 слайд) А он тоже сам генерит код на С.
Важно что С++ нет и не будет — ибо не нужен. Потому, что это не развивало индустрию а притягивало в нее лишний велосипед, раздувающий штат программистов. Развитие же наоборот сократило штат, увеличив объемы код на порядок.
Они просто отказались от писания кода на С руками!