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

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

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

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

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

В серии есть сбои в работе мк. раньше основная проблема была с данными в EEPROM. Кто с AVR знаком давно тот знает об этой проблеме. Решение этой проблемы программным путем особых успехов не имело. Данные в EEPROM, это заводские предустановки (калибровка) и чтобы их восстановить нужно технологическое оборудование.
Стали писать во Flash. модифицировалась базовая прошивка под конкретный прибор. Проблемы с распрограммированием ушли.
Но есть и другие отказы мк: битые порты и хрен знает что. не можем мы в него заглянуть. Думаем CRC прошивки проверять и конфигурации.
А теоритически повреждение РОНов, и пр. памяти должны вызвать сбои в алгоритме и пес не будет сбрасоваться, а мк будет.
Вопрос интересный. Кто что скажет?

Приходилось сталкиваться, начиная с 8080.
Контроль РОН и АЛУ был прописан тщательно и ни разу не дал ошибку.
Мои убеждения по обычным приборам (не спец применения):
Имеет смысл только контроль внешних устройств.
Проверка внутреннего ОЗУ невозможна в случае необходимости сохранять его содержимое или быстрого восстановления после сброса.
Проверка внутренней памяти программ имеет мало смысла поскольку программа должна работать. Статистика очень хорошая по последним 10 годам. Контрольная сумма используется только при программировании бутлоадером.
Проверка EEPROM проводится с помощью контрольной суммы блоков информации в "пользовательcком приложении".
Прибор должен иметь светодиод ошибки/индикации шевеления.

Резюме: вероятность отказа компонентов намного меньше вероятности проявления ошибки разработки, что делает контроль неэффективным.
Повторяю, все это относится к обычным приборам общепромышленного назначения, без резервирования и прочих трюков, но тем не менее не создающих повышенной опасности.

МК достаточно сложное устройство и полноценная проверка его сделает алгоритм еще более сложным, а систему соответсвенно еще более ненадежной.
Поэтому лучшим выходом является не контроль элементов системы, а контроль ее общей работоспособности.
Для этого существуют три способа.
1. Контороль целостности критических данных - CRC etc.
2. Борьба с зависанием - ватчдоги внутренние и внешние
3. Борьба с запрещенными состояниями - всевозможные аппаратные взаимоблокировки исключающие выполнение противоречивых команд даже в случае полной неработоспособности микропроцессорного модуля.

я не вижу смысла проверять целостность внутренних блоков контроллера ( используем AVR)... кроме eeprom кажется, ничего не портится

поэтому у нас "внутренние" проверки нацелены в основном на проверку целостности eeprom ( совпадения контрольной суммы) и проверку источника сброса ( в основном для детектирования аварии по питанию)

после выявления в одной их мег8 падения коэфф. усиления усилителя тактового генератора все собранные устройства тестируются на амплитуду тактового сигнала под нагрузкой в 10пф. хотя, я надеюсь, это был единичный случай.

Проверка работоспособности МК самим МК, работоспособность которого под сомнением, является прекрасным примером логического абсурда. Мало того, примитивные проверки типа 0х55-0хАА не выявят ровным счетом ничего. Если уж так хочется, то проверять нужно всю систему вместе с подключенными к ней устройствами - убедиться в целостности внешних интерфейсов, соответствия измеренных значений их областям допусков, корректности CRC/CS Flash/EEPROM. Тест, который проверит И ВЫЯВИТ некорректность функционирования ЛЮБОГО узла МК, можно попытаться написать и запускать в порядке входного контроля (отбраковки), а в рабочие системы уже ставить те МК, которые таковую отбраковку прошли, но это тоже малополезно. Грамотно и тщательно проведенное ВЫХОДНОЕ тестирование системы гораздо более эффективно, чем написание/проведение никому не нужных "академических" тестов голого МК

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

