Целесообразность тестирования памяти и регистров Опции

[Guest_Serg79_*]

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

Теперь хочу высказать свои мысли по этому поводу. Одним из главных требований выдвигаемых к программному обеспечению (ПО) для встраиваемых систем, это – контроль и проверка правильного функционирования рабочего окружения программы. К этому набору относятся, касательно микроконтроллеров AVR, регистры общего назначения (РОН), оперативно запоминающее устройство (ОЗУ), регистр состояния выполнения программы (SREG), память хранящая код программы (FLASH) и устройства с которыми работает программа (USART, ADC, TWI и т.д.).
Так что в независимости от того хочешь ты этого или не хочешь, твоя программа помимо того что должна соответствовать требованиям выдвигаемым “техническим заданием”, дополнительно должна выполнять все требования предъявляемые к ПО для встраиваемых систем.

Высказывания такого характера как: ”Да что их проверять, за всю мою долгую историю собирания разных устройств на коленка, еще не у одного контроллера не выбило ячейку памяти” или ”Этого не может быть потому что этого не может” и ”т.д.”, просто не выдерживают никакой критики.

А вот вопросы касающиеся целесообразности проверки того или иного узла микроконтроллера и глубины проверки одного взятого узла мне бы и хотелось здесь обсудить.

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

[_Pasha]

По поводу надежности программы.
Вот, я, например, никогда не допущу (в девайсе, работающем круглосуточно) использование ячейки ОЗУ для предварительно рассчитанной константы, в которую проц будет потом неделями заглядывать. Хороший пример для формулирования понятия надежной программы?

[SasaVitebsk]

По поводу надежности программы.
Вот, я, например, никогда не допущу (в девайсе, работающем круглосуточно) использование ячейки ОЗУ для предварительно рассчитанной константы, в которую проц будет потом неделями заглядывать. Хороший пример для формулирования понятия надежной программы?

Скажем так, я с этим не согласен. Ниже объясню почему. Это, кстати не относится к словам zltigo. Здесь я соглашусь. ВСЕ исключительные ситуации должны быть обработаны. Это очевидно. Более того именно программист и видит все эти ситуации. Иначе в его программе будут необработанные ветки либо упрощённый алгоритм.

Теперь возвращаясь к цитате.
Иными словами вы допускаете, что эта ячейка может быть повреждена в процессе работы? А чем она, простите, отличается от соседней? Или от ячейки стэка? А как, защититься, от повреждения стэка? Как контролировать постоянно меняющееся озу программой, которая сама меняет озу?

Программа должна быть простой и регулярной. Достаточной для реализации необходимого алгоритма. С момента, когда программа начинает жить своей жизнью - её надо просто переписывать заново.

По поводу проверок, я тоже согласен с подходом "анализ исправности чипа чипом исправность которого вызывает сомнения - нонсенс" Ну понимаю - сделать самодиагностику до старта и блокирнуться, хотя нет никакой гарантии что это произойдёт. Но теория вероятности такова, что для вас, к примеру, выход одного изделия из тысячи - 0.1%, а для клиента, который купил одно ваше изделие - 100%. Это я к тому что если от вашего изделия может взорваться снаряд (принципиально может), и вероятность этого события 0.1%, то это уже недопустимо потому, что кому-то это может стоить жизни. А значит здесь надо применять другие методы. Такие, чтобы выход из строя вашего изделия ЛЮБЫМ СПОСОБОМ не приводил к этому взрыву. Это только резервирование.

[_Pasha]

Теперь возвращаясь к цитате.
Иными словами вы допускаете, что эта ячейка может быть повреждена в процессе работы? А чем она, простите, отличается от соседней? Или от ячейки стэка? А как, защититься, от повреждения стэка? Как контролировать постоянно меняющееся озу программой, которая сама меняет озу?

У меня время жизни объектов без их регенерации сравнительно короткое. Иногда ставлю низкоприоритетный тред, который пересчитывает кое-какие "константы". И вот почему:
Сколько можно гонять/тестировать девайс? Новая ли разработка, либо просто выходной контроль - чем короче можно сделать этот процесс, тем лучше. В случае периодической калькуляции

С момента, когда программа начинает жить своей жизнью - её надо просто переписывать заново.

данный момент наступит быстрее при отладке, либо больше вероятность обнаружить некорректно работающее железо проца, если все на уровне. Если все ОК, то я могу уверенно полагать, что испытания прошли. Без организации теста наработки на сбой.

Такие, чтобы выход из строя вашего изделия ЛЮБЫМ СПОСОБОМ не приводил к этому взрыву.

Нет, я в такое не лезу. Зубками не вырос.

[SasaVitebsk]

