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

а таймер разве не может дёргать по совпадению и CS вверх вниз когда нужно и ДМА?

ну возьмите тот же кортекс от любого другого производителя, с нормальной периферией.
NXP вон умеет CSом дергать. в lpc8 во всяком случае, вряд ли в других сериях по другому.
и SCTimer там тоже это можно заставить делать как угодно.

да и атмел скорее всего тоже умеет.

Стенания из разряда "мыши кололись, плакали, но продолжали жрать кактус..."
Кто-ж Вас заставляет? МК разных полно на любой вкус и цвет - выбирай что более удобно.


Нет таких. Для одной задачи - один, для другой - другой. МК нужно выбирать под конкретную задачу.
Или точнее - наиболее подходящий под конкретную задачу. С учётом множества требований.
Идеального камня, под любую возможную задачу, не существует.


LPC (NXP), Tiva (TI), XMC4xx (Infenion) - все они имеют во много раз более навороченные SPI-блоки чем у STM32. Но всё равно - у каждого есть плюсы и минусы.


Возможность задания в тактах разных времянок (CS->data, межсловный интервал и т.п.) это есть в XMC4xxx.

Атмел точно умеет - проверял лично. Но камешки некоторые (на которых и проверял, собственно) морально устарели.


Никто не заставляет, на самом деле Просто было закуплено на лабораторию ведра STM32 разных калибров для как раз задач широкого применения, не требующих внушительной производительности. Когда задача описана словами "надо дискретизировать сигнал 5000 выборок/сек и передать отсчеты наружу...", невольно понимаешь, что STM32 тут за глаза. И вот лишь когда начинаешь детальнее входить в архитектуру программы, понимаешь, что программа будет сущий костыль... Видимо, этот CS у SPI не дает мне покоя


Пожалуй, нужно будет ознакомиться, благодарю.

Нажмите для просмотра прикрепленного файла

jcxz, как раз листаю референс на XMC4800. Общее впечатление - на днях сделаю себе отладку и попробую разобраться в новой для себя стилистике документации

Вы можете взять недорогой чип CPLD и использовать его для коррекции периферии.

> В STM32 CS не дергается аппаратно при транзакциях SPI, не понимаю, почему эти говноразработчики из STMicroelectronics не могут сделать это уже в какой реализации своих линеек микроконтроллеров?

а это точно?
вроде в даташите
NSS output enabled (SSM = 0, SSOE = 1)
This configuration is used only when the device operates in master mode. The
NSS signal is driven low when the master starts the communication and is kept
low until the SPI is disabled
в errate не упоминается

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

----------

выбор STM все-таки оправдан из-за большого количества всяческих плат и прочей доступностью
а глюки есть, наверняка всюду, за выросшую сложность и быстрый вывод на рынок новых чипов приходится платить - радуйтесь, что не i.mx программируете

