Перейти к содержанию
    

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Изменено пользователем repstosw

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

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

 

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

Изменено пользователем mantech

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

 

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

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

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

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

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Изменено пользователем repstosw

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Порылся в ТиШных 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:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

-HT - в QFP

 

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

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

 

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

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

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

 

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

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

 

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

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...