[Arlleex 131]

Ну "в каком-то из STM32" максимум 72МГц, что-ж Вы с ним не сравниваете?

Я не просто так написал

...при прочих равных условиях (главным образом, процессор Cortex-M4F).

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

Например (говорю по памяти) в Tiva 256-битная шина к памяти.

1. А в STM32 128-битная шина и ART-ускоритель памяти.

2. В Tiva-C до 120МГц максимум, STM32 линейки F4 (на том же проце) уже 180Мгц.

3. В Tiva-C производительность 150 DMIPS, в STM32 все той же линейки уже 225 DMIPS, как видно производительность на 1МГц частоты одинаковая, но STM32 выигрывает все-таки уже из-за более высокой частоты, кто бы что ни говорил.

4. Что в Tiva-C, что в STM32F4 по 256кБ RAM. Более того, в STM32F469 уже даже 384кБ RAM.

По периферии возможно, да, Tiva-C в некотором смысле привлекательнее, на первый взгляд (возможно и на второй, и на третий в некоторых приложениях).

Что за рекламный ход? Где такое написано? И на кой ляд это нужно (практически, а не теоретически)?

Наверное возможно для каких-то протоколов, но ЗАЧЕМ???

Про рекламный ход нигде не написано, но производители МК любят приукрасить свои камни. Я помню как в STM32F429 хвалили на семинаре в Москве их супер-пупер LCD-TFT контроллер. А по факту в реальном проекте применить его можно было с небольшими программными костылями из-за аппаратного бага в связке NOR-Flash + SDRAM. Зато сколько понтов было у представителей, когда они из внутренней Flash картинку на экран выводили... Стоило мне взять экран побольше разрешением, да повесить NOR-Flash + SDRAM, как понял, какие же они чудаки на букву м.

Я вот сейчас пишу прошивку на МК, который стоит на плате и выполняет вспомогательную функцию для ZYNQ7000 - следит за напряжениями питания, датчики опрашивает, да с пользователем общается. И одну I2C-шную микросхему уже было невозможно к ZYNQ7000 прицепить - остался только UART. Вот и пришлось завести ее через МК, а МК уже по UART отдает данные. Получился такой программный мост - I2C-UART. А мне об этих данных вообще знать не нужно - если бы такой мост можно было бы сделать аппаратно в XMC4800 - это был бы существенный плюс. Ну по крайней мере хотя бы попробовать задумку, если бы не получилось - программно в любом случае обыграть можно.

Более сложной и функциональной периферии и связки периферия+DMA+service_request-ы я не видел ни в одном Cortex-M.

Scatter-gather DMA в XMC4800 конечно выглядит очень вкусным, тут я полностью согласен. Но самое главное, чтобы за этой сложностью не потеряться в трех соснах.

Изменено 6 мая, 2018 пользователем Arlleex

[jcxz 184]

3. В Tiva-C производительность 150 DMIPS, в STM32 все той же линейки уже 225 DMIPS, как видно производительность на 1МГц частоты одинаковая, но STM32 выигрывает все-таки уже из-за более высокой частоты, кто бы что ни говорил.

Вы внимательнее прочитайте, что я написал: при выполнении линейного кода из флешь. А теперь посчитайте например за сколько тактов выполнится блок инструкций в 128-и битах? А если все (или многие инструкции 32-битные)? И сколько тактов нужно чтобы дочитать следующий блок на данной частоте МК? А теперь подумайте что в Tiva этот блок в 2 раза больше.

После этого увидите, что бОльшая частота не даёт никакого выигрыша в случае линейного кода из флешь. А вот более широкая шина (и бОльшая частота шины) - даёт.

И в Tiva тоже кстати есть кеш инструкций. Хоть и небольшой. Но скорость выборки по широкой шине такова, что во многих случаях никакие акселераторы и не нужны.

Так что STM32 даже на бОльшей частоте может запросто проиграть по скорости Tiva если код не влазит целиком в его кеш.

 

4. Что в Tiva-C, что в STM32F4 по 256кБ RAM. Более того, в STM32F469 уже даже 384кБ RAM.

