Об отечественной электронной промышленности

Реклама
Это таки требует ресурсов. Но отказ данной системы не критичен.
Я не совсем корректно выразился. Я имел ввиду, что вы не станете выводить 3Д реалистичную картинку на основной дисплей, потому что тогда при проблемах с мощной видеокартой станет недоступной не только не критичная картинка с радара. То есть все равно сделаете критичные системы на проверенных чипах, а "навороты" отделите, потому что главная причина не в том, что современные компы нечем было бы занять в самолёте, а именно в том, что критическая часть делается на проверенных деталях.

Например используя мажоритарную схему на трех разных аппаратных платформах, как в том же 777.
Мне кажется, мажоритарная схема хороша при отказах свзанных с браком или эксплуатации. Отказ вызванный аппаратной ошибкой (например, когда процессор какую-либо команду выполняет не так, как задумано при определенных редких условиях) приведет хоть на сотне одинаковых компьютерах к одинаковой ошибке. Если только ставить компьютеры на разных процессорах.
Впрочем, если ошибки будут спорадическими, но частыми, но для эксплуатантов это все равно будет ад, который рано или поздно плохо кончится.
Впрочем, уверен, что в реальности, все будет прозаичнее: просто процесс создания авионике на сыром процессоре будет выглядеть как типичное "до готовности всего год", по причине того, что сырое нестабильное устройство никто не рискнёт ставить в самолёт.
 
программы на МК вынуждены в большинстве случаев работать с переферией, потому что иметь прокладку в виде ОС и драйверов слишком жирно.
Спросите у эксперта Kit. , он вам раскажет про подходы к проектированию софта в автомотив, ключевые слова autosar, mcal.
Ну вот мы и пришли к утверждению,
Вам не стоит идти в системщики. С таким подходом вместо результата вы будете находить причины почему не сделано. Здесь подход "с моей стороны пули вылетели" не работает.
 
Мне кажется, мажоритарная схема хороша при отказах свзанных с браком или эксплуатации. Отказ вызванный аппаратной ошибкой (например, когда процессор какую-либо команду выполняет не так, как задумано при определенных редких условиях) приведет хоть на сотне одинаковых компьютерах к одинаковой ошибке. Если только ставить компьютеры на разных процессорах.
Впрочем, если ошибки будут спорадическими, но частыми, но для эксплуатантов это все равно будет ад, который рано или поздно плохо кончится.
Впрочем, уверен, что в реальности, все будет прозаичнее: просто процесс создания авионике на сыром процессоре будет выглядеть как типичное "до готовности всего год", по причине того, что сырое нестабильное устройство никто не рискнёт ставить в самолёт.
В 777 FBW на разных процессорах и с разнвм ПО в одном блоке PFC.
 
Вот, кстати,, слышал о таком и давно хотел узнать: это типичная практика или нет? Насколько это "роскошь" для разработчиков?
это типичная практика.
Вот прямо вчера обсуждали с инженерами, как будем обеспечивать требование независимости отказов в разрабатываемом блоке.
Решили делать два независимых вычислителя на разной элементной базе.
 
Реклама
Вам не стоит идти в системщики. С таким подходом вместо результата вы будете находить причины почему не сделано. Здесь подход "с моей стороны пули вылетели" не работает.
За меня переживать в этой ситуации нужно меньше всего: "системщики" обычно по ту сторону, где выбирают "где лучше". Я бы больше беспокоился за конечных потребителей, ибо результаты их труда (производительность и уровень жизни, в конечном счёте) в современной экономике находятся в прямой зависимости от средств производства, инфраструктуры и т.п.. созданных и поддерживаемых "системщиками". Когда "умников" и "недостаточно идейных" "интеллектуалов" перестают слушать, то обычно оптимизм у большинтсва относительного быстро заканчивается )
#ау
 
это типичная практика.
Вот прямо вчера обсуждали с инженерами, как будем обеспечивать требование независимости отказов в разрабатываемом блоке.
Решили делать два независимых вычислителя на разной элементной базе.
Ну что ж, значит задачи по созданию собственного процессора доя авионики умножаем на два. Ну хоть не так часто самолёты попадать будут - уже хорошо ))))
 
