Требуется проверять правильную работу регистров общего назначения (РОН) и оперативной памяти (ОЗУ) двумя значениями: 0x55 (01010101b) и 0xAA (10101010b). Вопрос заключается в том, что бы сделать это с минимальным количеством используемых команд (это значит максимальное быстродействие и минимально занимаемое место во FLASH).

Для 16 старших РОН (r16-r31) удалось все свести к четырем командам:

Я так думаю, дополнительно минимизировать проверку 16 старших РОН, уже не представляется возможным (все таки через ячейку памяти надо прогнать два значения).

А вот для первой половины РОН и ячеек памяти ОЗУ у меня такого однозначного решения нет. Вот и обращаюсь к коллективному разуму, что бы общими силами найти самое что ни есть оптимальное решение этой задачи.

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

да, странная задачка?! непонятно зачем собственно делать финт ушами?!
Все тоже самое только перед проверкой младших регистров записать в два старших регистра значения 0х55,0хаа. т.е. так:

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

Или проверять в шахматном порядке
для R0 и R16 соответственно:

и т.д. перебрать по парам.

Можно конечно ответить и на конкретно поставленный пример, на сама постановка задачи практически бессмысленна.

Почитайте принципы тестирования памяти. (Как правило означенные методы не применяются). И второе. Сколько раз я пытался тестировать внутренние регистры и встроенную память МП и МК, не разу не было случая, чтобы это дало хоть какой-нибудь результат. Оно в принципе и понятно. Поэтому рекомендую отказаться от данного теста, а для успокоения души примените просто расширенный тест оборудования.

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

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

1) Проверить r28-r31 как написано у автора

2) Проверить участок памяти от 0х000 до 0х01С (соответствует памяти регистров) как-то так

Код

mcheck: ld    z,r29
        st    r28,z+
        cp    r28,r29

3) Проверить участок памяти от 0х060 до RAMEND (соответствует оперативной памяти)

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

Когда-то давным-давно занимался тестированием советской статической памяти. Это была память экрана дисплея. Иногда наблюдалось взаимовлияние ячеек памяти. Обычные тесты (восьмикратное запись-считывание) ошибку не обнаруживали. Был написан сложный тест, в котором данные записывались по сложному закону с изменяемым интервалом между ячейками с одинаковой информацией. Время записи-считывания 2К - десятки миллисекунд. Иногда ошибка происходила через 40-50 минут после запуск теста.
Морал. Не хватает памяти - исключите тест памяти вообще.
Гложет совесть - проверяйте одну ячейку

>> Требуется проверять правильную работу регистров общего назначения (РОН) и оперативной памяти (ОЗУ) двумя значениями: 0x55 (01010101b) и 0xAA (10101010b). Вопрос заключается в том, что бы сделать это с минимальным количеством используемых команд (это значит максимальное быстродействие и минимально занимаемое место во FLASH).

Кто из нас РОНы РОНами называет и расшифровывает окружающим слово "ОЗУ " и hex-код? Правильно, студент. Судя по формулировке, задача чисто академическая. Более того, некий вариант этой процедуры, видимо, уже есть и задачей курсовой работы является создание более оптимального/короткого кода. Так что, не выпендривайтесь, смысленно/бессмысленно, а код выкладывайте )))

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

Если все мои догадки бред, то прощу прощения...

Гложет совесть - напишите 2 коментария перед началом программы:
// registers ok
// mem ok

К тому же и результат будет тот же.


Ушло уже в прошлое то время когда регистры надо было проверять! Чё за ним бегать?
Мы продаём компы. Городок небольшой, но доходит до 50 компов в месяц. За 4 года продаж из строя вышло 2 процессора. И то по вине пользователей.

Если память внутри МК накроется, то Вы об этом узнаете. Можете не волноваться.

А вы слыхали про такое:
"Концепция безопасных микроэлектронных систем: одиночные дефекты аппаратных и программных средств не должны приводить к опасным отказам и должны обнаруживаться с заданной вероятностью на рабочих или тестовых воздействиях не позднее чем в системе возникнет второй дефект".

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

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

Так надёжную систему не построить.

