Как то не верю.
Файловые системы и я тестирую. Не раз тут выкладывал результаты максимальной производительности.
И сколько же времени вы тестируете. Берете время c потолка? Какое количество файлов? А количество директорий? А количество одновременно открытых файлов?
И любой джуниор вам скажет что при достаточно долгом тесте файловой системы на Flash носителе у вас 100% случится сбой, так как есть такое явление как износ.
Чел более опытный намекнет, что у вас там со стеком и динамической памятью может быть нехватка и отказ в обслуживании.
Короче в любом случае получаете отказ. То что вы назовете это не отказом, а переходом в известное состояние (состояние аварии ) ничего не меняет.
Короче аргумент с FS не валидный.
Дайте че нить другое.

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


Не понял..... а где я писал про "файловые системы"??
Пример я привёл для SPI-FLASH. Только как пример. В остальном - поступаю аналогично.
Что такое износ - знаю, и он тут как бы совсем не при чём (размер чипа ==128МБ, читайте характеристики современных SPI-FLASH).


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

В моем тулбоксе около 10 разных файловых систем.
Большинство я тестировал. Тесты охватывают основные сервисы файловой системы.
Но главное это степень детерминированности файловых операций.
Чтобы набрать надежную статистику на уровне 0.98 пары часов конечно недостаточно.
Причем тесты надо повторять при смене платформы, компилятора и даже опции оптимизации в компиляторе.
А еще же есть десятки параметров в самой файловой системе которые тоже надо все перебрать.

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

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

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