Кто любит RISC в жизни, заходим, не стесняемся.
Ответить

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Сб ноя 23, 2019 20:27:56

Я так понял, человек не про это спрашивает. Интересует что-то, где хорошо описывалось бы программирование для STM со всеми его библиотеками и периферией.

Тогда ему нужно качать сниппеты с сайта ST.
Пользоваться калокубами, SPLами и прочей дерьмотой (даже opencm3) ни в коем случае нельзя! Это как гланды через задницу выдирать...
Читаем даташит, читаем RM, смотрим сниппеты и собираем свои сниппеты и даже готовые блоки.
Я себе подобным образом постепенно базу набиваю. Тоже по дурости неопытной сначала SPL пробовал, потом какое-то время сидел на opencm3, и лишь по прошествию определенного времени (тут толчок нужен был и им было то, что разрабы opencm3 поломали API, и мое терпение лопнуло) постиг дзен!

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Сб ноя 23, 2019 21:33:00

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

то транслятор ругается. Транслирует, но в итоге задержка не работает. А в асме это не разу не проблема.


Хорошие вопросы задаете, товарищ! Не, кроме шуток. Главный минус С - необходимость одно и то же по сто раз объявлять.
Но вам придется с этим смириться. Такова идеология С. Все, что вы используете, вы должны заранее объявить. Мое мнение, что оно прилетела со стародавніх времен, когда работает компилятор и хоть что-то хоть как-то компилит хотя бы за ночь ( не смейтесь. Я еще застал времена, когда С программу на компиляцию на ночь ставили) - уже праздник. Соответственно, в С вообще много фишек для облегчения жизни компилятору. Это - одна из них. Мне кажется, оно совершенно не современно. Но спорить - не возьмусь. Идеология - она вещь такая. Можно и в нос получить, ну ее нафиг :)

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

void delay(uint16_t time)
{}

Заработает?

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Сб ноя 23, 2019 22:55:53

Заработает?


Вот чего кокос выдал:
Код:
       [cc] D:\Disk_D\PRG\coconut\main.c:18:5: warning: implicit declaration of function 'Delay' [-Wimplicit-function-declaration]
       [cc]      Delay(8000000);
       [cc]      ^~~~~
       [cc] D:\Disk_D\PRG\coconut\main.c: At top level:
       [cc] D:\Disk_D\PRG\coconut\main.c:22:6: warning: conflicting types for 'Delay'


А вот моя писанина (вложение):
МК - плата с STM32F103RBT6 и программатор St-link V2, купил это добро на али в 2013 году.
Вложения
main.c
(617 байт) Скачиваний: 287
Последний раз редактировалось Shuspano Сб ноя 23, 2019 22:58:06, всего редактировалось 1 раз.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Сб ноя 23, 2019 22:56:57

Да, от знания асма толку никакого вообще.
....заявил человек его не знающий :)))

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Сб ноя 23, 2019 23:48:55

jcxz писал(а):Неправильно скомпилили.
Так приведите весь код, который нужно компилировать...
Что из себя представляет Pval, PIN_PRND_B и PIN_PRND_F?

jcxz писал(а):Или у Вас включена оптимизация по размеру, а не по скорости, или выбрано неправильное ядро (не CM3, CM4F).
Оптимизация O2, ядро M3.

jcxz писал(а):Компилятор у Вас зачем то перегружал повторно указатель, потратив на это лишние команды LDR.
Потому что данные в __IO регистре, т. е. valatile. Было бы лучше если привели текстовый код. Это исключило бы неточности.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Вс ноя 24, 2019 11:10:26

Фух... вроде мигает. Да, от знания асма толку никакого вообще. Ну да ладно.
мне вот интересен еще момент. Почему если подпрограмму пишу где нить внизу листинга, а вызываю ее где нибудь вверху, например:
Код:
while (1)
{
...
delay(8000000);
...
}

void delay(uint16_t time)
{}

то транслятор ругается. Транслирует, но в итоге задержка не работает. А в асме это не разу не проблема.


И никто до сих пор не заметил что-ли? Что 8000000 никак не влезет в uint16_t, где максимальное значение 65535. Делайте uint32_t.

И это ругается, потому что до вызова функцию нужно объявить. Сверху где-нибудь просто "void delay(uint32_t time);" всё, без кода функции. И ругаться не будет.

Но правильно сказали - писать на C учиться можно и на ПК. На МК оно не завязано. Ничем C для ПК не отличается от C для МК. Объявление регистров - это всего-лишь объявления регистрой. Ничего от EQU в асме не отличается.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Вс ноя 24, 2019 11:55:45

В смысле "тот же"? Кто с кем?
Немного поэкспериментировал с твоим примером. Процессор STM32F303 (CM4F), выполнение кода из SRAM. Скорее всего, из FLASH будут другие цифры по тактам.
Сделал тестовый код (надеюсь я правильно понял твои макросы). Тщательно проверил, чтобы считывание CYCCNT было строго одинаково везде.
Код:
  __disable_irq();
  uint32_t t1 = DWT->CYCCNT; 
  __NOP();
  GPIOC->ODR = 3 - ((GPIOA->IDR>>10)&1) - ((GPIOB->IDR>>0)&1)*2;
  uint32_t t2 = DWT->CYCCNT;
  DEBUG_Print("TICS = %d\r\n",t2-t1);   
  __enable_irq();

