Ну и что там такого "сногвышибательного"?? Вы по МХ6 питанию посмотрите - вот там капец полный плюс еще куча требований по алгоритму подачи питаний сторонних устройств, подключенных к портам чипа...



У меня МХ6 от усб прекрасно работает, а там потребление покруче будет, мягко говоря...


16 или 64мега - это для линукса с графикой, QT и пр. При экране, скажем, 1024х600 - нормально?? В таких объемах только DD-WRT с командной строкой и веб мордой, c небольшой навеской нормально пойдет, не более.
ЗЫ честно говоря не понимаю тех, кто эти камни использует под линуксом. Есть куда более продвинутые и дешевые чипы, с очень скудной докой, но под линуксом это не так важно.

Невооруженным глазом видно, что это семейство для приборного кластера в авто.
А там рулят Qt c INTEGRITY
Потому-то и нет нормального открытого софта под них.

Позиционировние налицо и нет смысла сравнивать SAMA5D2 с i.MX RT

По цифрам проблем не видно, да. Странно что это не добавлено в фичелист, капиталисты же любую фичу, если она возможна, стараются записать в плюсы. А так придется объясняться со своими что всё должно работать, а мне будут вполне справедливо отвечать "Ну смотри в документации же нет, значит риск что не заработает есть".

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

Хотя бы для ремонтников/настройщиков.

Выложена документация - https://www.nxp.com/docs/en/reference-manual/IMXRT1050RM.pdf

Что понравилось:
Периферия да, очень похожа на Kinetis, но много новой.
RTOS MQX уже поддерживает.
Работа по serial SPI со скростью 166 МГц DDR

Сильный упор на движки.
Аппаратные фичи для высокооборотных низкоиндуктивных BLDC движков с безсенсорным управлением.
Также продвинутые фичи для AC двигателей.
Поддержка 4-х движков одновременно вместе с самыми навороченными 5-и сигнальными энкодерами на каждом.
Прям идеальный 3D принтер получается или робот, даже не знаю.
Много про аудио как ни странно.
Камера, пиксельный конвертер и LCD на отдельной шине к внешней SDRAM.

Но ждем пожалуй ревизию A1 и стартуем.

Защищенная загрузка под НДА, цена тоже как у младших iMX, периферия примерно одинаковая... Ну движки - да, но что-то мне кажется что проще поставить отдельно контроллер на двигатели, и отдельный на всё остальное.

В моей работе простота и скорость разработки определяется этапом отладки. А отлаживать дивайс с одним чипом гораздо легче.

Ой не знаю... Если разработано все правильно и разбито на подмодули, которые выполняют четко определенную задачу и отладить их раз плюнуть, то проще на выделенных МК, чем когда все в куче и копайся там, в километрах исходников...

У меня ж IoT в добавок везде.
И так уже отдельно стоят uC для Bluetooth LE, uC для Wi-Fi ...
А еще все надо прямо в мотор засунуть.
Да и определенных задач никогда не было. Зачем фантазию то ограничивать?

Off, интересно, в СНГ аудитория Кинетиса через пару лет превысит 1.5 человека , считая Александра, или они снова продадутся кому нибудь? Я вообще запутался, почему из On semi не купит. Имхо 600 мгц вообще не впились, лучше бы интегрированный трансивер и озу с флеш более. Но есть надежда на Silabs с Cortex M23/33 для IoT, с БЛЕ и Thread конечно же в одном

и сколько там от 600мгц останется, 150 ?

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

Винигрет в головах.
Понимать же надо. Одно дело совать самописанный IP стек без понятия о TLS и доверенных сертификатах.
И другое дело BLE 5, да еще на отдельном чипе.
А и промавтоматика эт че...? Святая корова?
Я по молодости турбину на малой гидростанции завалил, и ничего все нормально было.
Промавтоматика самое место для экспериментов. Просто там контингент консервативный, типа местных "студентов"

