[SapegoAL 0]

Имеется проект. Очень значительный. Очень много вычислений. Вычисления сложные.

В проекте 7 моих задач. При отладке пока можно рассматривать 2 Calc и GUI. Всё написано на чистом Си.

Без выделения/ очистки памяти.

Установил контроль стека типа 2.

Наблюдаю следующую картину.

1. Растёт стек в задаче GUI. Точнее не совсем так. Вижу, что постепенно портится память по направлению к концу стека.

Это происходит рывками ч/з большие промежутки времени. Ставлю ловушку по DataBreakPoint и наблюдаю что

заполнение происходит в ОС в xPortPendSVHandler. Если после остановки я продолжаю исполнение и контролирую

сам указатель стека (R13) в задаче, то он жёстко стоит на месте. Причём намного ниже, чем портится память.

Отсюда у меня полная непонятка. Почему происходит рост?

В задаче использую sprintf. Пока грешу на это. Возможно что-то я не понимаю по сопроцессору. Может ещё какой-то стек используется

и он растёт? Проясните пожалуйста, кто в теме.

 

Ну и такой вопрос. Кто использовал данную ОС с данным процессором и может подтвердить, что всё устойчиво работает.

Как-то попроще будет. По увереннее себя буду чувствовать.

 

Заранее благодарю.

 

PS: Похоже всётаки на sprintf. Очень много жрёт. Но предельно. Выше определённой отметки стек не растёт.

[aba 0]

Во фриртосе под Cortex прерывания, насколько я помню, используют мейн стек. Возможно у Вас мейн стек расположен какраз за стеком задачи и прерывание налезает на стек задачи. Также, насколько помню, sprintf использует кучу, может он налезает???

[Lagman 1]

В настройках FreeRTOSConfig.h увеличить размер стека для idle configMINIMAL_STACK_SIZE, хотя бы для теста.

http://www.freertos.org/a00110.html

Потом можно увеличить стек для той задачи которая вредит http://www.freertos.org/a00125.html.

И проверить есть ли в файле с фунцией которая вызывает sprintf включение заголовочного файла #include <stdio.h>.

[SapegoAL 0]

Как-то забыл отписаться. :rolleyes: Извиняйте.

Работает всё очень устойчиво.

Был хомут. Мне почему-то казалось, что в thumb2 режиме выравнивания не требуется. Тем не менее Hard fault со всеми вытекающими.

Кроме того могу сказать что при использовании sprintf стека сжирается действительно много. Учитывая что у меня FreeRTOS + математика + плавучка + вывод оперативный.

Да ещё число знаков после запятой задаётся. Короче очень сложно контролировать стек. Переписал весь вывод в ручную. Теперь он по крайней мере стабильный а не плавающий от остановки к остановке.

 

Всем спасибо.

[megajohn 3]

Кроме того могу сказать что при использовании sprintf стека сжирается действительно много. Учитывая что у меня FreeRTOS + математика + плавучка + вывод оперативный.

Да ещё число знаков после запятой задаётся. Короче очень сложно контролировать стек. Переписал весь вывод в ручную. Теперь он по крайней мере стабильный а не плавающий от остановки к остановке.

 

для экономии памяти можно printf sprintf реализовать на отдельной задаче, в которую будет отправляться arg и list, и соотвесвенно блокирующее выполнение

 

[juvf 10]

Кроме того могу сказать что при использовании sprintf стека сжирается действительно много.

стандартная sprintf ОЧЕНЬ прожорлива. Мног сжирается памяти программ. Используйте printf-stdarg.c

 

FreeRTOS включает файл, который называется printf-stdarg.c - он содержит эффективную версию sprintf(), которая по минимуму использует стек, и может заменить во многих случаях стандартную библиотечную версию sprintf().

[SapegoAL 0]

Да я просто написал свои ф-ции вывода на дисплей.

[SapegoAL 0]

Кому интересно, работает очень устойчиво. В последней версии использовал: IAR 7.2, FreeRTOS 8.0. В небольшом количестве HAL 1.1 от st. В основном дрова свои.

Сейчас прикручиваю lwIP.