uC/OSII: память, как оно работает? Опции

[Koluchiy]

Здравствуйте, уважаемые гуру.
Никогда не работал с RTOS, так что буду задавать дилетантские вопросы.

Поясните пожалуйста, как эта система работает с памятью.
Стек выделяется каждой задаче, его размеры определяются при создании задачи.
Что на тему кучи (Heap)? Она общая для всех задач?

Есть ли какая-то защита памятей задач? (статических и динамических)
Умеет ли эта система работать с MMU? (процессор - NIOSII/f).

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

Всем заранее спасибо за ответы.
Можно вместо ответов посылать втуда, где читать.

[amusin]

Что на тему кучи (Heap)? Она общая для всех задач?

Да.
Если вы хотите работать с кучей из нескольких задач,
то следует использовать Mutex.

Есть ли какая-то защита памятей задач? (статических и динамических)
Умеет ли эта система работать с MMU? (процессор - NIOSII/f).

Не слышал такое про. Но лучше посмотреть порт ОС для этого МК.

[Koluchiy]

Спасибо за ответы!

Подскажите, как все-таки решать задачу определения необходимого объема памяти? Размеры стеков известны, необходимые размеры куч - нет (сколько-то нужно системе, сколько-то используемым библиотекам).

[andrewlekar]

Размер кучи можно определить только приблизительно: размещается памяти с запасом и прогоняется программа - потом смотрите, сколько памяти максимум требовалось. Размеры стеков для задач тоже рассчитываются таким методом - автоматического вычисления стека для задач я не встречал.

[Koluchiy]

потом смотрите, сколько памяти максимум требовалось

Нельзя ли подробнее, как можно посмотреть "потом", сколько памяти максимум требовалось?
Это какая-то примочка в отладчике, или в ОС?

[AlexandrY]

Нельзя ли подробнее, как можно посмотреть "потом", сколько памяти максимум требовалось?
Это какая-то примочка в отладчике, или в ОС?

Есть примочки и для Keil-а и для IAR-а которые позволяют смотреть состояния стеков задач uCOS и менеджера памяти.
В принципе задачи и в рабочем режиме могут контролировать свой стек и увеличивать его при необходимости.

В uCOS есть только менеджер разделов памяти с выделением блоков фиксированной длины.
Разделов этих может быть много, но надо всегда напрягаться какую длину назначить блокам.
Эт такой рудимент оставшийся со времен когда в микроконтроллерах было по 2-10 кБ памяти.

В других осях есть нормальные многозадачные malloc и free, например в MQX.
А почему бы вам не изучить MQX?

[Koluchiy]

Есть примочки и для Keil-а и для IAR-а которые позволяют смотреть состояния стеков задач uCOS и менеджера памяти.

Как они называются? Я в Eclipse пока нашел только фишку про контроль стека от переполнения.

[AlexandrY]

Как они называются? Я в Eclipse пока нашел только фишку про контроль стека от переполнения.

Они не называются, просто открываете закладку IAR там где плагины к RTOS и видите uCOS в списке.
Когда входите в отладчик видите меню с разными функциями работы с RTOS.

[andrewlekar]

У IAR это называется ucOS Plugin. На деле ось вызывает периодически задачу специальную, которая и проверяет заполненность стеков. Можно там запоминать максимум и выдавать его в терминал по запросу. Этот метод может давать неточное значение максимальной заполненности стека, а куча, кажется, вообще не проверяется. Чтобы наверняка, нужно ставить хук на malloc и free и отслеживать, сколько памяти выделилось в пике. Однако куча может фрагментироваться и нужно закладывать раза в 2 больше памяти, чем вычислили. Короче, муторное это занятие.

[jcxz]

Однако куча может фрагментироваться и нужно закладывать раза в 2 больше памяти, чем вычислили. Короче, муторное это занятие.

Почему именно в 2, а не больше?
А если в процессе работы программы была такая последовательность:
выделить 100байт, указатель A;
выделить 1байт, указатель B1;
освободить указатель A;
выделить 101байт, указатель A;
выделить 1байт, указатель B2;
освободить указатель A;
... ну и так далее, с увеличением запросов A и без освобождения указателей B.
Что будет после N таких проходов?
Занято (допустим при N=10) в конце будет всего: 1*10+109 байт.
А кучи израсходовано будет: 1*10+100*10+9.
Итого - куча нужна почти в 10 раз больше, чем максимальный полезно-занятый объём.

PS: Именно поэтому я никогда не использую кучу в своих embedded-проектах.