Излазил его наверно больше, чем все здесь на форуме , но кроме видеокорок все доки есть, изменил параметры sdma, чтоб работал, как dma2d, 3D вообще без надобности, остальное все было.
Ну и проц и видеоблок в нем на порядок круче, чем все стм и иже с ними..



FPU - да нет так нет..
С уартом можно использовать фифо "Separate receive / transmit 64/16 bytes entry FIFO for data payloads"

С спи - даже фифо не сделали - неуд!

ЗЫ. Это все-таки считается application processor, поэтому уж что есть Ну и usb типа EHCI - это совсем неплохо...

Почему "медленного"? Там же вроде - до 300МГц. При том что STM32 максимум 180МГц.


В нём UART имеет FIFO глубиной 64 байта - с таким FIFO и DMA не нужно. А вот для SPI оно очень даже нужно.

Вы его помнится без Linuxа запускали, я так понял осилили?


sdma не может заменить полноценно dma2d - фактически получится делать только две функции: заливка и копирование (аналогичный блок есть даже в древних i.mx287). А ведь прелесть DMA2D в растровых операциях, которые позволяют выводить шрифты, делать наложения с прозрачностью и т.п. без участия процессора.

Хотя с другой стороны быстродействие у i.mx6 даже если весь вывод графики делать процессором наверное всеравно будет поболее, чем у stm32f4+dma2d.


Потому, что по тестам (на сахаре тестировали как-то) у него выходило 5MFLOPS, а у stm32f4 32MFLOPS - FPU это сила (если конечно плавающая точка нужна). На целочисленных операциях наверное Nuvoton немного быстрее будет, но stm32f7xx (Cortex-M7) уже будет лучше с любой стороны.

Почему не сделали?:
Configurable bit length of a transaction from 1 to 32-bit and can be configured as burst mode, totally128-bit can be transmitted at one time
128 бит - какое-никакое но FIFO. В STM32 и такого нет


Понятно что программная эмуляция будет гораздо медленнее аппаратного FPU! Что тут тестировать? Странно ещё что такая маленькая разница всего в 6 раз.
А вот насчёт "любой стороны" я бы не был так категоричен.
Какой размер кеша на stm32f7xx? А с какой частотой работает flash программ у него и какова ширина шины выборки команд из flash программ?
А каково время входа в прерывание на stm32f7xx?

Это никак не FIFO - скорее извращенный DMA (на 4ре слова ). stm32 запросто может такое делать даже древние stm32f1xx. Единственно, что хорошо у Нувотоновского SPI это возможность задать произвольную длину "слова". У меня, например, с одним из девайсов обмен ведется 24битными словами и в нынешней реализации у STM это очень неудобно.


4K+4K, но у него еще есть ITCM (16K) и DTCM (64K), а еще есть 256K быстрого ОЗУ. Для большинства решаемых задач требующих максимальной производительности ядра это более выгодная конфигурация.


ITCM RAM работает на частоте ядра , флеш 256битный. В случае "промаха" потребуется 8циклов (на частоте 216МГц), чтобы вычитать данные из флеша, если ART не промахивается, то исполнение идет без задержек.

От меня встречный вопрос - сколько потребуется циклов Нувотону, чтобы вычитать данные с произвольного адреса из DDR2 памяти работающей на 150МГц? А если учесть, что по той же шине данные скармливаются на контроллер LCD и обрабатываются DMA2D, то все станет очень грустно.

В stm32f7xx/f4xx такая архитектура, что можно минимизировать задержки из-за обращения ядра/DMA2D/LTDC к одним и тем же интерфейсам/шинам.


У Cortex-Mx по этой части все будет много лучше ARM9. Фактически линейка Cortex-Mx создавалась с учетом минимизации отклика на прерывания.

Сообщение отредактировал Шаманъ - May 25 2016, 06:31

Почему это? Вполне себе обычный FIFO.


У Нувотона кроме кеша кода есть кеш данных, который размером 16К, который сгладит проблемы с доступом к коду и данным в одной области RAM.
А вот что будет когда Вы код разместите в "256K быстрого ОЗУ" откуда и данные надо выбирать.
У Nuvoton тоже есть отдельная SRAM, где можно разместить быстрые данные, чтобы они не мешали выборке команд.

Размер кеша в 4 раза больше + частота почти в 1.5 раза выше - я бы в большинстве задач (не связанных с float) поставил на Nuvoton, а не на stm32f7xx.
Да и float часто маловато, нужен double, а тогда преимущество от аппаратного FPU полностью пропадает.


Правда что-ли?
А то что для входа/выхода в прерывание в Cortex-M необходимо как минимум сохранить/восстановить 8 слов на стеке, в то время как ARM9 для входа в прерывание просто переключает режим CPU.
Если нужна очень быстрая реакция на какое-то прерывание, то ARM9 для этого гораздо лучше подходит с его системой прерываний.
Если нужны вложенные прерывания или переключение контекстов, то здесь ARM9 хуже конечно.

