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

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

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

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

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

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

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

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

В прерываниях крайне нежелательно использовать "долгоиграющие" вызовы.
Тем более, что USB сейчас довольно "оборотистый", даже 2.0.
Как вариант - сделайте свой "malloc", работающий на заранее выделенной области памяти, c быстрым "выделением" и "освобождением"
через указател(и) и размер. Его и пользуйте в ISR.

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



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


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

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

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

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



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

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

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


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


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


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