Новые 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 - соответствующее характеру использования данного драйвера). И затем перехожу к другому драйверу, со следующим даташитом. Конечно что-то из изученного ранее забывается, но так потом если опять понадобится использовать ту же самую периферию для другого драйвера, можно ещё раз перечитать мануал на неё.
Если конечно всё валить в одну кучу и никак не упорядочивать свой код, то в этой куче потом можно быстро запутаться. Так это не проблема сложности железа, а проблема быдлокодерства.