>> Appendix_B2.pdf [94 KiB]

Спасибо. Я такого документика не видел.

Добавлено after 43 minutes 37 seconds:
>> Ну конечно вы можете помучаться, вероятно вам кажется что сейчас это позарез нужно. Пожалуйста, не возражаю!

Тут смотрите, какой контекст. Вопрос, стоит или нет писать на ассемблере - вполне достоин обсуждения. Да и поспорить я - всегда ни вопрос. И сейчас, когда уже в теме в основном получены ответы - да почему бы и не обсудить.
Но вызывает ужаснейшее раздражение, что практически любое обсуждение в сети (да просто шутки ради - проглядите темы форума с этой точки зрения) будет начинать с того, что, во-первых, все будут долго понтоваться и пытаться унизить задающего вопрос. А во-вторых - начнутся фантазии на тему того, чего человек на самом деле не спрашивал. Причем довольно часто не опытному форумщику так и не удается сохранить свою тему, и обсуждение безнадежно уходит в ненужную сторону. Поэтому я и пытаюсь с самого начала таким вещам противодействовать.
Мне хочется таки получить ответ на мой вопрос.
Например, вы очень стараетесь меня убедить, что писать на ассемблере глупо. А с чего вы вообще-то взяли, что я собираюсь писать на ассемблере? С нуля? Покажите, где я это говорил? Нет. Не говорил я этого. Это в чистом виде ваши фантазии. Я просто знаю, что ассемблер - это лучший способ овладеть железякой. Кроме того, я также точно знаю, что будут встречаться задачи, которые потребую ассемблерных вставок. На столько точно, что я не стану вкладываться в изучение контроллера, с ассемблером которого я не разберусь.
И, кстати, одна из задач у меня есть прямо сейчас, и я ее собственно и реализовываю. Первым делом. Знаете какая? Я хочу понять возможности кристала. В том числе в плане реальной скорости обращения к портам. Для моих задач это необходимо. И тут без ассемблера - ну , совсем ни куда. Так что видете - вот вам реальный пример.
А так я с вами согласен. Реализация проекта на ассемблере с нуля - ну, наверное бывает оправдана, но лишь в очень экзотических случаях. Сейчас даже в голову ни чего не приходит. На Atmel это имело смысл, если хотелось полностью перехватить контроль над start-апом, там С все делает слишком не явно. Здесь такой необходимости нет.
Библиотеки, наверное, имеет смысл делать на ассемблере. Типа, один раз попотеть, что бы потом получить максимально быстрый код.
А так я еще не очень смотрел результаты работы компилятора. По опыту в то, что С код будет по быстродействию мало отличим от ассемблерного, я не верю ( ни в одной системе, с которой я имел дело раньше, такого не бывало ). Но - поживем увидим.

Ну раз теперь можно, то понеслась

Головушка ваша полна заблуждений:
Если только неестественным образом. А так всё прекрасно и без асм делается.

Лет 20 ARM-ми пользуюсь, ассемблерные вставки ни разу не делал. Чисто асмовые функции писал, но это считанные разы.

Пол царства на кону

Легко! Единственное что надо, смотреть листинги, чтобы контролировать, что получилось то что ожидалось. Пример.

Спойлер

Например, 20 ногодрыгов

Код:

template<auto f(), unsigned N>
void inline Repeat()
{
  if constexpr (N)
  {
    f();
    Repeat<f, N-1>();
  }
}

void Dryg()
{
  PA_1::set();
  PA_1::clear();
}

main()
{
   Repeat<Dryg,20>();
}

Листинг