Да и вообще - у ARM9 есть огромный плюс перед Cortex-M - это полноценный MMU. Позволяющий делать гибкую защиту памяти. Мне этого очень не хватает в Cortex-M.

FIFO это когда Вы пишите в один и тот же регистр, а данные уходят в порядке записи. А здесь четыре отдельных регистра, так что на FIFO никак не тянет.



Я же написал 4К+4К - у stm32f7xx тоже есть кэш данных. Кроме того код у Cortex-M7 скорее всего будет компактнее.


А Вы что не в курсе, что Cortex-Mx как правило быстрее работают из флеша и никто в обычном ОЗУ код не размещает. Для этого есть ITCM на отдельной шине.


Размер кэша больше в 4 раза, а SRAM меньше почти в шесть раз, плюс у stm32f7xx есть ITCM/DTCM (это может быть часто даже лучше кэша). Частота в 1.5 раза выше, но Cortex-M7 выдает 2.14DMIPS/MHz, а ARM9 только 1.1MIPS/MHz.


А то, что ARM9 не умеет прерывать load/stor multiple и подобные инструкции (в принципе этого уже достаточно, чтобы максимальное время было у ARM9 больше), не умеет делать tail-chaining, не умеет обрабатывать late-arriving? Да и регистры обычно нужны в прерывании. Сейчас начнете про FIQ рассказывать, но как правило его можно либо к какому-то одному источнику подключить, либо придется анализировать флаги от кого прерывание - думаете быстрее выйдет? В общем случае нет.


Ой ли...


Вот объясните, если сторонний код (который может убить систему) у меня не запускается, а все ПО написано мною зачем мне ММУ?

Сообщение отредактировал Шаманъ - May 25 2016, 08:28

FIFO - это не количество регистров, это буфер, служащий для уменьшения кол-ва прерываний/DMA-транзакций. Вне зависимости от того как устроена запись в него.


Да ну?! Неужто Cortex-M уже каждый такт умеет 2 с лишним команды выполнять?
Меньше читайте рекламных буклетов и больше смотрите систему команд. Что ARM9 что Cortex-M в части наиболее употребительных команд - все однотактовые и примерно одинаковые.
Вот в части всяких сложных а-ля DSP-расширений - там есть разница. Только сколько такого кода в реальных проектах?


Быстрее конечно. Так как не надо ни сохранять регистры, ни грузить рабочие переменные/указатели. Огромный выигрыш.
И очень часто у меня бывает, что в изделии есть один источник высокочастотных прерываний, которые надо обрабатывать как можно быстрее. Не много, а всего один. И ARM7/9 здесь выигрывает значительно.


Ну если Вы только Hello world пишете, то определённо не нужно. А у меня бывают проекты по нескольку десятков тысяч строк. Да ещё как правило несколько человек пишут.

https://mohammadthalif.wordpress.com/2011/1...mips-and-dmips/

FIFO это не либой буфер, а это буфер организованный особенным образом (не думал, что нужно объяснять), и 4ре отдельных регистра с произвольным доступом это может быть что угодно но не FIFO.


Качаем http://infocenter.arm.com/help/topic/com.a...rtex_m7_trm.pdf
Читаем:


Также читаем:
http://infocenter.arm.com/help/index.jsp?t....faqs/4160.html


Аналогичную цифру для stm32f7xx я уже приводил выше - 2.14DMIPS/MHz можете посмотреть сами у STM в доках.


Да огромный выигрыш, как же. Если основная программа выполняет инструкцию с загрузкой/выгрузкой нескольких регистров (а их может быть и 10, и больше), то пока она не закончится Вы даже не сможете начать обрабатывать прерывание. При этом стек будет лежать в кэшируемой области по-любому (а можно и в DTCM положить ), а вот загрузка-выгрузка может производиться и в некэшируемую область со всеми последствиями.


Ну в том проекте который собирается переезжать на сегодняшний день около 20тыс. строк, правда это не только код для обсуждаемого ARMа (там еще есть двухядерный DSP ) - чуть больше Hello word

Вам если и нужно, то MPU, а не MMU. MMU нужно если Вы собрались виртуальные адресные пространства организовывать и подобные вещи. Обычно это нужно когда будут запускаться сторонние программы - т.е. речь о совсем других системах. Кстати Cortex-M7 может быть с MPU

Вот типичный код для M4:

За сколько тактов выполнится на M7 и на ARM9? Считая что нет ожиданий памяти и т.п. Правильно - примерно одинаково.
Всё эти DMIPS-ы достигаются на сложных а-ля DSP командах, выполняющих несколько операций за команду. В обычном коде (не процедуры сигнальной обработки) такхи команд встречается оч. мало.
А такой код будет выполняться быстрее на CPU с большей тактовой.
Или M7 сможет автоматически запараллелить выполнение каких-то команд из этого кода?