Результаты под IAR и GCC

Затем немного плюсовщины добавил, чтобы компилятор сделал таки то что ты от него хотел.
Код:
  __disable_irq();
  GPIO::PB_0 pb0;
  uint32_t t1 = DWT->CYCCNT; 
  __NOP();
  GPIOC->ODR = 3 - ((GPIOA->IDR>>10)&1) - pb0*2;
  uint32_t t2 = DWT->CYCCNT;
  DEBUG_Print("TICS = %d\r\n",t2-t1);   
  __enable_irq();
И получил как раз
Код:
        UBFX     R3,R3,#+10,#+1
        RSB      R3,R3,#+3
        AND      R4,R4,#0x1
        SUB      R3,R3,R4, LSL #+1
Только разницы по тактам, как я и предполагал, никакой. Результаты под IAR и GCC

Но мы же любопытные. Полностью на плюсах получаем третий вариант на те же 17 тактов.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Вс ноя 24, 2019 22:20:27

Народ, а коль уж тут речь зашла. НА AVR GCC плюсы для серьезных задач использовать практически не возможно, так как TVM они держат не во FLASH, что было бы логично, а в ОЗУ. Ни разу не эффективно, а главное, ОЗУ кончается очень быстро.
А для STM как это решено?
Кстати, вот и еще один пример, зачем может быть нужен ассемблер: в сложных случаях понять, а что же такое намудрил компилятор.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Вс ноя 24, 2019 23:49:02

Немного поэкспериментировал с твоим примером. Процессор STM32F303 (CM4F), выполнение кода из SRAM. Скорее всего, из FLASH будут другие цифры по тактам.
Сделал тестовый код (надеюсь я правильно понял твои макросы).
Да, именно в такое мои макросы и должны были развернуться. Единственный момент - IAR ругается warning-ом на выражения, в которых встречаются сразу несколько чтений volatile переменных. Поэтому эта строка у меня разбита на 2: сперва "3 - ((GPIOA->IDR>>10)&1)", а потом - остальное.
Ну собственно IAR-овский результат такой же как у меня - 5 команд.

И получил как раз
Да, собственно этого я и ожидал от IAR-а. Как минимально-оптимальный результат. :) 4 шт. 4-байтовых арифметических команды.

Только разницы по тактам, как я и предполагал, никакой. Результаты под IAR и GCC
IAR-овский результат - 5 команд. Должен быть на 1 такт длиннее. Ну а то что "нет разницы" - так там в результаты попали множество LDR, которые в сумме длиннее. И IAR их поставил меньше. Таким способом с точностью до такта не измерить. Вобщем - GCC здесь оказался лучше. Но даже он не додумался до самого оптимального варианта, который я приводил 3-м по счёту. 8)
Вобщем - компиляторы ещё пока что тупее человека. :)

Добавлено after 5 minutes 43 seconds:
Так приведите весь код, который нужно компилировать...
Что из себя представляет Pval, PIN_PRND_B и PIN_PRND_F?
Посмотрите соседний пост VladislavS - он правильно угадал содержимое макросов. У него как раз и получилось от GCC то, что я ожидал. Правда не самый лучший вариант.

jcxz писал(а):Компилятор у Вас зачем то перегружал повторно указатель, потратив на это лишние команды LDR.
Потому что данные в __IO регистре, т. е. valatile.
Данные, но не указатель на них (адрес этого регистра). А у Вас GCC дважды зачем-то перегрузил этот адрес. Посмотрите на результат IAR (что я приводил) - там указатель на IO-регистры грузится один раз, и потом по нему дважды читаются оба порта (со смещением, так как они находятся по близким адресам).

Добавлено after 4 minutes 50 seconds:
Кстати, вот и еще один пример, зачем может быть нужен ассемблер: в сложных случаях понять, а что же такое намудрил компилятор.
Совершенно правы! Или "намудрил автор исходника". Я бывает когда ищу баг, гляну на результат компиляции и по нему сразу вижу баг (особенно - если что-то не так с приведением типов, расширением типов, знаками и т.п.).

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пн ноя 25, 2019 08:30:08

jcxz, смысл моего поста был в том, что я на IAR получил три разных кода, выполняющихся потактово одинаково. Все LDR и STR в нём одинаковы.

GCC там вне зачёта шёл.

Добавлено after 7 minutes 54 seconds:
НА AVR GCC плюсы для серьезных задач использовать практически не возможно, так как TVM они держат не во FLASH, что было бы логично, а в ОЗУ.
С++ настолько многогранен. Можно же не применять виртуальные методы и эллоцируюшие динамическую память объекты. И без них в языке столько "серьёзности"!

