[AlexandrY 3]

например если у меня есть SPI-FLASH в устройстве, но обращение к ней идёт не часто, то для теста (обнаружения редко проявляющихся непериодических сбоев как у ТС), я нагружаю данный интерфейс транзакциями чтения/записи по самое нехочу.

Как то не верю.

Файловые системы и я тестирую. Не раз тут выкладывал результаты максимальной производительности.

И сколько же времени вы тестируете. Берете время c потолка? Какое количество файлов? А количество директорий? А количество одновременно открытых файлов?

И любой джуниор вам скажет что при достаточно долгом тесте файловой системы на Flash носителе у вас 100% случится сбой, так как есть такое явление как износ.

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

Короче в любом случае получаете отказ. То что вы назовете это не отказом, а переходом в известное состояние (состояние аварии ) ничего не меняет.

Короче аргумент с FS не валидный.

Дайте че нить другое.

 

 

[jcxz 184]

Как то не верю.

Да конечно! Если Вы допускаете что в Ваших изделиях "даже могут возникнуть конструктивные повреждения" или оно может просто повиснуть просто из-за того что помеха проскочила по интерфейсу - понятно, что для вас являются фантастикой любые устройства которые не виснут. :biggrin:

 

Файловые системы и я тестирую. Не раз тут выкладывал результаты максимальной производительности.

Не понял..... а где я писал про "файловые системы"??

Пример я привёл для SPI-FLASH. Только как пример. В остальном - поступаю аналогично.

Что такое износ - знаю, и он тут как бы совсем не при чём (размер чипа ==128МБ, читайте характеристики современных SPI-FLASH).

 

И сколько же времени вы тестируете. Берете время c потолка?

"сколько времени" я вроде написал в своём посте.

 

Короче в любом случае получаете отказ.

Вы читать вообще умеете??? Запускал тесты на несколько часов, и не один раз - ни одного сбоя.

 

PS: То файловую систему какую-то увидели в моём сообщении, то динамическую память, то какие-то износы и отказы.... Вы мой пост-то прочитали? Поняли? :smile3046:

[AlexandrY 3]

Вы мой пост-то прочитали? Поняли? :smile3046:

Ну как. Я делаю запас на завирания и преувеличения.

Эт как бы неизбежно когда мы обсуждаем коней в известной субстанции без ссылок на первоисточники.

 

Несколько часов на тестирование файловой системы...? Вы меня хотите рассмешить?

Я файловые системы тестирую неделями. Трачу на написание тестов кучу времени и все равно не знаю все их метрики и все их поведение.

 

За свои несколько часов вы узнаете только характеристики износа только одного конкретного чипа.

С другой стороны если у вас не файловая система, а несколько процедурок записи в физические сектора, то че там тестировать?

 

 

 

[KnightIgor 2]

50/50... :) Есть проект "маршрутизатор-переводчик" промышленный. По 485-му "мастер" разговаривает с 232-ми "слейвами".

Шота мне подсказывает, а не на 5V ли эти все внешние чипы работают? F103 хоть и якобы на многих ногах 5V "терпимый", но не верю я в эти маркетинговые сказки. Если 5V по пину рубит регулярно через диоды на его 3.x вольт, могут быть самые непредсказуемые результаты.

 

[juvf 10]

Это только говорит о том, что данное устройство неправильно спроектировано.

Никакая комбинация входных данных (валидных или просто мусора) с любой частотой повторения на внешних интерфейсах не должна вводить устройство в состояние ступора либо любое другое нерабочее состояние. Если это не так - это кривое устройство и надо переделывать.

ППКС

В CAN-е это аппаратно сделано

нет там этого аппаратно. там транспортный уровень аппаратный, а протокольного нет. Например преобразователь протоколов CAN-USART (кан в любой серийный... Modbus, Гранит, МЭК-101, Лисна-Ч....) По кану от датчика приходят данные, их надо передать по МЭК-101 на OPC-сервер. Раз в секунду датчик передает пакет, преобразователь преобразовывает и передает дальше. Если пакеты от датчика пойдут 100 раз в сек.... - преобразователь может не успеть их обрабатывать... Если пакеты от датчика буферезировать, то может переполниться буфер. Ни какой аппаратный кан не поможет.

 

Попробуйте "стресс-тест" провести где нить в сети промышленных логических контроллеров. Тоже получите катастрофу.