Как альтернативу STM32 рассматриваю чипы SmartFusion2 от Microsemi (https://actel.ru/item/smartfusion2). Кто-нибудь использует, поделитесь впечатлениями. Младший, m2s005, как мне кажется, может закрыть достаточно большую нишу разрабатываемых устройств.

я собственно под атмел имел ввиду их новые кортексы, ATSAMC/D/E/...


LPC800 так тоже умеют.

LPC54 CSами умеет дергать невероятно, с настраиваемыми предзадержками и постзадержками.
Критерий выбора огонь.

Ну программируемой логикой можно все, конечно, поправить, но видится аппаратным костылем (перфекционист детектед).


Да, не дергается ножка у него...
Хотел сделать хитросплетенную логику на механизмах совпадения в таймерах, DMA и SPI, и все равно уперся в другую неприятную особенность, склеившей ласты на задумке.


Чем меня привлекают STM32 - в плане частот ядер они вроде как всегда впереди... Да и самих ядер. Если ARM что-то выпускает, они тут же подхватывают это и делают новые микроконтроллеры.
Ну а по периферии - не агонь. Все-таки присматриваюсь к XMC4, LPC пока что даже не смотрел. Вообще думаю проштудировать получше рынок МК на базе Cortex-M. А вообще некоторое время назад на глазах промелькнул некий Renesas-овский процессор RZ-A1 Cortex-A9. 10МБайт встроенного ОЗУ выглядят очень внушительными.

Ну так есть и с 64МБ если уж на то пошло и нужно ОЗУ.

Например, вам нужно передавать пакет данных в АЦП с частотой 5кГц.
Вы:
1. Делаете таймер с частотой срабатывания 5кГц.
2. В обработчике прерывания этого таймера поднимаете CS ручками.
3. Затем обрабатываете приемный буфер от SPI и готовите буфер отправки.
4. Потом опускаете CS ручками.
5. Настраиваете DMA и запускаете его.
6. Выходите из прерывания таймера.

Чем не устраивает? п. 2 и п. 4?

не устраивает ручками.
должно быть так:
1. приходит прерывание от таймера/внешнего прерывания с интервалом 1мкс
2. запускается чтение spi с автоматическим опускание CS
3. по завершении чтения CS поднимается, данные остаются в DMA
4. по заполнению половины буфера DMA обрабатываем полученные данные.

а еще извращенцы из LT делают ацп которым нужно 17-18 тактов на SPI, вот тоже ни туда, ни сюда, но это уже так, придирки

1мкс -> 1МГц.
Даже на МК с тактовой 168МГц у вас 168 тактов на посылку. По-моему, ничего разумного за такое время не сделать.
STM32F тут не подходит не из-за SPI, а из-за общей производительности.
Тут вариант - на внешней ПЛИС сделать опрос АЦП, а МК предоставить доступ по внешней шине,
или правдами-неправдами "окутать" доступ к АЦП в какой-нить DCMI при помощи CPLD попроще.
У ТС озвучивалась задача 5кГц, и под нее выбирались МК типа STM32F



Если 5кГц это максимум, то на любом STM32F это делается легко даже с ручным дерганьем CS.

ну нормальные последовательные порты умеют не только нормально аппаратно чипселектами дёргать но и произвольную длину слова задавать.

у меня процесс непериодический, т.е. мне не надо постоянно с таким интервалом, поэтому dma решает проблему.
новые stm32f умеют произвольное слово от 4 до 16 бит
ЗЫ даже если 5кГц два раза дергать прерывание по 8 тактов вход/выход + сохранить, тоже нифига не радостно

Так возьмите МК с богатой реализацией SPI, а не урезанной. Например: XMC4xxx - "Number of data bits per data frame 1 to 63".
И будет Вам и туда и сюда.
А вообще во многих SPI-АЦП частота преобразования и частота SCLK - это разные частоты, с разными источниками. Так что SCLK просто берётся с запасом и всё.


Не сделать чего??? 168 тактов - это вагон + ещё маленькая тележка.
168 тактов - это не много, а очень дофига для любой пересылки.
Ну конечно если иметь полноценный SPI-контроллер, а не "ручками" как на STM32. Да впрочем и на STM32 тоже можно сделать "не ручками" если голову включить. И будет совсем незначительная загрузка МК.
Для МК с более фичастым SPI, 1МГц - это вообще ни о чём. У меня на XMC4700 SPI работают с SCLK в 30-36 МГц при ядре 120-144МГц. Причём - параллельно по 2 канала SPI да ещё один при этом в dual-SPI. Загрузка CPU незначительная.


У меня в проекте на XMC4700 даже один из UART-ов работает с длиной слова 26 бит (1старт+24данных+1стоп). Вот это и называется - гибкая и эффективная периферия


Ну это уже скорее паранойя.... или тяжкое наследие АВР
12*2*2*5000/168e+6 = ~0.143% загрузка CPU (168МГц).
Даже с учётом того что вход/выход в ISR явно не 8 тактов (с чего Вы взяли?), а 12 тактов - это всё равно ни о чём.
Да и вообще - как уже говорил выше - с головой даже на STM32 можно сделать без дёрганий в прерывания: завести сигнал прерывания от АЦП на какую-нить периферию, умеющую генерить запросы обслуживания к DMA (таймер например), и дальше всё сделать DMA: и CS и транзакцию по SPI.

Если нужно заполнить кольцевой буфер для постобработки, то полностью согласен.

Да вот элементарный пример, решение которого полностью решило бы такую проблему.
Возможно ли в STM32F4 настроить периодическую отправку в SPI по DMA?
Я бы настроил событие по совпадению таймера 5000 раз в секунду пинать DMA, чтобы он положил данные в SPI->DR. Началась бы передача, по завершении которой выставился флаг RXNE, который пинал бы другой канал DMA, и тот складировал данные в буфер и говорил мне когда нужный объём данных наберётся для передачи по другому интерфейсу разом.
DMA устроен же так, что в режиме память-регистр я могу указывать только адрес регистра только того модуля, который пнул этот канал DMA, а как было бы здорово по запросу DMA от таймера сделать пересылку в SPI-DR, то есть в модуль, который не пинал этот DMA. Периодические вещи, например, отправки или прием данных по разным интерфейсам, в том числе SPI, стали бы возможны вовсе без участия процессора!

С чего вы это взяли? DMA может откуда угодно куда угодно произвести транзакцию, если на это нет ограничений (CCM, выравнивание и т.п.)
и есть доступ к соответствующим шинам. Много раз обсуждалось, как таймер инициирует транзакцию в SPI. Там единственная особенность,
что от момента запроса до момента транзакции может пройти некоторое время (у меня получалось ~12 тактов) и при высоких скоростях SPI
сложно получить равномерный SCK (без межсимвольных пауз).

Добрый день.
На отладочнике STM32L476-disco проверил формирование NSS в режимах TI Mode и Motorola Mode.
В обоих режимах сигнал вырабатывается в соответствии с
RM0351 Reference manual STM32L4x5 and STM32L4x6 advanced ARM®-based 32-bit MCUs
42.4.12 NSS pulse mode
This mode is activated by the NSSP bit in the SPIx_CR2 register and it takes effect only if
the SPI interface is configured as Motorola SPI master (FRF=0) with capture on the first
edge (SPIx_CR1 CPHA = 0, CPOL setting is ignored). When activated, an NSS pulse is
generated between two consecutive data frame transfers when NSS stays at high level for
the duration of one clock period at least. This mode allows the slave to latch data. NSSP
pulse mode is designed for applications with a single master-slave pair.

42.4.13 TI mode
TI protocol in master mode
The SPI interface is compatible with the TI protocol. The FRF bit of the SPIx_CR2 register
can be used to configure the SPI to be compliant with this protocol.
The clock polarity and phase are forced to conform to the TI protocol requirements whatever
the values set in the SPIx_CR1 register. NSS management is also specific to the TI protocol
which makes the configuration of NSS management through the SPIx_CR1 and SPIx_CR2
registers (SSM, SSI, SSOE) impossible in this case

камушек то под 2 тыщи стоит

TI "TM4C1294" - дорого и сердито - SPI работае на частоте до 60МГц (1/2 от тактовой) и с выборкой внешнего кристала "SS" там все хорошо))) Никаких "выбрать ручками".... Хотя есть странные индивидумы (мой коллега) - он "необъяснимо никаким здравым смысло" дрыгает этой ножкой тоже руками)))
Поддержка просто порaжает: форум с ответами в течении рабочего дня на любые вопросы(понятно, что все консультатнты - индусы со всеми вытекающими), своя библиотека не вызывающая НИКАКИХ нареканий - было желание писать все общение самому с нуля ,но посмотрев исходники , понял что получу тоже самое но только потеряю время
Так что для начала - просто сказка а не камушек и платы у них не хуже чем у STM - цена та же - около 20 баксаф...
Разводка плат сделана индусами со всеми вытекающими .... особенно аналоговая часть
Но для освоения нового камушка само то.

