Характеристики STM32

[protoder]

Здравствуйте. Для быстрой оценки возможности перехода на stm32 с atxmega хочу понять следующие параметры stm32 микроконтроллеров, не самые очевидные. В частности, в datasheet с первого захода найти их не получилось:
1 - максимальная скорость опроса портов: сколько тактов понадобится на чтение порта (кстати, верно ли чя понимаю, что порты только 16 разрядов. 32-х разрядных не бывает)?
2 - есть ли возможность вывести наружу сигнал тактовой частоты микроконтроллера
3 - может ли PLL работать от внешнего генератора (что бы иметь возможность синхронизировать микроконтроллер со внешним устройством по частоте

И вообще интересно было бы посмотреть скорость выполнения инструкций ассемблера. Есть же такие таблицы?

[Аlex]

1. Интересно, зачем Вам понадобилось это знать ? Вы собрались программно опрашивать вход с частотой в десятки мегагерц ? Для таких задач существует периферия. Забудьте о структуре AVR, тут всё по-другому.
Ну а вообще, зависит от частоты тактирования порта. По командам - 2...3 штуки.

2,3. На эти вопросы ответит даташит. Конкретно - раздел по тактированию (По памяти, если не ошибаюсь - RCC).

[Reflector]

protoder писал(а):

1 - максимальная скорость опроса портов: сколько тактов понадобится на чтение порта (кстати, верно ли чя понимаю, что порты только 16 разрядов. 32-х разрядных не бывает)?

От серии зависит, хочешь быстрый ногодрыг, бери F3, там можно за 2 такта забрать байт с порта и сохранить в память, в 3 раза быстрее, чем F1. Порты 16 бит.

2 - есть ли возможность вывести наружу сигнал тактовой частоты микроконтроллера

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

3 - может ли PLL работать от внешнего генератора (что бы иметь возможность синхронизировать микроконтроллер со внешним устройством по частоте

Да, PLL может работать от HSE, а для того есть bypass...

[protoder]

Спасибо за ответ.

>> там можно за 2 такта забрать байт с порта и сохранить в память, в 3 раза быстрее, чем F1

А что скажите про F051, F030 и F407?
ОТ чего зависит скорость? ОТ времени обработки ассемблерных команд, или от наличия команд, которых нет в младших моделях.
А можете указать комбинацию ассемблерных команд, которая прочитает за 2 такта (не смейтесь, я пока очень мало знаю про stm32)?

>> Да, PLL может работать от HSE, а для того есть bypass

Звучит очень круть! А вот по русски сможетеtnt (говорю ж, я пока мало что про stm знаю. Пока только пытаюсь понять, стоят ли они знакомства).

И еще вопрос - а какова реальная максимальная частота работы контролеров. Например, 48 мГц в F0- это потолок. Или работают и на 64 мГц?

[Мурик]

ОТ чего зависит скорость? ОТ времени обработки ассемблерных команд, или от наличия команд, которых нет в младших моделях.

В первую очередь от железа. И от частоты периферийных шин конечно же.

А можете указать комбинацию ассемблерных команд, которая прочитает за 2 такта (не смейтесь, я пока очень мало знаю про stm32)?

Для чего вам асм? Нужно быстро читать или записывать в порт? Лучше использовать DMA. http://www.cyberforum.ru/blogs/204791/blog5169.html

Звучит очень круть! А вот по русски

Прохождение тактового сигнала от HSE через умножитель (PLL).

Спойлер

Clock.png

(36.69 KiB) Скачиваний: 104

какова реальная максимальная частота работы контролеров. Например, 48 мГц в F0- это потолок. Или работают и на 64 мГц?

Разогнать можно до 96 МГц. http://purebasic.mybb.ru/viewtopic.php?id=583

[Reflector]

protoder писал(а):

А что скажите про F051, F030 и F407?

F0 - ~5 тактов, F4 - 4, но там и для DMA столько получается, а для F3 и F1 с DMA выходит заметно медленнее.

ОТ чего зависит скорость? ОТ времени обработки ассемблерных команд, или от наличия команд, которых нет в младших моделях.
А можете указать комбинацию ассемблерных команд, которая прочитает за 2 такта (не смейтесь, я пока очень мало знаю про stm32)?

LDRB + STRB, но это 2 такта для группы таких пар выполненных последовательно, для одной сложно сказать, там же конвеер, даже замерять точно не так просто. И для F3 код нужно из CCRAM выполнять. Скорость зависит фиг поймешь от чего, если у F1 порты висят на APB шине, вместо AHB, то пару тактов только из-за этого добавляется, а почему F3 настолько быстрее F4 сложно сказать...

Звучит очень круть! А вот по русски сможетеtnt (говорю ж, я пока мало что про stm знаю. Пока только пытаюсь понять, стоят ли они знакомства).

PLL может работать от внешнего генератора, не знаю что ты тут хочешь еще услышать

И еще вопрос - а какова реальная максимальная частота работы контролеров. Например, 48 мГц в F0- это потолок. Или работают и на 64 мГц?

STM32 гонятся очень хорошо, мелкие F0 на 96 MHz работают, 48-ми пиновые где-то на 80. F429 у меня работает на 300.

[protoder]

Аlex писал(а):

1. Интересно, зачем Вам понадобилось это знать ? Вы собрались программно опрашивать вход с частотой в десятки мегагерц ?

Ну... вообще-то да. А что мешает?

>> Забудьте о структуре AVR, тут всё по-другому.

Поясните

>> Ну а вообще, зависит от частоты тактирования порта. По командам - 2...3 штуки.

То есть я правильно понимаю, что порты висят на шине с меньшей частотой, и от этого зависит скорость команды - рискну предположить чтения из порта в регистр. Например, шина 1/4 clk, соответственно чтение порта 4 т.и. А потом еще из регистра надо переписать в память - еще один такт. Точно?

Добавлено after 14 minutes 25 seconds:
Народ, спасибо за ответы.

>> Нужно быстро читать или записывать в порт? Лучше использовать DMA.

В atxmega DMA медленнее, чем ассемблер, и, главное, она может уступать такты процессору, в итоге не факт, что частота опроса будет равномерной. А это в моей задаче (читаю АЦП) принципиально. В stm это не так?

>> Прохождение тактового сигнала от HSE

Очень сори - но кто такой HSE?

>> F4 - 4

В datasheet на 407 пишут про Up to 136 fast I/Os up to 84 MHz. Это что имеется ввиду? Частота шины портов?

>> F0 - ~5 тактов, F4 - 4, но там и для DMA столько получается, а для F3 и F1 с DMA выходит заметно медленнее.

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

>> для одной сложно сказать, там же конвеер

Конвеер? STM32 используют конвеер? То есть там не RealTime? Это сюрприз из неприятных. И это справедливо даже для M0? Или только для М4?

[Reflector]

protoder писал(а):

В atxmega DMA медленнее, чем ассемблер, и, главное, она может уступать такты процессору, в итоге не факт, что частота опроса будет равномерной. А это в моей задаче (читаю АЦП) принципиально. В stm это не так?

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

Очень сори - но кто такой HSE?

High speed external clock signal.

В datasheet на 407 пишут про Up to 136 fast I/Os up to 84 MHz. Это что имеется ввиду? Частота шины портов?

Оно видимо где-то так и получается, 2 такта на чтение, 2 на запись.

А вообще откуда такая информация? Опыт - или есть какая-то документа, в которой все это прочитать можно?

Такая информация добывается опытным путем, прочесть у других то можно, но ее достоверность будет пропорциональна опыту написавшего, лично я себе больше доверяю

Конвеер? STM32 используют конвеер? То есть там не RealTime? Это сюрприз из неприятных. И это справедливо даже для M0? Или только для М4?

Что значит не реал тайм? На абсолютном большинстве достаточно быстрых мк есть конвеер, по крайней мере если исполнение из флеша, потому что этот флеш медленный, по докам на каждые 24MHz добавляется такт ожидания(хотя реально можно добавлять где-то на каждые 40 MHz), без конвеера мк большую часть времени может просто ждать...

[protoder]

>> Такая информация добывается опытным путем, прочесть у других то можно, но ее достоверность будет пропорциональна опыту написавшего, лично я себе больше доверяю

В плане что в datasheet такого не пишут?

Добавлено after 9 minutes 41 second:
>> На абсолютном большинстве достаточно быстрых мк есть конвеер

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

[Sergi]

F0 захватывает за 4 такта. Опыты зафиксировал https://www.youtube.com/watch?v=PVgRDEoOYMI

[VladislavS]

Что за АЦП? Наверняка можно какую-нибудь шину аппаратную к нему организовать. Ногодрыг - последнее дело.

[Sergi]

Если вы за захват АЦП, то можно организовать внешний буфер и захватывать хоть за полтакта. Так я тоже делал в своем осциллографе.

[Мурик]

Странно - я думал, на таких частотах конвееры еще не нужны.

При чем здесь частота? Никогда не задумывались как МК может исполнять инструкцию за такт? Ведь ее нужно извлечь из флеша, поместить в проц, декодировать, исполнить и т. д. Даже в AVR (ATmega) есть конвейер.

Это большой плюсик в сторону atxmega

У нее тоже конвейер.

[Reflector]

Sergi писал(а):

F0 захватывает за 4 такта. Опыты зафиксировал https://www.youtube.com/watch?v=PVgRDEoOYMI

Может быть, я сомневался, потому и написал ~5 тактов. На M0 команды урезанные, нет STR с инкрементом, приходится использовать смещение, а оно всего 8-ми битное. Для твоего дисплея достаточно, а у меня был буфер 3.8KB, потому задействовал DMA.

Мурик писал(а):

У нее тоже конвейер.

Он там простенький, одноуровневый. Хотя M0 с точки зрения предсказуемости времени выполнения команд не далеко ушел, особенно если запускать на частотах где такты ожидания еще не нужны. Это у M3 уже куча исключений...

[Sergi]

В моем опыте запись 320 семплов развернутым циклом. Пробовал писать в порт через ODR c байтовой адресацией и через BSRR. Скорость получалась одинаковая.
В разгоне F030 с Flash latency =0 работал до 40-42МГц, с =1 до 75-80МГц. Всвязи с обилием кварцев 13 и 26МГц обычно запускаю PLL на 65, работает.

[Reflector]

Sergi писал(а):

В моем опыте запись 320 семплов развернутым циклом. Пробовал писать в порт через ODR c байтовой адресацией и через BSRR. Скорость получалась одинаковая.

Т.е. этот фрагмент не на ассме написан? Если да, то компилятор может переставлять инструкции, у меня он просто сначала в кучу регистров читал с порта, а потом их сохранял, получалось быстрее, но не то, что нужно Плюс запись в порт и чтение из него могут занимать разное количество времени, особенно на мк где есть write buffer.

В разгоне F030 с Flash latency =0 работал до 40-42МГц, с =1 до 75-80МГц.

Так и есть, только не все знают, что латентность для F0 можно хоть 7 выставить, а 2 реально может пригодиться, если разгонять до 80+ MHz.

[Sergi]

Писал на С типа так

buff[i] = GPIOA->IDR;
i++;
buff[i] = GPIOA->IDR;
i++;
....
2 такта на чтение из IDR, 1 такт на сохранение buff, 1 такт на инкремент. С DMA получалось дольше.
На М3 пробовал блочные команды чтобы захватить и сохранить за 2 такта, но они работали до 31(15 ?) выборки. Далее компилер переводил на длинные команды. Такое не подошло.
Вот перевод описания работы префитч буфера:
Реализация этого буфера предварительной выборки делает возможным более быстрое выполнение ЦП, поскольку ЦП выбирает одно слово за раз, а следующее слово легко доступно в буфере предварительной выборки. Это означает, что коэффициент ускорения будет порядка 2 в предположении, что код выровнен по 64-битной границе для переходов.
Выходит что с латентностью WS=1 скорость обработки команд не уменьшается.

[Reflector]

Sergi писал(а):

Писал на С типа так

buff[i] = GPIOA->IDR;
i++;
buff[i] = GPIOA->IDR;
i++;

Я про это и говорил, так делать не рекомендуется, по факту из этого кода может получиться такое:

Код:

R0 =  GPIOA->IDR;
R1 =  GPIOA->IDR;
R2 =  GPIOA->IDR;
R3 =  GPIOA->IDR;
buff[i++] = R0;
buff[i++] = R1;
buff[i++] = R2;
buff[i++] = R3;


На М3 пробовал блочные команды чтобы захватить и сохранить за 2 такта, но они работали до 31(15 ?) выборки. Далее компилер переводил на длинные команды. Такое не подошло.

У М3 есть команды с инкрементом, их повторяй сколько хочешь.

Код:

LDRB R0, [R1]
STRB R0, [R2], #1

31 - это смещение для коротких команд(или для M0), но относительно SP(команды тоже короткие) оно уже 8-ми битное, а скорость такая же.

Выходит что с латентностью WS=1 скорость обработки команд не уменьшается.

Скорость уменьшается для любой латентности отличной от 0. Естественно это происходит не всегда, но некоторые команды, типа перехода, сбрасывают конвеер и тогда для первой команды придется ждать эти дополнительные такты.

[Sergi]

В моем случае все работало через один регистр,захват был равномерный.

[Reflector]

Sergi писал(а):

В моем случае все работало через один регистр,захват был равномерный.

Очень в этом сомневаюсь, скорее, как это часто можно наблюдать, все проверки делались на глаз Но давай проверять... Берем твою строку и размножаем ее 80 раз:

Код:

buff[i++] = GPIOA->IDR;

Для F0 на выходе получаем LDR+STR для первых 32 элементов, если замерять скорость, то тут каждый байт сохраняется за 4 такта. Дальше компилятор между LDR и STR встроил ADDS, может показаться, что теперь тактов стало 5, но суммарно весь код выполняется за ~407 тактов, это 5.08 тактов на байт, т.е. LDR+ADDS+STR выполняются в среднем за 5.8 тактов. Так что тут нет никакой равномерности и быстрее DMA, который справляется за 5 тактов, получается только если писать на ассме со cмещением относительно SP и забирать всего пару сотен байт. Кстати, из RAM работает чуть быстрее и тогда действительно пара инструкций выполняется за 4, а три - за 5 тактов.

Теперь переносим код на F3, для локального буфера все похоже, LDR+STR, но если буфер сделать глобальным, то для 20 элементов получается следующая картина

Спойлер

Код:

ldr r1, [r3, #16]   
ldr r2, [r3, #16]   
ldr r7, [r3, #16]   
ldr r6, [r3, #16]   
ldr r5, [r3, #16]   
ldr r4, [r3, #16]   
ldr r0, [r3, #16]   
strb.w r1, [r8, #484]
ldr r1, [r3, #16]   
strb.w r2, [r8, #485]
ldr r2, [r3, #16]   
strb.w r7, [r8, #486]
ldr r7, [r3, #16]   
strb.w r6, [r8, #487]
ldr r6, [r3, #16]   
strb.w r5, [r8, #488]
ldr r5, [r3, #16]   
strb.w r4, [r8, #489]
ldr r4, [r3, #16]   
strb.w r0, [r8, #490]
ldr r0, [r3, #16]   
strb.w r1, [r8, #491]
ldr r1, [r3, #16]   
strb.w r2, [r8, #492]
ldr r2, [r3, #16]   
strb.w r2, [r8, #499]
strb.w r1, [r8, #498]
strb.w r7, [r8, #493]
strb.w r6, [r8, #494]
strb.w r5, [r8, #495]
strb.w r4, [r8, #496]
strb.w r0, [r8, #497]
ldr r0, [r3, #16]   
ldr r1, [r3, #16]   
ldr r2, [r3, #16]   
ldr r3, [r3, #16]   
strb.w r3, [r8, #503]
strb.w r0, [r8, #500]
strb.w r1, [r8, #501]
strb.w r2, [r8, #502]