Ассемблер KEIL

[Reflector]

protoder писал(а):

Я так понимаю, что для равномерного чтения надо отключить Prefetch (вроде больше олучать неравномерность на M0 не от куда). Но тогда скорее всего и производительность упадет.

Узкое место M0 - фон Неймановская архитектура, он пишет в RAM используя ту же шину посредством которой считывает инструкции. Если нужна скорость за малые деньги, то проще взять F303, они сейчас по цене как G0...

[protoder]

>> Если нужна скорость за малые деньги, то проще взять F303, они сейчас по цене как G0...

Да, я про них много слышал хорошего. Но - я пока с M0 разбираюсь.

Добавлено after 3 minutes 12 seconds:
>> Вы понимаете, что там начнутся проблемы с топологией платы и эл.магн.проблемы?

Ну, в текущей версии эта хрень через буферную память работает... Так что... Хуже-то точно не будет

[Кислородный]

В худшем случае инициализация даже двух пинов потребует записи в 6 регистров и, как минимум, будет размазана по коду. Оставшиеся 14 пинов опять же придется разбивать на группы,

Ну а что, по вашему, написано у Владислава? Вы ассемблерный код то читайте:

Код:

        MOVW     R1,#+21845            --- это  0101 0101 0101 0101 в двоичном виде
        LDR.N    R2,??__low_level_init_0+0x2C  ;; 0x48001002   --- это адрес MODER, верхнее полуслово
        STRH     R1,[R2, #+0]    ---- а это запись полуслова целиком в регистр MODER (верхнее полуслово)


ровно то же самое получается и с гораздо меньшими понтами. То есть -запись полуслова за один раз. Доступ по полуслову - это не бохвесть какое "открытие". ("открытие" не работает в F1 - там нет такого). Убрал ----------

Предупреждение за переход на личности. Fakir. На первый случай предупреждение нигде не фиксируем.

[Reflector]

Кислородный писал(а):

Ну а что, по вашему, написано у Владислава? Вы ассемблерный код то читайте:

Дело даже не в генерируемом коде... Допустим есть два пина для USART, в одном случае можно написать как-то так:

Код:

PinList<PinA<5, AF4>, PinC<11, AF0>>::mode<PinMode::AF_PushPull, PinMode::AF_PullUp>();   // TX3, RX3

или так:

Код:

PinList<PA5, PC11>::mode<PinMode::AF_PushPull, AF4, PinMode::AF_PullUp, AF0>();   // TX3, RX3

И это еще не самый продвинутый вариант, лично я пишу просто

Код:

usart3.init<PA5, PC11>(115200);

а AF подставляются сами, при этом еще и проверяется могут ли данные пины в принципе быть TX3 и RX3, иначе ошибка компиляции, так что даже перепутать TX с RX местами не представляется возможным. Что же в качестве альтернативы? Инитить MODER/OTYPER/OSPEEDR/AFRL для PA и MODER/OTYPER/OSPEEDR/PUPDR/AFRH для PC вручную? Потом нужно будет проинитить пины для USART2 и делать тот же самое заново?

[Кислородный]

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

[Мурик]

Ну, в текущей версии эта хрень через буферную память работает

В смысле к МК подключена внешняя память с параллельным интерфейсом работа с которой осуществляется ногодрыгом? Не проще взять МК с FSMC?

[Reflector]

Кислородный писал(а):

Нет, дело как раз в сгенерированном коде! Ведь именно этим понтовался Владислав, что типа не используется модификация. И пример подобрал "удачно" - последовательно 8 ног. Так то....

Не обязательно 8 ног подряд, положительный эффект достигается и при 4-х или 2-х ногах подряд, т.к. в регистрах AFRx поля 4-х битные и AF для пары пинов можно прописать при помощи одной STRB. Даже на одном пине может быть экономия если константа получается достаточно большая и компилятор получает ее путем сдвига более мелкой, а в шаблонной либе мелкая константа пишется в отдельный байт регистра. Но это все мелочи по сравнению с тем, что в одном случае будет одна строка, а в другом нужно инитить 9 регистров и тогда намного легче получить код не менее эффективный, а просто не рабочий

[Кислородный]

Ну вот, теперь и вы, Reflector, запутались. Разве я об этом писал? К тому же, есть F1xx, где ничего из этого, кроме целого четырехбайтного слова, не работает.
Программист должен быть гибким, мыслить ясно, подход выбирать логично, ну и обладать опытом - багажом предыдущих успехов и ошибок. Это не мной придумано. Программированию уже почти сотня лет, а если брать основы, то и того больше. И у истоков стояли люди поумнее нас с вами. Так и надо перенимать у них опыт, а не изобретать закостенелую отсебятину.
В наше время всё очень быстро меняется. Пока вы выдумываете мегабайты портянок, всё, поезд уже ушел, и вам надо перестраиваться на другие рельсы. А как это сделать, если вы слишком неповоротливы? Вот то-то и оно!

[protoder]

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

вот, вот, я про это и говорю. Свойство национальных технических форумов. Понтов и самоутверждений за счет собеседника иногда больше, чем полезной информации.
На англоязычной этой фигни сильно меньше. Что, в целом, очень обидно...

Добавлено after 8 minutes 22 seconds:

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

Ну, в текущей версии эта хрень через буферную память работает

В смысле к МК подключена внешняя память с параллельным интерфейсом работа с которой осуществляется ногодрыгом? Не проще взять МК с FSMC?

К МК подключена буферная память, в которую считывается на частоте около 80 мГц данные с АЦП. После чего atxmega в расслабленном режиме все это добро забирает, пересылает на комп. Где оно уже подвергается окончательной вивисекции

>> Не проще взять МК с FSMC?

Неа. Там 2 канала по 8 бит. FSMC узковата для них.
Да и, помнится, 80 мГц FSMC не потянет.

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

Добавлено after 7 minutes 41 second:
>> Узкое место M0 - фон Неймановская архитектура

Неймановская? Я че-то был уверен, что вроде Гарвардская. Разве нет?

[Мурик]

Неа. Там 2 канала по 8 бит. FSMC узковата для них.

16 бит. В некоторых МК 32 бита.

[protoder]

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

Неа. Там 2 канала по 8 бит. FSMC узковата для них.

16 бит. В некоторых МК 32 бита.

>> 16 бит. В некоторых МК 32 бита.

Ага... как в старом анекдоте - перепутал с прямым углом
Да, я имел ввиду интерфейс камеры.
FSMC тогда надо будет посмотреть. По идее, все все равно упрется в пропускную способность DMA.

Кстати, любопытно - если забирать данные с порта не одним, а двумя каналами DMA/ Со сдвигом по времени в половину цикла передачи. Это даст удвоение пропускной или нет?

[Мурик]

К МК подключена буферная память, в которую считывается на частоте около 80 мГц данные с АЦП. После чего atxmega в расслабленном режиме все это добро забирает, пересылает на комп.

Как МК на тактовой частоте 32 МГц успевает принять поток данных на частоте 80 МГц?

[protoder]

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

К МК подключена буферная память, в которую считывается на частоте около 80 мГц данные с АЦП. После чего atxmega в расслабленном режиме все это добро забирает, пересылает на комп.

Как МК на тактовой частоте 32 МГц успевает принять поток данных на частоте 80 МГц?

Да ни как. Говорю ж - память буферная. Сначала в нее быстро пишу, потом из нее медленно читаю.
Все круто. Но упростить устройство было б не плохо.

Добавлено after 6 minutes 47 seconds:
>> Не проще взять МК с FSMC?

Ну нет. FSMC хороша, когда нужны сигналы управления внешним устройством. Я все таки пока надеюсь решить проблему прямым чтением портов, и синхронизацией от MCO. Говорят, на F3 или F4 такое должно пройти. Вот домучаю F0, буду с ними разбираться.
F0 мне пока видятся хорошей заменой для Atxmega в ее задачах. Они примерно равны по мощи ( а в задачах с большим количеством математических вычислений Сortex сильно впереди). Но зато по цене в 3-4 раза дешевле.

Добавлено after 9 hours 30 minutes 5 seconds:
Вспомнил кстати одну ситуацию, где применение ассемблера оправдано даже на такой неудобной для этого платформе, как современные Pentium. Это использование новомодных векторных инструкций. Они практически не используются линейными компиляторами - рассчитаны-то на проведение параллельных вычислений. Я на них когда-то БПФ делал. Выигрыш более чем на 2 порядка по времени, чем библиотечный вариант на С++.
БПФ вообще выпендрежный алгоритм. Я на atxmega для его реализации некогда DMA использовал для ускорения процесса

[КРАМ]

protoder писал(а):

Я на них когда-то БПФ делал. Выигрыш более чем на 2 порядка по времени, чем библиотечный вариант на С++.
БПФ вообще выпендрежный алгоритм. Я на atxmega для его реализации некогда DMA использовал для ускорения процесса

Векторные инструкции тут не причем. Они вторичны. Первично использование DSP-инструкций. Дело в том, что типовая операция DSP - это A=A+X*Y (A=A-X*Y). Именно на ней строятся IIR, FIR и "бабочка" FFT. Однако и тут дело не в математике этой операции. Дело в управлении указателями. Эти инструкции ВНУТРИ СЕБЯ содержат предвыборку операндов и модификацию указателей на операнды. Именно в этом состоит проблема описать эти инструкции посредством языков программирования. Поэтому обычно библиотеки содержащие DSP функции (IIR, FIR, DFT, FFT и пр.) написаны на АСМе.
Не очень понятно, каким образом DMA Вам помог реализовать FFT. Ну разве только битреверсную перестановку сделать и то не понял как и зачем. Но это не занимает много времени при реализации FFT, ибо делается лишь один раз - на входе при прореживании по времени или на выходе при прореживании по частоте. Сама битреверсная перестановка, если нет ее аппаратной поддержки, для аналитического вычисления не только на Си, но и на АСМе будет корявой. Проще забить таблицу.

[protoder]

КРАМ. Если честно, ни чего не понял.
Ну, да фиг с ним. Снова про ассемблер M0.
А как в M0 пользоваться регистрами r8-r13? Я так понял, их можно применять только в операции ADD и BX. Но как их загрузить для использования в BX - вааще не понятно.

[КРАМ]

Как же Вы писали FFT на АСМе, если ничего не поняли из мною сказанного?

[protoder]

КРАМ писал(а):

Как же Вы писали FFT на АСМе, если ничего не поняли из мною сказанного?

Ну, учитывая, что правда вообще не понял, о чем речь, ответить мне будет затруднительно
Я вообще говорил про SIMD инструкции х86-й платформы. Которые позволяют за один раз выполнять арифметические ( и не только) операции над несколькими элементами массива. Термин DSP я знаю только как название сигнального процессора. Если это из их области, то я с ними не знаком.
Ну а про указатели и предвыборку - я действительно не понял контекста. Ну, как бы... понятно, что алгоритм FFT требует какой-то работы с указателями. Но, вроде, штука-то совсем штатная. Вобщем, не понял.

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

[КРАМ]

protoder писал(а):

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

Объясню на примере mac-команды DSP ядра контроллера dsPIC33.
Примерный вид команды выглядит как:

Код:

        mac      W5*W7, A, [W8]-=2, W5, [W11]-=2, W7


Это означает, что к содержимому 40-битного аккумулятора А будет прибавлен результат знакового умножения содержимого регистров W5 и W7, затем регистр W5 будет загружен (предвыборка для следующего кода) содержимым по указателю в W8, а регистр W7 по указателю W11. Затем указатель W8 будет декрементирован на 2 (одно слово), тоже самое будет проделано с W11.
Попробуйте заставить все это сделать компилятор так, чтобы он понял, что речь идет о mac-инструкции с таким содержимым, а не о дискретных инструкциях...

[Sergi]

В своей второй конструкции осциллографа тоже использовал буферную память и тоже с М0. Тема есть на форуме. Прибор успешно работает. Быстрая запись медленное чтение во внутреннюю RAM с обработкой. Тактирование от MCO или TIM1. Захват до удвоенной частоты тактирования ограничен скоростью работы памяти.

[КРАМ]

protoder писал(а):

Я вообще говорил про SIMD инструкции х86-й платформы. Которые позволяют за один раз выполнять арифметические ( и не только) операции над несколькими элементами массива...

Проблема многоядерного АЛУ (SIMD) состоит в том, что сама по себе математика может быть распараллелена на любое количество ядер, однако операнды нужно откуда то брать и результат куда то сохранять. А вот с этим полная засада. Патамушта дорога к ОЗУ всего одна. И никак не можно одновременно читать/писать по ней целый массив. Только один операнд, увы, может быть получен/отправлен по этой дороге в одном машинном цикле. В ДСП ядрах, правда, строят ДВЕ параллельных дороги. Но каждая из них ведет к АППАРАТНО разным секциям ОЗУ с одной стороны, и к разным РОНам с другой. Только так можно выполнить двухоперандную с точки зрения обращения к ОЗУ инструкцию за один машинный цикл.

Так вот о SIMD. Что бы применение параллельных АЛУ было рентабельно с точки зрения выигрыша по производительности, нужно грамотно размещать данные в ОЗУ разных уровней параллельного вычислителя. И максимально удлинять вычислительные блоки каждого АЛУ, чтобы минимизировать транзакции между ОЗУ разных уровней. Геморрой еще тот...