Как бы сомнительное "достижение"

В промавтоматике главное- простота и надежность, а эксперименты ставьте на "блондинках с планшетами", ИМХО конечно...

То что они не популярны здесь, не значит что они вообще непопулярны. А так думаю постепенно сольются с семейством LPC вбирая всё лучшее.

О как совпало, только что мне пришло приглашение на семинар ABB про смартсенсоры в каждый мотор - http://new.abb.com/motors-generators/servi...es/smart-sensor
Обгоняют меня ребята.
Но ничего, главное не кто первый, а кто дешевле скопировал.

Ну и... это просто дополнительная шняга, без которой все прекрасно работает, просто еще один канал съема и передачи информации, и даже если он зависнет или заддосят, мотор не остановится и не сгорит...

С LPC работал начиная с 2103, их тогда только завозить начали. Ничего не то что лучшего, но даже хорошего не вспомню. Хуже только Моторола была. И похоже они наконец то нашли друг друга. Отличалась принципом "меньше миллиона не продаем, доки под NDA, киты по килобаксу
'Промавтоматика самое место для экспериментов. " Это как? На АЭС в автоматике эксперименты? А, ну да, у вас АЭС вроде нет

К слову в Чернобыле рвануло вроде в ходе штатного эксперимента.
Управление на больших производствах насколько читал строится на обычных человеских эвристиках.
Т.е. там постоянно применяется метод проб и ошибок. По научному - эксперименты.

В те года вообще самое лучшее было у микрочипа и атмела, у второго даже заметно лучше. Моторола по началу вообще на оборонку работала и заказы гигантов типа HP, ясно дело с такой политикой других цен и не могло быть. Да и сейчас, чипы МХ6 семейства мягко говоря, не больно дешевы, хотя, если б все у них было шоколадно, не продались бы...



Ой, хорошо рассуждать об "экспериментах" сидя далеко от объекта, и нет, промавтоматика не место для них, а проводить эксперименты нужно в соотв. НИИ, передавая на реальные объекты только проверенные и перепроверенные результаты.

Да. Согласен и насчет Атмеля, и насчет мотороллера

а не вы ли ль там уже чегой-то подорвали ?
на объект нужно ехать уже с 146% отлаженным девайсом, а не эксперементировать



ага, и там не могло не рвануть, ибо экспериментаторы - наш поручик такой выдумщик - приложили все мыслимые и немыслимые усилия для

Это смотря какие движки. Параграф 28.2 из RM:

Так что один трехфазник с тормозным чоппером. В этом плане KV58 как-то поинтереснее...

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

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

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



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

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

Я вообще-то про него и писал как отдельное 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 для эмуляторов? (без линукса правда, в стиле баре-метал)

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

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

Да ничем он не поможет по сути, там даже выбор портретный или альбомный вывод не предусмотрен, пришлось программно "поворачивать" для вертикально расположенной матрицы, поворот там только картинки, которая в буфере источника и передача ее в получатель, причем с ограничениями по выравниванию то-ли в 4 или 8 пикселей не помню... Там для ускорения нужен аппаратный блиттер, а он есть только в IMX6 да и то под НДА.

А разве не порвёт 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. Поправьте, если ошибаюсь.

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



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

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

Честно говоря - я уже не помню. Вроде по мануалам разобрался, но может и какие примеры смотрел.
Точно помню, что очень не хватало примеров по USB. Остальное что там использовал: SDRAM, EDMA3, McASP, SPI, UART, I2C, MMU, PRUSS, взаимодействие ядер и т.п. - затруднений не вызвало.

УСБ в них не EHCI-совместимое? Если нет, тогда да, засада...

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

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

Ну я вам сочувствую, но я же предупреждал i.MX RT не для медиацентров.
От дисплея понадобятся кое какие сервисы.
Это нормально в данной теме.
В конце концов и внешних интерфейсов не вагон и памяти.
В i.MX все отлично сбалансировано для моих задач.