Опять же ещё раз открываем моё исходное сообщение и ещё раз внимательно перечитываем (раз не получается с первого раза):"когда мы выбирали Tiva для своего проекта".

Так вот - когда мы выбирали Tiva для своего проекта, у неё было 256КБ ОЗУ, а в самом жирном из тогда имевшихся STM32 - всего 192КБ (насколько помню).

 

А мне об этих данных вообще знать не нужно - если бы такой мост можно было бы сделать аппаратно в XMC4800 - это был бы существенный плюс. Ну по крайней мере хотя бы попробовать задумку, если бы не получилось - программно в любом случае обыграть можно.

Не очень понятно как вообще можно просто так передать из I2C в UART без какой-либо обработки протокола? Уже хотя бы потому, что I2C - это не просто поток байтов, а ещё и старты/стопы и адресации и переключение передача/приём и т.п. Собственно на аппаратном уровне в UART каждый байт - это независимый элемент (кадр), а в I2C кадр - это много байт.

Какой-то протокол должен быть. Возможно, что если этот протокол - ваш самопальный, то возможно, что его можно приспособить для полностью аппаратной обработки. Но мне кажется, что программная обработка будет просто легче и займёт меньше ресурсов МК. А о скорости тут вообще речь не идёт. Поэтому не вижу смысла городить огород на пустом месте.

 

Scatter-gather DMA в XMC4800 конечно выглядит очень вкусным, тут я полностью согласен.

Я не о том. В Tiva сделали очень грамотно, когда от каждой периферии умеющей генерить burst-DMA-запросы вывели два сигнала DMA-запросов: собственно burst и single. Одновременно. И обработку этих запросов в DMA-контроллере сделали по уровню, а не по edge. Вот в XMC к сожалению до этого не додумались и там с этим связано много проблем.

 

PS: В первую очередь советую Вам сразу же на купленной плате проверить ревизию чипа (XMC). И перепаять на последнюю.

У нас на EVB с XMC стояли инженерные образцы и я наступил сразу на несколько багов из ерраты. Пришлось их перепаивать.

В инженерных образцах много багов. Причём серьёзных. Но в серийных образцах баги уже не страшные.

Да: и у Infineon какая-то странная манера оформления еррат - те баги, что устранены в новых ревизиях чипа, из ерраты удаляются (не комментируются как относящиеся к такой-то ревизии, а просто удаляются!). И на сайте выложена еррата для последней ревизии. А для старых ревизий на сайте тоже есть ерраты (в архиве), но они не сразу находятся.

Так что имейте в виду.

[Arlleex 131]

Вы внимательнее прочитайте, что я написал: при выполнении линейного кода из флешь. А теперь посчитайте например за сколько тактов выполнится блок инструкций в 128-и битах? А если все (или многие инструкции 32-битные)? И сколько тактов нужно чтобы дочитать следующий блок на данной частоте МК? А теперь подумайте что в Tiva этот блок в 2 раза больше.

Да какая разница сколько тактов будет выполняться блок инструкций в 128 битах? Все эти prefetch-буферы и ускорители, а в Вашем случае более широкая шина необходима лишь для обеспечения zero-wait-state при чтении из Flash (значит 4 32-битные инструкции за 4 такта будет выполнено). Для Tiva, поскольку в нем ускорителя нет, сделали более широкую шину, для STM32 - поставили ускоритель. Но лишь для одной цели - получить нулевое ожидание при доступе к данным или инструкции при чтении из Flash. А раз это условие выполнено, то STM32 выигрывает, поскольку может исполнять линейный код с бОльшей частотой. Какая разница какая там шина, если что там, что там задержка при чтении из Flash отсутствует при чтении линейного кода? Между заполнениями 128-битных строк ускорителя тоже 0 циклов ожидания, так что при вычитке следующих 4 инструкций никакого ожидания не происходит.

Опять же ещё раз открываем моё исходное сообщение и ещё раз внимательно перечитываем (раз не получается с первого раза):"когда мы выбирали Tiva для своего проекта".