Напрашивается маленькая аналогия - построение надёжного ключа из ненадёжных элементов. Скажем, на 4 транзисторных ключах с лямбда отказа 1Е-7 построить ключ с лямбдой отказа 1Е-12. Очень просто - соединяете два ключа последовательно в цепь, а две такие цепи соединяете параллельно.

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

Вот, кстати, еще вспомнил пример, с Инмарсатовской группировкой. Она состоит из 3-4 спутников в одной точке стояния. Один спутник работает, второй стоит в горячем резерве (по-моему, порядка 5 минут готовность, надо уточнять), а третий - в холодном. Дорогое удовольствие, но когда речь идёт о спасении на море жизней сотен или тысяч человек, оно того стоит.

А вы просто подумайте головой.
1) Если у вас выйдет из строя память, где размещены регистры общего назначения, то до теста памяти дело не дойдёт. (И область стека кстати тоже)
2) Вероятность того что у вас выйдет из строя одна ячейка памяти не в регистровой области - близка к нулю.
3) При тестировании флэша и EEPROM в принципе серьёзные хомуты с неработоспособностью железа должны проявится.
4) При правильном написании программы неработоспособность ячейки памяти, должна в конечном итоге приводить к вылету, который может быть обнаружен.

С другой стороны. В 99% случаев (я уверен в этом) при нарушении работы памяти, нет способа блокировать работу программы. Таким образом одним микропроцессором в безопасных системах точно не обойтись. На это существуют системы резервирования. Примеры привёл уважаемый GM.



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

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

Иными словами грамотно написанный вачдог в 5 раз полезнее начального тестирования.

Всё это моё личное мнение, основанное на моих задачах. Конечно в каждом конкретном случае надо решать самому.

Вообще говоря, надёжность и безопасность не совсем одно и тоже. Ситема может быть ненадёжна, но безопасна. НАДЁЖНОСТЬ = БЕЗОПАСНОСТЬ только в том случае, если к опасным последствиям приводит выход из строя любого элементарного элемента системы. В реальных системах при средней наработке на отказ 30000 - 50000 тыс. часов. интенсивность опасного отказа системы должна составлять 10^-10 - 10^-11. Безопасную систему трудно построить на одном процессоре. Применяються дублированные и троированные системы в которых производиться параллельная обработка информации. Производиться сравнение (или мажоритирование конечных результатов). Это ни есть резервирование. Тестироваться в системе должно ВСЁ. Программы в процессорах должны быть самопроверяемы. Производяться тесты всех переферийных узлов процессоров.
Транзисторные ключи не применяються для включения исполнительных устройств. Хоть тысячу соедини и последовательно-парралельно. Любой полупроводниковый компонент является элементом с симметричным отказом, т.е. в случае выхода из строя, например диод, примерно с равной степенью вероятности может оказаться в состоянии пробоя или замыкания.

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

Для тех кто в танке или для тех кто не читал первый топик повторю еще раз:
А для тех, кто хочет и дальше продолжить обсуждение вопроса целесообразности проведения тестов памяти, прошу высказывать ваши мысли в следующей теме: Целесообразность тестирования памяти и регистров.


Теперь по существу.
Вот что мне удалось придумать для первой половины РОН (r0-r15):

Таким образом, на 16 регистров получается 49 команд, что равно 3.0625 команды на один регистр. Так же важно то, что размер каждой используемой здесь команды составляет одно слово (2 байта) и время выполнения один такт. И так, для проверки первой половины РОН нам потребуется 98 байт FLASH-памяти и 49 тактов микроконтроллера (что на мой взгляд, довольно не плохо).
У кого есть мысли по дальнейшей минимизации данной процедуры, прошу высказывать свои идеи.

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

Тогда начали думать о тестировании и изучать алгоритмы этого дела.
В итоге пришли к выводу, что идеальный вариант - это записать в память массив случайного набора данных несколько раз, со сдвигом по адресам с шагом 1-3-5-7.... (потом, естественно, считать и сравнить). А случайный массив лежит рядом: это программный код.
Можно еще случайный массив по битам подвигать или еще как поизвращаться.

Но запись $55/$AA не эффективна абсолютно (если заглянуть внутрь конкретной памяти, то тест $55/$AA пройдет безупречно, когда в памяти останется одна живая ячейка, а адреса перебираться не будут).

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


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

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

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