И что? Ну пускай не может прервать. Только это всего одна команда.
А Cortex-M на вход/выход потратит одну такую операцию на вход (8 сохранений контекста),
потом в ISR надо загрузить как минимум один указатель да рабочую область ОЗУ с переменными, загрузить все переменные, перед завершением все переменные выгрузить (если нужно), восстановить контекст (8 чтений). Разницу ощущаете?


MPU у меня везде используется, но он слишком слаб: всего 8 регионов, минимальная гранулярность 32 байта (вроде) и регионы должны быть выровнены на границы кратные размеру. Это очень сильно сокращает возможности защиты. MMU не только для виртуализации, он и по защите гораздо более гибок. И кешем данных можно управлять удобнее с помощью него.

Пример еще более искусственный, чем тесты.


Да нет, на обычных тоже работает. Достаточно переставить у Вас команды и, если вычитываемые и записываемые данные окажутся в памяти на разных шинах (что довольно типично, например, загрузка констант из флеша в ОЗУ) каждая загрузка/сохранение будет выполнена одновременно.


Та одна команда может столько тактов утянуть... В ARM9 переменные в регистры загружать не надо? Вы о чем? После входа в ISR можно сразу работать. А вот с ARM9, если Вы собираетесь на С обработчик писать, будет засада, ибо рабочие регистры R0..R3 не переключаются при смене контекста.


Мне сложно представить задачу где нужно такое. Либо притянуто за уши, либо проблема с архитектурой ПО.

P.S. Что-то от темы мы сильно удалились... Я бы с удовольствием послушал mantech про standalone i.MX6. Интересно плата была своя или какой-то SoM использовался? Может это решение (в том числе и "на вырост" , а если четырехядерный поставить , то можно даже от DSP процессора избавиться, хотя это и не актуально, но все же...).

Сообщение отредактировал Шаманъ - May 25 2016, 12:33

Да, уже с год, как в контроллерах у пользователей работает. Самое сложное для меня было, это , как ни странно, Hello world запустить Просто есть там нюансы с подготовкой имиджа для заливки в камень, после того, как тест заработал, было уже гораздо легче, т.к. был pltform sdk.



Да, использовал готовый модуль, ибо по цене даже дешевле, чам самому ваять.
Думал 2х ядерный запилить, но ценник кусачий А в принципе - ничего такого пугающе сложного там нет. Этап 1 - запустить камень, подрыгать пинами. 2) инит уарта, вывод в printf. 3) запуск MMU и кешей(к сожалению, без MMU кэши не работают). 4) запуск контроллера прерываний(он там как у нувотона, с программным выбором вектора из таблицы). 5) делал собственный переключатель контента для многозадачности.
6) инициализация дисплейного контроллера (кстати, он многие функции DMA2D может делать, включая альфа-наложение и ресайзинг), портировал свой гуй... И пожалуй все!

Впечатления от видеоконтроллера - на четверочку, так и не смог запустить 2х канальный LVDS, причем по отдельности каналы работают "на ура", 2х канальный режим хотел для "мониторных" матриц использовать с большим разрешением, но пришлось довольствоваться HDMI.
По скорости - нет вопросов, ничего не моргает, и при ДМА и просто так(как ни как память DDR3 на 400МГц 32 бита)

Когда-то игрался с LPCшкой и сдрам на 100МГц, так при одновременной работе с ДМА и экраном начиналась рябь, что совсем не айс...

ЗЫ. Сейчас пока времени нет, хочу поднять аллвиннер А20 в стандалон, думаю, как в нем имидж создавать, чтоб хелловорд запустить. Ядро там почти такое-же, уарты стандартный 16550, мму, кэши, прерывания, усб все такое-же, как в мх6. Может кто пробовал? Просто платок с таким процом полно и цена демократичная...

Сообщение отредактировал mantech - May 25 2016, 20:32

А что там пробовать, если есть u-boot? А так A20 - процессор просто замечательный, с загрузкой только есть некоторые "приколы".

Почему искусственный? Это кусок реального листинга. Взятый наугад.


Ну если это действительно так и последовательность
STR R2,[R0]
LDR R3,[R1]
если R0 и R1 указывают в регионы памяти на разных шинах, будет выполнена за 1 такт, то тогда да - это большой плюс.
Хотя утверждать это по вышеприведённой цитате из TRM я бы не стал. Хотелось бы увидеть более конкретное доказательство.


Я о FIQ. И о том, что можно написать ISR, который будет уже хранить все рабочие переменные/указатели в регистрах R8-R14 без необходимости их загрузки при входе в ISR.
Таким образом можно получить наибольшую скорость реакции на прерывание.
Мне такие ISR как раз и приходилось писать. Конечно на асм.


Хмм... очень похоже на ARM9. Там тоже кеш данных без MMU не работает. Хотя кеш кода работает и без MMU.
Контроллер прерываний там как у ARM9 (IRQ, FIQ, банковые регистры состояний CPU, etc.)?