Перейти к содержанию
    

AT32F437: эффективность работы команд под WS0

20 часов назад, dmitrykhom сказал:

Думал над этим. Но это тот же cortex-M4, возможно, чуть более лучший, чем AT32F437. Но GD он ввел санкции, в отличие от AT, поэтому я уж лучше останусь на STM, потому что там cortex-M7, и скорость адекватная.

В первую очередь, как мне представляется вопрос в цене и доставаемости. В плане доставаемости в России, об Артери у нас, как то, положительного впечатления не сложилось. В плане цены, тут недавно случилось в срочном порядке копить пару STM32F427ZIT, так отдали без малого 15 тысяч, при том, что аналогичные 450 от GD, свободно "бери не хочу" от 800р за штуку

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 08.08.2023 в 21:20, dmitrykhom сказал:

Кто-нибудь имеет такой опыт? Может ли подсказать, как нивелировать разницу? Или что я не учёл, когда рассчитывал, что все команды будут исполняться где-то за 1-2-4 такта. А 1 такт это около 3,5 нс.

Я запустил такой код на частоте 288МГц. 1 такт ~3.47нс.

	MOVS R4, #0x0001
	LDR R5, =0x40020418
	STR R4, [R5, #0]
	STR R4, [R5, #16]
	STR R4, [R5, #0]
	STR R4, [R5, #16]
	LDR R5, =0x40020418
	LDR	R6,	[R5]
	LDR R5, =0x40020418
	LDR	R6,	[R5]
	STR R4, [R5, #0]
	STR R4, [R5, #16]
	STR R4, [R5, #0]
	STR R4, [R5, #16]
	STR R4, [R5, #0]
	STR R4, [R5, #16]

 

В середине есть блок из пар загрузки из Flash с последующим чтением из периферии.

Каждая такая пара выполняется за порядка 20нс (~6 тактов). Если убрать либо чтение Flash, либо чтение из периферии, то число тактов резко падает (к 1 такту).

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

Например, между этими двумя командами можно поставить NOP, и это никак не повлияет на время выполнения - оно не увеличится.

Вместо NOP можно поместить более полезную команду, которая не конфликтует за доступ к AHB.

 

В 11.08.2023 в 11:03, vladec сказал:

В плане доставаемости в России, об Артери у нас, как то, положительного впечатления не сложилось.

AT32F437 то пропадают, то появляются по несколько тысяч штук. -ZG и -ZM не принципиально отличаются по цене, и за такой функционал - считаю, даром.

В идеале хотелось бы, чтоб все устаканилось, и появилась ревизия В, т.к. в А много силиконовых глюков.

Тоже долго мучились, но решили делать серийное изделие на AT32F437Z

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кста, вместо "LDR R5, =0x40020418" можно использовать MOV/MOVT

	MOV 	R5, #0x0418
	MOVT	R5, #0x4002

- это чуть-чуть быстрее (раза в два)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 час назад, adnega сказал:

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

Вообще говоря в приведенном коде загрузка константы (адреса) из Flash должна вестись по DCode-шине, выборка инструкций по ICode, а System bus обращается к периферии.

И тут надо глядеть, есть ли в AT32F узкое горлышко при доступе к Flash: данные будут лежать "недалеко" от инструкций, поэтому возможность параллельной работы зависит от задумки китайцев...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 11.08.2023 в 12:38, Arlleex сказал:

Вообще говоря в приведенном коде загрузка константы (адреса) из Flash должна вестись по DCode-шине, выборка инструкций по ICode, а System bus обращается к периферии.

И тут надо глядеть, есть ли в AT32F узкое горлышко при доступе к Flash: данные будут лежать "недалеко" от инструкций, поэтому возможность параллельной работы зависит от задумки китайцев...

Вы правы. Если сравнить реализацию в AT32F437

image.thumb.png.c4a27bf350db1ff3b3216cab02a97d0f.png

с реализацией в STM32F43x

image.thumb.png.29e5641ea25ff4b065ff08b1cee3d6b3.png

то видно, что I и D шины у ST разделены, поэтому ситуация может быть принципиально лучше.

Но если ответить на часть вопроса, то в AT32F437 выборка инструкций идет на частоте PLL (288 МГц макс), с нулевыми циклами ожидания.

В случаях, когда команда дергает I и D шины - МК AT32F437 может существенно проигрывать ST.

Получается, что для загрузки 32-битных значений в регистр по памяти проигрываем (8 против 6), но по тактам можем выиграть сильно (если таких ситуаций много).

Может, есть какой ключик компилятора на этот случай?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

11 часов назад, adnega сказал:

Каждая такая пара выполняется за порядка 20нс (~6 тактов). Если убрать либо чтение Flash, либо чтение из периферии, то число тактов резко падает (к 1 такту).

Поставьте обе 

LDR	R6,	[R5]

друг за дружкой, и число тактов тоже должно упасть.

9 часов назад, adnega сказал:

что I и D шины у ST разделены

Дело не только в шинах. Изучите документ: https://www.cse.scu.edu/~dlewis/book3/docs/Cortex-M4%20Instruction%20Timing.pdf

чтобы понимать - от чего зависит скорость выполнения LDR/STR на Cortex-M4+. И как её увеличить.

Он касается всех Cortex-M4+, вне зависимости от производителя и его конфигурации шин.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

57 минут назад, jcxz сказал:

друг за дружкой, и число тактов тоже должно упасть.

Если коллеги выше намеряли правильно и это достоверные цифры, то как-то не похоже на задержки расчета (декодером) адреса смежных LDR/STR, ИМХО...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 11.08.2023 в 22:08, jcxz сказал:

Поставьте обе 

LDR	R6,	[R5]

друг за дружкой, и число тактов тоже должно упасть.

Вот несколько измерений, которые добавлял в середину цепочки из     STR     R4, [R5, #imm]

	// 13.4 ns
	MOV 	R5, #0x0418
	MOVT	R5, #0x4002
	LDR		R6,	[R5]
	
	// 20.4 ns
	LDR 	R5, =0x40020418
	LDR		R6,	[R5]
	
	// 20.4 ns
	LDR 	R5, =0x40020418
	NOP
	LDR		R6,	[R5]
	
	// 24.0 ns
	LDR 	R5, =0x40020418
	LDR		R6,	[R5]
	LDR		R6,	[R5]
	
	// 3.5 ns
	LDR		R6,	[R5]
	
	// 16.6 ns
	LDR 	R5, =0x40020418
	
	// 20.4 ns
	LDR 	R5, =0x40020418
	LDR 	R5, =0x40020418
	
	// 20.4 ns
	LDR 	R5, =0x40020418
	LDR 	R6, =0x40020418
В 11.08.2023 в 22:08, jcxz сказал:

Дело не только в шинах. Изучите документ: https://www.cse.scu.edu/~dlewis/book3/docs/Cortex-M4%20Instruction%20Timing.pdf

Интересный документ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 час назад, adnega сказал:

Вот несколько измерений, которые добавлял в середину цепочки из     STR     R4, [R5, #imm]

    // 20.4 ns
	LDR 	R5, =0x40020418
	LDR 	R6, =0x40020418

Не хватает варианта с заменой этого на одну LDRD R5, R6, =0x40020418  :wink:

Имхо: Лучше времена приводить в тактах. Нагляднее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 12.08.2023 в 10:39, jcxz сказал:

Не хватает варианта с заменой этого на одну LDRD R5, R6, =0x40020418  :wink:

Имхо: Лучше времена приводить в тактах. Нагляднее.

80052bc: e9df 5604   ldrd  r5, r6, [pc, #16] ; 80052d0 <cc>
..
080052d0 <cc>: 
80052d0: 40020418  .word 0x40020418                                                                                                                           
80052d4: 40020418  .word 0x40020418 

те же 20.4 нс (6 тактов, 12 байт).

Но

80052bc: f44f 6583   mov.w r5, #0x0418                                                                                                                   
80052c0: f2c4 0502   movt  r5, #0x4002                                                                                                                
80052c4: f44f 6683   mov.w r6, #0x0418                                                                                                                   
80052c8: f2c4 0602   movt  r6, #0x4002

всего 13.4 нс (4 такта, 16 байт)

Кста, на тему теневого копирования, WS=0 и т.п. недавно сделал пост, но он оказался не замеченным, хотя там беда масштабнее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 10.08.2023 в 16:06, Arlleex сказал:

Про DMA понял, про прерывания - не понял. Вам нужно отключить вообще любые прерывания и в main() в бесконечном цикле линейно разместить блок из нескольких подряд дерганий ногой GPIO.

...

P.S.3. Кстати, Вы и эксперимент с GPIO и осциллографом тоже под отладчиком проводили? Или в МК уже была зашита прошивка, а программатор вовсе не подцеплен?

Процесс запущен в прерывании, его некому перебивать. В фоновом цикле запускал - результат тот же. Снимал отладчик, втыкаю плату в розетку - результат тот же.

В 10.08.2023 в 16:06, Arlleex сказал:

 

Все-таки, я пока что предполагаю, что где-то что-то недонастроено, либо все-таки кто-то перебивает доступ CPU к шине.

Я бы, интереса ради (не знаю, как у Вас щас) скачал оригинальный стартап + конфиг тактирования и повторил эксперименты.

Идея правильная, об этом я забыл. Попробую.

В 10.08.2023 в 16:06, Arlleex сказал:

И, повторюсь, GPIO-шкой смотреть время выполнения команд не совсем честно. Все-таки таймером DWT правильнее. На скрине да, Вы верно его нашли.

Р.S. Еще вопрос. Каково состояние бита NZW_BST у Вас, посмотрите отладчиком?

Ещё как честно! А если меня AT обманывает? Картинка, мною представленная, очень стабильна, с небольшим джиттером. Если поставить повторение этих команд, картинка будет стабильно повторена.

Я не запомнил точные данные, но команды приблизительно от 1 до 5 единиц по счётчику.

Посмотрю этот бит.

В 10.08.2023 в 17:23, Arlleex сказал:

 

 

В 10.08.2023 в 16:06, Arlleex сказал:

А Вы уверены, что это именно так и работает? У меня есть подозрение, что проект должен линковаться не с 0x08000000, а с 0x0. Иначе контроллеру как-то надо знать (читай - задавать руками), область какого банка Flash "кэшируется" (копируется) в быструю SRAM для реализации zero-wait-execution. Попробуйте слинковать программу с адреса 0x0.

Уверен, так задано в проекте, да и по disassembly это видно. Перерыл все документы, ничего не нашел по конфигурации банков. Везде написано, что кэширование происходит автоматически в старшую область sram. Причем я смотрел - в этой области данных из флэшки нет. Видать, это сделано для защиты кода инструкций.

Почему вторая инструкция так долго выполняется. Это же чтение данных из памяти, и оно выполняется дольше, чем запись. Думал по первой инструкции, может, процессор долго лезет к смещению РС. Делал локацию рядом с перепрыгиванием и даже до команды - результат тот же.

Изменено пользователем dmitrykhom

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

54 минуты назад, adnega сказал:
80052bc: e9df 5604   ldrd  r5, r6, [pc, #16] ; 80052d0 <cc>
..
080052d0 <cc>: 
80052d0: 40020418  .word 0x40020418                                                                                                                           
80052d4: 40020418  .word 0x40020418 

те же 20.4 нс (6 тактов, 12 байт).

Что-то не так сделали.... должно быть 8 байт.

40 минут назад, dmitrykhom сказал:

Ещё как честно! А если меня AT обманывает?

Кто такой AT? И почему он обманывает вас?

40 минут назад, dmitrykhom сказал:

Картинка, мною представленная, очень стабильна, с небольшим джиттером. Если поставить повторение этих команд, картинка будет стабильно повторена.

Причём тут какая-то "стабильность картинки"? Оценивать скорость работы команд, по скорости GPIO - совершенно не правильно. Почитайте мануалы на МК, посмотрите - что на какой шине сидит и от чего тактируется. Операции записи в регистры GPIO могут проходить через несколько межшинных мостов, каждый может вносить задержку. И скорость которую "намеряете" таким образом не будет иметь ничего общего с реальной скоростью выполнения команд.

Arlleex вам всё правильно написал. ARM - это не AVR, ногодрыгательные подходы для него уже не применимы. Для измерения задержек выполнения команд следует пользоваться DWT.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

32 минуты назад, jcxz сказал:

Причём тут какая-то "стабильность картинки"? Оценивать скорость работы команд, по скорости GPIO - совершенно не правильно. Почитайте мануалы на МК, посмотрите - что на какой шине сидит и от чего тактируется. Операции записи в регистры GPIO могут проходить через несколько межшинных мостов, каждый может вносить задержку. И скорость которую "намеряете" таким образом не будет иметь ничего общего с реальной скоростью выполнения команд.

Arlleex вам всё правильно написал. ARM - это не AVR, ногодрыгательные подходы для него уже не применимы. Для измерения задержек выполнения команд следует пользоваться DWT.

Всё правильно - gpio вносит задержки, и мой осциллограф тоже. Но мне бы сейчас разобраться с гораздо бо́льшими задержками, которые вносятся, елки-палки, обработчиком команд!

14 часов назад, jcxz сказал:

Поставьте обе 

LDR	R6,	[R5]

друг за дружкой, и число тактов тоже должно упасть.

Дело не только в шинах. Изучите документ: https://www.cse.scu.edu/~dlewis/book3/docs/Cortex-M4%20Instruction%20Timing.pdf

чтобы понимать - от чего зависит скорость выполнения LDR/STR на Cortex-M4+. И как её увеличить.

Он касается всех Cortex-M4+, вне зависимости от производителя и его конфигурации шин.

 

А вот за это спасибо. Похоже, что в этих деталях кроется самое основное.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

11 часов назад, jcxz сказал:

Что-то не так сделали.... должно быть 8 байт.

@adnega считает общую занимаемую память: команда + литеральный пул...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

43 минуты назад, Arlleex сказал:

@adnega считает общую занимаемую память: команда + литеральный пул...

Вот именно: 4 + 4 = 8   Первый класс школы, если что  :wink:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...