Нечто эдакое ? EK-TM4C1294XL (цена у нас, правда, около 40 кваксов).
Программатор-отладчик, по виду, на плате. Как эта платформа в отладке ? (привык к "хорошему", IAR)

У нас чуть дороже 20ки $ настоящих денег)
Программатор-отладчик на плате и виртуальный комп-порт для отдалки через принтф , например...
Отладка прекрасная - никаких притензий - все доступно - все ресурсы и периферия ... это все в Keil ( тоже привык к хорошему!!! и больше никогда на IAR c этим "убогим" спартанским IDE и "недоотладчиком"). После того как Keil купила ARM .. все встало как надо...
Самое важное, что для этого камня есть "безглючная" библиотека низкого уровня и TI поставляет бесплатную, постоянно обновляему IDE собственного производства, но ввиду безальтернативности в лице Keil-а оставил ее без внимания...
Вобщем рекомендую для старта!

Спасибо за инф.
IAR, возможно, есть "ньюансы" для каждого процессора. По IAR/MSP430 - у меня только плюсы.

О каких нюансах речь? Ещё несколько лет назад, ещё на прошлой работе создали линейку устройств на TM4C129DNCPDT. ПО там довольно большое и сложное (писалось группой программистов), с использованием многой периферии и без индусских "библиотек". Писалось/отлаживалось всё в IAR. Сейчас уже несколько лет как вся эта линейка продаётся. Производится сейчас по несколько тыс. шт. в месяц. Никаких проблем с IAR-ом или контроллером нет. Вполне нормальный МК. DMA-контроллер - так пожалуй вообще лучший из тех, что я видел в разных Cortex-M-МК.
А если у кого-то что-то не работает, то может это случай "плохого танцора"?