Хорошо, с этим понятно.

Не очень понятно как вообще можно просто так передать из I2C в UART без какой-либо обработки протокола? Уже хотя бы потому, что I2C - это не просто поток байтов, а ещё и старты/стопы и адресации и переключение передача/приём и т.п.

Ну, скажем, сформировать старт-стоп можно. А вот все пересылки данных ничем не отличаются между I2C и UART. Внешнее устройство пишет в UART какой-нибудь зарезервированный символ - XMC4800 формирует старт-условие. Дальше устройство пишет физический байт адреса по UART - он транслируется в I2C-шную посылку. И все остальные байты передаются либо принимаются (тем более UART полнодуплексный). По завершении транзакции XMC4800 формирует стоп-условие. Правда для этого XMC4800 нужно знать длину записываемых/считываемых данных для корректной работы логики запуска DMA. Ну опять же, это все мысли вслух, и если уж докопаться, то можно разных изворотов придумать, как угодно творческой душе разработчика (и не надо вот сейчас говорить что это сплошной бред и т.д., порой причудливые решения куда лучше справляются с задачей).

И обработку этих запросов в DMA-контроллере сделали по уровню, а не по edge. Вот в XMC к сожалению до этого не додумались и там с этим связано много проблем.

А какие преимущества запроса по уровню, а не по фронту?

PS: В первую очередь советую Вам сразу же на купленной плате проверить ревизию чипа (XMC). И перапаять на последнюю.

...

Так что имейте в виду.

Жесть Ревизию гляну как доберусь до платки. Спасибо, буду знать.

[jcxz 184]

Между заполнениями 128-битных строк ускорителя тоже 0 циклов ожидания, так что при вычитке следующих 4 инструкций никакого ожидания не происходит.