Код:

    LDR.N    R1,??DataTable1  ;; 0x48000018
    MOVS     R0,#+2
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]
    STR      R0,[R1, #+0]
    STRH     R0,[R1, #+2]

Заблуждение. Можно делать библиотеки, которые подстраиваются под ситуацию и будут эффективней однократно накодированных.

Зря. Компиляторы под ARM шибко умные стали. Среднестатистическому программисту с ними тягаться тяжело.

>> А так всё прекрасно и без асм делается.

ну не. тут вопрос вкуса. Это как с вождением авто. для меня важно хорошо понимать,что под капотом. Даже если я ни когда не полезу туда с отверткой (молотком и зубилом...).

>> Пол царства на кону
у меня задачи такие. Много работаю с низкоуровневым железом на высоких скоростях. Хотя, не скрою, ваш листинг произвел впечатление.

>> Единственное что надо, смотреть листинги, чтобы контролировать, что получилось то что ожидалось. Пример.

Ух ты! Не. Красиво. Не поспоришь. Это в ARM так насобачились компилить С++? У Atmel с плюсами совсем погано было.
Так. Интересно. А где плюсы хранят TVM? В памяти программ или в RAM? У того же атмела хранила в RAM, что делало совершенно не возможным применение сложных алгоритмов (память кончалась). И я где-то читал, что это вообще беда компиляторов под гарвардскую архитектуру.
Не, ну это будет классно, если можно будет вообще обходиться без АСМ. Я не то, что б фанат...
Хотя, с другой стороны... А почему бы и нет? Например, С код может слететь при изменении настроек оптимизации. А ассемблер уже ни куда не денется.

И, Владислав, если уж зашел разговор. Пару комментариев по листингу.
LDR.N R1,??DataTable1 ;; 0x48000018

Что значит N после LDR. А ?? перед DataTable (DataTable, я так понимаю, это сишная какая-то внутренняя приблуда?)

MOVS R0,#+2

Зачем ставят # перед числовыми константами? Вроде ж, и без них хорошо?

От компилятора зависит. Их для ARM даже отличных три, а так ещё больше.

У ARM с RAM сильно свободней. Но всё равно, лучше виртуальными не злоупотреблять. Только там где реально надо.


Это как раз и есть неудобство асма - разный синтаксис у разных компиляторов.

И поэтому вы начали первым написав
Не подумали что этим вы унижаете отвечающих?
Так что не удивляйтесь что к вам такое отношение. Как вы к людям, так и они к вам!

ОК. Как собираетесь при этом учитывать латентность флеша, работу буфера пред. выборки, конвейер с предсказанием переходов и многие другие нюансы?
Это не простой PIC16 где гарантировано за 4 такта генератора выполняется одна инструкция (кроме переходов и вызова подпрограмм если не ошибаюсь).

Для дерганья портами хорошо подходят DMA+GPIO. Проц в это время может заниматься другими делами.

Нет. С переносимостью могут быть проблемы. И если выиграете пару тактов на 1000 инструкций, оно того стоит?

Что мешает проверить?

Возьмите STM32H750 за 4 доллара работающий на частоте 480 МГц с 2 МБ флеша и 1 МБ ОЗУ, или этого мало?

>> By specifying a 16-bit version explicitly with the LDR.N instruction, a 16-bit instruction
is always generated. This may lead to the constant being placed in the literal pool, even though a 32-bit instruction could have loaded the value directly using MOV or MVN.
By specifying a 32-bit version explicitly with the LDR.W instruction, a 32-bit instruction
is always generated.
If you do not specify either .N or .W, the 16-bit LDR (CODE16) instruction will be generated, unless Rd is R8-R15, which leads to the 32-bit variant being generated.

Ага... Понятно. Ну да, специфика набора команд контроллера дает некоторую необычность компиляторов. В принципе, вполне адекватную. Но не очень понятную по началу.

>> Кто будет писать про на фига тебе ассемблер, получит в глаз

Да у меня уже скоро это станет любимым спортом - попытаться так задать вопрос, что бы с самого начала обсуждение пошло в правильном русле... Перебрал, по-моему, уже все варианты. И серьезные, и шутливые. И на прямую просил... Все бестолку.

>> Как собираетесь при этом учитывать латентность флеша, работу буфера пред. выборки, конвейер с предсказанием переходов и многие другие нюансы?

Легко! Использую Cortex M0!

>> Для дерганья портами хорошо подходят DMA+GPIO.

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

>> И если выиграете пару тактов на 1000 инструкций, оно того стоит?

Не берусь спорить. Плохо знаком с эффективностью ARM компиляторов. Приведенный выше листинг и вправду впечатляет. Но как человек, имеющий опыт в разработке компиляторов, поверить, что ARM - овцы смогли достичь уровень "пара тактов на 1000 инструкций" пока не могу. Буду рад ошибиться.

>> Возьмите STM32H750 за 4 доллара работающий на частоте 480 МГц с 2 МБ флеша и 1 МБ ОЗУ, или этого мало?

Ну можно и так. А можно изучить ассемблер, и сэкономить по 3.5 бакса с девайса...

К ним тоже относится. У их флеша есть латентность, имеется конвейер и т. д. Даже выравнивание кода может сказаться на производительности.

Крупносерийное производство очень дешевых устройств что каждая копейка на счету?
Время потраченное на изучение асма (чтобы код был лучше чем у компилятора ЯВУ, нужно очень хорошо знать асм и все нюансы ядра) и разработку на нем не бесплатно. Хотя это решать вам.

>> К ним тоже относится. У их флеша есть латентность, имеется конвейер и т. д.

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

>> Даже выравнивание кода может сказаться на производительности.

А вот с этого момента пожалуйста поподробнее. Я об этом не знаю.

Добавлено after 6 hours 9 minutes 22 seconds:
Владислав. А что это за класс, тот, что PA1? И что за библиотека?

void Dryg()
{
PA_1::set();
PA_1::clear();
}

Вы явно не следите за моим "творчеством". На асме вы таких оптимизаций в библиотеке никогда не сделаете. На С, впрочем, тоже. А к этим оптимизациям компилятор добавит ещё свои и в результате получается бомба. С тех пор, правда, тот кусочек серьёзно переписан, но суть осталась та же, только форма современней стала.

Ууууу, эээээтоооо уже яяяяявный перебор, явный! Чрезмерно. Из крайности в крайность бросаетесь. Один хочет библы на голом асме писать, другой запилил на ++ тааааакууую кашу, в которой слишком мало масла. И если это только для несчастного GPIO, то что там дальше. Ой, нет, нет не показывайте "творчество"! Уж дай бог без таких обойдемся. Это похоже на индусский код. У тех тоже простые вещи расписаны через таааакие дебри, что... Сразу видно, что вы мало практикуетесь на практических задачах.
"Если человек ясно мыслит, он ясно и пишет" (С)кто-то из великих.

Про ногодрыг. Если нужен быстрый отклик, смотрите в сторону ПЛИС. А микроконтроллер в этом смысле тормознутый, он ничего не делает без команды "сверху", а в случае АРМ еще и через РОН (регистры r0, r1 и т.д.).
Инструкция str занимает два цикла.
GPIO + DMA? Еще больший тормоз. DMA сначала спросит "главного", а можна ли? И получив одобрямс, чето перешлет. Итого - до 5 циклов тормозов.

Можно конечно взять супербыстрый H7 на 400 МГц, но только у него вообще любая периферия работает не быстрее 200 МГц. Это только ядро разогнано до 400, остальное пыхтит не быстрее 200.
Да и вообще, зачем вам сотня мегагерц на ногах? Вы понимаете, что там начнутся проблемы с топологией платы и эл.магн.проблемы?

Топикстартеру же совет - выбрать золотую середину между асмом и индусской кашей "творчества". Лучшие программисты-практики пишут ясно и кратно, без размазывания сущностей.

Выравнивание кода не сказывается на производительности. Оно сказывается вообще на возможности выполнить инструкцию. Некоторые жопистые инструкции (в мануале про ни написано) желают видеть расположение четко по границам 4-х или 2-х байт, то есть адреса кратные 2 или 4. Выравнивание приводится за счет инструкций NOP. Они в этом случае не проходят по конвейеру, отбрасываются, но зато выравнивают положение инструкций по границе.

Как железячник по рождению ))), и потому любитель АСМа, рискну предложить автору темы альтернативу. Поскольку он впрягся в М0, скажу, что для быстрого ногодрыга это крайне неудачная платформа. И тут что АСМ, что Си - никакой разницы.
Зато есть очень адекватная АСМ-среда в dsPIC33. И скорость этой платформы нынче вышла на 100 МИПС, а те, что 70 МИПС, стали начальным уровнем. Впрочем, возможно автор темы уже давно это все знает. Ну тогда извиняйте великодушно...

