Перейти к содержанию
    

_lexa_

Участник
  • Постов

    50
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о _lexa_

  • Звание
    Участник
    Участник

Посетители профиля

947 просмотров профиля
  1. Всем добрый день! Работаю со следующей системой: SoC - am3358, linux-rt-4.19.94-rt39-ga242ccf3f1 из SDK 06_03_00_106 Столкнулся со следующей проблемой - есть приложение, в котором работают, скажем, 8 потоков, 1 из которых RT, остальные неRT. В RT-потоке создается и запускается таймер с уведомлением о срабвтывании с помощью потока (timer_create(), timer_settime()), Также из RT-потока с периодом от 0,1 до 2 с производится обновление времени срабатывания этого таймера. Через какое-то время работы приложения процессор начинает сначала перегружаться, затем вовсе зависает. В то время, когда процессор перегружен, получилось снять такой лог: Судя по RCU stall detector: такая ситуация возможна при использовании механизма RCU в RT-потоках. Я так понимаю, при вызове timer_settime() и при срабоатывании таймера выполняется синхронизаация чтения/записи RCU. Я предполагаю, что наложились события срабатывания таймера и обновление времени срабатывания из RT-потока, в которых задействованы механизмы RCU (что-то вроде - драйвер таймера находился в критической секции, RT-поток вытеснил этот процесс и завис на ожидении grace period). Пробовал выичтывать время до срабатывания таймера и если оно меньше 1 мс - ожидать срабатывания, не помогло. Помогает - если RT-поток сделать не RT потоком Вопрос - как избежать подобных зависаний, при том, что поток, вызывающий обновления таймера, должен быть реального времени?
  2. Похоже вы не привыкли читать посты полностью. По первым двум предложениям ответ написали или бредом называете свой ответ?
  3. Это понятно. Но, допустим, сломанная механическая пломбы тоже не может подтверждать факт вскрытия корпуса (пломбу кто-то сломал, но корпус не вскрывал). В эксплуатационной документации пишут, что нарушение пломбы снимает с производителя гарантийные обязательства. Т.е. приравняли факт нарушения пломбы к факту вмешательства в схему и ПО устройства. Вот у меня и возник вопрос, чем это регламентировано. Но, как я понял из ответа Plain, это обозначено в законодательстве страны и договоре (в виде строчек о нарушении пломбы в эксплуатационной документации) между производителем и покупателем.
  4. Идея конечно интересная, но в моем случае требует доработки - чтоб была многоразовой, и считыватель должен быть частью устройства
  5. Задачу я озвучил в самом начале - искал реле с определенным функционалом, для контроля вскрытия корпуса. Про пломбы тема пошла не от меня. Я не говорил, что отказываюсь от этих пломб. Речь о пломбах возникла процессе обсуждения, стало интересно почему программный контроль не может являться электронной пломбой со всеми юридическими гарантиями.
  6. Как-то все сложно. Можете подсказать какими документами все это нормируется и какие организации предоставляют услуги по проверке ПО и фиксации факта его заливки?
  7. А что у вас подаст сигнал на контроллер? Я предположил, что оконечный выключатель или просто кнопка, вариант - геркон. Но это тоже все механика Такие крайности я, конечно, не рассматриваю. После воды с заморозкой полагаю устройство восстановлению подлежать не будет. В любом случае любую систему безопасности можно обмануть А для чего пломбу необходимо видеть, разве нельзя написать в эксплуатационной документации, что факт вскрытия фиксируется электроникой? Почему это не может быть доказательной базой?
  8. Сейчас в моду входят "электронные пломбы" в дополнение к механическим
  9. Задача мелка, не хотел еще батарейку ставить Вместо реле придется все равно поставить оконечник времен царя гороха. А так да, про батарейку и RTC я знаю. Но в идеале батарейку ставить не хотелось бы - сильно снижает надежность устройства. Какой из вариантов надежней (оконечник + батарейка или реле без батарейки) - вопрос спорный надо считать. Но на первый взгляд реле без батарейки выглядит надежнее.
  10. Я же указал - контроль вскрытия корпуса. Цифра не будет работать без питания, а это событие должно фиксироваться и без питания
  11. Всем добрый день! Помогите найти подходящее реле для контроля вскрытия корпуса электронного устройства. От реле требуется, чтобы при отпускании управляющей кнопки реле "перекидывалось" и размыкался контакт, дальнейшее нажатие кнопки на состояние контактов не влияло, при этом возврат реле осуществлялся бы только соленоидом управления при нажатой кнопке. Напряжение управления - не более 5 В, потребление соленоида не более 0,5 Вт, нагрузочная способность контактов практически не важна. Габариты в пределах 30х20х20. Нашел наиболее близкое устройство - указательное реле РУ-21, но в нем все наоборот (соленоид перекидывает реле при не нажатой кнопке, возвращается кнопкой при отсутствии напряжения на соленоиде), а также не подходит габаритами и напряжением управления
  12. согласен, пример не удачный. В свое время решал проблему с кэшированием денных из RAM (оптимизация доступа к данным контроллером), которые не должны были кэшироваться. Спутал с оптимизацией компилятора.
  13. Да уже ничего понимать не требуется, решение вопроса на второй странице. вот потребовалась мне константа для отладки, чтобы можно было после перезагрузки платы посмотреть значение которое было до перезагрузки. Потом я ее вообще удалю. Зачем мне для нее структуру создавать? Но при этом есть массив для записи диагностической информации. И для чего мне объединять временную константу с данными диагностики. А по поводу анекдота - вариативность ситуаций может быть довольно большой. Вы это не рассматриваете? Например, расположил я данные в DTCMRAM (STM32F7), зачем их объявлять как volatile. А запись во флэш - отдельная функция, при этом чтение (копирование) данных в определенных ситуациях проще поручить ДМА
  14. Я и не спорю, что надо учитывать оптимизацию компилятора при работе с памятью, как и работу кэша. Но запись и чтение памяти не ограничивается простой операцией "а = b". Можно сделать для этого специальную функцию, в которую передаются указатели на "а" и "b", можно сделать ассемблерную вставку, можно использовать ДМА и т.п. Кстати работает такая конструкция (константа в ROM, при этом не инициализируется и volatile) __no_init const volatile uint32_t my_const @ ".const_noinit";
×
×
  • Создать...