| |
|
  |
 Целесообразность тестирования памяти и регистров |
|
|
|
Guest_Serg79_*
|
 Apr 28 2007, 09:57
|
Guests
|
В данной теме мне хотелось бы обсудить вопрос целесообразности проведения тестирований памяти и регистров микроконтроллера.
Теперь хочу высказать свои мысли по этому поводу. Одним из главных требований выдвигаемых к программному обеспечению (ПО) для встраиваемых систем, это – контроль и проверка правильного функционирования рабочего окружения программы. К этому набору относятся, касательно микроконтроллеров AVR, регистры общего назначения (РОН), оперативно запоминающее устройство (ОЗУ), регистр состояния выполнения программы (SREG), память хранящая код программы (FLASH) и устройства с которыми работает программа (USART, ADC, TWI и т.д.).
Так что в независимости от того хочешь ты этого или не хочешь, твоя программа помимо того что должна соответствовать требованиям выдвигаемым “техническим заданием”, дополнительно должна выполнять все требования предъявляемые к ПО для встраиваемых систем.
Высказывания такого характера как: ”Да что их проверять, за всю мою долгую историю собирания разных устройств на коленка, еще не у одного контроллера не выбило ячейку памяти” или ”Этого не может быть потому что этого не может” и ”т.д.”, просто не выдерживают никакой критики.
А вот вопросы касающиеся целесообразности проверки того или иного узла микроконтроллера и глубины проверки одного взятого узла мне бы и хотелось здесь обсудить.
Вот я и хочу услышать мнение тех людей, которым приходилось сталкиваться с данными вопросами, а так же послушать их высказывания по этому поводу и методы решения этих проблем.
|
|
|
|
|
|
|
|
Apr 28 2007, 10:35
|
Гуру
Группа: Свой
Сообщений: 2 702
Регистрация: 14-07-06
Пользователь №: 18 823
|
Цитата(Serg79 @ Apr 28 2007, 09:57)  В данной теме мне хотелось бы обсудить вопрос целесообразности проведения тестирований памяти и регистров микроконтроллера.
...
Вот я и хочу услышать мнение тех людей, которым приходилось сталкиваться с данными вопросами, а так же послушать их высказывания по этому поводу и методы решения этих проблем. Приходилось сталкиваться, начиная с 8080. Контроль РОН и АЛУ был прописан тщательно и ни разу не дал ошибку. Мои убеждения по обычным приборам (не спец применения): Имеет смысл только контроль внешних устройств. Проверка внутреннего ОЗУ невозможна в случае необходимости сохранять его содержимое или быстрого восстановления после сброса. Проверка внутренней памяти программ имеет мало смысла поскольку программа должна работать. Статистика очень хорошая по последним 10 годам. Контрольная сумма используется только при программировании бутлоадером. Проверка EEPROM проводится с помощью контрольной суммы блоков информации в "пользовательcком приложении". Прибор должен иметь светодиод ошибки/индикации шевеления. Резюме: вероятность отказа компонентов намного меньше вероятности проявления ошибки разработки, что делает контроль неэффективным. Повторяю, все это относится к обычным приборам общепромышленного назначения, без резервирования и прочих трюков, но тем не менее не создающих повышенной опасности.
--------------------
Уходя, оставьте свет...
|
|
|
|
|
|
|
Guest_=AVR=_*
|
Apr 28 2007, 11:23
|
Guests
|
Проверка работоспособности МК самим МК, работоспособность которого под сомнением, является прекрасным примером логического абсурда. Мало того, примитивные проверки типа 0х55-0хАА не выявят ровным счетом ничего. Если уж так хочется, то проверять нужно всю систему вместе с подключенными к ней устройствами - убедиться в целостности внешних интерфейсов, соответствия измеренных значений их областям допусков, корректности CRC/CS Flash/EEPROM. Тест, который проверит И ВЫЯВИТ некорректность функционирования ЛЮБОГО узла МК, можно попытаться написать и запускать в порядке входного контроля (отбраковки), а в рабочие системы уже ставить те МК, которые таковую отбраковку прошли, но это тоже малополезно. Грамотно и тщательно проведенное ВЫХОДНОЕ тестирование системы гораздо более эффективно, чем написание/проведение никому не нужных "академических" тестов голого МК
|
|
|
|
|
|
|
|
Apr 29 2007, 13:06
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(=AVR= @ Apr 28 2007, 11:23) Проверка работоспособности МК самим МК, работоспособность которого под сомнением, является прекрасным примером логического абсурда. Самоконтроль сам-себя совершенно обыденное явление. Для процессоров на рассыпухе это было проcто абсолютно обязательной процедурой. С переходом на микропроцессоры это как-то от конечного пользователя стало скрыто, но тем не менее даже для первых интеловских микропроцессоров существовали официально раздаваемые пользователям диагностические программы постепенно от простого к сложному, базируясь на уже проверенном проверяющие ядро. Да и сейчас, ка Вы полагаете тестируются контроллеры у производителя  ? По нынешним временам тестом ядра не занимаюсь, но памяти тестирую обязательно. Диагностика встроенной внешней периферии - тоже. Привычка когда-то десять лет занимался диагностическим оборудованием для производства коммутационной техники.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Apr 29 2007, 14:53
|
Частый гость
Группа: Свой
Сообщений: 117
Регистрация: 6-07-05
Из: Белгород
Пользователь №: 6 575
|
Добавлю свое замечание по этому вопросу.
Из опыта, ни разу не сталкивался с битым RAM или FLASH памятью AVR-ок. EEPROM, конечно, надо писать с контрольной суммой.
А вот "частично выбитые" электромагнитным импульсом (или статикой) входы мк - это было.
К примеру, лапка мк настроена на вход. Типовой (даташит) входящий ток - мка должен быть, однако в реалии - более 2 ма, чтобы ядро поняло, что на входе - лог "1". Это было следствие электростатического разряда на лапку.
Так же и в режиме работы - попробуйте поднести мощную радиостанцию к мк в режиме передачи (5 Вт будет достаточно).
Если разводка платы непродумана полностью, то мк начнет "глючить".
Если же импульс помехи будет достаточный, чтобы частично пробить защитные входные диоды и транзисторы - то деградация вывода со временем обеспечена....
Конечно, возможны "глюки" и со стороны производителя мк, когда при производстве "где-то что-то пролилось не туда" или маленькая пылинка сделала свое дело.....
Но вспомним Фуджики винчестеры серии MPG320 - когда из-за активного флюса (или промывки) жидкость через выводы проникла к кристаллу и начала его разъедать.... Миллионы винтов сдохли...
Поэтому надежность - это комплексное понятие, простым тестом не отследишь...
|
|
|
|
|
|
|
|
Apr 29 2007, 19:50
|
Гуру
Группа: Свой
Сообщений: 2 702
Регистрация: 14-07-06
Пользователь №: 18 823
|
Цитата(Kovrov @ Apr 29 2007, 12:46) Тоже очень больной вопрос....
...
посему считаю что тест флеша и тест регистров и озу очень желеательным. Любой чужой опыт, хм, дополняет мои представления. Но такой аспект. На полупроводники сильно влияют окружающие условия. У нас на заводике все приборы тестируются в предельных рабочих режимах по температуре и напряжению. Мне кажется это гораздо важнее и эффективнее, чем прогон простейшего теста компонентов при наладке. Вы спросите - а как же диагностика и поиск неисправности? Отвечу. Был такой опыт на заре микроконтроллерных устройств - отдали в производство прибор, с идеальной, как казалось, диагностикой - на каждом модуле был светодиодик, который гасился только в случае успешного прохождения теста этого модуля. Оказалось, что жизнь богаче, что эта классная диагностика может давать ложные ошибки, и пропускать реальные. А обыкновенный наладчик без образования находит причину отказа проще, не вдаваясь в высшие материи. Поэтому вопрос о цене вопроса (сорри за каламбур). Ну, отказал контроллер, ну выкинули его, дальше работаем. В приведенном случае он отказал уже у клиента. И какая разница, что показала диагностика. Отказ то произошел.
--------------------
Уходя, оставьте свет...
|
|
|
|
|
|
|
|
Apr 30 2007, 00:35
|
Гуру
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521
|
Цитата(KRS @ Apr 28 2007, 12:58) А вот у меня был реальный случай в ATMega8515 5 бит в регистре R12 (или R14 не помню точно). не всегда устанавливался в еденицу. а использовался этот регистр в прерывании там сохранялся указатель на очередь клавиатуры. Так вот глюк был совершенно смешной нажимаешь 16 раз на клавиатуре, а потом она сама еще 16 раз нажимает, и так далее...
Я запарился искать, потом когда в очередной раз поменял код все регистры сохранял в стеке и не использовал этот все работало. Написал простой тест регистров, так вот на всех платах кроме одной тест проходил.
Но такой контроллер мне попался один из нескольких тысяч. НЕВЕРЮ! Ну хоть убейте не верю. У вас выбит один бит в регистре и при этом у Вас только кнопка не работает?!!!!!!! Это чтож за программа у Вас была такая? Если писать на ASMе и при этом программа байт 500, то тогда ещё такое возможно. Но в реальном проекте данный камень бы просто не работал! Это совершенно очевидно. Хотелось бы услышать zltigo. Вот Вы в каждое изделие вставляете тест памяти. Сколько у вас было случаев неисправности ОЗУ? Сколько у Вас было случаев неисправности озу, при котором изделие работало, но скажем сбоило? Ну и последний самый главный вопрос Вам как специалисту. Можно ли написать такой тест, который в случае выхода из строя ОЗУ либо регистров в процессе работы изделия делал "проверка правильного функционирования рабочего окружения программы". Ну и если это возможно, то насколько это загрузит процессор. На мой взгляд, о чём я и писал в предыдущей ветке, вопрос не только в возможности, но и в целесообразности! Можно всё! Но, на мой взгляд нецелесообразно. Потому, что я, кпримеру, не возьмусь за написание такой программы, которая со 100% вероятностью при неисправности озу или регистров не выполнит ЛЮБОЕ ДЕЙСТВИЕ. Если же мы вернёмся к IBM, то думаю zltigo Вам подтвердит, что там сначала проверяется маленький участок озу и только потом запускается дальнейшее тестирование! Если привести это грубо к какому-то знаменателю, то они не гарантируют прохождение теста если не работает маленький кусочек ОЗУ и процессор в начальный момент. Работоспособность регистров должна быть обязательно. Иначе последствия непредсказуемы. Существуют у нек. МП немаскируемые вектора по ошибочной команде, тогда в принципе возможно создать систему с защитой от таких ошибок. Но это к AVR не относится.
|
|
|
|
|
|
|
|
Apr 30 2007, 00:55
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Долго думал участвовать в обсуждении или не участвовать... Все-таки не удержался и решил поучаствовать Дело в том что я достаточно много времени занимался тестированием и ремонтом памяти для PC, по этому вопросы и проблемы поднятые в этом топике мне близки и понятны... Попробую высказаться только по сути: - тестировать полезно (но не всегда необходимо) - для простых тестов типа 0X55, 0xAA мы можем получить только информацию о том что какая-то линия данных как-то не так подключена к процессору(типа иногда сбоит, ну или что чаще бывает на модулях памяти это банальный непропай или неправильные подтягивающие резисторы) - для исключения ошибок по адресным линиям нужно прописывать в память адрес тестируемой ячейки и потом сравнивать его при чтении - для более подробного тестирования необходимо над каждой ячейкой памяти делать сдвиговые операции - для еще более подробного тестирования нужно прописывать блок памяти некоторыми данными, потом производить сдвиговые операции над всем блоком памяти а затем проверять результат - а самый простой вариант это просто прописывать некоторые данные с заранее просчитанным CRC16/32 а затем их просто считывать и проверять CRC (в CRC сдвигов вполне хватает)
|
|
|
|
|
|
|
|
Apr 30 2007, 19:56
|
За битами по регистрам гоняюсь
Группа: Свой
Сообщений: 457
Регистрация: 24-04-06
Из: Таганрог
Пользователь №: 16 446
|
А вот ещё какой вопрос возникает.
Все предложенные способы тестирования памяти и регистров не проверяют изменение данных со временем. Если через несколько секунд (или миллисекунд) информация изменится, то быстро пролетающие тесты ошибок не обнаружат. В конце 80-х годов мы разрабатывали промышленные контроллеры на КР580, и встретилась фантастическая неисправность процессора - регистр "Е" терял данные через несколько секунд. Если оператор вводил данные с кнопок быстро, то всё было ОК, а если задумывался, то в память записывались нули. А остальные функции прибор выполнял безукоризненно. Так как КР580 выполнен на динамических регистрах, то видимо были проблемы с их регенерацией. Контороллеры AVR вроде-бы статические, хотя где-то я читал что это не совсем так, МК плохо работали на очень низких частотах.
В нашем контексте, IMHO, необходимо осуществлять очень тщательную проверку МК и системы после изготовления, причём проверять ещё и сохранность информации во времени. А в готовом изделии тесты могут быть и простыми.
--------------------
Курсор влево, курсор вправо - считается хакерством. FORMAT C: производится без предупреждения
|
|
|
|
|
|
|
|
Apr 30 2007, 20:52
|
Местный
Группа: Свой
Сообщений: 226
Регистрация: 2-06-06
Пользователь №: 17 720
|
Цитата Так как КР580 выполнен на динамических регистрах интересно, это как ?
|
|
|
|
|
|
|
|
Apr 30 2007, 23:23
|
Знающий
Группа: Свой
Сообщений: 543
Регистрация: 22-10-05
Пользователь №: 9 984
|
2Nanobyte Незнаю как РОН ,но SRAM в AVR указано явно хотя КР580ИК80А для меня загадка природы 2all Теперь насчет целесообразности Вот у меня такое неподобство - за день трижды слетела прошивка EEPROM в AVR,ну вот и какой толк от этого тестирования ? Лично для меня ответ только один - если в нем хранятся ответственные данные , изменение которых может привести к физической поломке МК ,периферии или механического устройства которым управляет МК и т.д., но в любом случае или мы вынуждены устройство останавливать ,весело могая лямпочкой или оно само по себе уйдет в ступор- ситуации это особо не меняет ,полюбому нужно ремонтировать или что боллее актуально - задумываешся над способами как можно увеличить надежноть работы. Тоесть думаеш уже над переносом данных во ФЛЕШ ,помехозащищеностью и написанию промежуточных технологических прошивок для настроек и калибровок ну на крайняк уже камни другие пробовать ,что меня особо не радует
|
|
|
|
|
|
|
|
May 1 2007, 00:09
|
За битами по регистрам гоняюсь
Группа: Свой
Сообщений: 457
Регистрация: 24-04-06
Из: Таганрог
Пользователь №: 16 446
|
Цитата(bodja74 @ May 1 2007, 00:23) ...Незнаю как РОН ,но SRAM в AVR указано явно... Ну, хоть и написано SRAM, на самом деле может быть и псевдо-SRAM. По крайней мере очень многие современные RAM построены на конденсаторах, но имеют встроенную схему регенерации содержимого и внешний интерфейс обычной статической памяти.  Цитата ...хотя КР580ИК80А для меня загадка природы О-о-о, вы много потеряли Всё познаётся в сравнении. Со слезами вспоминаются те трюки, котрые приходилось делать, используя этот CPU, чтобы получить эквивалент нескольких команд AVR. А уж ввод/вывод был просто   Но до сих пор использую некоторые собранные на этом CPU приборы. А некоторые УФ ПЗУ (573РФ1, 573 РФ2) записаны 22 года назад (200 000 часов), и еще нормально работают. Вот это была надёжность!!!
--------------------
Курсор влево, курсор вправо - считается хакерством. FORMAT C: производится без предупреждения
|
|
|
|
|
|
|
|
May 1 2007, 00:48
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(SasaVitebsk @ Apr 30 2007, 00:35) Хотелось бы услышать zltigo. Вот Вы в каждое изделие вставляете тест памяти. Сколько у вас было случаев неисправности ОЗУ? Сколько у Вас было случаев неисправности озу, при котором изделие работало, но скажем сбоило? Ну я все свои изделия не вижу . Для встроенной RAM никогда лично не видел, а для внешней, когда завод производитель укомплектовал 5V вместо 3V памятью девайсы работали до нескольких часов, но сбоили. Попадалась опять-таки партия чипов которые с ADSP жить не хотели без глюков. Цитата Можно ли написать такой тест... Разумеется нет, но некоторое приближение получить можно. Цитата Если же мы вернёмся к IBM, то думаю zltigo Вам подтвердит, что там сначала проверяется маленький участок озу и только потом запускается дальнейшее тестирование! Тестирование там начинается примерно на 4-5 команде (первые там запрет NMI), когда генерится импульс старшим битом 60h порта после чего там остается "1". Дальлее инициализация Video, периферии, таймеров (у первых IBM регенерация памяти была софтовая по таймеру), DMA.. между всеми этими операциями наращивался счетчик в 60h порту. После инициализации второго канала таймера уже можно было и попищать. И где-то уже потом-потом тестировалось 16K памяти, инициализация стека и понеслось... Причем 16K были выбраны не как минимально необходимые для тестирования, а как минимально гарантированные в наличии (во времена были!). Цитата Если привести это грубо к какому-то знаменателю, то они не гарантируют прохождение теста если не работает маленький кусочек ОЗУ и процессор в начальный момент. Как следует из вышеизложенного тесты у IBM идут и до "появления" RAM.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
May 2 2007, 16:37
|
Гуру
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521
|
Цитата(slog @ May 2 2007, 13:19) Можно проверить CRC EEPOM и FLASH, как самые вероятные причины отказов. Остальное проверить сложно и малополезно и нет 100% вероятности выявления неисправности. И вообщем то с переходом на импортные микросхемы дефекты стали настолько редки, что про тестирование процессора можно и забыть. Лучше обратить внимание на качество остальных элементов, особенно электролитических конденсаторов. Нонэйм электролиты, качество пайки, тепловые и электрические режимы - вот теперь на что смотреть надо. Совершенно согласен. Безусловно если есть внешние элементы (в том числе и память) то проверять можно и даже нужно. Желательно тесты памяти использовать как предлагалось. То есть динамический тест с записью данных в ОЗУ по определённому алгоритму а потом сравнение. Ну и диагональные. Статические тесты, как правило показывают только полную неработоспособность памяти в целом. Я, если есть возможность, и при сложной задаче, иногда её разбиваю на модули. Каждый со своим МК. Связь по последовательному интерфейсу. Как правило такие системы работают надёжнее чем один МК со сложной обвеской. (если не использовать ПЛМ). Да и разрабатывать полегче.
|
|
|
|
|
|
|
|
May 9 2007, 06:34
|
Группа: Новичок
Сообщений: 11
Регистрация: 3-05-06
Пользователь №: 16 721
|
Хочу сказать свои два слова. В общем случае различают диагностику и тестирование (в литературе встречаются и другие определения). Суть тестирования проверка программно-аппаратных средств в использованиии специально подобранного (искусственного) набора тестов, данных, сигналов и т.д., что требует (как правило) прерывания выполнения основного алгоритма со всеми вытекающими последствиями. Суть диагностики - оценка правильности функционирования программно-аппаратных средств на реальном (текущем) наборе сигналов, данных и т.д. (гапример выход считанных данных за границы, проверка промужуточных (конечных) данных на недопустимые занчения и т.д.), что не требует (как правило) прерывания выполнения основного алгоритма. Очевидно, в общем случае, эффективность тестирования выше, чем диагностики, но требует больше вычислительных, а зачастую и аппаратных ресурсов. В своей практике применяю и тестирование и диагностику. Как правило, тестирование проводится при запуске системы (прибора) и по команде оператора при возникновении подозрения на ту или иную несиправность (её определение и локализация). Диагностика проводится постоянно, по ряду ключевых параметров, точек алгоритма, сигналов и т.д. Глубину тестирования и диагностики необходимо выбирать исходя из назначения системы, объема её программных и аппаратных средств, стоимости и т.д. В общем задача творческая.  Очевидно, при проведении как диагностик, так и тестирования можно говорить только о вероятности определения той или иной несиправности, тем более о вероятности общего нормального функционирования программно-аппаратных средств.
|
|
|
|
|
|
|
|
Feb 11 2008, 18:16
|
Местный
Группа: Участник*
Сообщений: 323
Регистрация: 11-02-08
Пользователь №: 34 947
|
Цитата(=AVR= @ Apr 28 2007, 14:23) Проверка работоспособности МК самим МК, работоспособность которого под сомнением, является прекрасным примером логического абсурда. Мало того, примитивные проверки типа 0х55-0хАА не выявят ровным счетом ничего. Если уж так хочется, то проверять нужно всю систему вместе с подключенными к ней устройствами - убедиться в целостности внешних интерфейсов, соответствия измеренных значений их областям допусков, корректности CRC/CS Flash/EEPROM. Тест, который проверит И ВЫЯВИТ некорректность функционирования ЛЮБОГО узла МК, можно попытаться написать и запускать в порядке входного контроля (отбраковки), а в рабочие системы уже ставить те МК, которые таковую отбраковку прошли, но это тоже малополезно. Грамотно и тщательно проведенное ВЫХОДНОЕ тестирование системы гораздо более эффективно, чем написание/проведение никому не нужных "академических" тестов голого МК Может это и абсурд, но в серьёзных приложениях (атомная энергетика, космос, управление ядерным оружием и т.п.) у Вас никто не примет девайс, в программе которого нет модуля самотестирования как при включении так и во время работы
--------------------
После устранения бага в программе она стала работать....хуже
|
|
|
|
|
|
|
|
Feb 11 2008, 18:49
|
Участник
Группа: Свой
Сообщений: 66
Регистрация: 28-01-08
Из: Николаев
Пользователь №: 34 507
|
Для любой встроенной системы, имеет смысл тестировать EEPROM(для AVR), так как в ней наиболее часто происходят сбои, тестировать регистры(таймеры, АЦП, USART и т.п.) не имеет смысла потому, что с нерабочими регистрами устройство просто не пройдёт выходной контроль. В процессе работы есть смысл проверять связь с внешними устройствами (хотя это происходит само собой, если не использовать задержку вместо ожидания готовности устройства). Гораздо важнее обеспечить "Безопастное состояние" устройства после/вовремя сбоя. Например в случае выхода из строя источника тактирования процессора никакие тесты не помогут, а установка второго МК для контроля основного приводит к вопросу "Кто будет сторожить сторожей?".
Последнее не относится к задачам где требуется резервирование, это отдельная и сложная тема.
|
|
|
|
|
|
|
|
Feb 11 2008, 20:05
|
Местный
Группа: Участник*
Сообщений: 323
Регистрация: 11-02-08
Пользователь №: 34 947
|
Цитата(Getmanov @ Feb 11 2008, 21:49) тестировать регистры(таймеры, АЦП, USART и т.п.) не имеет смысла потому, что с нерабочими регистрами устройство просто не пройдёт выходной контроль. Входной-то контроль может вполне вероятно, что они и проходят, но не факт, что какой-то из модулей MCU не выйдет из строя после 10 лет эксплуатации.. Поэтому тестировать надо Как Вы считаете, что более надёжно: 1) Вероятность сбоя устройства равна 10 в минус 9 степени; вероятность того, что этот сбой система не обнаружит (не зарегистрирует) и соотвтетственно не предпримит ни каких мер равна 50% 2) Вероятность сбоя устройства равна 10 в минус 3 степени; вероятность того, что этот сбой система не обнаружит (не зарегистрирует) и соотвтетственно не предпримит ни каких мер равна 0,0000001% И что более надёжно? "Надёжная" система, сбои которой просто не обнаруживаются или "ненадёжная" система, у которой 99,99999999% сбоев обнаруживаются и предпринимаются соответствующие меры по устранению их последствий Как говорится: лучше перебдеть, чем недобдеть
--------------------
После устранения бага в программе она стала работать....хуже
|
|
|
|
|
|
|
|
Feb 11 2008, 20:35
|
Знающий
Группа: Свой
Сообщений: 841
Регистрация: 10-05-07
Из: Чебоксары (Россия)
Пользователь №: 27 640
|
Насчёт тестов считаю, что они полезны, но не особо. Хотя сам во время работы CRC32 программы всё время считаю (в фоновом режиме).
Но вот то, что интересно:
Никто из авторов про ЛОГ-и даже и не упомянул! А без логов все эти тесты - фикция.
Тест только во время работы полезен. На производстве выходной контроль д.б., а это почище любого теста будет!
Ну так вот - произошло что-то во время работы . Тест там что-то накопал, или просто процессор по собаке перезапустился, и снова все работает. Никто об этом и не узнал! Ну, может оператор нецензурно выругался, питание выключил-включил и забыл об этом. В худшем случае питание само выключилось (может по всему городу). И всё - все концы в воду!
Некоторые горе-разработчики этому даже рады будут! Они ничего не докажут - мы ни в чём не признаемся!
Так вот я считаю - тесты только тогда полезны, когда логи есть. А вот логи - они и без тестов полезны. И заменяют их во многих случаях (если не во всех).
Но насчёт логов - это уже другая тема. Может организуем? Я бы поддержал.
|
|
|
|
|
|
|
|
Feb 11 2008, 20:44
|
Местный
Группа: Участник*
Сообщений: 323
Регистрация: 11-02-08
Пользователь №: 34 947
|
Цитата(galjoen @ Feb 11 2008, 23:35) Насчёт тестов считаю, что они полезны, но не особо. Хотя сам во время работы CRC32 программы всё время считаю (в фоновом режиме).
Но вот то, что интересно:
Никто из авторов про ЛОГ-и даже и не упомянул! А без логов все эти тесты - фикция.
Тест только во время работы полезен. На производстве выходной контроль д.б., а это почище любого теста будет!
Ну так вот - произошло что-то во время работы . Тест там что-то накопал, или просто процессор по собаке перезапустился, и снова все работает. Никто об этом и не узнал! Ну, может оператор нецензурно выругался, питание выключил-включил и забыл об этом. В худшем случае питание само выключилось (может по всему городу). И всё - все концы в воду!
Некоторые горе-разработчики этому даже рады будут! Они ничего не докажут - мы ни в чём не признаемся!
Так вот я считаю - тесты только тогда полезны, когда логи есть. А вот логи - они и без тестов полезны. И заменяют их во многих случаях (если не во всех).
Но насчёт логов - это уже другая тема. Может организуем? Я бы поддержал. Я не упомянул про логи, потому что считал ведение логов само собой разумеющимся... Результаты POWER_ON-теста и самотестирования и самодиагностики во время работы девайса разумеется должны быть так или иначе донесены до человека (или выодом на экран или записью в энергонезависимый архив)
--------------------
После устранения бага в программе она стала работать....хуже
|
|
|
|
|
|
|
|
Feb 14 2008, 09:41
|
Участник
Группа: Свой
Сообщений: 66
Регистрация: 28-01-08
Из: Николаев
Пользователь №: 34 507
|
Цитата(Дон Амброзио @ Feb 11 2008, 22:05) Как говорится: лучше перебдеть, чем недобдеть Перебдеть то может и лучше, если это не будет вызывать сбоев оборудования, по опыту скажу, главное не перестараться. Когда диагностика превосходит по сложности основную программу, это только повышает вероятность отказа, причем однозначно по вине разработчика, что очень неприятно. Могу сделать вывод, что диагностика работы обязательна, но без фанатизма. Для устройств которые обеспечивают надёжность 99.9(9)% надо использовать какой-нибудь ПЛК с горячим резервированием, а не городить огород из МК.
|
|
|
|
|
|
|
|
Feb 14 2008, 11:14
|
Гуру
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521
|
Цитата(Getmanov @ Feb 14 2008, 13:41) Для устройств которые обеспечивают надёжность 99.9(9)% надо использовать какой-нибудь ПЛК с горячим резервированием, а не городить огород из МК. Особенно если учесть тот факт, что стоимость младших моделей МК опустилась ниже 1$, а стоимость средних 32-ух битников ниже 10$. При этом стоимость оборудования обычно превышает 100, а при высоком требовании к надёжности будет от 1000 и выше. При таком соотношении можно создавать высоконадёжное оборудование с элементами тестирования и резервирования. Либо применяя ПЛМ либо дробя устройство на кучу мелких интелектуальных оконечных устройств с резервированием. Естественно всё зависит от задачи. Естественно, что при этом будет учитываться и надёжность компонентов, в том числе и МК
|
|
|
|
|
|
|
|
Feb 14 2008, 15:45
|
Местный
Группа: Участник*
Сообщений: 323
Регистрация: 11-02-08
Пользователь №: 34 947
|
Цитата(Getmanov @ Feb 14 2008, 12:41) Перебдеть то может и лучше, если это не будет вызывать сбоев оборудования А почему правильно написанная программа должна вызывать сбои оборудования? Да хоть она сверхсложная и сверхзапутанная к оборудованию-то это какое имеет отношение? Если в программе нет ошибок, доущенных на этапе её проектирования, то никаких сбоев оборудования она вызвать не может.. Скорее наоборот, сбой оборудования может вызвать сбой в программе
--------------------
После устранения бага в программе она стала работать....хуже
|
|
|
|
|
|
|
|
Feb 16 2008, 00:29
|
Участник
Группа: Свой
Сообщений: 66
Регистрация: 28-01-08
Из: Николаев
Пользователь №: 34 507
|
Цитата(Дон Амброзио @ Feb 14 2008, 17:45) Скорее наоборот, сбой оборудования может вызвать сбой в программе А вот как раз и нет. Сбой оборудования не должен вызывать сбоя в программе, иначе это ПЛОХАЯ программа. Цитата(Дон Амброзио @ Feb 14 2008, 17:45) А почему правильно написанная программа должна вызывать сбои оборудования? Да хоть она сверхсложная и сверхзапутанная к оборудованию-то это какое имеет отношение? Под оборудованием я имел ввиду весь комплекс, а если он сбоит, то заказчику будет все равно, почему у него не работает его устройство- потому, что МК повис, или потому, что провод оборвался.
|
|
|
|
|
|
|
|
Feb 16 2008, 11:32
|
Местный
Группа: Участник*
Сообщений: 323
Регистрация: 11-02-08
Пользователь №: 34 947
|
Цитата(Getmanov @ Feb 16 2008, 03:29) А вот как раз и нет. Сбой оборудования не должен вызывать сбоя в программе, иначе это ПЛОХАЯ программа. Да? А случайный джамп не вызовет сбоя в программе? И искжение данных в ОЗУ? Почитайте тут http://electronix.ru/forum/index.php?showt...mp;#entry365890Цитата(Getmanov @ Feb 16 2008, 03:29) если он сбоит, то заказчику будет все равно, почему у него не работает его устройство- потому, что МК повис, или потому, что провод оборвался. Согласен..А к чему Вы это сказали? Цитата(Dog Pawlowa @ Feb 15 2008, 07:31) Потому что, дружище доктор, диагностика требует и дополнительных аппаратных затрат. По крайней мере дополнительного объема программной памяти Да Вы мне прям Америку открыли Цитата(Dog Pawlowa @ Feb 15 2008, 07:31) будет сбоить именно при диагностическом тестировании. Повторяю. Нормально написаннная программа без ошибок просто так не сбоит. Если программа сбоит (ПРАВИЛЬНАЯ ПРОГРАММА) значит железо сбойнуло Цитата(SasaVitebsk @ Feb 15 2008, 14:02) Чем сложнее система, тем она менее надёжна. Это относится и к программному обеспечению, хотя и в меньшей степени. Это к программному обеспечению не относиться...Поскольку для программного обеспечения нет такого понятия как износ. Если алгоритм корректный и кодирование без ошибок, то сложная программа будет даже более надёжной, поскольку более интеллектуально сможет разрулить все ситуации, чем дубовая простая прога, в которой от всех ситуация есть только лом - Watchdog
--------------------
После устранения бага в программе она стала работать....хуже
|
|
|
|
|
|
|
|
Feb 16 2008, 11:48
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(Дон Амброзио @ Feb 16 2008, 14:32) Если алгоритм корректный и кодирование без ошибок, то сложная программа будет даже более надёжной, поскольку более интеллектуально сможет разрулить все ситуации, чем дубовая простая прога, в которой от всех ситуация есть только лом - Watchdog Абсолютно правильные слова - подпишусь под каждым. Неуклонно следую принципу, что в правильно написанной системе кода, который занимается разборками с нештатными ситуациями должно быть как минимум сопоставимое количество с рабочим кодом. Watchdоg, для защиты от программых ошибок это вообще абсолютный моветон. Однако, весь, извинте, буду грубым, бред, который в соседней ветке и тут выплескивается не соответствует первым-же словам Вашего постулата "если алгоритм корректный" - ну нет корекных алгоритмов работы программ в неисправных машинах. И "кодирование без ошибок" - занимаясь всей этой надуманной фигней написать код без ошибок становится невероятной задачей, для сколь-нибудь РЕАЛЬНОГО приложения, а не кунштюковской демки.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Feb 16 2008, 12:52
|
Участник
Группа: Свой
Сообщений: 66
Регистрация: 28-01-08
Из: Николаев
Пользователь №: 34 507
|
Цитата(Дон Амброзио @ Feb 16 2008, 13:32) Повторяю. Нормально написаннная программа без ошибок просто так не сбоит. Если программа сбоит (ПРАВИЛЬНАЯ ПРОГРАММА) значит железо сбойнуло Что Вы имеете в виду под железом? Если только МК то согласен, если весь комплекс,то нет!
|
|
|
|
|
|
|
|
Feb 16 2008, 12:53
|
Знающий
Группа: Свой
Сообщений: 841
Регистрация: 10-05-07
Из: Чебоксары (Россия)
Пользователь №: 27 640
|
Цитата(_Pasha @ Feb 16 2008, 14:53) По поводу надежности программы.
Вот, я, например, никогда не допущу (в девайсе, работающем круглосуточно) использование ячейки ОЗУ для предварительно рассчитанной константы, в которую проц будет потом неделями заглядывать. Хороший пример для формулирования понятия надежной программы? Соглашусь, что этот пример хорош, но только в том случае, если эта константа вообще не меняется. Если она периодически меняется - я буду её в ОЗУ хранить. Но и её инверсию тоже. И при "заглядывании" их ксорить и на FFFFFFFF проверять.
|
|
|
|
|
|
|
|
Feb 16 2008, 13:09
|
Местный
Группа: Участник*
Сообщений: 323
Регистрация: 11-02-08
Пользователь №: 34 947
|
Цитата(zltigo @ Feb 16 2008, 14:48) не соответствует первым-же словам Вашего постулата "если алгоритм корректный" - ну нет корекных алгоритмов работы программ в неисправных машинах. Если при разработки Embedded-программы, предназначенной для использования в устройствах, которые может быть годами должны работать без вмешательства человека Вы в коде программы не предусмотрели реакции на отказы тех или иных узлов, то, ИМХО, это программа не правильная и устанавливать её на девайс, ИМХО, преступление Цитата(Дон Амброзио @ Feb 16 2008, 16:04) не предусмотрели реакции на отказы тех или иных узлов Даже лучше так сказать: "если при разработке алгоритма программы Вы не учли возможные сбои в работе устройства, и не заложили в алгоритм их обнаружение(детектирование) и устранение их последствий..."
--------------------
После устранения бага в программе она стала работать....хуже
|
|
|
|
|
|
|
|
Feb 16 2008, 13:17
|
Гуру
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521
|
Цитата(_Pasha @ Feb 16 2008, 15:53) По поводу надежности программы.
Вот, я, например, никогда не допущу (в девайсе, работающем круглосуточно) использование ячейки ОЗУ для предварительно рассчитанной константы, в которую проц будет потом неделями заглядывать. Хороший пример для формулирования понятия надежной программы? Скажем так, я с этим не согласен. Ниже объясню почему. Это, кстати не относится к словам zltigo. Здесь я соглашусь. ВСЕ исключительные ситуации должны быть обработаны. Это очевидно. Более того именно программист и видит все эти ситуации. Иначе в его программе будут необработанные ветки либо упрощённый алгоритм. Теперь возвращаясь к цитате. Иными словами вы допускаете, что эта ячейка может быть повреждена в процессе работы? А чем она, простите, отличается от соседней? Или от ячейки стэка? А как, защититься, от повреждения стэка? Как контролировать постоянно меняющееся озу программой, которая сама меняет озу? Программа должна быть простой и регулярной. Достаточной для реализации необходимого алгоритма. С момента, когда программа начинает жить своей жизнью - её надо просто переписывать заново. По поводу проверок, я тоже согласен с подходом "анализ исправности чипа чипом исправность которого вызывает сомнения - нонсенс" Ну понимаю - сделать самодиагностику до старта и блокирнуться, хотя нет никакой гарантии что это произойдёт. Но теория вероятности такова, что для вас, к примеру, выход одного изделия из тысячи - 0.1%, а для клиента, который купил одно ваше изделие - 100%. Это я к тому что если от вашего изделия может взорваться снаряд (принципиально может), и вероятность этого события 0.1%, то это уже недопустимо потому, что кому-то это может стоить жизни. А значит здесь надо применять другие методы. Такие, чтобы выход из строя вашего изделия ЛЮБЫМ СПОСОБОМ не приводил к этому взрыву. Это только резервирование.
|
|
|
|
|
|
|
|
Feb 16 2008, 14:14
|
;
Группа: Участник
Сообщений: 5 646
Регистрация: 1-08-07
Пользователь №: 29 509
|
Цитата(SasaVitebsk @ Feb 16 2008, 16:17) Теперь возвращаясь к цитате.
Иными словами вы допускаете, что эта ячейка может быть повреждена в процессе работы? А чем она, простите, отличается от соседней? Или от ячейки стэка? А как, защититься, от повреждения стэка? Как контролировать постоянно меняющееся озу программой, которая сама меняет озу? У меня время жизни объектов без их регенерации сравнительно короткое. Иногда ставлю низкоприоритетный тред, который пересчитывает кое-какие "константы". И вот почему: Сколько можно гонять/тестировать девайс? Новая ли разработка, либо просто выходной контроль - чем короче можно сделать этот процесс, тем лучше. В случае периодической калькуляции Цитата С момента, когда программа начинает жить своей жизнью - её надо просто переписывать заново. данный момент наступит быстрее при отладке, либо больше вероятность обнаружить некорректно работающее железо проца, если все на уровне. Если все ОК, то я могу уверенно полагать, что испытания прошли. Без организации теста наработки на сбой. Цитата Такие, чтобы выход из строя вашего изделия ЛЮБЫМ СПОСОБОМ не приводил к этому взрыву. Нет, я в такое не лезу. Зубками не вырос.
|
|
|
|
|
|
|
|
Feb 16 2008, 22:38
|
Гуру
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521
|
Цитата(_Pasha @ Feb 16 2008, 18:14) У меня время жизни объектов без их регенерации сравнительно короткое. Иногда ставлю низкоприоритетный тред, который пересчитывает кое-какие "константы". Я совершенно не спорю с вами я просто не знаю ответа. Вот скажите мне при каком условии вероятность сбоя будет выше? 1) 1 раз записать ячейку - 100 млн. раз её прочитать. 2) 100 тыс. раз записать ячейку - 100 млн. раз её прочитать. Давайте ещё один пример виртуальный с EEPROM. Представим себе ситуацию что надо хранить 50 байт данных и периодически обновлять их. Как надёжнее? 1) Просто записать и КС 2) Хранить 3 экземпляра и кс. и ещё вопрос В каком из этих вариантов EEPROM разрушится быстрее или вероятность появления ошибки выше?
|
|
|
|
|
|
|
|
Feb 17 2008, 08:02
|
;
Группа: Участник
Сообщений: 5 646
Регистрация: 1-08-07
Пользователь №: 29 509
|
Цитата(SasaVitebsk @ Feb 17 2008, 01:38) Я совершенно не спорю с вами я просто не знаю ответа.
.................
В каком из этих вариантов EEPROM разрушится быстрее или вероятность появления ошибки выше? А резервирование - то делается на макроуровне, на уровне блоков. А все остальное - камлания и холодный термоядерный синтез. Есть пример - контроллер мостовой пилы для резки гранита. Все просто - тележка ездит вперед/назад, пила вверх/вниз и враво/влево, датчики положения (холла). Решения - периодическая проверка живучести системного таймера, таймауты на прием сигналов датчиков. Красота... но если пила в камне, то вправо/влево включать нельзя. А как сие определить? Проверить положение? А если что-то врет? Тогда получается некрасивая пропорция - проц за 1 доллар убивает пилу за 2000 оных. Вышли из положения - перемещения влево/вправо можно только выключить автоматом. Включить - только вручную. Извините за оффтоп.
|
|
|
|
|
|
|
|
Feb 17 2008, 09:46
|
Гуру
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521
|
Конечно - это всё не праздные вопросы. И в каждом конкретном случае надо самостоятельное решение принимать. А груз ответственности велик. Скажем в таких приложениях никто не заставляет AVR применять, хотя с другой стороны если проц за 1$ это ещё не значит что он не надёжный. К тому же резервирование на процессорах за 1$ будет стоить дешевле  естественно с точки зрения аппаратной части. А вот разработка программного обеспечения - будет трудоёмким. (Я естественно не призываю - так - вариант) Такие вопросы, в общем то всегда возникают. У вас пила дисковая, а мне, к примеру, сейчас придётся раскручивать 2 барабана размером в рост человека. А это всё в цеху, гле люди непрерывно ходят. А мне отлаживать. Причём разгон-торможение, синхронное движение. А людей не выгонишь - круглосуточно работают. Будем решать. Будем внимательнее.
|
|
|
|
|
|
|
|
Feb 17 2008, 09:52
|
;
Группа: Участник
Сообщений: 5 646
Регистрация: 1-08-07
Пользователь №: 29 509
|
Цитата(SasaVitebsk @ Feb 17 2008, 12:46) Причём разгон-торможение, синхронное движение. Брат объявился! Про пилу - это дела минувших дней. А про Вашу тему - сейчас то же самое делаю по синхронному движению. В личку можно?
|
|
|
|
|
|
|
|
Feb 18 2008, 14:57
|
Участник
Группа: Свой
Сообщений: 66
Регистрация: 28-01-08
Из: Николаев
Пользователь №: 34 507
|
Цитата(SasaVitebsk @ Feb 17 2008, 11:46) Конечно - это всё не праздные вопросы. И в каждом конкретном случае надо самостоятельное решение принимать. А груз ответственности велик. Будем решать. Будем внимательнее. Полностью согласен, достаточность мер диагностики определяет только разработчик и под свою ответственность. И на 99% вероятность аварии в его руках. Но если вернуться к теме Цитата Целесообразность тестирования памяти и регистров То честно говоря не вижу в этом особого смысла, да и возможности. При включении можно проверить всё, что угодно. А как во время работы проверить ОЗУ? Остановить устройство, и записывать-считывать память, регистры и т.п.? Цитата(_Pasha @ Feb 17 2008, 10:02) Есть пример - контроллер мостовой пилы для резки гранита.
Все просто - тележка ездит вперед/назад, пила вверх/вниз и враво/влево, датчики положения (холла).
Решения - периодическая проверка живучести системного таймера, таймауты на прием сигналов датчиков. Красота... но если пила в камне, то вправо/влево включать нельзя. А как сие определить?
Проверить положение? А если что-то врет? Тогда получается некрасивая пропорция - проц за 1 доллар убивает пилу за 2000 оных. Для устройств, которые выполняют периодические действия эта задача решаема, например в ЧПУ станка такую проверку можно выполнять перед запуском программы. А если процесс непрерывный или непредсказуемый? Да и вероятность выхода из строя ячейки памяти гораздо ниже, чем какого либо датчика, поэтому стоит обращать внимание на диагностику периферийных устройств, исходя из моего опыта, это в большой степени снижает вероятность отказа, и конечно же стоит следить за "качеством" программы написаной Вами.
|
|
|
|
|
|
|
|
May 18 2008, 18:40
|
Местный
Группа: Участник*
Сообщений: 323
Регистрация: 11-02-08
Пользователь №: 34 947
|
Цитата(Getmanov @ Feb 18 2008, 18:57) При включении можно проверить всё, что угодно. А как во время работы проверить ОЗУ? Остановить устройство, и записывать-считывать память, регистры и т.п.? Как как.. Да как два пальца абосфальт.. Записал чё-нить в ОЗУ и тут же прочитал (проверил тем самым записалось ли). Не знал про такой способ?
--------------------
После устранения бага в программе она стала работать....хуже
|
|
|
|
|
|
|
|
May 18 2008, 19:10
|
Участник
Группа: Свой
Сообщений: 66
Регистрация: 28-01-08
Из: Николаев
Пользователь №: 34 507
|
Цитата(Дон Амброзио @ May 18 2008, 21:40) Как как.. Да как два пальца абосфальт.. Записал чё-нить в ОЗУ и тут же прочитал (проверил тем самым записалось ли). Не знал про такой способ? А тут же, это когда, через такт, секунду, месяц? А ещё бывают volatile переменные, что, запрещать к ним доступ, что бы прочитать что записалось?
|
|
|
|
|
|
|
|
May 19 2008, 04:11
|
Местный
Группа: Участник
Сообщений: 424
Регистрация: 6-03-06
Из: Н.Новгород
Пользователь №: 14 997
|
Цитата(Getmanov @ May 18 2008, 23:10) А тут же, это когда, через такт, секунду, месяц?
А ещё бывают volatile переменные, что, запрещать к ним доступ, что бы прочитать что записалось? Можно выделить сразу буфер, для проверуи памяти. Сначала проверяете его, а потом блоками перетаскиваете в него содержимое из ОЗУ, проверив определённый участок памяти, возвращаете туда то что перекидывали. Естенственно на время теста нужно вырубать прерывания. А период тестирования определяется параметрами надёжности и безопасности вашего устройства.
|
|
|
|
|
|
|
|
May 19 2008, 04:58
|
Участник
Группа: Свой
Сообщений: 66
Регистрация: 28-01-08
Из: Николаев
Пользователь №: 34 507
|
Цитата(BigBolt @ May 19 2008, 07:11) Можно выделить сразу буфер, для проверуи памяти. Сначала проверяете его, а потом блоками перетаскиваете в него содержимое из ОЗУ, проверив определённый участок памяти, возвращаете туда то что перекидывали. Естенственно на время теста нужно вырубать прерывания. А период тестирования определяется параметрами надёжности и безопасности вашего устройства. Единственный способ проверок такого рода, резервирование двойное, а то и тройное.
|
|
|
|
|
|
|
|
May 19 2008, 10:23
|
Частый гость
Группа: Свой
Сообщений: 151
Регистрация: 21-02-06
Пользователь №: 14 561
|
Цитата(_Pasha @ May 19 2008, 08:54) Известно из работ 80-х годов по тестированию ОЗУ (конкретнее - если найду книжку - скажу) о том, что такой способ является самым грубым и не обеспечивает выявление даже половины возможных неисправностей. ...очень бы хотелось посмотреть эту книгу, поскольку вопрос интересует давно. Сам считаю что в части случаев такая проверка необходима (все что связано с системами управления в ядерной энергетики и оружием)
|
|
|
|
|
|
|
|
May 20 2008, 10:14
|
кекс
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326
|
Цитата(Rst7 @ May 20 2008, 13:00) Плохо то, что без MMU невозможно контролировать переполнение стека абсолютно надежно, единственный способ - время от времени проверять положение указателя, особенно в процедурах, которые закопаны глубоко. Можно контроллировать и без MMU. Во всяком случае детектить выход за границу можно. В ручную напр так: Зарезервировать участок памяти перед стеком, заполнить каким-нить патерном, нагрузить программу работой "по самые нехочу", снять слепок памяти и посмотреть как глубоко залезли в резервную память. Автоматически можно также, во многих случаях отдетектится переполнение до того как система зайдет в тупик.
|
|
|
|
|
|
|
|
May 20 2008, 10:57
|
Местный
Группа: Участник
Сообщений: 424
Регистрация: 6-03-06
Из: Н.Новгород
Пользователь №: 14 997
|
Цитата(zltigo @ May 20 2008, 14:05) А потом - суп с котом одна из массовых ошибок памяти это ошибки/сбои адресации а не данных - подзаписали не туда и все... Предложите свой способ...
|
|
|
|
|
|
|
|
May 20 2008, 12:03
|
Местный
Группа: Участник
Сообщений: 355
Регистрация: 27-03-07
Из: Україна, Чуднів
Пользователь №: 26 530
|
Цитата(zltigo @ May 20 2008, 13:05) одна из массовых ошибок памяти это ошибки/сбои адресации а не данных - подзаписали не туда и все... Ваш ответ однозначно понять не получается. снизойдите пожалуйста, и обясните разве данные не портачатся когда выделенная память испорчена? К примеру про стек, регистры содержат правильный индекс указатель на данные в стеке?
--------------------
нельзя недооценивать предсказуемость глупости
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
Проверил. Действительно в мелких проектах r12 почему-то не задействован под IAR.
