syoma

Хорошая штука, только как его от брызг и попадания воды защитить и чтобы он еще при этом что-то показывал?

Автоматы можно запилить и промоделировать в Stateflow, а затем сгенерить HDL code.

Не очень. В lifetime каждый вкладывает свое определение. Например у всяких вентиляторов lifetime регламентируется как время, до которого должны доживать 80% или 90% тестируемых вентиляторов.

Обычно у производителей есть отдельный раздел и доки по reliability, где они приводят FIT и прочие данные касательно надежности. Причина - эти данные накапливаются и обновляются по мере производства на основе долговременного тестирования. Например для Xilinx все данные находятся вот в этом отчете, который регулярно обновляется https://www.xilinx.com/support/documentation/user_guides/ug116.pdf. Для других микросхем и производителей нужно просто гуглить. Эти данные можно считать как worst case, поэтому общая оценка надежности может быть заниженной. Поэтому дальше можно использовать MIL-HDBK-217, Bellcore SR-332, ANSI/VITA 51.1-2008 для того, чтобы привести данные производителя к вашим условиям по температуре, стрессам и т.д. Для простых элементов типа транзисторов, резисторов и конденсаторов можно использовать просто данные из MIL-HDBK-217. Насколько я помню, этот фактор изменяет оценку надежности в зависимости от того насколько реальные параметры эксплуатации отличаются от максимальных условий работы, указанных в даташите. Например если у вас в схеме стоит электролит с максимальным рабочим напряжением 50В, а вы реально на него подаете не более 24В, то Power stress factor будет 24/50= 0,48. Соответственно, если этот конденсатор при работе на 50В имеет надежность 50 Fit, то в вашем случае он будет иметь надежность 50*0,48=24 FIT, то есть надежность повышается. Ну примерно так. Точно также power stress factor можно задать для других компонентов - транзистор рассчитан на ток 2А, а вы им коммутируете только 200ма - Power stress factor 0.1. Резистор рассчитан на 2Вт, а вы на нем рассеиваете только 1Вт - 0,5 и т.д.

Да, но он, вроде коннектится только к компьютерным IDE, а не к телефонным аппликухам.

Ну, электронное производство - само по себе вредная штука :-)

Это же автономный программатор. На компе залил в него нужную прошивку, а потом на производстве подключаешь к платам и прошиваешь уже без компа. Единственное, что не хватает фоточек, как эта работа на производстве выглядит. И не знаю многим ли это нужно в реальности, но я бы больше заинтересовался каким-нибудь Wireless программатором Cortex-M - например сам программатор в виде платки с Bluetooth/Wi-fi модулем + аппликуха для телефона iOS/Android. Возможностей должно быть больше.

Довольно оригинально :-) Интересно, где эти разработчики сейчас.

А в трубке будет тот же уровень воды, что и вне ее? Под мостом течет река, достаточно быстрая - скорость может доходить до 10м/с, с турбулентностями и завихрениями. Разница давлений и все такое?

Интересно, почему у вас так. У нас вроде как тяжелые проекты на Ultrascale+, P&R занимает часов 6. Неопределенное время сборки или непредсказуемый результат типа 50/50 допустим только на этапе разработки и отладки функционала, когда дизайн еще сырой и требует доводки, но в финальной версии - которая идет в релиз такое не допускается. Будь ласка, реши все проблемы с времянками, чтобы проект гарантированно собирался, и тогда релизь. Действительно для CI, тогда наверное такое не подходит, но по идее если сборка занимает больше заданного времени - ее надо тупо обрывать и говорить, что это фейл.

Мы пробуем сделать CI для проектов на ПЛИС. Пока дошли до возможности делать синтез и P&R на сервере. На этом все. Фактически основная проблема, что почти всю инфраструктуру нужно лепить с нуля, готовых решений нет. И вторая основная проблема - HW тестирование. У нас ПЛИС управляет силовой электроникой и для полноценного HIL нужен симулятор за пару сотен килобаксов. Никто его в CI не отдаст.

ГОСТ IEC 61000-4-8 ? Но это переменка. Насчет постоянки не видел.

А кто что скажет по time-of-flight датчиках для данного применения? Например, наткнулся у ST на рекламку. https://www.st.com/en/imaging-and-photonics-solutions/time-of-flight-sensors.html#overview То есть это оптика, интересно как она работает, если попадут брызни? Можно закрыть стеклом?

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

Вот тут нашел еще один прикол - у меня в прерываниях используются локальные переменные, которые, как я понял, находятся тоже в data overlay. Что произойдет с ними, если прерывание с более высоким приоритетом прервет прерывание с низким приоритетом, в котором используются локальные переменные? Получается, что оно может испортить их значение?