У меня время жизни объектов без их регенерации сравнительно короткое. Иногда ставлю низкоприоритетный тред, который пересчитывает кое-какие "константы".

Я совершенно не спорю с вами я просто не знаю ответа.

Вот скажите мне при каком условии вероятность сбоя будет выше?
1) 1 раз записать ячейку - 100 млн. раз её прочитать.
2) 100 тыс. раз записать ячейку - 100 млн. раз её прочитать.

Давайте ещё один пример виртуальный с EEPROM.
Представим себе ситуацию что надо хранить 50 байт данных и периодически обновлять их.
Как надёжнее?
1) Просто записать и КС
2) Хранить 3 экземпляра и кс.
и ещё вопрос
В каком из этих вариантов EEPROM разрушится быстрее или вероятность появления ошибки выше?

[_Pasha]

Я совершенно не спорю с вами я просто не знаю ответа.
.................
В каком из этих вариантов EEPROM разрушится быстрее или вероятность появления ошибки выше?

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

Есть пример - контроллер мостовой пилы для резки гранита.
Все просто - тележка ездит вперед/назад, пила вверх/вниз и враво/влево, датчики положения (холла).
Решения - периодическая проверка живучести системного таймера, таймауты на прием сигналов датчиков. Красота... но если пила в камне, то вправо/влево включать нельзя. А как сие определить?
Проверить положение? А если что-то врет? Тогда получается некрасивая пропорция - проц за 1 доллар убивает пилу за 2000 оных. Вышли из положения - перемещения влево/вправо можно только выключить автоматом. Включить - только вручную.
Извините за оффтоп.

[Getmanov]

Конечно - это всё не праздные вопросы. И в каждом конкретном случае надо самостоятельное решение принимать. А груз ответственности велик.
Будем решать. Будем внимательнее.

Полностью согласен, достаточность мер диагностики определяет только разработчик и под свою ответственность. И на 99% вероятность аварии в его руках.
Но если вернуться к теме

Целесообразность тестирования памяти и регистров

То честно говоря не вижу в этом особого смысла, да и возможности. При включении можно проверить всё, что угодно. А как во время работы проверить ОЗУ? Остановить устройство, и записывать-считывать память, регистры и т.п.?

Есть пример - контроллер мостовой пилы для резки гранита.
Все просто - тележка ездит вперед/назад, пила вверх/вниз и враво/влево, датчики положения (холла).
Решения - периодическая проверка живучести системного таймера, таймауты на прием сигналов датчиков. Красота... но если пила в камне, то вправо/влево включать нельзя. А как сие определить?
Проверить положение? А если что-то врет? Тогда получается некрасивая пропорция - проц за 1 доллар убивает пилу за 2000 оных.

Для устройств, которые выполняют периодические действия эта задача решаема, например в ЧПУ станка такую проверку можно выполнять перед запуском программы. А если процесс непрерывный или непредсказуемый?
Да и вероятность выхода из строя ячейки памяти гораздо ниже, чем какого либо датчика, поэтому стоит обращать внимание на диагностику периферийных устройств, исходя из моего опыта, это в большой степени снижает вероятность отказа, и конечно же стоит следить за "качеством" программы написаной Вами.

[Дон Амброзио]

При включении можно проверить всё, что угодно. А как во время работы проверить ОЗУ? Остановить устройство, и записывать-считывать память, регистры и т.п.?

Как как.. Да как два пальца абосфальт.. Записал чё-нить в ОЗУ и тут же прочитал (проверил тем самым записалось ли). Не знал про такой способ?

[Getmanov]

Как как.. Да как два пальца абосфальт.. Записал чё-нить в ОЗУ и тут же прочитал (проверил тем самым записалось ли). Не знал про такой способ?

А тут же, это когда, через такт, секунду, месяц?
А ещё бывают volatile переменные, что, запрещать к ним доступ, что бы прочитать что записалось?

[EugeNNe]

А тут же, это когда, через такт, секунду, месяц?
А ещё бывают volatile переменные, что, запрещать к ним доступ, что бы прочитать что записалось?

Можно выделить сразу буфер, для проверуи памяти. Сначала проверяете его, а потом блоками перетаскиваете в него содержимое из ОЗУ, проверив определённый участок памяти, возвращаете туда то что перекидывали. Естенственно на время теста нужно вырубать прерывания. А период тестирования определяется параметрами надёжности и безопасности вашего устройства.

[_Pasha]

Сначала проверяете его, а потом блоками перетаскиваете в него содержимое из ОЗУ, проверив определённый участок памяти, возвращаете туда то что перекидывали.

Известно из работ 80-х годов по тестированию ОЗУ (конкретнее - если найду книжку - скажу) о том, что такой способ является самым грубым и не обеспечивает выявление даже половины возможных неисправностей.