Вот -
https://blog.nxp.com/iot/crossover-to-extre...elq_cid=1860362

Без флэш-памяти.

И зачем на таком быстром МК тормозная флешь?

Зато посмотрите их цены. Это просто праздник.
Я глазом не успел моргнуть как раскупили их KIT-ы IMXRT1050-EVKB
Теперь сижу жду когда появятся в продаже.

А что за "Wireless connectivity interface for – Wi-Fi®, Bluetooth®, BLE, ZigBee® and Thread™" у IMXRT1050?

Да хорошо, если никаких. Шас начал работать с STM32F429. После Ti/MSP430 "ломка"
Вот думаю может отложить STM и начать с TM4C1294.

Кто их знает.
Может они этим намекает, что на него много чего из IoT портировано. Например https://github.com/zephyrproject-rtos/zephyr
А может в boot ROM на этот счет у них что-то есть.


В свое время я переходил с MSP430 на OMAP-ы того же TI.
Скажу вам что преемственности там никакой.
Так что если думает вам облегчит вхождение в новую архитектуру знание экосистемы производителя то зря.

В составе экосистемы присутствует документация и прочие сопутствующие материалы.
У Ti с этим все благополучно. А по STM - я пока не определился. Надо привыкнуть-разобраться что и где.
Ti дает на странице продукта и в даташитах массу перекресных ссылок. У STM с этим как-то "скромненько".
Или вообще пусто.

Может, вы тут не смотрели?

Вот даташит оттдуда
AN3126 Application note Audio and waveform generation using the DAC in STM32 microcontrollers.
А есть ли проект-исходник, соответствующий даташиту ? Ссылки в нем я не увидел. И есть ли ОНО вообще.
(Это я для примера привел. В Ti документации такие вопросы "что-где" не возникают - полно гиперссылок. Моей "фе" в этом смысле).
Наверное я не эвропээец . . .
ps
Googl проплачивает STM за "лаконичную" подготовку документации

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

Ну, претензий, кроме вышеупомянутой, нет. Пока. По причине того, что я только в начале процесса "раскуривания".
Этап RTFM.
Исходный код приложения, которое прошито в EVB NUCLEO-F429ZI. В любых вариантах. Оно мигает светодиодиками.
В даташите на EVB есть пара ссылок. Обе - на <www.st.com>
Понятно где смотреть. Это похоже на Ti DriverLib пакет, где все "в одной колбе" - и даташиты, и драйверы, и примеры для разных семейств контроллера.
(под 200 мб)

Спасибо за инф.

За документацию с кучей перекрестных ссылок можно на кол сажать не думая. Совершенно идиотская идеология создания технического документа, которую невозможно читать вдумчиво и воспринимать (как в ГОСТ-ах всяких). Куда удобнее в одном-двух-трех документах расписать весь функционал, разбить предмет описания на независимые модули. А когда читатель хочет поднять, например, SPI, он после прочтения главы только о SPI должен взять и запустить этот модуль. А не скакать по перекрестным ссылкам внутри документа, как там включить то, а как там включить это. Помню листал документацию от PIC32MX - проклял всех этих писателей. А у STM32 очень удобно сделано - если и есть перекрестные ссылки, то только внутри документа, и их количество невелико. И то, обычно недалеко в пределах текущей главы. И пусть такой документ 3-4 тысячи страниц будет, но мне, например, куда удобнее выделить часок-другой на перевод и переваривание интересующей главы и сразу же запустить периферию, чем танцевать с бубном на предмет "блин, а что ж я забыл то сделать то?".