Ну что ж, значит задачи по созданию собственного процессора доя авионики умножаем на два. Ну хоть не так часто самолёты попадать будут - уже хорошо ))))
В PFC не какие то "собственные процессоры для авионики" а обычные промышленные насколько я знаю. И их три разных, а блоков PFC тоже три... безопасность прежде всего.
 
В PFC не какие то "собственные процессоры для авионики" а обычные промышленные насколько я знаю.
Ну мы тут обсуждаем гипотетическое создание отечественных процессоров и микроконтроллеров, которые можно было бы производить полностью в России . Так как их пока никаких нету, то соответвенно для двух разных нужно создать два для трех разных - три , ну и т.д.
 
Ну мы тут обсуждаем гипотетическое создание отечественных процессоров и микроконтроллеров, которые можно было бы производить полностью в России . Так как их пока никаких нету, то соответвенно для двух разных нужно создать два для трех разных - три , ну и т.д.
А можно просто создать 2-3 типовых процессора и архитектуру строить уже из учёта имеющихся ресурсов и возможностей... Все равно переделывать в блоках платы пин в пин не получится. А адаптировать уже имеющиеся алгоритмы под новое железо это не такая и сложная уж задача... Да потребует времени... Но любая разработка требует времени. Недостаток ресурсов, мощности, периферии также легко закрывается аппаратно установкой дополнительных компонентов, переходом на архитектуры с несколькими микроконтроллерами и разделением задач. Везде можно найти способ выкрутится.

Главное не это - главное чтобы эти 2-3 типовых процессора были доступны для разработчика... И самый лучший способ если бы они производились у нас
 
А можно просто создать 2-3 типовых процессора и архитектуру строить уже из учёта имеющихся ресурсов и возможностей...
Скорее сначала делают архитектуру, а потом на ее основе нужные процессоры , в том числе используя типовые блоки. Проблема в том, что даже имея доступ к готовым архитектурам и типовым блокам процессоры у нас создавали не то, чтобы быстро (все новое делается не быстро). Но когда процесс казалось бы вышел на финишную прямую и начали появляться плоды, произошло то, что произошло и нужно создавать почти все с начала. И задач при этом подросло: раньше можно было озадачиваться лишь теми направлениями, что лучше получаются или для создания которых есть ресурсы (человеческие прежде всего), то теперь нужно все и сразу и выбирать не приходится.

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

Главное не это - главное чтобы эти 2-3 типовых процессора были доступны для разработчика...
Да, лучше быть здоровым, богатым, и с процессором. Да ещё к процессору мануал доступный для скачивания "без регистрации и смс", отладочные платы и бесплатные образцы для ознакомления партнёрам. Больше доступности хорошей и разной. Если бы ещё и в текущей реальности и в этой жизни... Так мы бы тогда ух!

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

И противоречие реальности идеи противопоставления современных микроконтроллеров (тех, об "импортозамещении" которых идёт речь) и микропроцессоров в целом.

разве непонятно, что все эти игры с кешем, ускорителями флеш-памяти, выполнением кода из ОЗУ вызваны тем, что выполнение кода из флеш не обеспечивает полной утилизации ресурса ядра. На пальцах.
контроллер 1. более современный мк частота ядра - 72 МГц, флеш - 25 МГц; олдскульный контроллер 2. Частота ядра - 50 МГц, флеш - 25 МГц. Переход на более современный мк не обеспечит рост производительности в 72/50 = 1.4 раза. Так понятнее?
Вообще-то мы говорим о мк, разработчиков которых не смутила идея сделать ядро с частотой выше 100 МГц. Вы их считаете некомпетентными? Или вы считаете некомпетентными тех, кто такие мк устанавливает в собственную продукцию?
 
Реальность такова, что для уменьшения ограничений скорости флеша применяют те или иные ухищрения (кеш команд).
современных микроконтроллеров (тех, об "импортозамещении" которых идёт речь) и микропроцессоров в целом.
Я их не противопоставлял. Это ваши домыслы. Читайте внимательнее.
 
Реклама
Вообще-то мы говорим о мк, разработчиков которых не смутила идея сделать ядро с частотой выше 100 МГц
Ну тогда потрудитесь узнать на какой частоте работает флеш в этом мк. Принципиальной разницы не будет.
 
Назад