Добавлено after 2 hours 23 minutes 58 seconds:
Кстати, между нами эмбеддерами.
Вот такой код делает то же самое, но выполняется на 2 такта быстрее.
Код:
  __disable_irq();
  uint32_t t1 = DWT->CYCCNT; 
  __NOP();
  GPIOC->ODR = ~(((GPIOA->IDR>>10)&1) | ((GPIOB->IDR>>0)&1)*2) & 3;
  uint32_t t2 = DWT->CYCCNT;
  DEBUG_Print("TICS = %d\r\n",t2-t1);   
  __enable_irq();
Код:
//GPIOC->ODR = ~(((GPIOA->IDR>>10)&1) | ((GPIOB->IDR>>0)&1)*2) & 3;
        LDR.N    R1,??DataTable1_1  ;; 0x48000010
        LDR      R3,[R1, #+0]
        LDR      R4,[R1, #+1024]
        UBFX     R3,R3,#+10,#+1
        ORR      R3,R3,R4, LSL #+1
        MVNS     R3,R3
        AND      R3,R3,#0x3
        STR      R3,[R1, #+2052]

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пн ноя 25, 2019 16:59:46

>> С++ настолько многогранен. Можно же не применять виртуальные методы и эллоцируюшие динамическую память объекты. И без них в языке столько "серьёзности"!

Можно. Но уже совсем не так интересно. Многое недоступно. Включая стандартную библиотеку классов. Это уже не С++, а в лучшем случае С+ какой-то :)

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Вт ноя 26, 2019 08:11:32

Ну да. Кроме каких-то совсем уж экзотических ситуаций. В принципе, на вскидку даже и в голову для примера ни чего не приходит.

В одном из проектов стала у меня гавкать собака по имени IWDG. Редко, непредсказуемо и проморгал на каком этапе редактирования проекта возникла такая беда, т.е. и не знал куда копать. Завел тогда собаку WWDG и обработчик прерывания от нее. В обработчиках прерывания WWDG и исключения HardFault вставил ассемблерную вставку, которая выдергивала контент со стека, а именно указатель стека и, самое главное, программный счетчик . Затем эти данные и еще кое-какие тестовые, я записывал во флеш. С помощью этого нашел где нарукожопил.

Как вставлять ассемблерную вставку в Си (компилятор GCC) читал тут.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Чт ноя 28, 2019 04:44:27

Кстати, возвращаясь к теме. Никто не сказал главного - того, что для нормальных ассемблеров (про Гнусный я ничего не знаю) нет заголовочных файлов от производителя. Все упражнения на тему ассемблера STM32, ходящие в Сети, либо оперируют "магическими числами", либо используют самодельные наборы описания периферии, в лучшем случае - полученные самодельными конвертерами из сишных файлов .h, а то и просто переделанными из этих .h вручную.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Чт ноя 28, 2019 10:02:26

Никто не сказал главного - того, что для нормальных ассемблеров (про Гнусный я ничего не знаю) нет заголовочных файлов от производителя


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

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Чт ноя 28, 2019 11:45:47

Ну да, всего лишь закат Солнца вручную...

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Чт ноя 28, 2019 17:34:57

Никто не сказал главного - того, что для нормальных ассемблеров (про Гнусный я ничего не знаю) нет заголовочных файлов от производителя.
И что? Я описания периферии всегда сам пишу, по мануалу на МК. Даже если работа с периферией идёт только из си. и никакие "заголовочные файлы от производителя" не пользую.

Добавлено after 2 minutes 11 seconds:
Ну да, всего лишь закат Солнца вручную...
Ну так всегда так: кто-то пишет программу сам (кто это умеет), а кто-то не умеет и за него это делает куб. Не всем дано быть Рафаэлями! :)))

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Чт ноя 28, 2019 20:09:42

jcxz, то есть ляпую отсебятину насрав на стандарт.
Это не "закатсолнцавручную" это полная ж. и полное пренебрежение окружающих.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Чт ноя 28, 2019 20:47:27

с заголовочными файлами для asm проблем нет.
у MDK учебник входит в комплект.
документация есть тут http://infocenter.arm.com/help/index.js ... JIHGJ.html
и есть скромный сайт http://stm32asm.ru/index.html

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Чт ноя 28, 2019 23:05:04

jcxz, то есть ляпую отсебятину насрав на стандарт.
Какой такой "стандарт"?
Это не "закатсолнцавручную" это полная ж. и полное пренебрежение окружающих.
Какие такие "окружающие"? И какое отношение они имеют к тому что я разрабатываю?

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пт ноя 29, 2019 07:18:58

Я описания периферии всегда сам пишу, по мануалу на МК.
А зачем? Ведь это имеет смысл, если ты это делаешь лучше производителя. Чем твоё описание лучше? Стоит оно того, учитывая что это ещё и источник ошибок?

У меня есть хотелки по улучшению файлов описания периферии, но оценивая весь этот зоопарк, понимаю что неподъёмно.
Ответить