Вдогонку вспомнилось. Ещё в embedded следует с большой осторожностью относится ко всем рекурсивным алгоритмам. В частности -- к сортировке. Вполне возможно, что в C-библиотеке идущей в комплекте с компилятором реализована функция qsort(), и что при переносе на микроконтроллер никто не задумывался, как она будет там работать. И попытка подать на вход отсортированную в обратном порядке последовательность может привести к максимальному использованию стека, т.е. при сортировке n элементов потребуется n кадров стека при наивной реализации алгоритма быстрой сортировки. А столько стека может и не быть! При не наивной реализации обычно есть всякие ухищрения и стек используется не сильно, но лимиты всё равно могут быть из мира "больших ПК", где нормой является 2 МБайта на стек (а не пару килобайт). Может быть стоит озаботиться заранее и использовать сортировку Шелла, например. При некоторой потери в скорости использование стека нулевое (алгоритм не рекурсивный).
Да и вообще глубину стека оценить следовало бы аналитически (если нет рекурсий). Ибо практическими прямыми измерениями не всегда можно найти настоящий максимум и могут найтись неожиданные сюрпризы. Интересным могут являться программа GNU cflow, опция -fstack-usage у gcc и варнинг -Wstack-usage. К сожалению скомбинировать вывод cflow и *.su файл полученный от gcc с опцией -fstack-usage сходу так не просто, дам ссылку на opensource проект, но не знаю насколько оно рабочее:
https://github.com …masgeorgec/Stack-usage Я в своё время не осилил.
fk0, легенда (06.02.2019 03:39, просмотров: 571) ответил fk0 на Где ты видел диагностику или обработку ошибок? Программисты программы пишут не предполагая возникновения ошибок в используемых подсистемах (библиотечных функциях или аппаратуре), ошибок у себя и какой-либо их обработки (возможность аварийного