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

[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]

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

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

Опять же ещё раз открываем моё исходное сообщение и ещё раз внимательно перечитываем (раз не получается с первого раза):"когда мы выбирали Tiva для своего проекта".

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

Не очень понятно как вообще можно просто так передать из I2C в UART без какой-либо обработки протокола? Уже хотя бы потому, что I2C - это не просто поток байтов, а ещё и старты/стопы и адресации и переключение передача/приём и т.п.

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

И обработку этих запросов в DMA-контроллере сделали по уровню, а не по edge. Вот в XMC к сожалению до этого не додумались и там с этим связано много проблем.

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

PS: В первую очередь советую Вам сразу же на купленной плате проверить ревизию чипа (XMC). И перапаять на последнюю.
...
Так что имейте в виду.

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

[jcxz]

Между заполнениями 128-битных строк ускорителя тоже 0 циклов ожидания, так что при вычитке следующих 4 инструкций никакого ожидания не происходит.

Да ладно?!... Похоже вы так и не взяли калькулятор и не посчитали...
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