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

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

[_pv]

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

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

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

[jcxz]

Вот элементарно - есть АЦП внешний, управляется через SPI, CS-ом дергать обязательно. В STM32 CS не дергается аппаратно при транзакциях SPI, не понимаю, почему эти говноразработчики из STMicroelectronics не могут сделать это уже в какой реализации своих линеек микроконтроллеров? Из-за такого намеренного "косяка", который они вроде как и не пытаются исправить, невозможно запустить DMA на этот SPI, приходится запускать чертов таймер, дергать лапой в прерывании и там же запускать транзакцию

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

Какие камни наиболее гибкие в этом плане?

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

NXP вон умеет CSом дергать. в lpc8 во всяком случае, вряд ли в других сериях по другому.

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

Помню в AT91SAM7X512 (и младших по памяти моделях) была возможность не то что аппаратно лапкой CS дергать, так даже время задавалось в количествах тактов вот этих самых задержек. А тут фигу.

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

[Arlleex]

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

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

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

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

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


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

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

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

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

Сообщение отредактировал Arlleex - Mar 22 2018, 16:58

[jcxz]

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

[Arlleex]

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

[twix]

Видимо, этот CS у SPI не дает мне покоя

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

Сообщение отредактировал twix - Mar 22 2018, 18:50

[yes]

> В 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 программируете

[technik-1017]

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

[_pv]

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

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

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

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

[skripach]

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

[Arlleex]

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

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

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

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

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

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

[jcxz]

10МБайт встроенного ОЗУ выглядят очень внушительными.

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

[adnega]

невозможно запустить DMA на этот SPI,

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

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

[dac]

2. В обработчике прерывания этого таймера поднимаете CS ручками.
4. Потом опускаете CS ручками.
Чем не устраивает? п. 2 и п. 4?

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

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

[adnega]

приходит прерывание от таймера/внешнего прерывания с интервалом 1мкс

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

задача описана словами "надо дискретизировать сигнал 5000 выборок/сек и передать отсчеты наружу...", невольно понимаешь, что STM32 тут за глаза.

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

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

[_pv]

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

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

[dac]

1мкс -> 1МГц.
Даже на МК с тактовой 168МГц у вас 168 тактов на посылку. По-моему, ничего разумного за такое время не сделать.

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

[jcxz]

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

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

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

Не сделать чего??? 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стоп). Вот это и называется - гибкая и эффективная периферия

ЗЫ даже если 5кГц два раза дергать прерывание по 8 тактов вход/выход + сохранить, тоже нифига не радостно

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

[adnega]

на STM32 можно сделать без дёрганий в прерывания: завести сигнал прерывания от АЦП на какую-нить периферию, умеющую генерить запросы обслуживания к DMA (таймер например), и дальше всё сделать DMA: и CS и транзакцию по SPI.

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

[Arlleex]

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

[adnega]

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

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

[Andrew Su]

Добрый день.
На отладочнике 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

[inventor]

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

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

[backa]

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

[k155la3]

TI "TM4C1294" - дорого и сердито - SPI работае на частоте до 60МГц (1/2 от тактовой) и с выборкой внешнего кристала "SS" там все хорошо))) Никаких
. . .
Так что для начала - просто сказка а не камушек и платы у них не хуже чем у STM - цена та же - около 20 баксаф...
. . .

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

[backa]

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

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

[k155la3]

. . . Программатор-отладчик на плате и виртуальный комп-порт для отдалки через принтф , например...
Вобщем рекомендую для старта!

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

[jcxz]

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

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

[AlexandrY]

Какие камни наиболее гибкие в этом плане?

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

[ViKo]

Вот -

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

[jcxz]

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

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

[AlexandrY]

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

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

[segment]

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

[k155la3]

О каких нюансах речь? . . .

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

[AlexandrY]

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

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

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

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

[k155la3]

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

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

[adnega]

У STM с этим как-то "скромненько".

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

[k155la3]

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

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

[adnega]

А есть ли проект-исходник, соответствующий даташиту ?

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

[k155la3]

Т.е. к документации как к таковой претензий нет, а нужны какие-то исходники? . . .

Ну, претензий, кроме вышеупомянутой, нет. Пока. По причине того, что я только в начале процесса "раскуривания".
Этап RTFM.

. . . Кста, что вы понимаете под исходниками? . . .

Исходный код приложения, которое прошито в EVB NUCLEO-F429ZI. В любых вариантах. Оно мигает светодиодиками.
В даташите на EVB есть пара ссылок. Обе - на <www.st.com>