А вот у меня был реальный случай в ATMega8515 5 бит в регистре R12 (или R14 не помню точно). не всегда устанавливался в еденицу. а использовался этот регистр в прерывании там сохранялся указатель на очередь клавиатуры. Так вот глюк был совершенно смешной нажимаешь 16 раз на клавиатуре, а потом она сама еще 16 раз нажимает, и так далее...
Я запарился искать, потом когда в очередной раз поменял код все регистры сохранял в стеке и не использовал этот все работало. Написал простой тест регистров, так вот на всех платах кроме одной тест проходил.
Но такой контроллер мне попался один из нескольких тысяч.

Тоже очень больной вопрос....
У меня в одном проекте иммется тестирование сначала регистров потом озу.
кристалл м16
если косяк - зажигаю группу светодиодов
И что характерно....
наблюдал очень непонятный момент...
во первых... сколько не шил партий всегда все гладко запускалось
т.е тест проходил без ошибок
но тем не менее на одном из объектов произошел отказ
ну то се... вообщем взял конроллер на исследование..
действительно, наблюдал непрохождение теста, причем самое непонятное то, что при внешнем ресете проц запускался и работал какое то время без сбоев там 3-4 часа
потом чувствовался ватч дог или переполнение стека и проц шел на вектор ресета...
так вот...
если процу щелкнуть питанием то тест озу не проходил...
причем это наблюдалось в 100%
ну естествеено храню этот камень как дорогую реликвию - для опытов :-)
посему считаю что тест флеша и тест регистров и озу очень желеательным.

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

Добавлю свое замечание по этому вопросу.
Из опыта, ни разу не сталкивался с битым RAM или FLASH памятью AVR-ок. EEPROM, конечно, надо писать с контрольной суммой.
А вот "частично выбитые" электромагнитным импульсом (или статикой) входы мк - это было.
К примеру, лапка мк настроена на вход. Типовой (даташит) входящий ток - мка должен быть, однако в реалии - более 2 ма, чтобы ядро поняло, что на входе - лог "1". Это было следствие электростатического разряда на лапку.

Так же и в режиме работы - попробуйте поднести мощную радиостанцию к мк в режиме передачи (5 Вт будет достаточно).
Если разводка платы непродумана полностью, то мк начнет "глючить".
Если же импульс помехи будет достаточный, чтобы частично пробить защитные входные диоды и транзисторы - то деградация вывода со временем обеспечена....

Конечно, возможны "глюки" и со стороны производителя мк, когда при производстве "где-то что-то пролилось не туда" или маленькая пылинка сделала свое дело.....
Но вспомним Фуджики винчестеры серии MPG320 - когда из-за активного флюса (или промывки) жидкость через выводы проникла к кристаллу и начала его разъедать.... Миллионы винтов сдохли...

Поэтому надежность - это комплексное понятие, простым тестом не отследишь...

Любой чужой опыт, хм, дополняет мои представления.

Но такой аспект. На полупроводники сильно влияют окружающие условия. У нас на заводике все приборы тестируются в предельных рабочих режимах по температуре и напряжению. Мне кажется это гораздо важнее и эффективнее, чем прогон простейшего теста компонентов при наладке.
Вы спросите - а как же диагностика и поиск неисправности?
Отвечу. Был такой опыт на заре микроконтроллерных устройств - отдали в производство прибор, с идеальной, как казалось, диагностикой - на каждом модуле был светодиодик, который гасился только в случае успешного прохождения теста этого модуля. Оказалось, что жизнь богаче, что эта классная диагностика может давать ложные ошибки, и пропускать реальные. А обыкновенный наладчик без образования находит причину отказа проще, не вдаваясь в высшие материи.

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

НЕВЕРЮ! Ну хоть убейте не верю.

У вас выбит один бит в регистре и при этом у Вас только кнопка не работает?!!!!!!! Это чтож за программа у Вас была такая?

Если писать на ASMе и при этом программа байт 500, то тогда ещё такое возможно. Но в реальном проекте данный камень бы просто не работал! Это совершенно очевидно.



Хотелось бы услышать zltigo. Вот Вы в каждое изделие вставляете тест памяти. Сколько у вас было случаев неисправности ОЗУ? Сколько у Вас было случаев неисправности озу, при котором изделие работало, но скажем сбоило?

