[Aner 8]

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

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

[jcxz 242]

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

Ещё лет 6 назад писал проект на OMAP-L137. Внутренней памяти там как раз столько. Остальные ресурсы - в разы больше: два ядра по <=450МГц каждое (причём одно из них - настоящий DSP) + 2 усечённых ядра на половинной частоте бонусом.

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

И было это всё ещё в те времена, когда STM32 под стол пешком ходил до 100МГц не дополз.

Не знаю что такое "железный подход", но писал так же, как и для Cortex.

[mantech 53]

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

 

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

[AlexandrY 3]

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

Насколько понимаю все эти переходы на DDR4, LVDS .. только ради GUI и HMI

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

 

 

[repstosw 18]

Насколько понимаю все эти переходы на 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 отвечает моим хотелкам или там тоже абстракция с пингвинами?

Изменено 25 марта, 2018 пользователем repstosw

[mantech 53]

Насколько понимаю все эти переходы на DDR4, LVDS .. только ради GUI и HMI

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

 

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

 

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

 

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

Изменено 25 марта, 2018 пользователем mantech

[repstosw 18]

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

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

 

[jcxz 242]

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

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

[AlexandrY 3]

Нет, GUI не нужен.

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

Старые игровые приставки эмулировать?

Что скрывается за понятием "универсальные алгоритмические задачи"?

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

 

i.MX RT как явствует из названия не заточен под коней в вакууме.

Его целевая область - работа в окружении требующем отклика с детерминизмом в микросекунды, отягощенным HMI начального уровня.

Хотя эмулировать какой-нить ZX на i.MX RT было бы идеально и даже можно было бы туда ввести новые элементы интерактивности, типа управление кнопками по ориентации и т.п.

На i.MX RT есть очень подробная документация, как раз для тех кто любит работать с регистрами и битами напрямую.

У меня в работе утилита для генерации из их мануала смарт-хидеров, где будут подробно расписаны все регистры и их биты с прямыми работающими линками на страницы мануала.

 

 

[repstosw 18]

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 куда интереснее будут! :)

Изменено 26 марта, 2018 пользователем repstosw

[jcxz 242]

Порылся в ТиШных 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 куда интереснее будут! :)

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

[AlexandrY 3]

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

Посмотрел я эти эмуляторы.

Делаются они весьма примитивно. Реально там никаких нет алгоритмов. Если они и были, то остались в ромах.

Тратить на это i.MX RT будет нецелевым расходованием интеллекта.

 

[repstosw 18]

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

-HT - в QFP

 

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

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

 

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

Работал под CCS3.3 - всё ок. Можно было отлаживать одновременно независимо 2 ядра.

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

 

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

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

 

Посмотрел я эти эмуляторы.

Делаются они весьма примитивно. Реально там никаких нет алгоритмов. Если они и были, то остались в ромах.

Тратить на это i.MX RT будет нецелевым расходованием интеллекта.

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

Быстрая числодробилка напрашивается!

 

[AlexandrY 3]

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

Быстрая числодробилка напрашивается!

Судя по валу сорсов по этой теме на Github, то ничего не стоят.

И что собственно там считать если это просто эмуляция?

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

 

[repstosw 18]

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

В SNES-эмуляторе графическая система на floating point. Эмулятор Snes9x. Потому что : поворот, растяжение, текстурирование :)

Особо упоротые реализации в CPS1/2 - синтез звука на floating point.

 

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

Если оно того не стоит, то насколько будет удачен выбор Allwinner A13, v3s для эмуляторов? (без линукса правда, в стиле баре-метал)