Э нет, документация на TM4C1294 как раз очень интегрированная, там в одном документе все инфа содержится, даже систему команд Cortex-M4 туда всунули.
Секрет в том что там какая-то совершенно кастрированная периферия и они умудрились все засунуть в 1100 страниц.
Обычно на такие чипы документаци раза в два толще.

Тогда действительно что-то с ним точно не так
Коллеги пользуются такими МК (это ж Tiva-series, если не ошибаюсь) - но 80МГц выглядят как-то не привлекательными относительно 180МГц у тех же STM32 при прочих равных условиях (главным образом, процессор Cortex-M4F).
P.S. 80МГц - в каком-то из семейства Tiva-C, не говорю, что во всех так, но выше 150МГц Tiva-C вроде нет.
P.P.S. Подарили мне тут платку на XMC4800, периферию которой так открыто и усердно хвалил jcxz.

Беглым взглядом сразу захотелось узнать про возможности DMA (я сую DMA практически во все места, где это видится удобным) - очень заинтриговала возможность пересылок "периферия-периферия", то есть теоретически, без участия процессора, я могу конвертировать I2C, скажем, в SPI, или UART в SPI или как-нибудь еще. Кто досконально разбирался (например, jcxz), намекните, это правда? Без участия процессора сделать мост периферия-периферия? Или все-таки рекламный ход с кучей сопутствующих ограничений?

Что именно там "кастрированное"?


Ну "в каком-то из STM32" максимум 72МГц, что-ж Вы с ним не сравниваете?
Например (говорю по памяти) в Tiva 256-битная шина к памяти. И на тот момент (момент их появления) благодаря ей, разница в скорости выполнения линейного кода из флешь с STM32 была несущественной (когда мы выбирали Tiva для своего проекта). А вот преимущество более развитой периферии по сравнению с STM32 и бОльший объём ОЗУ - это для нас было существенно.


Что за рекламный ход? Где такое написано? И на кой ляд это нужно (практически, а не теоретически)?
Наверное возможно для каких-то протоколов, но ЗАЧЕМ???
В XMC возможно например для I2C с помощью DMA полностью запустить/выполнить/остановить одну или даже несколько подряд транзакций, с записью, чтением и тем и другим сразу. Запрограммировав её предварительно в памяти.
Да в принципе некоторые транзакции в XMC можно выполнять вообще даже без DMA: заранее запрограммировать содержимое пересылки в FIFO, а затем стартовать её от сигнала любой периферии (service request) или внешнего сигнала или даже логической комбинации сигналов через ERU.
Более сложной и функциональной периферии и связки периферия+DMA+service_request-ы я не видел ни в одном Cortex-M.
Хотя сам DMA в Tiva пожалуй получше...

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

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

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

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

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


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


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


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

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

Да какая разница сколько тактов будет выполняться блок инструкций в 128 битах? Все эти prefetch-буферы и ускорители, а в Вашем случае более широкая шина необходима лишь для обеспечения zero-wait-state при чтении из Flash (значит 4 32-битные инструкции за 4 такта будет выполнено). Для Tiva, поскольку в нем ускорителя нет, сделали более широкую шину, для STM32 - поставили ускоритель. Но лишь для одной цели - получить нулевое ожидание при доступе к данным или инструкции при чтении из Flash. А раз это условие выполнено, то STM32 выигрывает, поскольку может исполнять линейный код с бОльшей частотой. Какая разница какая там шина, если что там, что там задержка при чтении из Flash отсутствует при чтении линейного кода? Между заполнениями 128-битных строк ускорителя тоже 0 циклов ожидания, так что при вычитке следующих 4 инструкций никакого ожидания не происходит.

Хорошо, с этим понятно.

