Новые ARM Cortex-M7 на 600 МГц Опции

[AlexandrY]

Объявлено о выходе на рынок семейства i.MX RT
Все STM32 остаются далеко позади.
Те кто долго и упорно изучал экосистему Freescale в лице Kinetis вознаграждены.
i.MX RT будет поддерживаться RTOS MQX и наверняка будет иметь периферию аналогичную Kinetis.
Всякие малинки тоже отдыхают и по цене и по производительности.

[__inline__]

Есть ли достойная замена STM32F... на частоте от 400 МГц, QFP корпус, внутренняя память не менее 512 кБ с железным подходом программирования?

[Aner]

Есть ли достойная замена STM32F... на частоте от 400 МГц, QFP корпус, внутренняя память не менее 512 кБ с железным подходом программирования?

Ну посмотрите наконец на Allwiner и им подобные SoC, ... я уже год как три проекта завершил. Поначалу были сомнения китай и все такое. В итоге уже не хочу на STM32 ... что то делать. Ну да там DDR3, DDR4, LVDS, многослойка, 0402, 0201, руками уже не очень ..., Linux, Android, ... На STM32F/H поддержка старых проектов только.

[AlexandrY]

Ну посмотрите наконец на Allwiner и им подобные SoC, ... я уже год как три проекта завершил. Поначалу были сомнения китай и все такое. В итоге уже не хочу на STM32 ... что то делать. Ну да там DDR3, DDR4, LVDS, многослойка, 0402, 0201, руками уже не очень ..., Linux, Android, ... На STM32F/H поддержка старых проектов только.

Насколько понимаю все эти переходы на DDR4, LVDS .. только ради GUI и HMI
Да и то от жадности, поскольку эффективные GUI и HMI предлагаются и для Cortex-Mx, но только за деньги.

[__inline__]

Насколько понимаю все эти переходы на DDR4, LVDS .. только ради GUI и HMI
Да и то от жадности, поскольку эффективные GUI и HMI предлагаются и для Cortex-Mx, но только за деньги.

Нет, GUI не нужен.
Нужно просто быстрое ядро под универсальные алгоритмические задачи (эмуляция 8- и 16- битных процессоров) + обработка графики (копирование из одной области памяти в другую, копирование массива в регистр данных дисплея). DDR я как понимаю будет лучше смотреться, чем обычная PC133 SDRAM.

Ну посмотрите наконец на Allwiner и им подобные SoC, ... я уже год как три проекта завершил. Поначалу были сомнения китай и все такое. В итоге уже не хочу на STM32 ... что то делать. Ну да там DDR3, DDR4, LVDS, многослойка, 0402, 0201, руками уже не очень ..., Linux, Android, ... На STM32F/H поддержка старых проектов только.

Приобрёл 2 платы на A13: Olinuxino и SOM-модуль. И-за текущих работ не могу пока до них добраться, поэтому в режиме сбора информации.
Есть ещё v3s, к счастью там не надо DDR разводить.
Ничё, время лечит, думаю за пол-года-год будет SDK "чистый поток сознания", наподобие как китайцы перелопатили SPL-говнокод на "регистры" для STM32.
Если нет, то сам займусь.

Ещё лет 6 назад писал проект на OMAP-L137. Внутренней памяти там как раз столько. Остальные ресурсы - в разы больше: два ядра по <=450МГц каждое (причём одно из них - настоящий DSP) + 2 усечённых ядра на половинной частоте бонусом.
Он конечно в BGA, но в QFP есть отдельно его DSP-ядро. И уж для потоковой обработки данных оно будет в разы быстрее чем Cortex-M на 400МГц.
И было это всё ещё в те времена, когда STM32 под стол пешком ходил до 100МГц не дополз.
Не знаю что такое "железный подход", но писал так же, как и для Cortex.

Под железным подходом имел ввиду - не использовать HAL, OS; только хедеры регистров и их бит. Ну может ещё что-то типа SPL допускается. Не более!
Никаких абстракций, только имена регистров и их биты!
Ну писать только C/C++, Asm , никаких питонов, сишарпов и прочих джав.

Вы как человек с опвытом можете сказать, OMAP-L137 отвечает моим хотелкам или там тоже абстракция с пингвинами?

Сообщение отредактировал __inline__ - Mar 25 2018, 04:06

[jcxz]