Ну и последний самый главный вопрос Вам как специалисту.
Можно ли написать такой тест, который в случае выхода из строя ОЗУ либо регистров в процессе работы изделия делал "проверка правильного функционирования рабочего окружения программы". Ну и если это возможно, то насколько это загрузит процессор.



На мой взгляд, о чём я и писал в предыдущей ветке, вопрос не только в возможности, но и в целесообразности! Можно всё! Но, на мой взгляд нецелесообразно. Потому, что я, кпримеру, не возьмусь за написание такой программы, которая со 100% вероятностью при неисправности озу или регистров не выполнит ЛЮБОЕ ДЕЙСТВИЕ.

Если же мы вернёмся к IBM, то думаю zltigo Вам подтвердит, что там сначала проверяется маленький участок озу и только потом запускается дальнейшее тестирование! Если привести это грубо к какому-то знаменателю, то они не гарантируют прохождение теста если не работает маленький кусочек ОЗУ и процессор в начальный момент. Работоспособность регистров должна быть обязательно. Иначе последствия непредсказуемы. Существуют у нек. МП немаскируемые вектора по ошибочной команде, тогда в принципе возможно создать систему с защитой от таких ошибок. Но это к AVR не относится.

Долго думал участвовать в обсуждении или не участвовать...
Все-таки не удержался и решил поучаствовать

Дело в том что я достаточно много времени занимался тестированием и ремонтом
памяти для PC, по этому вопросы и проблемы поднятые в этом топике мне близки и понятны...

Попробую высказаться только по сути:
- тестировать полезно (но не всегда необходимо)
- для простых тестов типа 0X55, 0xAA мы можем получить только информацию о том
что какая-то линия данных как-то не так подключена к процессору(типа иногда сбоит,
ну или что чаще бывает на модулях памяти это банальный непропай или неправильные
подтягивающие резисторы)
- для исключения ошибок по адресным линиям нужно прописывать в память
адрес тестируемой ячейки и потом сравнивать его при чтении
- для более подробного тестирования необходимо над каждой ячейкой памяти делать
сдвиговые операции
- для еще более подробного тестирования нужно прописывать блок памяти некоторыми данными,
потом производить сдвиговые операции над всем блоком памяти а затем проверять результат

- а самый простой вариант это просто прописывать некоторые данные с заранее просчитанным
CRC16/32 а затем их просто считывать и проверять CRC (в CRC сдвигов вполне хватает)

Если вы знаете, как IAR распределяет регистры, то нечего удивительного в этом нет
я же говрю этот регистр использовался только в прерывании, и не рабтала е одна клавиша а клавиатурный буфер глючил

Беру свои слова обратно. Проверил. Действительно в мелких проектах r12 почему-то не задействован под IAR.

А вот ещё какой вопрос возникает.
Все предложенные способы тестирования памяти и регистров не проверяют изменение данных со временем. Если через несколько секунд (или миллисекунд) информация изменится, то быстро пролетающие тесты ошибок не обнаружат. В конце 80-х годов мы разрабатывали промышленные контроллеры на КР580, и встретилась фантастическая неисправность процессора - регистр "Е" терял данные через несколько секунд. Если оператор вводил данные с кнопок быстро, то всё было ОК, а если задумывался, то в память записывались нули. А остальные функции прибор выполнял безукоризненно. Так как КР580 выполнен на динамических регистрах, то видимо были проблемы с их регенерацией. Контороллеры AVR вроде-бы статические, хотя где-то я читал что это не совсем так, МК плохо работали на очень низких частотах.
В нашем контексте, IMHO, необходимо осуществлять очень тщательную проверку МК и системы после изготовления, причём проверять ещё и сохранность информации во времени. А в готовом изделии тесты могут быть и простыми.

интересно, это как ?

Очень просто. Статические регистры выполнены на обычных триггерах, а динамические на конденсаторах, примерно так-же, как и RAM. Этим, кстати, и объясняется минимальная тактовая частота процессора КР580ИК80А - 500 КГц. Об этом я читал в старом журнале по электронике.

