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

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

Baremetal писали под них или только "Linux, Android,"??

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

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


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


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

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

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

Да ладно, и чем могут помочь деньги в отсутствии видеоускорителей в камне, отсутствии исходников по работе с ним, т.к. доки только под НДА?? Или платные гуи только под экранчики 320х240 с софтовой отрисовкой, дак такие и даром не нужны, ибо их полно везде



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

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

Для BF532, BF533 я абстракцию писал сам На выходе получилось что-то вроде своего SDK (или API), делающий всю необходимые функции: установка клоков CPU, SDRAM, SPI, настройка периферии, стека , кучи... Повезло что Блекфины линуксоеды и прочие ОСо-любы не испортили

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

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

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

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

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

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

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

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




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

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

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

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

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


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


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


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

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

-HT - в QFP


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


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


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


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

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

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

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