Под железным подходом имел ввиду - не использовать HAL, OS; только хедеры регистров и их бит. Ну может ещё что-то типа SPL допускается. Не более!
Никаких абстракций, только имена регистров и их биты!
...
Вы как человек с опвытом можете сказать, OMAP-L137 отвечает моим хотелкам или там тоже абстракция с пингвинами?

Да, я же написал, что писал на нём так же, как для других своих проектов на Cortex-M и ARM: никаких библиотек или ещё чего-то. Брал мануал на соответствующую перефирию и писал по нему драйвер. Единственно что ОС конечно была - это uCOS-II. Но я её почти во всех проектах использую. Кроме неё и кроме ещё хидеров с описанием регистров периферии - больше никакого чужого кода в проекте не было. Конечно что-то я смотрел по примерам TI как надо инициализировать (контроллер SDRAM например), но писал полностью самостоятельно. Даже USB-стек пришлось писать самому (в примерах для OMAP-L137 готового USB-стека в исходниках не было, предлагалось использовать либо linux либо какую-то проприетарную ОС в бинарниках с готовым USB-стеком - оба этих варианта не устраивали, взял стек из одного из своих проектов на LPC и портировал его под OMAP).
Вся периферия для OMAP-Lxxx хорошо описана (все регистры, описание подробное), мануалы есть на всё. Правда объём документации очень большой и она разделена на много файлов pdf (каждый по своему периферийному блоку или части), а не всё в одном как для Cortex-ов обычно.
Я использовал ARM- или DSP- ядра, а также немного одно из PRUSS-ядер (на большее не хватило необходимости Это всё на си и немного ассемблера. Периферия там тоже хороша. Особенно понравились McASP и EDMA3 - такого мощного DMA-контроллера не видел больше ни в одном из множества ARM-ов с которыми когда-либо работал! Даже в последних МК, с которыми сейчас работаю, даже их DMA-контроллерам далеко до возможностей EDMA3.
Также использовал MMU для своих целей - тоже вещь очень удобная и очень жаль что в Cortex-M её нету.
Да и вообще - наличие отдельных ядер для множества практических задач - это очень круто!

PS: До сих пор очень жалею что у меня больше не было проектов для OMAP-Lxxx. Но для всех моих последующих проектов он слишком мощный. Да даже для того проекта он был слишком мощный (использование каждого из ARM и DSP ядер - менее чем на 20% в самом тяжёлом режиме работы).

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

Не знаю, когда писал под OMAP-Lxxx там конечно описаний регистров периферии было побольше чем обычно бывает в Cortex-M, но ничего - справился. И не запутался. Хотя это было уже 6 лет назад, а с тех пор надеюсь мой опыт ещё вырос.
Чтобы не "запутываться", надо делить свой код на уровни, абстрагируясь от железа в драйверах нижнего уровня. Я обычно изучаю периферию на какой-то новый периферийных блок (набор регистров) или 2-3 блока если драйвер требует их совместного использования (например SPI+DMA), пишу драйвер для этой периферии, оформляю к нему API для последующего его использования (API - соответствующее характеру использования данного драйвера). И затем перехожу к другому драйверу, со следующим даташитом. Конечно что-то из изученного ранее забывается, но так потом если опять понадобится использовать ту же самую периферию для другого драйвера, можно ещё раз перечитать мануал на неё.
Если конечно всё валить в одну кучу и никак не упорядочивать свой код, то в этой куче потом можно быстро запутаться. Так это не проблема сложности железа, а проблема быдлокодерства.

[__inline__]

PS: До сих пор очень жалею что у меня больше не было проектов для OMAP-Lxxx. Но для всех моих последующих проектов он слишком мощный. Да даже для того проекта он был слишком мощный (использование каждого из ARM и DSP ядер - менее чем на 20% в самом тяжёлом режиме работы).

OMAPL137-HT в QFP корпусе. В свете сегодняшних политических событий его вряд-ли возможно из США в Россию передать. Так сказал mouser.com.

Порылся в ТиШных DSP, нашёл ещё красавца - TMS320C6745 - тоже в QFP, версия 456 МГц. Если его сравнить с BF532 на 400 МГц, то очевидно , что TMS лучше ?
Заинтересовал VLIW и наличие FPU, чего нет у Блекфина. А также подключение SDRAM с шириной ШД аж 32 бита!
Ну и доставаем.

На счёт Code Composer Studio, поддержка TMS там на уровне? Или всё спрятано в линуксах?

С БГА пичаль, мне надо чтоб без ухищрений распаять.

Или всё-же долбить Allwinner?

Старые игровые приставки эмулировать?
Что скрывается за понятием "универсальные алгоритмические задачи"?
Либо вы точно знаете свои алгоритмы и что в них хотите улучшить, либо не знаете и вам подойдет только raspberry pi

i.MX RT как явствует из названия не заточен под коней в вакууме.
Его целевая область - работа в окружении требующем отклика с детерминизмом в микросекунды, отягощенным HMI начального уровня.
Хотя эмулировать какой-нить ZX на i.MX RT было бы идеально и даже можно было бы туда ввести новые элементы интерактивности, типа управление кнопками по ориентации и т.п.
На i.MX RT есть очень подробная документация, как раз для тех кто любит работать с регистрами и битами напрямую.
У меня в работе утилита для генерации из их мануала смарт-хидеров, где будут подробно расписаны все регистры и их биты с прямыми работающими линками на страницы мануала.

Я очень часто работаю с чужим исходным кодом и не могу позволить себе роскошь потратить время на тотальное переписывание исходных кодов эмуляторов (это не только процессор, но и периферия). Это к вопросу "Либо вы точно знаете свои алгоритмы и что в них хотите улучшить, либо не знаете"

Ну и ZX эмулировать совсем неинтересно. GameBoy Color или NES куда интереснее будут!

Сообщение отредактировал __inline__ - Mar 26 2018, 09:28

[jcxz]

Порылся в ТиШных DSP, нашёл ещё красавца - TMS320C6745 - тоже в QFP, версия 456 МГц. Если его сравнить с BF532 на 400 МГц, то очевидно , что TMS лучше ?

Я вообще-то про него и писал как отдельное DSP-ядро от OMAP-L137:

Ещё лет 6 назад писал проект на OMAP-L137.
...
Он конечно в BGA, но в QFP есть отдельно его DSP-ядро. И уж для потоковой обработки данных оно будет в разы быстрее чем Cortex-M на 400МГц.

Про OMAP-L137 в QFP я ничего не знаю, в то время не было, но может уже сделали.

Заинтересовал VLIW и наличие FPU

Нету там отдельного "unit"-а, команды работы с плавающей точкой (и float и double) - это часть ядра как и все прочие команды. Даже используют те же регистры, что и целочисленные команды.

На счёт Code Composer Studio, поддержка TMS там на уровне? Или всё спрятано в линуксах?

В смысле? Какое отношение CCS имеет к линуху? CCS - это среда/отладчик, без разницы что под ней отлаживается.
Работал под CCS3.3 - всё ок. Можно было отлаживать одновременно независимо 2 ядра.

Ну и ZX эмулировать совсем неинтересно. GameBoy Color или NES куда интереснее будут!

Это хобби что-ль такое?

[__inline__]

Про OMAP-L137 в QFP я ничего не знаю, в то время не было, но может уже сделали.

-HT - в QFP

Нету там отдельного "unit"-а, команды работы с плавающей точкой (и float и double) - это часть ядра как и все прочие команды. Даже используют те же регистры, что и целочисленные команды.

Это хотел сказать, что нужна плавучка, а то как она реализована - в виде юнита или в составе команд основного АЛУ - уже не интересует

В смысле? Какое отношение CCS имеет к линуху? CCS - это среда/отладчик, без разницы что под ней отлаживается.
Работал под CCS3.3 - всё ок. Можно было отлаживать одновременно независимо 2 ядра.

В смысле, что экзамплы входят в неё или нет? Наподобие как у Visual DSP: в папке есть примеры работы с периферией Блекфина (наподобие SDK).

Это хобби что-ль такое?

А почему бы и нет?

Посмотрел я эти эмуляторы.
Делаются они весьма примитивно. Реально там никаких нет алгоритмов. Если они и были, то остались в ромах.
Тратить на это i.MX RT будет нецелевым расходованием интеллекта.

Ха! Эмуляция только одного графического чипа Capcom Play System-2 и его звуковой части Q-Sound + FM- синтез чего только стоят.
Быстрая числодробилка напрашивается!

[AlexandrY]

Ха! Эмуляция только одного графического чипа Capcom Play System-2 и его звуковой части Q-Sound + FM- синтез чего только стоят.
Быстрая числодробилка напрашивается!

Судя по валу сорсов по этой теме на Github, то ничего не стоят.
И что собственно там считать если это просто эмуляция?
Там в эмуляторах даже тип float не применяют.

[__inline__]

Там в эмуляторах даже тип float не применяют.

В SNES-эмуляторе графическая система на floating point. Эмулятор Snes9x. Потому что : поворот, растяжение, текстурирование
Особо упоротые реализации в CPS1/2 - синтез звука на floating point.

Вот я и хочу понять, насколько осчастливят меня ARM Kinetis, или всё-же лучше взять C6745, который будет по-лучше прошлого варианта эмулятора с ADSP BF532?
Если оно того не стоит, то насколько будет удачен выбор Allwinner A13, v3s для эмуляторов? (без линукса правда, в стиле баре-метал)

[AlexandrY]

В SNES-эмуляторе графическая система на floating point. Эмулятор Snes9x. Потому что : поворот, растяжение, текстурирование
Особо упоротые реализации в CPS1/2 - синтез звука на floating point.

Вот я и хочу понять, насколько осчастливят меня ARM Kinetis, или всё-же лучше взять C6745, который будет по-лучше прошлого варианта эмулятора с ADSP BF532?
Если оно того не стоит, то насколько будет удачен выбор Allwinner A13, v3s для эмуляторов? (без линукса правда, в стиле баре-метал)

Ну вот мы подошли и к алгоритмам, а говорите не знаете.
Вам же поворот-растяжение то придется портировать ручками.
Но к сожалению c GUI не работаю сейчас, так что смотрите сами в мануалах.
На вскидку вам поможет помочь модуль Pixel Pipeline в i.MX RT, который и масштабирует и поворачивает аппаратно и alpha-blending делает.
Но опыт ADSP тут точно не пригодится, будет всё другое.
Планируйте на освоение периферии i.MX где-то полгода.

Но я бы с ADSP не переходил. Для такого рода эмуляторов не вижу никаких преимуществ при переходе на другую платформу.
Им же практически ничего не нужно из периферии.

[__inline__]

Но я бы с ADSP не переходил. Для такого рода эмуляторов не вижу никаких преимуществ при переходе на другую платформу.
Им же практически ничего не нужно из периферии.

А разве не порвёт C6745 BF532 хотя-бы из-за:
1) VLIW до 6 команд одновременно - против 2 команд у BF532 //выигрыш в 3 раза
2) SDRAM 32 бит - против 16 бит у 532-го // выигрыш в 2 раза
3) Hardware floating point - против софтварных целочисленных рядов Тейлора на 532-м //выигрыш в специфических местах
4) 475 МГц - против 400 // несущественно, но приятно
5) У BF532 - скудный малооперандный ассемблер, в отличие от того же ARM. У C6745 вроде как по-лучше?