2Nanobyte

Незнаю как РОН ,но SRAM в AVR указано явно хотя КР580ИК80А для меня загадка природы

2all

Теперь насчет целесообразности
Вот у меня такое неподобство - за день трижды слетела прошивка EEPROM в AVR,ну вот и какой толк от этого тестирования ?
Лично для меня ответ только один - если в нем хранятся ответственные данные , изменение которых может привести к физической поломке МК ,периферии или механического устройства которым управляет МК и т.д., но в любом случае или мы вынуждены устройство останавливать ,весело могая лямпочкой или оно само по себе уйдет в ступор- ситуации это особо не меняет ,полюбому нужно ремонтировать или что боллее актуально - задумываешся над способами как можно увеличить надежноть работы.
Тоесть думаеш уже над переносом данных во ФЛЕШ ,помехозащищеностью и написанию промежуточных технологических прошивок для настроек и калибровок ну на крайняк уже камни другие пробовать ,что меня особо не радует

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


О-о-о, вы много потеряли Всё познаётся в сравнении. Со слезами вспоминаются те трюки, котрые приходилось делать, используя этот CPU, чтобы получить эквивалент нескольких команд AVR. А уж ввод/вывод был просто Но до сих пор использую некоторые собранные на этом CPU приборы. А некоторые УФ ПЗУ (573РФ1, 573 РФ2) записаны 22 года назад (200 000 часов), и еще нормально работают. Вот это была надёжность!!!

Ну я все свои изделия не вижу . Для встроенной RAM никогда лично не видел, а для внешней, когда завод производитель укомплектовал 5V вместо 3V памятью девайсы работали до нескольких часов, но сбоили. Попадалась опять-таки партия чипов которые с ADSP жить не хотели без глюков.

Разумеется нет, но некоторое приближение получить можно.

Тестирование там начинается примерно на 4-5 команде (первые там запрет NMI), когда генерится импульс старшим битом 60h порта после чего там остается "1". Дальлее инициализация Video, периферии, таймеров (у первых IBM регенерация памяти была софтовая по таймеру), DMA.. между всеми этими операциями наращивался счетчик в 60h порту. После инициализации второго канала таймера уже можно было и попищать. И где-то уже потом-потом тестировалось 16K памяти, инициализация стека и понеслось... Причем 16K были выбраны не как минимально необходимые для тестирования, а как минимально гарантированные в наличии (во времена были!).

Как следует из вышеизложенного тесты у IBM идут и до "появления" RAM.

Можно проверить CRC EEPOM и FLASH, как самые вероятные причины отказов. Остальное проверить сложно и малополезно и нет 100% вероятности выявления неисправности. И вообщем то с переходом на импортные микросхемы дефекты стали настолько редки, что про тестирование процессора можно и забыть. Лучше обратить внимание на качество остальных элементов, особенно электролитических конденсаторов. Нонэйм электролиты, качество пайки, тепловые и электрические режимы - вот теперь на что смотреть надо.

Совершенно согласен. Безусловно если есть внешние элементы (в том числе и память) то проверять можно и даже нужно. Желательно тесты памяти использовать как предлагалось. То есть динамический тест с записью данных в ОЗУ по определённому алгоритму а потом сравнение. Ну и диагональные. Статические тесты, как правило показывают только полную неработоспособность памяти в целом.

Я, если есть возможность, и при сложной задаче, иногда её разбиваю на модули. Каждый со своим МК. Связь по последовательному интерфейсу. Как правило такие системы работают надёжнее чем один МК со сложной обвеской. (если не использовать ПЛМ). Да и разрабатывать полегче.

