_lexa_

Здоровья вам!

Похоже вы не привыкли читать посты полностью. По первым двум предложениям ответ написали или бредом называете свой ответ?

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

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

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

Как-то все сложно. Можете подсказать какими документами все это нормируется и какие организации предоставляют услуги по проверке ПО и фиксации факта его заливки?

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

Сейчас в моду входят "электронные пломбы" в дополнение к механическим

Задача мелка, не хотел еще батарейку ставить Вместо реле придется все равно поставить оконечник времен царя гороха. А так да, про батарейку и RTC я знаю. Но в идеале батарейку ставить не хотелось бы - сильно снижает надежность устройства. Какой из вариантов надежней (оконечник + батарейка или реле без батарейки) - вопрос спорный надо считать. Но на первый взгляд реле без батарейки выглядит надежнее.

Я же указал - контроль вскрытия корпуса. Цифра не будет работать без питания, а это событие должно фиксироваться и без питания

Всем добрый день! Помогите найти подходящее реле для контроля вскрытия корпуса электронного устройства. От реле требуется, чтобы при отпускании управляющей кнопки реле "перекидывалось" и размыкался контакт, дальнейшее нажатие кнопки на состояние контактов не влияло, при этом возврат реле осуществлялся бы только соленоидом управления при нажатой кнопке. Напряжение управления - не более 5 В, потребление соленоида не более 0,5 Вт, нагрузочная способность контактов практически не важна. Габариты в пределах 30х20х20. Нашел наиболее близкое устройство - указательное реле РУ-21, но в нем все наоборот (соленоид перекидывает реле при не нажатой кнопке, возвращается кнопкой при отсутствии напряжения на соленоиде), а также не подходит габаритами и напряжением управления

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

Да уже ничего понимать не требуется, решение вопроса на второй странице. вот потребовалась мне константа для отладки, чтобы можно было после перезагрузки платы посмотреть значение которое было до перезагрузки. Потом я ее вообще удалю. Зачем мне для нее структуру создавать? Но при этом есть массив для записи диагностической информации. И для чего мне объединять временную константу с данными диагностики. А по поводу анекдота - вариативность ситуаций может быть довольно большой. Вы это не рассматриваете? Например, расположил я данные в DTCMRAM (STM32F7), зачем их объявлять как volatile. А запись во флэш - отдельная функция, при этом чтение (копирование) данных в определенных ситуациях проще поручить ДМА

Я и не спорю, что надо учитывать оптимизацию компилятора при работе с памятью, как и работу кэша. Но запись и чтение памяти не ограничивается простой операцией "а = b". Можно сделать для этого специальную функцию, в которую передаются указатели на "а" и "b", можно сделать ассемблерную вставку, можно использовать ДМА и т.п. Кстати работает такая конструкция (константа в ROM, при этом не инициализируется и volatile) __no_init const volatile uint32_t my_const @ ".const_noinit";

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