Да ладно?!... Похоже вы так и не взяли калькулятор и не посчитали... :(

4 инструкции в 128-битной строке кеша (допустим все они 1-тактные) - значит 4 такта. А сколько тактов wait-states требуется STM32 на 180МГц на выборку очередной порции данных из кеша при кеш-промахе? 7 или 8? И как позвольте узнать будет 0 тактов ожидания между заполнениями строк, если вся строка выполняется за 4 такта, а на чтение новой нужно 8 тактов??? (ещё раз - разговор про линейный код, или линейный участок кода по-крайней мере такой длины, что не влезает в кеш; т.е. - имеют место кеш-промахи).

И "ускоритель" в STM32 как я понимаю - это и есть просто кеш команд. Ну так в Tiva он тоже есть, только маленький.

 

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

Прочитаете мануал - разберётесь с возможностями.

Например у меня на XMC была задача: необходимо было передать из одного устройства на XMC в другое (на XMC) по UART небольшой пакет с данными (результаты вычислений). Кроме самих данных необходимо было в этой же пересылке передать и время получения этих данных на устройстве-источнике данных (в некий момент времени Т на устройстве-источнике данные считываются с АЦП, над ними выполняется ряд математических операций, полученный результат отправляется устройству-приёмнику, а также устройству приёмнику нужно передать момент времени чтения данных из АЦП (устройство-приёмник должно знать когда было чтение по его собственным часам) с максимально-возможной точностью, желательно до такта CPU).

Так вот я сделал примерно так: от таймера, который своим сигналом S1 запускает преобразование АЦП, также через некоторое время T2 (несколько мкс) генерится сигнал S2, запускающий передачу содержимого FIFO UART-а. По прерыванию завершения преобразования АЦП в ISR обрабатываются данные и записываются в FIFO UART. Время преобразования АЦП + время вызова и работы ISR заведомо меньше T2. Значит сигнал S2 возникает в момент когда данные для передачи уже лежат в FIFO.

В принимающем XMC я первый перепад на линии RX.UART (начала старт-бита) фиксирую таймером. Получается синхронизация ведущий-ведомый с точностью до такта частоты тактирования таймеров. И без джиттера!

На каком еще МК можно сделать подобное? Я таких не знаю. :laughing:

 

А какие преимущества запроса по уровню, а не по фронту?

Я где-то в этой теме (а может другой, но недавно) уже подробно описывал какие проблемы возникают при генерации DMA-запросов по перепаду уровня заполненности FIFO. Не хочу повторяться. Так вот: DMA-event-ы "по уровню" полностью снимают эти проблемы.

Вот оно: https://electronix.ru/forum/index.php?showt...t&p=1558972

[Arlleex 131]

Да уж, я думал я один изворачиваюсь с периферией как только можно

Ну а насчет количества тактов, кешей и выигрыша в широкой шине - ничего не буду говорить. У меня есть две платы - одна на Tiva-C (Cortex-M4, 80МГц) и STM32F4 (Cortex-M4, 180МГц). Напишу линейный длинный код на ассемблере, буду фиксировать контрольные точки таймером. Сравню результаты. Ибо, судя по описанию STM-овцев, их ART-ускоритель при линейном коде как раз-таки и работает на максимальную производительность - код не перепрыгивает никуда, не нужно перезаполнять строки кэша, как только выкачали 128 бит и начали их выполнять, тут же подкачивается еще 128 бит и т.д.

В общем, если будет время на неделе - отпишусь, что получилось. Пока что не верю :laughing:

[Arlleex 131]

Итак, ради интереса сделал тест.

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

Предварительно процессор настраивается на 180МГц, количество тактов процессора, затрачиваемое на чтение 128 бит из Flash - 6 циклов (5WS).

Код теста:

        AREA MY_PROGRAM, CODE, READONLY
        
        ENTRY
        
MyProg    PROC
        
        EXPORT Main
        
DWT_CYCCNT    EQU    0xE0001004
DWT_CONTROL    EQU    0xE0001000
SCB_DEMCR    EQU    0xE000EDFC

Main
        ldr r0, =SCB_DEMCR
        mov r1, #0x01000000
        str r1, [r0]
        
        ldr r0, =DWT_CONTROL
        ldr r1, [r0]
        mov r2, #0x1
        orr r1, r2
        str r1, [r0]
        
        ldr r0, =DWT_CYCCNT
        mov r1, #0x0

        b loop
        
        LTORG

loop
        str.w r1, [r0]
        
        mul.w r3, r4, r5
    ; ...
    ; ТЫСЯЧА ТАКИХ ИНСТРУКЦИЙ
    ; ...
        mul.w r3, r4, r5
        
        ldr.w r2, [r0]
        
        b.w loop
        
        ENDP

        END

Инструкции как раз подобраны наихудшие: 1 такт исполнение, 32-разрядные из набора Thumb-2.

 

1. Отключаю кэш инструкций и данных, отключаю prefetch-buffer выборки.

2. Запускаю код на исполнение под отладчиком без точек останова.

3. Пока код выполняется, ставлю точку останова на строку

b.w loop

и смотрю содержимое регистра R2 (считанное значение в 180МГц тактах): 0x8CB = 2251.

4. Время математики: 1000 однотактных 32-разрядных команд, 1000/4=250 циклов обращения к Flash-памяти по 128 бит. С учетом того, что WS=5, 5*250=1250 тактов накладных расходов на ожидание доступа к данным. Прибавляем такты выполнения команд: 1250 + 1000 = 2250. Что на 1 такт меньше считанного показания с системного регистра. Двигаемся дальше.

5. Включаем prefetch-buffer выборки и повторяем шаги 2-3. Содержимое CYCCNT = 1501.

6. Выключаем prefetch-buffer, включаем кэш. Содержимое CYCCNT = 2250. По-моему логично, поскольку в кэше хранятся адреса команд начала последних использованных подпрограмм и веток кода, а не сам код (в документации вроде про это написано).

7. Включаем prefetch-buffer и кэш. Содержимое CYCCNT = 1501.

 

Как видно, при включенном буфере предвыборки будет потеря производительности, однако если в коде будут использованы не только 32-разрядные инструкции Thumb-2, а 16-разрядные, скорее всего количество тактов совпадет с количеством инструкций между метками замера. Замерил - CYCCNT = 1001.

Отключаю prefetch - CYCCNT = 1251. Интересно, почему сейчас 1251, ведь 8 однотактных инструкций перекрывают 5WS при доступе к Flash... Это пока под вопросом, я разберусь.

 

Собственно говоря, этих сведений мне достаточно, чтобы полагать, что большого толку от широкой шины на Tiva-C не будет. Она сделана точно для таких же целей, для каких и ART-ускоритель в STM32 - обеспечить нулевое состояние задержки при выполнении смешанного (32-разрядного и 16-разрядного) кодов Thumb и Thumb-2.

Если сравнивать производительность выполнения 32-битного кода Thumb-2 STM32, работающего на частоте, допустим, 150МГц, над производительностью Tiva-C, работающего на 120МГц при выполнении того же 32-битного кода, то плюс широкой шине - бесспорно предвыборка 8 команд лучше чем предвыборка 4. Однако на реальной практике код представляет из себя смесь 16- и 32-разрядных инструкций, поэтому подобный метод расчета производительности не годится, нужны данные CoreMark или Dhrystone.

[jcxz 184]

7. Включаем prefetch-buffer и кэш. Содержимое CYCCNT = 1501.

Только зачем было делать столько телодвижений если уже из теории и следует эта цифра (250_выборок * 6_тактов_на_выборку = 1500) ? :laughing:

Ваши измерения как раз и совпадают с теорией - значит выполнены правильно. :laughing:

 

Как видно, при включенном буфере предвыборки будет потеря производительности, однако если в коде будут использованы не только 32-разрядные инструкции Thumb-2, а 16-разрядные, скорее всего количество тактов совпадет с количеством инструкций между метками замера. Замерил - CYCCNT = 1001.

Опять-же - берём в руки калькулятор и считаем:

Чтобы при длительности выборки ==6 тактов не было простоев из-за недозагрузки prefetch, нужно чтобы команды из этой выборки выполнялись как минимум те же 6 тактов.

А это возможно при 2*4+4*2 - т.е. в prefetch-пакете 2 шт. 32-битных команд + 4 шт. 16-битных. Т.е. - соотношение 32-битных к 16-битным должно быть как минимум 1/2.

А теперь возьмите и посмотрите код любого тяжёлого фильтра или какого-то другого тяжёлого алгоритма обработки данных, либо просто - большую сложную и хорошо оптимизированную функцию (в которой используется много регистров). Увидите, что подавляющее большинство команд как раз - 32-битные.

Только в простых функциях, где используется мало регистров, только в них бОльшее большинство команд 16-битные.

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

Конечно в таком потоке команд не будут все команды только однотактные. Предположим что в prefetch-блоке одна инструкция типа LDR или STR. Но тогда всё равно получается:

по размеру 3*4+2*2 = 16байт; по тактам 2+1+1+1+1 = 6тактов - только если в prefetch-блоке 3 команды 32-битные (одна из них - LDR/STR) + 2команды 16-битные - это граничный случай когда всё будет ещё успевать работать без остановок выполнения. А в реальном коде тяжёлых вычислений процентная доля 32-битных команд будет (имхо) всё-таки повыше.

А теперь ещё осталось вспомнить, что разговор идёт о Cortex-M4F. И вычисления с большой вероятностью будут не целочисленные, а с плавающей точкой. А где Вы видели 16-битные инструкции с float? А теперь ещё вспомним что регистров FPU гораздо больше чем целочисленных, что позволяет строить код с малым числом обращений с памяти, т.е. - на однотактных инструкциях в основном. Вот здесь то и получим существенную разницу.

 

Однако на реальной практике код представляет из себя смесь 16- и 32-разрядных инструкций

Да, Вы как-нить посмотрите на реальный код тяжёлых вычислений. Не тот код, который в обычных функциях со множеством ветвлений и малым количеством регистровых переменных, а на действительно вычислительный код (тем более с float). Ибо для обычных задач этих 120МГц и так - за глаза, а производительность я оценивал только для вычислительных задач.

Да, и ещё раз повторю: когда мы выбирали Tiva, не было STM32 на 180МГц, а были только максимум на 168МГц. А это разница по частоте всего на 40%. И часть из этих 40% покроется за счёт более широкой шины Tiva, так что останется выигрыш может процентов 20% (а в каких-то отдельных случаях может быть ещё и проигрыш, например - ISR со множеством переменных, редко выполняющийся (вытесненный из кеша) на Tiva может выполниться даже быстрее). А разница в 20% уже была для нас несущественна, на фоне выигрыша по ОЗУ и лучшей периферии.

 

Да и вообще: более слабая периферия приводит к дополнительным накладным вычислительным расходам (в случае STM32), что ещё сокращает разницу в скорости ядер. Уж не говоря о том, что многое из того, что мы сделали на Tiva, было невозможно сделать на STM32 (даже нонешних 180МГц). Это множество последовательных интерфейсов с полноценным FIFO и DMA, а также dual-SPI который позволили увеличить скорость работы с SPI-FLASH. А на STM32 мы бы ещё скорей всего не пролезли по скорости доступа к SPI-FLASH.

[COMA 1]

Я для себя определил два варианта для перехода:

серия i.MX RT либо серия STM32H7

[Arlleex 131]

Только зачем было делать столько телодвижений если уже из теории и следует эта цифра (250_выборок * 6_тактов_на_выборку = 1500) ?

Ваши измерения как раз и совпадают с теорией - значит выполнены правильно.

Теория, подтвержденная практикой - залог хорошего понимания природы вещей

Просто очень любопытно стало, и протестил, пока время есть.

А вот насчет 1250 тактов при всех инструкциях в 16 бит не могу понять, как так получается. Перерыл кучу документации, есть даже вот такая картинка:

 

Но как бы я ни строил график растактовки конвейера, все равно не получается там 1250. Даже при учете, что процессор считывает сразу 2 инструкции, но декодинг все-таки последовательный, все равно не совпадают расчеты. Откуда там два лишних такта берется на выборку каждых 128 бит из Flash - не пойму.

Да и рисунок выше какой-то не шибко понятный, слова "инструкции, после того как извлечены, могут несколько тактов тупить прежде чем процессор их декодировать начнет" - с чего бы это, казалось бы? "До двух инструкций может быть выбрано за одно чтение" - а вот этот механизм вообще интересен. Как процессор понимает, что перед ним 32-битная или 16-битная команда? По идее он всегда читает 32 бита и смотрит на поле кода операции, ну да ладно, с этим понятно. Ну а если он читает такой порядок:

1. instr 1 (16 bit);

2. instr 2 (16 bit);

3. instr 3 (16 bit);

4. instr 4 (32 bit);

5. instr 5 (32 bit);

6. instr 6 (16 bit).

 

Вот забирает он первые 32 бита и понимает, что там первая инструкция 16-битная, и потом декодирует вторую инструкцию - понимает, что она 16-битная тоже.

Забирает он следующие 32 бита. Декодирует первую команду, смотрит на код операции второй команды - а она 32-битная оказывается. Надо дочитать еще 16 бит с шины. Считывает 32 вместо 16. Декодирует уже полное слово. В буфере у него остались 16 бит 5-й инструкции. Она тоже 32-битная - он опять делает такие махинации. Потом из буфера забирает шестую инструкцию и декодирует, она 16-битная, все в порядке.

Однако вроде как утверждается, что даже рядом стоящие команды смешанной разрядности не влияют на количество тактов их выполнения. Как оно тогда устроено?

 

P.S. Отвечаю сам себе на второй вопрос. Логика придумалась в голове + наблюдения за PC в отладчике:

1. Процессор всегда считывает целое слово в регистр команды по адресу, который хранится в PC.

2. Процессор декодирует старшее полуслово (см. ARMv7M Architecture Reference Manual) и смотрит, 16- или 32-битная эта команда:

- если 16-битная, процессор ее выполняет и увеличивает PC на 2;

- если 32-битная, процессор обрабатывает ее как 32-битную и увеличивает PC на 4.

После этого логика переходит на п.1 и так по кругу.

 

На первый вопрос (откуда 1250 тактов) ответа пока что не нашел.

Изменено 9 мая, 2018 пользователем Arlleex

[Arlleex 131]

Итак, выложу сюда две растактовки из экспериментов.

1. WS = 5, Prefetch-OFF, 32-bit Thumb-2 command.

Здесь A - Addressing cycle, F - Fetch, D - Decode, E - Execution.

 

Для выполнения 4 полноценных 32-битных команд необходимо 9 тактов.

1000/4 = 250 обращений к памяти, соответственно, 9*250 = 2250 тактов - это время выполнения 1000 32-битных команд.

 

2. WS = 5, Prefetch-ON, 32-bit Thumb-2 command.

Здесь A - Addressing cycle, F - Fetch, D - Decode, E - Execution.

 

Для выполнения 4 полноценных 32-битных команд необходимо 6 тактов, поскольку при первом Fetch адресуются следующие 128 бит Flash-памяти устройством Prefatch-ера, и в итоге мы получаем перехлест в 2 такта в сторону понижения производительности.

1000/4 = 250 обращений к памяти, соответственно, 6*250 = 1500 тактов - это время выполнения 1000 32-битных команд.

 

3. WS = 5, Prefetch-OFF, 16-bit Thumb-2 command.

Пока что пусто, т.к. не понимаю как ведет себя процессор и подсистема pipeline с 16-битными инструкциями.

4. WS = 5, Prefetch-ON, 16-bit Thumb-2 command.

Очевидно, станет понятно, если прояснится п. 3.

Изменено 9 мая, 2018 пользователем Arlleex

[jcxz 184]

Итак, выложу сюда две растактовки из экспериментов.

1. WS = 5, Prefetch-OFF, 32-bit Thumb-2 command.

А какой практический смысл в отключении предвыборки?

[Arlleex 131]

Никакого абсолютно. У меня в проектах он всегда включен.

Поэтому чисто спортивный интерес к поведению процессорного устройства.

 

Пишут в документации, что при напряжении питания менее 2.1В prefetch необходимо отключать. При этом процессор может тактироваться до 120МГц. Поэтому в некоторых случаях и будет необходимо знать растактовку CPU на 16-битных командах.

 

Вот еще пример, когда предвыборку отключать желательно. Я понимаю, что это косяк только STM32, скорее всего, но чем не причина...

Изменено 9 мая, 2018 пользователем Arlleex

[Arlleex 131]

Подниму свою же тему.

1. Программировал платку с XMC4800. И хотел найти ревизию MCU - беглым взглядом кроме как в обозначении самой микросхемы не нашел в Datasheet. На сайте у них все XMC4800 имеют последние две буквы AA. Глянул на МК помладше - там есть позиции AA, AB, AC... Я так понял это и есть ревизия?

2. Где узнать, какая ревизия ядра Cortex-M4F там стоит? Тоже довольно немаловажная информация, по которой лучше сразу скачать документацию нужной ревизии.

 

P.S. Отвечаю сам себе же.

Так же как и во всех других Cortex-Mx - в регистре IDCODE ревизия MCU, в CPUID - версия CPU.

Изменено 6 июля, 2018 пользователем Arlleex

[jcxz 184]

1. Программировал платку с XMC4800. И хотел найти ревизию MCU - беглым взглядом кроме как в обозначении самой микросхемы не нашел в Datasheet. На сайте у них все XMC4800 имеют последние две буквы AA. Глянул на МК помладше - там есть позиции AA, AB, AC... Я так понял это и есть ревизия?

Да. Для XMC4500 и XMC4700 - так и есть. Пишется в 3-й строчке на корпусе чипа.

 

PS: Ну и как впечатления от чипа? B)

[Arlleex 131]

PS: Ну и как впечатления от чипа? B)

Ага, спасибо.

А впечатления, ммм, ну как бы кратко так сказать - это не STM32. Регистров действительно дофига и все расплывается в голове. Но это, думаю, временно :laughing: