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

[Eros]

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

[Forger]

На первой странице даташита есть такая фраза:
192 KB of TCM RAM (inc. 64 KB of ITCM RAM + 128 KB of DTCM RAM for time critical routines)

[Eros]

На первой странице даташита есть такая фраза:
192 KB of TCM RAM (inc. 64 KB of ITCM RAM + 128 KB of DTCM RAM for time critical routines)

Да я знаю, использую кэш и пробовал помещать и данные и функцию в эту область, прироста скорости вычисления не значительная на 5-6 мкс

Сообщение отредактировал Eros - Sep 18 2018, 10:17

[Forger]

А какой компилятор используется?

[Eros]

А какой компилятор используется?

Пользуюсь Keil'ом 5

[Forger]

Пользуюсь Keil'ом 5

Да я не про среду (IDE), а про компилятор.
Впрочем, не суть ))

Покажите этот "капризный" код.

[Eros]

Да я не про среду (IDE), а про компилятор.
Впрочем, не суть ))

Покажите этот "капризный" код.

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

[Forger]

Ну кеил собтвенно и использует стандартный армовский компилятор.

В 5й Keil встроены ДВА компилятора, совершенно разные, один - можно сказать уже legacy.

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

Потестить есть на чем, но, честно говоря, лень. Ведь поиск максимума тоже можно решить по-разному

[Eros]

В 5й Keil встроены ДВА компилятора, совершенно разные, один - можно сказать уже legacy.


Потестить есть на чем, но, честно говоря, лень. Ведь поиск максимума тоже можно решить по-разному

А, понял. Использую 5 версию.
Линейный поиск максимума. Вы знаете как найти максимум по-другому? Буду рад вариантам

Код

for (uint16_t i = 0; i<512; i++)
{
    if (max<mas[i])
   {
    max = mas[i];
   }
}

До этого я аналогично заполняю этот массив значениями 2*i

Сообщение отредактировал Eros - Sep 18 2018, 10:59

[jcxz]

Линейный поиск максимума. Вы знаете как найти максимум по-другому? Буду рад вариантам

Изучить систему команд CPU и написать на ассемблере. Такой си-шный код совсем нет смысла тестировать на скорость.

[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]

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

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