реклама на сайте
подробности

 
 
2 страниц V  < 1 2  
Reply to this topicStart new topic
> Минимизация проверки ячейки памяти
Guest_Serg79_*
сообщение Apr 28 2007, 10:00
Сообщение #16





Guests






Для тех кто в танке или для тех кто не читал первый топик повторю еще раз:
Цитата(Serg79 @ Apr 26 2007, 09:29) *
P.s. Здесь не обсуждается вопрос целесообразности всех этих проверок. Главная подымаемая здесь тема, это найти оптимальное решение для данной задачи. Так что, прошу не флеймить. Заранее всех благодарю. smile.gif
А для тех, кто хочет и дальше продолжить обсуждение вопроса целесообразности проведения тестов памяти, прошу высказывать ваши мысли в следующей теме: Целесообразность тестирования памяти и регистров.


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

mov r0, r16
mov r1, r16
...
mov r14, r16
mov r15, r16

com r0
com r1
...
com r14
com r15

sub r0, r1
1: brne 1b
...
sub r14, r15
1: brne 1b

Таким образом, на 16 регистров получается 49 команд, что равно 3.0625 команды на один регистр. Так же важно то, что размер каждой используемой здесь команды составляет одно слово (2 байта) и время выполнения один такт. И так, для проверки первой половины РОН нам потребуется 98 байт FLASH-памяти и 49 тактов микроконтроллера (что на мой взгляд, довольно не плохо).
У кого есть мысли по дальнейшей минимизации данной процедуры, прошу высказывать свои идеи.
Go to the top of the page
 
+Quote Post
CDT
сообщение Apr 28 2007, 14:30
Сообщение #17


Местный
***

Группа: Свой
Сообщений: 303
Регистрация: 3-03-05
Пользователь №: 3 044



Цитата(Serg79 @ Apr 28 2007, 10:00) *
Здесь не обсуждается вопрос целесообразности всех этих проверок. Главная подымаемая здесь тема, это найти оптимальное решение для данной задачи.

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

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

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


--------------------
Опыт - чудесная вещь: легко использовать, можно продать, трудно пропить.
Go to the top of the page
 
+Quote Post
Дон Амброзио
сообщение Feb 11 2008, 18:24
Сообщение #18


Местный
***

Группа: Участник*
Сообщений: 323
Регистрация: 11-02-08
Пользователь №: 34 947



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



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


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

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

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


--------------------
После устранения бага в программе она стала работать....хуже
Go to the top of the page
 
+Quote Post

2 страниц V  < 1 2
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 17th July 2025 - 22:34
Рейтинг@Mail.ru


Страница сгенерированна за 0.01383 секунд с 7
ELECTRONIX ©2004-2016