[SapegoAL 0]

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

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

 

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

[Nanobyte 0]

А вот ещё какой вопрос возникает.

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

В нашем контексте, IMHO, необходимо осуществлять очень тщательную проверку МК и системы после изготовления, причём проверять ещё и сохранность информации во времени. А в готовом изделии тесты могут быть и простыми.

[umup 0]

Так как КР580 выполнен на динамических регистрах

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

[Nanobyte 0]

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

[bodja74 0]

2Nanobyte

 

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

 

2all

 

Теперь насчет целесообразности

Вот у меня такое неподобство - за день трижды слетела прошивка EEPROM в AVR,ну вот и какой толк от этого тестирования ?

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

Тоесть думаеш уже над переносом данных во ФЛЕШ ,помехозащищеностью и написанию промежуточных технологических прошивок для настроек и калибровок ну на крайняк уже камни другие пробовать ,что меня особо не радует :)

[Nanobyte 0]

...Незнаю как РОН ,но SRAM в AVR указано явно...

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

:bb-offtopic:

...хотя КР580ИК80А для меня загадка природы :)

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

[zltigo 0]

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

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

Можно ли написать такой тест...

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

Если же мы вернёмся к IBM, то думаю zltigo Вам подтвердит, что там сначала проверяется маленький участок озу и только потом запускается дальнейшее тестирование!

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

Если привести это грубо к какому-то знаменателю, то они не гарантируют прохождение теста если не работает маленький кусочек ОЗУ и процессор в начальный момент.

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

[slog 0]

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

[SapegoAL 0]

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

 

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

 

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

[ПАВ 0]

Хочу сказать свои два слова.

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

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

 

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

[klop 0]

Для средненькой прооверки памяти AVR польззовал следующий тест:

1. Все 0

2 Все 1

3 Шагающая 1

4 Шагающий 0

5 Random

 

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

[Don_Ambrosio 0]

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

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

[Getmanov 0]

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

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

[Don_Ambrosio 0]

тестировать регистры(таймеры, АЦП, USART и т.п.) не имеет смысла потому, что с нерабочими регистрами устройство просто не пройдёт выходной контроль.

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

 

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

 

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

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

 

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

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

 

 

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

[galjoen 0]

Насчёт тестов считаю, что они полезны, но не особо. Хотя сам во время работы CRC32 программы всё время считаю (в фоновом режиме).

Но вот то, что интересно:

Никто из авторов про ЛОГ-и даже и не упомянул! А без логов все эти тесты - фикция.

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

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

Некоторые горе-разработчики этому даже рады будут! Они ничего не докажут - мы ни в чём не признаемся!

Так вот я считаю - тесты только тогда полезны, когда логи есть. А вот логи - они и без тестов полезны. И заменяют их во многих случаях (если не во всех).

 

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