Вот совсем недавно на форуме тоже исследовал М0 и даже доказывал за ногодрыг в 4 такта. Но товарищи подсказали и указали. Можно на коротких программах. На длинных теряется монотонность. Они оказались правы. Для меня этот вопрос закрыт.

Хорошие сапоги, надо брать! (с)
А может просто не хватило тяму понять что там написано? Я вот на китайский тоже смотрю и вижу кашу, однако это письменность великой культуры!
А я покажу. Только не внутренности, вам их всё равно не понять, а результат. Какова бы ни была библиотеки и сложна внутри, зато проста и эффективна в применении. Пишется то она один раз, а применяется постоянно.

Спойлер

Код:

ConfigList< PinMode::PushPull_LowSpeed<0>, GpioE<0xFF00>,        // PE8-PE15 = LEDS 
            PinMode::AF_PushPull_HighSpeed<14>, PA_11, PA_12,    // PA11=USBDM, PA12=USBDP
            PinMode::AF_PushPull_HighSpeed_PullUp<0x0>, PA_13,   // PA13=SWDIO
            PinMode::AF_PushPull_LowSpeed_PullDown<0x0>, PA_14,  // PA14=SWCLK
            PinMode::Input_Floating, CfgCmd::AllUnusedPins
          >::pwr_config();

