[turnon 1]

On 3/27/2023 at 12:17 PM, EdgeAligned said:

По поводу обработки всякого рода Fault-ов. Они не зря придуманы, поэтому в обработчиках этих исключений нужно писать код, помогающий диагностировать ошибку. Аппаратные средства микроконтроллера сохраняют флаги причин, вызвавших ошибку и последний адрес памяти программ перед "совершение ошибки".

А можно ли надеяться на корректное исполнение кода и вообще его исполнение после HardFault?

И например я сохранил флаги и последний адрес памяти, как дальше работать с этой информацией?

[113 3]

Ну при наличии экрана можно вывести их туда (как BSOD). Можно в uart выплюнуть или на карту записать. Да, делать это все надо на максимально низком уровне, не выходя из прерывания.

[turnon 1]

On 4/10/2023 at 9:35 PM, fpga_student said:

Вроде там чето писали на хабре про автоматизацию тестирования ПО, вот интересно ктото делает автоматические тесты такого рода ?

Всю разработку веду в vscode с тестами на googletest. Ограничений у тестов нет, память на PC бесконеяна по сравнению с ПК.
Работы с железом 10% и она не меняется. А ту же логику обновления прошивки легко "замокать" и покрыть тестами.

[jcxz 217]

32 минуты назад, turnon сказал:

как дальше работать с этой информацией?

пинать программиста. Только так.

[turnon 1]

On 4/11/2023 at 11:02 AM, Arlleex said:

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

И что в итоге? Игры в релизе без багов? Хренушки)) Ярких примеров уйма.

И что вы предлагаете? Отменить тестирование потому что оно не находит 100% багов?

[Arlleex 160]

16 минут назад, turnon сказал:

И что вы предлагаете? Отменить тестирование потому что оно не находит 100% багов?

Я предлагаю не относиться к тестированию встроенного ПО как к мнообещающей магии, которая сделает все по красоте.

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

[turnon 1]

On 4/11/2023 at 11:17 AM, fpga_student said:

Я не видел лучшего программиста, чем мой программист. Но в исходнике с архивом 40 Мегов, нашлось и у него интересное(

А как вы поняли, что он лучший?

47 minutes ago, Arlleex said:

Я предлагаю не относиться к тестированию встроенного ПО как к мнообещающей магии, которая сделает все по красоте.

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

Так я о чем?

[turnon 1]

On 4/11/2023 at 11:28 AM, Arlleex said:

P.S. Был у нас тут когда-то на форуме некий Александр, который прям кайфовал от одного USB-стека от азура на 500 МБ исходников

Видел исходники от файловой системы этого азура, кромешний п-ц.

[Arlleex 160]

29 минут назад, turnon сказал:

Так я о чем?

Вообще без понятия. Так о чем?

[turnon 1]

On 4/11/2023 at 2:02 PM, tonyk_av said:

В той книжке про 300 типичных ошибок тесты на граничных условиях были одними из первых.

Так что же за книжка? Не гуглится.

On 4/11/2023 at 1:54 PM, fpga_student said:

И да, я видел таких людей - тестировщиков от рождения. Боже упаси. Софт станет бесконечно надежным, но он будет дороже в 1000 раз. Что может быть страшнее профессионала тончайшим образом понимающего все ньюансы, и всю свою энергию и понимание тратящего на то чтобы сломать вашу систему ?

Вот тут не понял. Да это самый ценный человек в команде и на него молиться надо.

3 hours ago, jcxz said:

пинать программиста. Только так.

Так я и есть этот программист.

[EdgeAligned 75]

Ну, по новому кругу пошли 🙂 

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

6 часов назад, turnon сказал:

А можно ли надеяться на корректное исполнение кода и вообще его исполнение после HardFault?

В принципе, да. Поскольку МК выходит из состояния ненормальной работы и переходит в участок кода, который должен быть изолирован бесконечным циклом whille(1) и завершаться (не обязательно) командой системного сброса SystemReset(). 
И если не ошибаюсь на память, в этой теме я уже писал, что желательно сделать в обработчике HardFault.   Этот "серьезный проблэм" бывает двух типов: ошибка извлечения из таблицы векторов и необработанная ошибка, предусмотренная другими исключениями (Forced).  
Адрес памяти программ, вызывавший любую из ошибок, желательно сохранить, например в Backup SRAM и использовать затем при "разборе полетов". Имея исходник программы, можно найти, к какой функции в каком программном модуле принадлежит этот адрес и просмотреть исходники на предмет косяка программиста.

Изменено 18 апреля, 2023 пользователем EdgeAligned

[Arlleex 160]

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

[EdgeAligned 75]

Илон Маск недавно предупредил, что ИИ скоро будет умнее людей, и вот тогда он сможет написать совершенно безглючный и самосовершенствующийся код! 🙂 Ну а пока время Скайнета и Терминахтера не настало, человеки сами должны заботиться о коде и искать баги. Ошибаются все. Не ошибается тот, кто ничего не делает. Но это не повод совершенно игнорировать любые способы диагностирования, отладки и тестирования. 
Для написания максимально безглючных программ нужно много знать и иметь нехилый багаж именно багов, чтобы знать их в лицо и понимать, как с ними бороться и как их искать. Проще говоря, программист, написавший кучу глючных программ, знает все баги поименно и узнает их в лицо при встрече 🙂 Ну, образно выражаясь, конечно.

Чем проще обработчик HardFault, тем меньше шансов насадить в нем багов. По крайней мере, в while(1) { } сложно положить более одного бага 🙂  Хотя особо умелые - смогут! С дуру можно и МПХ сломать, как говорится.

Изменено 18 апреля, 2023 пользователем EdgeAligned

[Arlleex 160]

49 минут назад, EdgeAligned сказал:

Ошибаются все. Не ошибается тот, кто ничего не делает.

Вот, замечательно. А теперь: условный я написал тест, и по этому тесту моя программа отработала на ура. Через полгода мне звонят с объекта и говорят, что устройство сбойнуло и перезапустилось само (потому что закопано в тайге на глубине обитания зеленых подземных камнеедов и выкапываться оно по ТЗ не планировалось). Что делать дальше? Писать тест для тестирования тестов? Или как? Как оценить достаточность и глубину тестов? Кто ее оценит?

А вдруг у ТС студент-программист эти тесты даже написал, только написал их криво, в результате получилось то что получилось?

Полагаю, дальше будет лишь демагогия на тему "сам дурак, учись писать тесты" и т.д., да?

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

Цитата

По крайней мере, в while(1) { } сложно положить более одного бага...

Ну, как сказать, все же ведь зависит от той грани, где ты уже что-то знаешь (съел собаку) и чего-то не знаешь, то есть никаких собак не евши.

В HF достаточно вызвать какую-нибудь функцию дендрофекального принта через системные вызовы SVCall (как это кто-то даже вполне может использовать), якобы печатая в UART текстом причину HF, и получаем CPU Lockup, из которого в большинстве случаев неподготовленный программист не выйдет никогда, кроме сброса.

Ну а насчет ИИ, то я искренне верю, что какая-то часть ресурсов (человеческих) надумает использовать ИИ в целях тестирования ПО.

[EdgeAligned 75]

Ну а что вы сами предлагаете тогда?

30 минут назад, Arlleex сказал:

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

Да, расскажите это тысячам пассажиров самолета (или хотябы линейным пилотам гражданской авиации), что они прямо в полете справятся лучше, чем летчик-испытатель! 
 

В HardFault можно ничего не печатать, никуда не передавать, а просто сохранить в бэкапе флаги и адреса памяти, содержащиеся в регистрах MMFAR, BFAR, и выполнить программный системный сброс, инициировав перезагрузку МК. А уже после перезагрузки, используя флаг причины перезагрузки и сохраненную информацию, можно попытаться её отобразить. Или же вообще заблокировать работу микроконтроллера, выдавая на диагностический разъем (светодиод) код ошибки. Поскольку HardFault - "это есть вери биг проблэм"

 

Изменено 18 апреля, 2023 пользователем EdgeAligned