Режим Persistence на осциллографе был включен?

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

C тех пор, как по условиям теста этот список НЕ МЕНЯЕТСЯ. Разброс времен у Автора был вызван незакрытыми прерываниями при вызове менеджера и ничем более.

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


Зато избавлюсь от лишней задачи

(1) - Я не настолько религиозен
(2) Согласен. В рамках здравого смысла и уголовного кодекса.
(3) Согласен. Если не следовать (1,2)

Да, но я бы не стал (имхо). Нельзя ли просто выделить память статически, или динамически, но создавать её при подключении usb и удалять при отключении?


А зачем так сложно? Сделайте один менеджер в SDRAM, переопределите операты new и delete, если используете Си++.

Если ксть СДРАМ, которой обычно много, вы уверены, что вообще нужна дин. память? Тем более только в одном месте, как сказали.

Тоже подпишусь под этим высказыванием - Вы полностью правы!
Вот только из сообщений ТС видно, что он не представляет.


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


Так и будет И в случае начинающего велосипедостроителя (что мы имеем), первого компонента будет много больше чем 2-го


Для связных применений, особенно если в ПО имеется несколько каналов связи с несколькими драйверами, лучше создать "кучу" в виде распределённого статически массива блоков фиксированного размера. Размер блока (оптимально) == размеру максимального кадра протокола связи (протоколов, если обмен идёт по нескольким протоколам одновременно).
Выделение свободного блока из такой "кучи" можно организовать разными способами. Самый универсальный: изначально поместить дескрипторы всех блоков нашей "кучи" в FIFO-очередь свободных блоков, откуда их будет при необходимости брать каждый драйвер канала связи, заполнять и помещать в другую очередь (или какой другой механизм) на вход целевого процесса (процессов, если протоколов несколько) обработки входящих связных кадров. После обработки и освобождения блока, его дескриптор должен возвращаться в исходную очередь свободных дескрипторов.
Дескриптор блока здесь - это просто индекс соответствующего элемента в массиве-"куче".
Пул свободных дескрипторов и очереди дескрипторов между драйверами связи и обработчиками можно организовать и проще, если дескрипторов мало, то просто можно битмапом в переменной u32 например. Здесь по обстоятельствам.
Такие дескрипторы можно передавать через механизм очередей даже не только между задачами ОС или ISR, но и между процессорами в многоядерной среде, таким образом используя общий пул связных блоков для нескольких ядер.

Начал немного сомневаться. В принципе, можно обойтись и статической. Но мне надо заполнять массивы разной длины. Наверно, я мог бы создать один гигантский массив размером во всю СДРАМ, а потом заполнять его, сохраняя адрес и размер выделенного кусочка. Но это же, по сути, делает и malloc. То есть я как бы избавил себя от лишней работы.

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

В один момент времени нужно от 1 до 15 экземпляров массива. Причем, возможна ситуация, когда из одного экземпляра массива читаются данные, а другой экземпляр уничтожается, создается новый другого размера и туда данные записываются.

Persistence это вот такой вид как внизу.
Платформа Kinetis MK66 180 МГц, компилятор IAR, оптимизация максмимальная

Запись процесса выделения 1500 блоков памяти случайного размера, но не более 255 байт с помощью malloc


Запись процесса освобождения 1500 блоков с помощью free.


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

Но все равно потом пожалеете.

Просто пройду мимо и плюсану тех, кто говорил про memory pool'ы (что там у вас, 15 статически аллоцированных массивов максимальной длины).

их не 15, их может быть 15 максимум, может быть один, занимающий почти всю память, может быть два и т.д.