[Dima1060 0]

Здравствуйте!

Подскажите пожалуйста, можно ли использовать функции динамического выделения памяти malloc и free в обработчике какого либо прерывания? Если да, то как примерно оценить время выполнения этой функции?

[AlexandrY 3]

Здравствуйте!

Подскажите пожалуйста, можно ли использовать функции динамического выделения памяти malloc и free в обработчике какого либо прерывания? Если да, то как примерно оценить время выполнения этой функции?

 

Где-то можно, а где-то нельзя.

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

[Dima1060 0]

Где-то можно, а где-то нельзя.

А с чем связана разница? Где можно и где нельзя? Мне надо использовать malloc и free в обработчике прерывания USB. То есть приходит команда по USB и в обработчике я выделяю или освобождаю память.

 

 

 

[zltigo 0]

А с чем связана разница? Где можно и где нельзя?

Изучаете исходные тексты КОНКРЕТНОЙ используемой Вами в каждом конкретном случае функции и решаете в каждом КОНКРЕТНОМ случае можете такой вариант функции использовать или нет. Если нет, то можно-ли сие исправить, например, оберткой, или надо менять более серьезно.

 

[novikovfb 17]

А с чем связана разница? Где можно и где нельзя? Мне надо использовать malloc и free в обработчике прерывания USB. То есть приходит команда по USB и в обработчике я выделяю или освобождаю память.

Почитайте про понятие реентерабельности функций и посмотрите, как работают функции malloc и free в Вашей системной библиотеке. Может получиться, что прерывание возникнет в момент выполнения функции malloc или free, в прерывании будет вызвана функция malloc или free, может получиться либо выделение одного и того же буфера двум разным указателям или полное разрушение структуры кучи.

[Dima1060 0]

Почитайте про понятие реентерабельности функций и посмотрите, как работают функции malloc и free в Вашей системной библиотеке. Может получиться, что прерывание возникнет в момент выполнения функции malloc или free, в прерывании будет вызвана функция malloc или free, может получиться либо выделение одного и того же буфера двум разным указателям или полное разрушение структуры кучи.

У меня предполагается только один malloc и один free, в прерывании USB, в разных командах.

Посмотреть код malloc...он где то в библиотеках запрятан. Не подскажете где его найти для Keil ARM?

[novikovfb 17]

У меня предполагается только один malloc и один free, в прерывании USB, в разных командах.

Посмотреть код malloc...он где то в библиотеках запрятан. Не подскажете где его найти для Keil ARM?

тогда может и будет работать, если по времени успеет. Насчет исходников Keil - не знаю, у IAR были исходники в версии 2009 года, там просмотр связанного списка, поиск первой свободной области достаточного размера, сделана блокировка от повторного входа, но она поможет только в многозадачной среде, т.к. попытка остановить обработчик прерывания до окончания выполнения фоновой задачи добром не кончится.

По длительности обработки malloc и free - там, скорее всего, просмотр списка занятых/свободных областей памяти в куче, чем сильнее фрагментирована куча - тем медленнее будет работать.

[Dima1060 0]

Понятно, а если эта куча выделена во внешней SDRAM памяти, как у меня, наверно, еще медленнее будет.

[k155la3 26]

. . . в прерывании USB, в разных командах.

Посмотреть код malloc...он где то в библиотеках запрятан. . . . .

В прерываниях крайне нежелательно использовать "долгоиграющие" вызовы.

Тем более, что USB сейчас довольно "оборотистый", даже 2.0.

Как вариант - сделайте свой "malloc", работающий на заранее выделенной области памяти, c быстрым "выделением" и "освобождением"

через указател(и) и размер. Его и пользуйте в ISR.

 

[esaulenka 5]

В прерываниях крайне нежелательно использовать "долгоиграющие" вызовы.

Крайне нежелательно мыслить исключительно догмами. Правильный ответ - во втором уже сообщении, "где-то можно, где-то нет".

Если понимать, что происходит и представлять себе последствия, можно делать всё, что нужно.

Прерывания в современных контроллерах (читай "cortex-M") - вполне себе недо-операционка. С многими уровнями вложенности задач, если надо.

 

 

Тем более, что USB сейчас довольно "оборотистый", даже 2.0.

USB, даже 2.0, даже в 2016 году ещё поискать надо. В большинстве контроллеров бесплатно (без дополнительного PHY) до сих пор full-speed. И его до сих пор хватает для очень многих изделий.

 

Как вариант - сделайте свой "malloc", работающий на заранее выделенной области памяти, c быстрым "выделением" и "освобождением"

через указател(и) и размер. Его и пользуйте в ISR.

А вот совет "из г-на и палок быстренько сделайте свой велосипед" может выйти боком, когда через полгода у этого велосипеда окажется 13 колёс.

[megajohn 3]

А вот совет "из г-на и палок быстренько сделайте свой велосипед" может выйти боком, когда через полгода у этого велосипеда окажется 13 колёс.

 

давно ли пулы памяти это велосипед ?

[Dima1060 0]

Померял осциллографом время выполнения malloc, выполняется в основном за 1 мкс иногда за 3 мкс, потыкал, чтобы забить побольше памяти, стало выполняться иногда за 1,2 или 3,2 мкс.

Функции вызова задачи FreeRTOS 4,5-6,9 мкс (для создания сообщения там тоже динамически выделяется память, но не с помощью malloc). Мда...

[zltigo 0]

А вот совет "из г-на и палок быстренько сделайте свой велосипед"....

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

 

 

Функции вызова задачи FreeRTOS 4,5-6,9 мкс (для создания сообщения там тоже динамически выделяется память, но не с помощью malloc). Мда...

Что Вы назвали "вызовом задачи" неведомо никому :(. Это раз. Задачи как таковые никакие сообщения не создают, а при собственно передаче сообщения никакого динамического выделения памяти уже не происходит. Ну и третье, если есть уже один менеджер памяти, как в FreeRTOS, причем в исходниках, то вторым пользоваться незачем. Ну и пятое - измеряли время Вы НЕПРАВИЛЬНО, поскольку время отрабатывания парочки malloc/free при отсутствии других вызовов менеджера, не может меняться при хоть сколь-нибудь реальной реализации этих функций.

 

[novikovfb 17]

время отрабатывания парочки malloc/free при отсутствии других вызовов менеджера, не может меняться при хоть сколь-нибудь реальной реализации этих функций.

с каких пор просмотр связанного списка (а очень часто именно на нем делают управление кучей) перестал зависеть от длины этого списка?

[Dima1060 0]

Что Вы назвали "вызовом задачи" неведомо никому :(. Это раз.

Я имел ввиду создание сообщения (Message) и отправку его в очередь (osMessagePut).

Данное сообщение потом разблокирует задачу и в ней выполняется malloc

 

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

Не создают, я сам создаю, в прерывании и память динамически выделяю, средствами RTOS

 

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

Менеджер памяти в FreeRTOS копается в внутренней RAM процессора (причем в статически выделенном ему кусочке этой RAM). А malloc выделяет память из внешней SDRAM.

 

Ну и пятое - измеряли время Вы НЕПРАВИЛЬНО, поскольку время отрабатывания парочки malloc/free при отсутствии других вызовов менеджера, не может меняться при хоть сколь-нибудь реальной реализации этих функций.

Не знаю, дернул ножкой вверх до выполнения malloc и дернул вниз после выполнения. Хотя возможно в процессе вклинилось другое прерывание...ну не суть, главное, что дольше 3 мкс malloc у меня не выполнялся, а это мизерная задержка.