Ну, скажем, сформировать старт-стоп можно. А вот все пересылки данных ничем не отличаются между I2C и UART. Внешнее устройство пишет в UART какой-нибудь зарезервированный символ - XMC4800 формирует старт-условие. Дальше устройство пишет физический байт адреса по UART - он транслируется в I2C-шную посылку. И все остальные байты передаются либо принимаются (тем более UART полнодуплексный). По завершении транзакции XMC4800 формирует стоп-условие. Правда для этого XMC4800 нужно знать длину записываемых/считываемых данных для корректной работы логики запуска DMA. Ну опять же, это все мысли вслух, и если уж докопаться, то можно разных изворотов придумать, как угодно творческой душе разработчика (и не надо вот сейчас говорить что это сплошной бред и т.д., порой причудливые решения куда лучше справляются с задачей).

А какие преимущества запроса по уровню, а не по фронту?

Жесть Ревизию гляну как доберусь до платки. Спасибо, буду знать.

Да ладно?!... Похоже вы так и не взяли калькулятор и не посчитали...
4 инструкции в 128-битной строке кеша (допустим все они 1-тактные) - значит 4 такта. А сколько тактов wait-states требуется STM32 на 180МГц на выборку очередной порции данных из кеша при кеш-промахе? 7 или 8? И как позвольте узнать будет 0 тактов ожидания между заполнениями строк, если вся строка выполняется за 4 такта, а на чтение новой нужно 8 тактов??? (ещё раз - разговор про линейный код, или линейный участок кода по-крайней мере такой длины, что не влезает в кеш; т.е. - имеют место кеш-промахи).
И "ускоритель" в STM32 как я понимаю - это и есть просто кеш команд. Ну так в Tiva он тоже есть, только маленький.


Прочитаете мануал - разберётесь с возможностями.
Например у меня на XMC была задача: необходимо было передать из одного устройства на XMC в другое (на XMC) по UART небольшой пакет с данными (результаты вычислений). Кроме самих данных необходимо было в этой же пересылке передать и время получения этих данных на устройстве-источнике данных (в некий момент времени Т на устройстве-источнике данные считываются с АЦП, над ними выполняется ряд математических операций, полученный результат отправляется устройству-приёмнику, а также устройству приёмнику нужно передать момент времени чтения данных из АЦП (устройство-приёмник должно знать когда было чтение по его собственным часам) с максимально-возможной точностью, желательно до такта CPU).
Так вот я сделал примерно так: от таймера, который своим сигналом S1 запускает преобразование АЦП, также через некоторое время T2 (несколько мкс) генерится сигнал S2, запускающий передачу содержимого FIFO UART-а. По прерыванию завершения преобразования АЦП в ISR обрабатываются данные и записываются в FIFO UART. Время преобразования АЦП + время вызова и работы ISR заведомо меньше T2. Значит сигнал S2 возникает в момент когда данные для передачи уже лежат в FIFO.
В принимающем XMC я первый перепад на линии RX.UART (начала старт-бита) фиксирую таймером. Получается синхронизация ведущий-ведомый с точностью до такта частоты тактирования таймеров. И без джиттера!
На каком еще МК можно сделать подобное? Я таких не знаю.


Я где-то в этой теме (а может другой, но недавно) уже подробно описывал какие проблемы возникают при генерации DMA-запросов по перепаду уровня заполненности FIFO. Не хочу повторяться. Так вот: DMA-event-ы "по уровню" полностью снимают эти проблемы.
Вот оно: https://electronix.ru/forum/index.php?showt...t&p=1558972

Да уж, я думал я один изворачиваюсь с периферией как только можно
Ну а насчет количества тактов, кешей и выигрыша в широкой шине - ничего не буду говорить. У меня есть две платы - одна на Tiva-C (Cortex-M4, 80МГц) и STM32F4 (Cortex-M4, 180МГц). Напишу линейный длинный код на ассемблере, буду фиксировать контрольные точки таймером. Сравню результаты. Ибо, судя по описанию STM-овцев, их ART-ускоритель при линейном коде как раз-таки и работает на максимальную производительность - код не перепрыгивает никуда, не нужно перезаполнять строки кэша, как только выкачали 128 бит и начали их выполнять, тут же подкачивается еще 128 бит и т.д.
В общем, если будет время на неделе - отпишусь, что получилось. Пока что не верю