Форум разработчиков электроники ELECTRONIX.ru [Русская версия Invision Power Board]

Автор: Eros Sep 18 2018, 09:14

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

Автор: Forger Sep 18 2018, 10:14

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

Автор: Eros Sep 18 2018, 10:16

Цитата(Forger @ Sep 18 2018, 13:14)

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

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

Автор: Forger Sep 18 2018, 10:31

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

Автор: Eros Sep 18 2018, 10:33

Цитата(Forger @ Sep 18 2018, 13:31)

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

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

Автор: Forger Sep 18 2018, 10:34

Цитата(Eros @ Sep 18 2018, 13:33)

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

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

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

Автор: Eros Sep 18 2018, 10:44

Цитата(Forger @ Sep 18 2018, 13:34)

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

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

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

Автор: Forger Sep 18 2018, 10:50

Цитата(Eros @ Sep 18 2018, 13:44)

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

В 5й Keil встроены ДВА компилятора, совершенно разные, один - http://electronix.ru/redirect.php?https://electronix.ru/forum/index.php?s=&showtopic=148695&view=findpost&p=1583064 уже legacy.

Цитата

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

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

Автор: Eros Sep 18 2018, 10:58

Цитата(Forger @ Sep 18 2018, 13:50)

В 5й Keil встроены ДВА компилятора, совершенно разные, один - http://electronix.ru/redirect.php?https://electronix.ru/forum/index.php?s=&showtopic=148695&view=findpost&p=1583064 уже legacy.

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

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

Код

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

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

Автор: jcxz Sep 18 2018, 11:15

Цитата(Eros @ Sep 18 2018, 13:58)

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

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

Автор: aaarrr Sep 18 2018, 11:42

Цитата(Eros @ Sep 18 2018, 12:14)

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

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

Автор: jcxz Sep 18 2018, 11:52

Цитата(aaarrr @ Sep 18 2018, 14:42)

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

Вангую, что автор не только оптимизацию забыл включить, но прерывания забыл запретить при "измерении"

И 168*42/512 = 13.78125 тактов на один элемент - всё равно как-то многовато.....

Цитата(Eros @ Sep 18 2018, 13:44)

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

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

Автор: Tanya Sep 18 2018, 13:04

Цитата(jcxz @ Sep 18 2018, 14:52)

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

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

Автор: jcxz Sep 18 2018, 13:26

Цитата(Tanya @ Sep 18 2018, 16:04)

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

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

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

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 Sep 18 2018, 13:59

Цитата(jcxz @ Sep 18 2018, 16:26)

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

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

Автор: Forger Sep 18 2018, 14:08

Цитата(Tanya @ Sep 18 2018, 16:59)

Или нет?

Как правильно заметил jcxz, все будет зависеть от того, насколько часто будет выполняться условие ветвление, а это зависит от набора самих данных.
Скажем, если все данные идут "по нарастающей", то время всего сравнения будет одно, а если "спадающей", то уже совсем другое.
Чтобы этого не было, нужно "выровнять" время отработки в одном и другом условии (например, банальными NOP-ами).

Автор: jcxz Sep 18 2018, 14:10

Цитата(Tanya @ Sep 18 2018, 16:59)

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

Исходник независимо - ну и что? Выполняться он будет за разное число тактов, в зависимости от данных. Я говорил о том, что тест проведённый ТС-ом для его исходника - некорректен, так как выполнение его исходника будет зависеть от данных. А значит нужно указывать - на каком наборе данных тестировать, или тестировать для самого худшего случая.

PS: Код, который я привёл - он для CM4. Возможно на CM7 появились ещё какие-то новые команды, с помощью которых можно ещё оптимизировать. Не знаю. Всё в руках ТС-а.

Автор: Obam Sep 18 2018, 19:38

У вас в "LDMIA R0, {R3-R9, R12}" одни и те же 8 слов грузятся всю дорогу. R0 c "!" должон быть, чтоб по массиву двигаться

Автор: jcxz Sep 18 2018, 19:58

Цитата(Obam @ Sep 18 2018, 22:38)

У вас в "LDMIA R0, {R3-R9, R12}" одни и те же 8 слов грузятся всю дорогу. R0 c "!" должон быть, чтоб по массиву двигаться

Да, Вы правы, забыл. Исправил. Проверял поверхностно, на скорую руку.

Автор: Eros Sep 19 2018, 05:38

Цитата(jcxz @ Sep 18 2018, 17:10)

Исходник независимо - ну и что? Выполняться он будет за разное число тактов, в зависимости от данных. Я говорил о том, что тест проведённый ТС-ом для его исходника - некорректен, так как выполнение его исходника будет зависеть от данных. А значит нужно указывать - на каком наборе данных тестировать, или тестировать для самого худшего случая.

PS: Код, который я привёл - он для CM4. Возможно на CM7 появились ещё какие-то новые команды, с помощью которых можно ещё оптимизировать. Не знаю. Всё в руках ТС-а.

Я указывал, что изначально массив заполняется по возрастанию, т.е. это и будет по сути самый худший случай. Еще что у меня получилось: собрал с максимальной оптимизации (мой косяк, не заметил) получилось 65 мкс, и потом попробовал запретить прерывания получилось 50 мкс. Спасибо за совет, сейчас попробую ради интереса на ассемблере и использовать TCM RAM.

Автор: jcxz Sep 19 2018, 05:52

Цитата(Eros @ Sep 19 2018, 08:38)

Спасибо за совет, сейчас попробую ради интереса на ассемблере и использовать TCM RAM.

А за сколько у Вас мой ассемблерный вариант выполняется?
PS: Мерить время лучше в отладчике по отладочному таймеру (в ядре).

Автор: Eros Sep 19 2018, 05:55

Цитата(jcxz @ Sep 19 2018, 08:52)