В целом вижу оправданным переход на C6745. Поправьте, если ошибаюсь.

[AlexandrY]

В целом вижу оправданным переход на C6745. Поправьте, если ошибаюсь.

Да переходите уже.
Здесь обсуждаем i.MX RT.
А то мне ваши посты придется перенести в "остальные микроконтроллеры"

Да ничем он не поможет по сути, там даже выбор портретный или альбомный вывод не предусмотрен

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

[mantech]

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

Вот это поворот!! Так так, и каким это дисплеем оно поддерживается??, может "тупой" матрицей, без контроллера и памяти, с RGB входами и синхрой, или я чего-то не понял и можно перекинуть синхры наоборот, как фазы в движке, чтоб он назад поехал

[AlexandrY]

Вот это поворот!! Так так, и каким это дисплеем оно поддерживается??, может "тупой" матрицей, без контроллера и памяти, с RGB входами и синхрой, или я чего-то не понял и можно перекинуть синхры наоборот, как фазы в движке, чтоб он назад поехал

Не понял эмоцию. А что еще есть дисплеи без поворотов? Там же контроллер стоит!

[mantech]

Не понял эмоцию. А что еще есть дисплеи без поворотов? Там же контроллер стоит!

Это прикол или вы просто не в теме, какой контроллер в матрице, или что вы там под дисплеем понимаете и какой поворот, я не про экраны с контроллером и встроенной памятью, а про "тупые" матрицы с приемником ргб или лвдс и сегментными драйверами. Или что, они тоже должны уметь поворачивать на 90 град?

Сообщение отредактировал mantech - Mar 26 2018, 15:15