Делаем. Нет катастрофы. Например эл.счетчик. Запрос-ответ, запрос-ответ. Начинаем часто запрашивать - тот отвечает или пропускает запросы, но не виснет. Можно послать запрос и не дожидаясь ответа послать ещё запрос - счетчик не должен зависнуть.

 

сделать грамотное нагрузочное тестирование очень сложно

Легко. На китах типа дискавери, на китах ПЛИСовых, на ПК.

 

во вторых оно не для выявления ошибок

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

 

ps

сработает WDT

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

 

[AlexandrY 3]

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

Спецы из NXP дискуссию с вами на этом и закончили бы. Потому как в i.MX RT уже четыре! WDT аппаратных реализовано.

WDT к вашему сведению абсолютно нужен для контроля риалтайма. Если вам не нужен значит вы просто не разрабатываете под риалтайм, т.е. вам пока что его просто не доверяют. :laughing:

[haker_fox 60]

Эта штука как минимум не нужна, как максимум опасна.

Я тоже так раньше думал :rolleyes: Но со временем пришёл к выводу, если она есть, то почему бы и не использовать? Ведь WDT не просто перезагрузит плату, он ещё и выставит флаги статуса в специальном регистре, что позволит залогировать это событие. А главное, устройство хоть и зависнет, но всё же продолжит работу спустя таймаут.

 

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

[juvf 10]

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

Кто и что мне чего то там доверяет или не доверяет? У вас это из темы в тему. Это вам кроме красной кнопки похоже чего-то не доверяют, вот вы и считаете, что кому-то что-то кто-то должен доверить.

 

Спецы из NXP дискуссию с вами на этом и закончили бы.

Как обычно - пустослов. Говорите за себя. А по теме ни чего не сказали..... хотя судя по вашим высказываниям про стрес-тест - с вам говорить дальше не о чем.

Ведь WDT не просто перезагрузит плату

готов подискутировать, но не в этой теме.

[haker_fox 60]

готов подискутировать, но не в этой теме.

Я тоже, создайте, пожалуйста, новую тему с названием, которое вам наиболее удобно.

 

Я файловые системы тестирую неделями. Трачу на написание тестов кучу времени и все равно не знаю все их метрики и все их поведение.

Расскажите, пожалуйста, как вы тестируете ФС? И почему неделями? Какие тесты требуют такого длительного времени?

[Rst7 5]

Если 5V по пину рубит регулярно через диоды на его 3.x вольт, могут быть самые непредсказуемые результаты.

 

Шутите, какие защитные диоды? Там же по другому все сделано, совсем другая схемотехника этих выводов. Там нет защитных диодов в привычном для CMOS понимании в p-канальном плече.

[mantech 34]

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

 

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

[haker_fox 60]

Ну вот и зря.

Интересно, а в критических приложения (зависит жизнь человека) собака допускается (кроме резервирования системы)?

[mantech 34]

Интересно, а в критических приложения (зависит жизнь человека) собака допускается (кроме резервирования системы)?

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

[AlexandrY 3]

Расскажите, пожалуйста, как вы тестируете ФС? И почему неделями? Какие тесты требуют такого длительного времени?

В моем тулбоксе около 10 разных файловых систем.

Большинство я тестировал. Тесты охватывают основные сервисы файловой системы.

Но главное это степень детерминированности файловых операций.

Чтобы набрать надежную статистику на уровне 0.98 пары часов конечно недостаточно.

Причем тесты надо повторять при смене платформы, компилятора и даже опции оптимизации в компиляторе.

А еще же есть десятки параметров в самой файловой системе которые тоже надо все перебрать.

 

Или тут про CAN тема. В многозадачном приложении CAN строится на очередях причем очереди к каждой задаче потребителю.

Как выбрать глубину очереди и главное приоритеты задач чтобы не нарушить риалтайма?

Здесь не тестирование до ошибки нужно, а итеративное тестирование с подстройкой или вариацией средств межзадачной синхронизации.

Т.е. сложная и не факт что всегда оправданная процедура.

 

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

Это просто непонимание сложности темы тестирования.

 

 

 

 

[mantech 34]

В моем тулбоксе около 10 разных файловых систем.

 

Это для коллекции или тут какой-то практический смысл, но что-то не могу придумать такового