Перейти к содержанию
    

uC/OSII: память

Здравствуйте, уважаемые гуру.

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

 

Поясните пожалуйста, как эта система работает с памятью.

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

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

 

Есть ли какая-то защита памятей задач? (статических и динамических)

Умеет ли эта система работать с MMU? (процессор - NIOSII/f).

 

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

Задача статистики такой информации вроде не дает. Есть ли другие способы?

 

Всем заранее спасибо за ответы.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Да.

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

то следует использовать Mutex.

 

Есть ли какая-то защита памятей задач? (статических и динамических)

Умеет ли эта система работать с MMU? (процессор - NIOSII/f).

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Это какая-то примочка в отладчике, или в ОС?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Это какая-то примочка в отладчике, или в ОС?

 

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

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

 

В uCOS есть только менеджер разделов памяти с выделением блоков фиксированной длины.

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

Эт такой рудимент оставшийся со времен когда в микроконтроллерах было по 2-10 кБ памяти.

 

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

А почему бы вам не изучить MQX? ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Однако куча может фрагментироваться и нужно закладывать раза в 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-проектах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...