На что бы перейти..., В плане платформы Опции

[Arlleex]

С практикой работы с STM32 у меня пополняется чаша больше ненависти к этим камням, нежели положительных эмоций.
Вот элементарно - есть АЦП внешний, управляется через SPI, CS-ом дергать обязательно. В STM32 CS не дергается аппаратно при транзакциях SPI, не понимаю, почему эти говноразработчики из STMicroelectronics не могут сделать это уже в какой реализации своих линеек микроконтроллеров? Из-за такого намеренного "косяка", который они вроде как и не пытаются исправить, невозможно запустить DMA на этот SPI, приходится запускать чертов таймер, дергать лапой в прерывании и там же запускать транзакцию (одиночную), потом снова выжидать нужное время и поднимать CS обратно, формируя нужные длительности между CS и первым/последним клоком SCLK... Помню в AT91SAM7X512 (и младших по памяти моделях) была возможность не то что аппаратно лапкой CS дергать, так даже время задавалось в количествах тактов вот этих самых задержек. А тут фигу.
С ходу даже не придумал как аппаратным таймером ножку аппаратно дергать так, чтобы еще после опускания CS выжидалось время небольшое и затем осуществлялась транзакция по SPI без прерываний, по DMA , например. И, чувствую, такой возможности тупо нет. Хотя, казалось бы, банальная вещь - что сложного было реализовать полностью аппаратный CS? Урезали половину функциональности DMA<->SPI...
И вот знаете, косяков все больше и больше обнаруживается с каждым детальным разбором.
Какие камни наиболее гибкие в этом плане? ПЛИС не в расчет, знаю что там проще сделать такое и т.д. но интересует возня именно с Cortex-M профиля. Раньше немного работал с ARM7TDMI, но это уже устаревший камень, Cortex-ы для меня более привлекательны, хотелось бы что-то действительно с хорошей периферией. Прокомментируйте, пожалуйста.

[Arlleex]

Ну "в каком-то из STM32" максимум 72МГц, что-ж Вы с ним не сравниваете?

Я не просто так написал

...при прочих равных условиях (главным образом, процессор Cortex-M4F).

Сравнение бралось между схожими линейками, построенных на одном ядре.

Например (говорю по памяти) в Tiva 256-битная шина к памяти.

1. А в STM32 128-битная шина и ART-ускоритель памяти.
2. В Tiva-C до 120МГц максимум, STM32 линейки F4 (на том же проце) уже 180Мгц.
3. В Tiva-C производительность 150 DMIPS, в STM32 все той же линейки уже 225 DMIPS, как видно производительность на 1МГц частоты одинаковая, но STM32 выигрывает все-таки уже из-за более высокой частоты, кто бы что ни говорил.
4. Что в Tiva-C, что в STM32F4 по 256кБ RAM. Более того, в STM32F469 уже даже 384кБ RAM.
По периферии возможно, да, Tiva-C в некотором смысле привлекательнее, на первый взгляд (возможно и на второй, и на третий в некоторых приложениях).

Что за рекламный ход? Где такое написано? И на кой ляд это нужно (практически, а не теоретически)?
Наверное возможно для каких-то протоколов, но ЗАЧЕМ???

Про рекламный ход нигде не написано, но производители МК любят приукрасить свои камни. Я помню как в STM32F429 хвалили на семинаре в Москве их супер-пупер LCD-TFT контроллер. А по факту в реальном проекте применить его можно было с небольшими программными костылями из-за аппаратного бага в связке NOR-Flash + SDRAM. Зато сколько понтов было у представителей, когда они из внутренней Flash картинку на экран выводили... Стоило мне взять экран побольше разрешением, да повесить NOR-Flash + SDRAM, как понял, какие же они чудаки на букву м.
Я вот сейчас пишу прошивку на МК, который стоит на плате и выполняет вспомогательную функцию для ZYNQ7000 - следит за напряжениями питания, датчики опрашивает, да с пользователем общается. И одну I2C-шную микросхему уже было невозможно к ZYNQ7000 прицепить - остался только UART. Вот и пришлось завести ее через МК, а МК уже по UART отдает данные. Получился такой программный мост - I2C-UART. А мне об этих данных вообще знать не нужно - если бы такой мост можно было бы сделать аппаратно в XMC4800 - это был бы существенный плюс. Ну по крайней мере хотя бы попробовать задумку, если бы не получилось - программно в любом случае обыграть можно.

Более сложной и функциональной периферии и связки периферия+DMA+service_request-ы я не видел ни в одном Cortex-M.

Scatter-gather DMA в XMC4800 конечно выглядит очень вкусным, тут я полностью согласен. Но самое главное, чтобы за этой сложностью не потеряться в трех соснах.

Сообщение отредактировал Arlleex - May 6 2018, 16:30

[jcxz]

3. В Tiva-C производительность 150 DMIPS, в STM32 все той же линейки уже 225 DMIPS, как видно производительность на 1МГц частоты одинаковая, но STM32 выигрывает все-таки уже из-за более высокой частоты, кто бы что ни говорил.

Вы внимательнее прочитайте, что я написал: при выполнении линейного кода из флешь. А теперь посчитайте например за сколько тактов выполнится блок инструкций в 128-и битах? А если все (или многие инструкции 32-битные)? И сколько тактов нужно чтобы дочитать следующий блок на данной частоте МК? А теперь подумайте что в Tiva этот блок в 2 раза больше.
После этого увидите, что бОльшая частота не даёт никакого выигрыша в случае линейного кода из флешь. А вот более широкая шина (и бОльшая частота шины) - даёт.
И в Tiva тоже кстати есть кеш инструкций. Хоть и небольшой. Но скорость выборки по широкой шине такова, что во многих случаях никакие акселераторы и не нужны.
Так что STM32 даже на бОльшей частоте может запросто проиграть по скорости Tiva если код не влазит целиком в его кеш.

4. Что в Tiva-C, что в STM32F4 по 256кБ RAM. Более того, в STM32F469 уже даже 384кБ RAM.

Опять же ещё раз открываем моё исходное сообщение и ещё раз внимательно перечитываем (раз не получается с первого раза):"когда мы выбирали Tiva для своего проекта".
Так вот - когда мы выбирали Tiva для своего проекта, у неё было 256КБ ОЗУ, а в самом жирном из тогда имевшихся STM32 - всего 192КБ (насколько помню).

А мне об этих данных вообще знать не нужно - если бы такой мост можно было бы сделать аппаратно в XMC4800 - это был бы существенный плюс. Ну по крайней мере хотя бы попробовать задумку, если бы не получилось - программно в любом случае обыграть можно.

Не очень понятно как вообще можно просто так передать из I2C в UART без какой-либо обработки протокола? Уже хотя бы потому, что I2C - это не просто поток байтов, а ещё и старты/стопы и адресации и переключение передача/приём и т.п. Собственно на аппаратном уровне в UART каждый байт - это независимый элемент (кадр), а в I2C кадр - это много байт.
Какой-то протокол должен быть. Возможно, что если этот протокол - ваш самопальный, то возможно, что его можно приспособить для полностью аппаратной обработки. Но мне кажется, что программная обработка будет просто легче и займёт меньше ресурсов МК. А о скорости тут вообще речь не идёт. Поэтому не вижу смысла городить огород на пустом месте.

Scatter-gather DMA в XMC4800 конечно выглядит очень вкусным, тут я полностью согласен.

Я не о том. В Tiva сделали очень грамотно, когда от каждой периферии умеющей генерить burst-DMA-запросы вывели два сигнала DMA-запросов: собственно burst и single. Одновременно. И обработку этих запросов в DMA-контроллере сделали по уровню, а не по edge. Вот в XMC к сожалению до этого не додумались и там с этим связано много проблем.

PS: В первую очередь советую Вам сразу же на купленной плате проверить ревизию чипа (XMC). И перепаять на последнюю.
У нас на EVB с XMC стояли инженерные образцы и я наступил сразу на несколько багов из ерраты. Пришлось их перепаивать.
В инженерных образцах много багов. Причём серьёзных. Но в серийных образцах баги уже не страшные.
Да: и у Infineon какая-то странная манера оформления еррат - те баги, что устранены в новых ревизиях чипа, из ерраты удаляются (не комментируются как относящиеся к такой-то ревизии, а просто удаляются!). И на сайте выложена еррата для последней ревизии. А для старых ревизий на сайте тоже есть ерраты (в архиве), но они не сразу находятся.
Так что имейте в виду.