STM32H7+DCMI+DMA+обработка Опции

[Eros]

Всем привет! Кто-нибудь использует в своих проектах STM32H7? Очень интересная диковинка, с которой достаточно не просто разобраться...
Суть вопроса в чем: пытаемся реализовать проект на борде пока что, снимается сигнал с аналоговой линейки, который подается на внешний
АЦП и от этого АЦП идет параллельный интерфейс к DCMI (14 бит). Далее DCMI укладывает по DMA в (u16). Далее, начинается самое интересное...
Чтобы обработать сигнал необходимо найти максимум в массиве.. Массив представляет из себя u16 и 512 кол-во элементов.. Этот цикл занимает по времени около 120 мкс?
Мне кажется это не адекватно, это примерно уровень f4. CPU настроен на 400 МГЦ.
Какие могут быть идеи? Может есть какие-то особенности для H7? Кэш используется

[aaarrr]

Этот цикл занимает по времени около 120 мкс?
Мне кажется это не адекватно, это примерно уровень f4. CPU настроен на 400 МГЦ.

На F4@168MHz такой цикл занимает 42мкс. Оптимизацию не забыли включить? И в какой памяти источник данных расположен?

[jcxz]

На F4@168MHz такой цикл занимает 42мкс. Оптимизацию не забыли включить? И в какой памяти источник данных расположен?

Вангую, что автор не только оптимизацию забыл включить, но прерывания забыл запретить при "измерении"
И 168*42/512 = 13.78125 тактов на один элемент - всё равно как-то многовато.....

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

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

[Tanya]

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

Это как от значений?

[jcxz]

Это как от значений?

Так как неизвестно во что скомпилится этот сишный исходник, то возможно там будут команды условного перехода при сравнениях. И тогда: идём по одной ветке после сравнения - одно число тактов, по другой - другое.

Такие простые вещи оптимизировать можно только на ассемблере. Вот например так (вроде этого хочет ТС):

CODE

PUBLIC FindMaxU16
;extern "C" uint FindMaxU16(u32 *);
THUMB
FindMaxU16: PUSH {R4-R9, LR}
MOVS R2, #512 / 16 - 1
MOVS R1, #0
p111: SUBS R2, #1
LDMIA R0!, {R3-R9, R12}
USUB16 LR, R1, R3
SEL R1, R1, R3
USUB16 LR, R1, R4
SEL R1, R1, R4
USUB16 LR, R1, R5
SEL R1, R1, R5
USUB16 LR, R1, R6
SEL R1, R1, R6
USUB16 LR, R1, R7
SEL R1, R1, R7
USUB16 LR, R1, R8
SEL R1, R1, R8
USUB16 LR, R1, R9
SEL R1, R1, R9
USUB16 LR, R1, R12
SEL R1, R1, R12
BPL p111
CMP R1, R1, LSL #16
IT CC
LSLCC R1, R1, #16
LSRS R0, R1, #16
POP {R4-R9, PC}

Указатель (аргумент FindMaxU16()) должен быть выровнен на границу 32 бит. И данные должны быть в диапазоне: 0...32767 (ТС вроде говорил про 14-битные данные - тогда должно подойти).
Этот код выполняется за ~963 такта. Нетрудно пересчитать в мкс если надо. На CPU ТС-а должно быть ~2.5 мкс. И время выполнения от данных тут не зависит.

[Tanya]

Так как неизвестно во что скомпилится этот сишный исходник, то возможно там будут команды условного перехода при сравнениях. И тогда: идём по одной ветке после сравнения - одно число тактов, по другой - другое.

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