Код:

        MOVW     R1,#+21845
        LDR.N    R2,??__low_level_init_0+0x2C  ;; 0x48001002
        STRH     R1,[R2, #+0]
        MOV      R3,#+10880
        LDR.N    R1,??__low_level_init_0+0x30  ;; 0x48000002
        STRH     R3,[R1, #+0]
        MOV      R12,#+36
        STRB     R12,[R1, #+13]
        MOV      R2,#+4032
        STRH     R2,[R1, #+8]
        MOV      R3,#+974848
        STR      R3,[R1, #+34]

Это всё! Продолжайте дрюкать биты в MODER-ах оператором "|="

А что кроме хамства таким как вы остаётся? Нормальный человек, если не нравится, просто пройдёт мимо.

Может честнее написать, что не знаешь С++, вот и не понимаешь?

Из чего видно то? Вы мои изделия видели? Я вам их код показывал? Что за влажные фантазии?

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

Добавлено after 8 minutes 19 seconds:
А причём тут ядро процессора и скорость работы периферии?

А при том, что про ногодрыг за 4 такта товарищ ответил на мое сообщение. Контекстом этой темы был ногодрыг на АСМе конкретно М0.

Наоборот! Я слишком хорошо знаю С++, чтобы понять ту степень каши, которую вы там "натворили". И помимо С++ я владею С#, ...<тут еще список языков>...
И что это за манера - отвечать на критику хамством и потоком ущемленного самосознания? Да не нужны мне ваши "влажные фантазии" - это всё вода, с высоты моего опыта. Вам бы столько, дайбох. И не надо мне показывать ваши потуги - я десять раз вас переплюну по практическим реализованным проектам, и без лишнего себялюбия.

Владислав, для опытного программиста одного взгляда достаточно, чтобы определить качество написанного кода и количество в нем воды.
Вы хотите в одном месте за один раз настроить ноги? Да не вопрос! GPIOA->MODER = 0x12345678 или (1<<(PIN5 * 2)) | (2<< (PNI7 * 2) ... если это делать именно за один раз, не модульно, а в одном месте, к чему вы и стремитесь.
И не благодарите. Не согласны - продолжайте дальше дрюкать тонны индусского текста. Индусский код - он ведь незря так назван. Индусы - они ведь получали деньги по числу написанных строк. Потому и создавали жутко раздутые конструкции вместо простого и прямого пути. У вас, Владислав, как раз прослеживается индусская ветвь. Прямой путь заменяете на непроворотливую кашу, причем даже не понимаете, насколько вы в этой каже увязли, и что есть другой путь, совершенно прямой.

Видите, в чем опыт, Владислав? Одного взгляда достаточно было, чтобы определить количество ненужной воды в ваших "творениях" и понять то направление, в котором вы желали двигаться. Ну и указать более короткий путь. Потому что вы заблудились, либо вам платят конфетами за кол-во строк.

Кароч, дальше спорить с самоделкиным не желаю, я слишком себя уважаю. Мой опыт - да вам бы, Владислав. Когда начнете делать что-то реальное практическое, тогда поймете. Как вижу, вы только на форуме и заседаете сутками. Удачки, и скорейшего перехода к практическим занятиям. А то вы похожи на молодого студента, недавно узнавшего новые уравнения в матричном виде, и через эти уравнения пытаетесь вычислять площадь квадрата.

Сейчас в руках есть прототип на STM32G071K8. Если скинете в личку функцию захвата с порта В в буфер Buff[] смогу проверить скорость. Там DMA нет,только ногодрыг.

Я замерял, если буфер достаточно большой, то три инструкции LDR+STR+ADD в среднем выполняются за 4.096 такта, не важно из флеша выполнять или RAM, есть WS или нет.
Заодно проверил F7, там из флеша 6+ тактов, из RAM - 5+, зато DMA + сон дают ровно 3. Софтово по-прежнему лидер F3, LDR+STR за 2 такта из CCM.

Владислав, да, не слежу. И, кажется, зря . Но я вообще не часто на котах, только когда припрет сильно.
А киньте пожалуйста ссылочку на ваше творчество? Я так понял, вы библиотеку смастерили под С++?

Добавлено after 4 minutes 26 seconds:
>> Выравнивание кода не сказывается на производительности. Оно сказывается вообще на возможности выполнить инструкцию. Некоторые жопистые инструкции (в мануале про ни написано) желают видеть расположение четко по границам 4-х или 2-х байт, то есть адреса кратные 2 или 4. Выравнивание приводится за счет инструкций NOP. Они в этом случае не проходят по конвейеру, отбрасываются, но зато выравнивают положение инструкций по границе.

А это еще что за кошмарики? Я опять что-то продолбал в мануалах, или оно не относится к Cortex M0 ( я пока дальше не лезу во избежании каши в голове... Они и так пухнет )

Добавлено after 5 minutes 11 seconds:
>> И тут что АСМ, что Си - никакой разницы.

я догадываюсь. Но пока хочу разобраться с M0, и потом лезть дальше.
Сильно разбегаться по платформам не хочется. Все таки всегда сильно трудоемко начинать. А на STM32 я, уже чувствую, застряну на долго ( в целом платформа мне нравится). Ну и да - где ее не хватит, есть ПЛИСы.
Но вот выжать из нее все, что выжимается, кажется того стоит.

Добавлено after 51 second:
>> Зато есть очень адекватная АСМ-среда в dsPIC33.

но вообще спасибо. Посмотрю.

Добавлено after 1 minute 15 seconds:
>> Вот совсем недавно на форуме тоже исследовал М0 и даже доказывал за ногодрыг в 4 такта. Но товарищи подсказали и указали. Можно на коротких программах. На длинных теряется монотонность. Они оказались правы. Для меня этот вопрос закрыт.

А киньте ссылочку пожалуйста, если не в труд

Добавлено after 7 minutes 26 seconds:
>> Сейчас в руках есть прототип на STM32G071K8. Если скинете в личку функцию захвата с порта В в буфер Buff[] смогу проверить скорость. Там DMA нет,только ногодрыг.

Сергей, если не в труд. Чуть вышу кину несколько вариантов кода. Прогоните?
Меня волнует не только скорость захвата, но и равномерность * что бы не было пропусков). Поэтому я тестировать собираюсь, прикрутив к порту счетчик, тактируемый от MCO.

Добавлено after 2 minutes 32 seconds:
>> то три инструкции LDR+STR+ADD в среднем выполняются за 4.096 такта

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

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


Просишь ссылочку на свою же тему?

>> Просишь ссылочку на свою же тему?

О! А я че-то давно от туда не получал сигнальчиков. Думал, обсуждение заглохло.