Хочу сказать свои два слова.
В общем случае различают диагностику и тестирование (в литературе встречаются и другие определения). Суть тестирования проверка программно-аппаратных средств в использованиии специально подобранного (искусственного) набора тестов, данных, сигналов и т.д., что требует (как правило) прерывания выполнения основного алгоритма со всеми вытекающими последствиями. Суть диагностики - оценка правильности функционирования программно-аппаратных средств на реальном (текущем) наборе сигналов, данных и т.д. (гапример выход считанных данных за границы, проверка промужуточных (конечных) данных на недопустимые занчения и т.д.), что не требует (как правило) прерывания выполнения основного алгоритма. Очевидно, в общем случае, эффективность тестирования выше, чем диагностики, но требует больше вычислительных, а зачастую и аппаратных ресурсов.
В своей практике применяю и тестирование и диагностику. Как правило, тестирование проводится при запуске системы (прибора) и по команде оператора при возникновении подозрения на ту или иную несиправность (её определение и локализация). Диагностика проводится постоянно, по ряду ключевых параметров, точек алгоритма, сигналов и т.д. Глубину тестирования и диагностики необходимо выбирать исходя из назначения системы, объема её программных и аппаратных средств, стоимости и т.д. В общем задача творческая.

Очевидно, при проведении как диагностик, так и тестирования можно говорить только о вероятности определения той или иной несиправности, тем более о вероятности общего нормального функционирования программно-аппаратных средств.

Для средненькой прооверки памяти AVR польззовал следующий тест:
1. Все 0
2 Все 1
3 Шагающая 1
4 Шагающий 0
5 Random

Вроде как работало неплохо.

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

Для любой встроенной системы, имеет смысл тестировать EEPROM(для AVR), так как в ней наиболее часто происходят сбои, тестировать регистры(таймеры, АЦП, USART и т.п.) не имеет смысла потому, что с нерабочими регистрами устройство просто не пройдёт выходной контроль. В процессе работы есть смысл проверять связь с внешними устройствами (хотя это происходит само собой, если не использовать задержку вместо ожидания готовности устройства). Гораздо важнее обеспечить "Безопастное состояние" устройства после/вовремя сбоя. Например в случае выхода из строя источника тактирования процессора никакие тесты не помогут, а установка второго МК для контроля основного приводит к вопросу "Кто будет сторожить сторожей?".
Последнее не относится к задачам где требуется резервирование, это отдельная и сложная тема.

Входной-то контроль может вполне вероятно, что они и проходят, но не факт, что какой-то из модулей MCU не выйдет из строя после 10 лет эксплуатации.. Поэтому тестировать надо

Как Вы считаете, что более надёжно:

1) Вероятность сбоя устройства равна 10 в минус 9 степени; вероятность того, что этот сбой система не обнаружит (не зарегистрирует) и соотвтетственно не предпримит ни каких мер равна 50%
2) Вероятность сбоя устройства равна 10 в минус 3 степени; вероятность того, что этот сбой система не обнаружит (не зарегистрирует) и соотвтетственно не предпримит ни каких мер равна 0,0000001%

И что более надёжно? "Надёжная" система, сбои которой просто не обнаруживаются
или "ненадёжная" система, у которой 99,99999999% сбоев обнаруживаются и предпринимаются соответствующие меры по устранению их последствий


Как говорится: лучше перебдеть, чем недобдеть

Насчёт тестов считаю, что они полезны, но не особо. Хотя сам во время работы CRC32 программы всё время считаю (в фоновом режиме).
Но вот то, что интересно:
Никто из авторов про ЛОГ-и даже и не упомянул! А без логов все эти тесты - фикция.
Тест только во время работы полезен. На производстве выходной контроль д.б., а это почище любого теста будет!
Ну так вот - произошло что-то во время работы . Тест там что-то накопал, или просто процессор по собаке перезапустился, и снова все работает. Никто об этом и не узнал! Ну, может оператор нецензурно выругался, питание выключил-включил и забыл об этом. В худшем случае питание само выключилось (может по всему городу). И всё - все концы в воду!
Некоторые горе-разработчики этому даже рады будут! Они ничего не докажут - мы ни в чём не признаемся!
Так вот я считаю - тесты только тогда полезны, когда логи есть. А вот логи - они и без тестов полезны. И заменяют их во многих случаях (если не во всех).

Но насчёт логов - это уже другая тема. Может организуем? Я бы поддержал.