. . Какие-то исходники, слышал, можно получить тут. . .

Понятно где смотреть. Это похоже на Ti DriverLib пакет, где все "в одной колбе" - и даташиты, и драйверы, и примеры для разных семейств контроллера.
(под 200 мб)

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

[Arlleex]

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

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

[AlexandrY]

За документацию с кучей перекрестных ссылок можно на кол сажать не думая.

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

[Arlleex]

Тогда действительно что-то с ним точно не так
Коллеги пользуются такими МК (это ж 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), намекните, это правда? Без участия процессора сделать мост периферия-периферия? Или все-таки рекламный ход с кучей сопутствующих ограничений?

[jcxz]

Секрет в том что там какая-то совершенно кастрированная периферия

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

P.S. 80МГц - в каком-то из семейства Tiva-C, не говорю, что во всех так, но выше 150МГц Tiva-C вроде нет.

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

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

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

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

[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

[Arlleex]

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

[Arlleex]

Итак, ради интереса сделал тест.
Использую аппаратный регистр CYCCNT для подсчета реального количества тактов, затрачиваемых на исполнение кода.
Предварительно процессор настраивается на 180МГц, количество тактов процессора, затрачиваемое на чтение 128 бит из Flash - 6 циклов (5WS).
Код теста:

Код

        AREA MY_PROGRAM, CODE, READONLY
        
        ENTRY
        
MyProg    PROC
        
        EXPORT Main
        
DWT_CYCCNT    EQU    0xE0001004
DWT_CONTROL    EQU    0xE0001000
SCB_DEMCR    EQU    0xE000EDFC

Main
        ldr r0, =SCB_DEMCR
        mov r1, #0x01000000
        str r1, [r0]
        
        ldr r0, =DWT_CONTROL
        ldr r1, [r0]
        mov r2, #0x1
        orr r1, r2
        str r1, [r0]
        
        ldr r0, =DWT_CYCCNT
        mov r1, #0x0

        b loop
        
        LTORG

loop
        str.w r1, [r0]
        
        mul.w r3, r4, r5
    ; ...
    ; ТЫСЯЧА ТАКИХ ИНСТРУКЦИЙ
    ; ...
        mul.w r3, r4, r5
        
        ldr.w r2, [r0]
        
        b.w loop
        
        ENDP

        END

Инструкции как раз подобраны наихудшие: 1 такт исполнение, 32-разрядные из набора Thumb-2.

1. Отключаю кэш инструкций и данных, отключаю prefetch-buffer выборки.
2. Запускаю код на исполнение под отладчиком без точек останова.
3. Пока код выполняется, ставлю точку останова на строку

Код

b.w loop

и смотрю содержимое регистра R2 (считанное значение в 180МГц тактах): 0x8CB = 2251.
4. Время математики: 1000 однотактных 32-разрядных команд, 1000/4=250 циклов обращения к Flash-памяти по 128 бит. С учетом того, что WS=5, 5*250=1250 тактов накладных расходов на ожидание доступа к данным. Прибавляем такты выполнения команд: 1250 + 1000 = 2250. Что на 1 такт меньше считанного показания с системного регистра. Двигаемся дальше.
5. Включаем prefetch-buffer выборки и повторяем шаги 2-3. Содержимое CYCCNT = 1501.
6. Выключаем prefetch-buffer, включаем кэш. Содержимое CYCCNT = 2250. По-моему логично, поскольку в кэше хранятся адреса команд начала последних использованных подпрограмм и веток кода, а не сам код (в документации вроде про это написано).
7. Включаем prefetch-buffer и кэш. Содержимое CYCCNT = 1501.

Как видно, при включенном буфере предвыборки будет потеря производительности, однако если в коде будут использованы не только 32-разрядные инструкции Thumb-2, а 16-разрядные, скорее всего количество тактов совпадет с количеством инструкций между метками замера. Замерил - CYCCNT = 1001.
Отключаю prefetch - CYCCNT = 1251. Интересно, почему сейчас 1251, ведь 8 однотактных инструкций перекрывают 5WS при доступе к Flash... Это пока под вопросом, я разберусь.

Собственно говоря, этих сведений мне достаточно, чтобы полагать, что большого толку от широкой шины на Tiva-C не будет. Она сделана точно для таких же целей, для каких и ART-ускоритель в STM32 - обеспечить нулевое состояние задержки при выполнении смешанного (32-разрядного и 16-разрядного) кодов Thumb и Thumb-2.
Если сравнивать производительность выполнения 32-битного кода Thumb-2 STM32, работающего на частоте, допустим, 150МГц, над производительностью Tiva-C, работающего на 120МГц при выполнении того же 32-битного кода, то плюс широкой шине - бесспорно предвыборка 8 команд лучше чем предвыборка 4. Однако на реальной практике код представляет из себя смесь 16- и 32-разрядных инструкций, поэтому подобный метод расчета производительности не годится, нужны данные CoreMark или Dhrystone.

[jcxz]

7. Включаем prefetch-buffer и кэш. Содержимое CYCCNT = 1501.

Только зачем было делать столько телодвижений если уже из теории и следует эта цифра (250_выборок * 6_тактов_на_выборку = 1500) ?
Ваши измерения как раз и совпадают с теорией - значит выполнены правильно.

Как видно, при включенном буфере предвыборки будет потеря производительности, однако если в коде будут использованы не только 32-разрядные инструкции Thumb-2, а 16-разрядные, скорее всего количество тактов совпадет с количеством инструкций между метками замера. Замерил - CYCCNT = 1001.

Опять-же - берём в руки калькулятор и считаем:
Чтобы при длительности выборки ==6 тактов не было простоев из-за недозагрузки prefetch, нужно чтобы команды из этой выборки выполнялись как минимум те же 6 тактов.
А это возможно при 2*4+4*2 - т.е. в prefetch-пакете 2 шт. 32-битных команд + 4 шт. 16-битных. Т.е. - соотношение 32-битных к 16-битным должно быть как минимум 1/2.
А теперь возьмите и посмотрите код любого тяжёлого фильтра или какого-то другого тяжёлого алгоритма обработки данных, либо просто - большую сложную и хорошо оптимизированную функцию (в которой используется много регистров). Увидите, что подавляющее большинство команд как раз - 32-битные.
Только в простых функциях, где используется мало регистров, только в них бОльшее большинство команд 16-битные.
Если же написать на си какие-то операции с матрицами к примеру, в которых задействовано много переменных и скомпилировать с максимальным уровнем оптимизации, то там вообще почти все команды (с выхода компилятора IAR) будут 32-битные (IAR, имхо, плохо размещает данные по регистрам, не учитывая длину получающихся команд).
Конечно в таком потоке команд не будут все команды только однотактные. Предположим что в prefetch-блоке одна инструкция типа LDR или STR. Но тогда всё равно получается:
по размеру 3*4+2*2 = 16байт; по тактам 2+1+1+1+1 = 6тактов - только если в prefetch-блоке 3 команды 32-битные (одна из них - LDR/STR) + 2команды 16-битные - это граничный случай когда всё будет ещё успевать работать без остановок выполнения. А в реальном коде тяжёлых вычислений процентная доля 32-битных команд будет (имхо) всё-таки повыше.
А теперь ещё осталось вспомнить, что разговор идёт о Cortex-M4F. И вычисления с большой вероятностью будут не целочисленные, а с плавающей точкой. А где Вы видели 16-битные инструкции с float? А теперь ещё вспомним что регистров FPU гораздо больше чем целочисленных, что позволяет строить код с малым числом обращений с памяти, т.е. - на однотактных инструкциях в основном. Вот здесь то и получим существенную разницу.

Однако на реальной практике код представляет из себя смесь 16- и 32-разрядных инструкций

Да, Вы как-нить посмотрите на реальный код тяжёлых вычислений. Не тот код, который в обычных функциях со множеством ветвлений и малым количеством регистровых переменных, а на действительно вычислительный код (тем более с float). Ибо для обычных задач этих 120МГц и так - за глаза, а производительность я оценивал только для вычислительных задач.
Да, и ещё раз повторю: когда мы выбирали Tiva, не было STM32 на 180МГц, а были только максимум на 168МГц. А это разница по частоте всего на 40%. И часть из этих 40% покроется за счёт более широкой шины Tiva, так что останется выигрыш может процентов 20% (а в каких-то отдельных случаях может быть ещё и проигрыш, например - ISR со множеством переменных, редко выполняющийся (вытесненный из кеша) на Tiva может выполниться даже быстрее). А разница в 20% уже была для нас несущественна, на фоне выигрыша по ОЗУ и лучшей периферии.

Да и вообще: более слабая периферия приводит к дополнительным накладным вычислительным расходам (в случае STM32), что ещё сокращает разницу в скорости ядер. Уж не говоря о том, что многое из того, что мы сделали на Tiva, было невозможно сделать на STM32 (даже нонешних 180МГц). Это множество последовательных интерфейсов с полноценным FIFO и DMA, а также dual-SPI который позволили увеличить скорость работы с SPI-FLASH. А на STM32 мы бы ещё скорей всего не пролезли по скорости доступа к SPI-FLASH.

[COMA]

Я для себя определил два варианта для перехода:
серия i.MX RT либо серия STM32H7

[Arlleex]

Только зачем было делать столько телодвижений если уже из теории и следует эта цифра (250_выборок * 6_тактов_на_выборку = 1500) ?
Ваши измерения как раз и совпадают с теорией - значит выполнены правильно.

Теория, подтвержденная практикой - залог хорошего понимания природы вещей
Просто очень любопытно стало, и протестил, пока время есть.
А вот насчет 1250 тактов при всех инструкциях в 16 бит не могу понять, как так получается. Перерыл кучу документации, есть даже вот такая картинка:


Но как бы я ни строил график растактовки конвейера, все равно не получается там 1250. Даже при учете, что процессор считывает сразу 2 инструкции, но декодинг все-таки последовательный, все равно не совпадают расчеты. Откуда там два лишних такта берется на выборку каждых 128 бит из Flash - не пойму.
Да и рисунок выше какой-то не шибко понятный, слова "инструкции, после того как извлечены, могут несколько тактов тупить прежде чем процессор их декодировать начнет" - с чего бы это, казалось бы? "До двух инструкций может быть выбрано за одно чтение" - а вот этот механизм вообще интересен. Как процессор понимает, что перед ним 32-битная или 16-битная команда? По идее он всегда читает 32 бита и смотрит на поле кода операции, ну да ладно, с этим понятно. Ну а если он читает такой порядок:
1. instr 1 (16 bit);
2. instr 2 (16 bit);
3. instr 3 (16 bit);
4. instr 4 (32 bit);
5. instr 5 (32 bit);
6. instr 6 (16 bit).

Вот забирает он первые 32 бита и понимает, что там первая инструкция 16-битная, и потом декодирует вторую инструкцию - понимает, что она 16-битная тоже.
Забирает он следующие 32 бита. Декодирует первую команду, смотрит на код операции второй команды - а она 32-битная оказывается. Надо дочитать еще 16 бит с шины. Считывает 32 вместо 16. Декодирует уже полное слово. В буфере у него остались 16 бит 5-й инструкции. Она тоже 32-битная - он опять делает такие махинации. Потом из буфера забирает шестую инструкцию и декодирует, она 16-битная, все в порядке.
Однако вроде как утверждается, что даже рядом стоящие команды смешанной разрядности не влияют на количество тактов их выполнения. Как оно тогда устроено?

P.S. Отвечаю сам себе на второй вопрос. Логика придумалась в голове + наблюдения за PC в отладчике:
1. Процессор всегда считывает целое слово в регистр команды по адресу, который хранится в PC.
2. Процессор декодирует старшее полуслово (см. ARMv7M Architecture Reference Manual) и смотрит, 16- или 32-битная эта команда:
- если 16-битная, процессор ее выполняет и увеличивает PC на 2;
- если 32-битная, процессор обрабатывает ее как 32-битную и увеличивает PC на 4.
После этого логика переходит на п.1 и так по кругу.

На первый вопрос (откуда 1250 тактов) ответа пока что не нашел.

Сообщение отредактировал Arlleex - May 9 2018, 14:40

[Arlleex]

Итак, выложу сюда две растактовки из экспериментов.
1. WS = 5, Prefetch-OFF, 32-bit Thumb-2 command.

Здесь A - Addressing cycle, F - Fetch, D - Decode, E - Execution.

Для выполнения 4 полноценных 32-битных команд необходимо 9 тактов.
1000/4 = 250 обращений к памяти, соответственно, 9*250 = 2250 тактов - это время выполнения 1000 32-битных команд.

2. WS = 5, Prefetch-ON, 32-bit Thumb-2 command.

Здесь A - Addressing cycle, F - Fetch, D - Decode, E - Execution.

Для выполнения 4 полноценных 32-битных команд необходимо 6 тактов, поскольку при первом Fetch адресуются следующие 128 бит Flash-памяти устройством Prefatch-ера, и в итоге мы получаем перехлест в 2 такта в сторону понижения производительности.
1000/4 = 250 обращений к памяти, соответственно, 6*250 = 1500 тактов - это время выполнения 1000 32-битных команд.

3. WS = 5, Prefetch-OFF, 16-bit Thumb-2 command.
Пока что пусто, т.к. не понимаю как ведет себя процессор и подсистема pipeline с 16-битными инструкциями.
4. WS = 5, Prefetch-ON, 16-bit Thumb-2 command.
Очевидно, станет понятно, если прояснится п. 3.

Сообщение отредактировал Arlleex - May 9 2018, 15:29

[jcxz]

Итак, выложу сюда две растактовки из экспериментов.
1. WS = 5, Prefetch-OFF, 32-bit Thumb-2 command.

А какой практический смысл в отключении предвыборки?

[Arlleex]

Никакого абсолютно. У меня в проектах он всегда включен.
Поэтому чисто спортивный интерес к поведению процессорного устройства.

Пишут в документации, что при напряжении питания менее 2.1В prefetch необходимо отключать. При этом процессор может тактироваться до 120МГц. Поэтому в некоторых случаях и будет необходимо знать растактовку CPU на 16-битных командах.

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

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

[Arlleex]

Подниму свою же тему.
1. Программировал платку с XMC4800. И хотел найти ревизию MCU - беглым взглядом кроме как в обозначении самой микросхемы не нашел в Datasheet. На сайте у них все XMC4800 имеют последние две буквы AA. Глянул на МК помладше - там есть позиции AA, AB, AC... Я так понял это и есть ревизия?
2. Где узнать, какая ревизия ядра Cortex-M4F там стоит? Тоже довольно немаловажная информация, по которой лучше сразу скачать документацию нужной ревизии.

P.S. Отвечаю сам себе же.
Так же как и во всех других Cortex-Mx - в регистре IDCODE ревизия MCU, в CPUID - версия CPU.

Сообщение отредактировал Arlleex - Jul 6 2018, 05:27

[jcxz]

1. Программировал платку с XMC4800. И хотел найти ревизию MCU - беглым взглядом кроме как в обозначении самой микросхемы не нашел в Datasheet. На сайте у них все XMC4800 имеют последние две буквы AA. Глянул на МК помладше - там есть позиции AA, AB, AC... Я так понял это и есть ревизия?

Да. Для XMC4500 и XMC4700 - так и есть. Пишется в 3-й строчке на корпусе чипа.

PS: Ну и как впечатления от чипа?

[Arlleex]

PS: Ну и как впечатления от чипа?

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

[jcxz]

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

Да, через полгодика-годик уже в целом многое запомнится и будет казаться "как это я раньше без всего этого великолепия обходился?"

[Arlleex]

Да, через полгодика-годик уже в целом многое запомнится и будет казаться "как это я раньше без всего этого великолепия обходился?"

Кстати попутно вопрос позвольте задать.
Вы используете XMCLib или только хардкорный XMC4xxx.h и погнали кодить с референсом перед глазами? Я тут просто бегло глянул эту библиотеку - не совсем прикинул что к чему.

[jcxz]

Вы используете XMCLib или только хардкорный XMC4xxx.h и погнали кодить с референсом перед глазами? Я тут просто бегло глянул эту библиотеку - не совсем прикинул что к чему.

3-й вариант. У меня все структуры-определения IO-периферии - свои.

[Arlleex]

Боюсь мне начальство не выделит времени на такие процедуры

[jcxz]

Боюсь мне начальство не выделит времени на такие процедуры

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

[Arlleex]

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

Ну как сказать с секундомером... Спешка всегда и всюду Отсюда и бывают не до конца выловленные баги (по вечерам после работы вычищаю, если есть). Всегда хочется посидеть, лучше продумать алгоритм, поковырять досконально МК, узнать плюшки и фишки, но нужен только результат и никого не волнует, насколько крутой программный автомат я сделал.
Бежать, да вот куда? Везде такая суета, ИМХО
А описывать структуры - я на самом деле когда-то делал, но для AVR/PIC/ARM7. Времени у меня было побольше тогда
Ну это все так, лирика. Больше склоняюсь к варианту, что файла описания регистров IO-периферии мне хватает. Но другое дело, если они по-уродски будут структурированы в XMC или названия не понравятся - буду переписывать. Благо с XMC я занимаюсь чисто для себя, для расширения кругозора в области существующих МК.

Сообщение отредактировал Arlleex - Jul 6 2018, 10:06