Я не упомянул про логи, потому что считал ведение логов само собой разумеющимся... Результаты POWER_ON-теста и самотестирования и самодиагностики во время работы девайса разумеется должны быть так или иначе донесены до человека (или выодом на экран или записью в энергонезависимый архив)

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

Могу сделать вывод, что диагностика работы обязательна, но без фанатизма.

Для устройств которые обеспечивают надёжность 99.9(9)% надо использовать какой-нибудь ПЛК с горячим резервированием, а не городить огород из МК.

Особенно если учесть тот факт, что стоимость младших моделей МК опустилась ниже 1$, а стоимость средних 32-ух битников ниже 10$. При этом стоимость оборудования обычно превышает 100, а при высоком требовании к надёжности будет от 1000 и выше.

При таком соотношении можно создавать высоконадёжное оборудование с элементами тестирования и резервирования. Либо применяя ПЛМ либо дробя устройство на кучу мелких интелектуальных оконечных устройств с резервированием. Естественно всё зависит от задачи. Естественно, что при этом будет учитываться и надёжность компонентов, в том числе и МК

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

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

Стиральная доска всегда надёжнее чем стиральная машина. Чем сложнее система, тем она менее надёжна. Это относится и к программному обеспечению, хотя и в меньшей степени.

А вот как раз и нет. Сбой оборудования не должен вызывать сбоя в программе, иначе это ПЛОХАЯ программа.

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

Да? А случайный джамп не вызовет сбоя в программе? И искжение данных в ОЗУ? Почитайте тут
http://electronix.ru/forum/index.php?showt...mp;#entry365890


Согласен..А к чему Вы это сказали?



Да Вы мне прям Америку открыли


Повторяю. Нормально написаннная программа без ошибок просто так не сбоит. Если программа сбоит (ПРАВИЛЬНАЯ ПРОГРАММА) значит железо сбойнуло


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

Абсолютно правильные слова - подпишусь под каждым. Неуклонно следую принципу, что в правильно написанной системе кода, который занимается разборками с нештатными ситуациями должно быть как минимум сопоставимое количество с рабочим кодом. Watchdоg, для защиты от программых ошибок это вообще абсолютный моветон. Однако, весь, извинте, буду грубым, бред, который в соседней ветке и тут выплескивается не соответствует первым-же словам Вашего постулата "если алгоритм корректный" - ну нет корекных алгоритмов работы программ в неисправных машинах. И "кодирование без ошибок" - занимаясь всей этой надуманной фигней написать код без ошибок становится невероятной задачей, для сколь-нибудь РЕАЛЬНОГО приложения, а не кунштюковской демки.

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

Что Вы имеете в виду под железом? Если только МК то согласен, если весь комплекс,то нет!

Соглашусь, что этот пример хорош, но только в том случае, если эта константа вообще не меняется. Если она периодически меняется - я буду её в ОЗУ хранить. Но и её инверсию тоже. И при "заглядывании" их ксорить и на FFFFFFFF проверять.

Если при разработки Embedded-программы, предназначенной для использования в устройствах, которые может быть годами должны работать без вмешательства человека Вы в коде программы не предусмотрели реакции на отказы тех или иных узлов, то, ИМХО, это программа не правильная и устанавливать её на девайс, ИМХО, преступление


Даже лучше так сказать: "если при разработке алгоритма программы Вы не учли возможные сбои в работе устройства, и не заложили в алгоритм их обнаружение(детектирование) и устранение их последствий..."

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

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

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

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

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



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


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

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

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

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

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

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

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

Скажем в таких приложениях никто не заставляет AVR применять, хотя с другой стороны если проц за 1$ это ещё не значит что он не надёжный. К тому же резервирование на процессорах за 1$ будет стоить дешевле естественно с точки зрения аппаратной части. А вот разработка программного обеспечения - будет трудоёмким. (Я естественно не призываю - так - вариант)

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

Будем решать. Будем внимательнее.

Брат объявился!
Про пилу - это дела минувших дней.
А про Вашу тему - сейчас то же самое делаю по синхронному движению.
В личку можно?

На то она и личка