Изучаем STM32 Cortex M3

[makser1]

SasaVitebsk, именно так тоже думаю.

[niXto]

Я на AVR сейчас стараюсь не работать с битами. То есть на булевую переменную выделяю байт.

Зря. Установка-сброс бита в регистре - 1 слово программы, загрузка константы в регистр - 2. Сохранение-загрузка регистра с битами - одна команда, а не до 8, как в случае с константами. Ну и удобно групповое изменение одной командой одновременно нескольких бит (установка-сброс через логическое И, ИЛИ, инверсия через Исключающее ИЛИ), в случае с константами это минимум до 8 команд, а если нужна инверсия - то ещё прибавляется команда сравнения и переход. В итоге одни неудобства.

Уточните, какие преимущества есть у констант в регистрах на АВР по сравнению с битовыми флагами

[SasaVitebsk]

Уточните, какие преимущества есть у констант в регистрах на АВР по сравнению с битовыми флагами

А Вы задумывались, зачем начиная с некоторых кристаллов(например m88 ) Atmel ввёл регистры IO GPIOR?
Всё как бы просто. Биты чаще всего применяют как флаги. В одном байте флагов 8 получается. Чаще всего флаги что-то символизируют. Ну типа закончилась обработка АЦП, принят пакет по USART, таймаут по CAN, ну и так далее. То есть эти флаги глобальные. Представим, что сработал флаг завершения обработки АЦП. Я обработал результаты, что-то там сделал и сбрасываю флаг. Загружаю флаг в регистр, сбрасываю флаг в регистре - в этом месте произошло прерывание от USART и взвёлся флаг приёма пакета, находящийся в том же байте - п/п обработки прерывания закончилась и мы вернулись назад - я записываю регистр назад в байт флага. При этом флаг USART затирается.
Давайте посмотрим с другой стороны. Опять таки рассмотрим ту же AVR. Если я размещаю 1 флаг на байт, то работа с ним будет не медленнее. Таким образом Ваш выигрыш только память. 7 байт на каждые 8 флагов. Но реально их немного в программе. А всё ушло катастрофически. Одно дело я писал на x51 и у меня было 128/256 байт памяти, а совсем другое дело даже таже atmega8, что практически младший камень сейчас. Там 1к памяти. Пересмотрите проекты и Вы увидите, что памяти, как правило сейчас более чем достаточно. Причём, как правило в разы.
Бывают исключения, когда например я писал бутлоадер для той же atmega8 с 128 битным ключём и протоколом WAKE UP. Надо было в 1к флэши вогнать. Ну тогда и бог велел. Тогда я саму дешифрацию написал на ASM, разместил флаги прямо в регистре. Расчёт CRC сделал соответствующим образом тоже через регистр. И всё это указал компилятору. У меня было для m8 1 байт лишний, а для m88 - 3..
А вот давайте рассмотрим более-менее приличный проект на lpc. Ну скажем на lpc1764 или даже на той же lpc2106. Там 1 порт 32 линии. Теперь представим, что у вас в проекте RTOC любая. Прога разбита на задачи. Одна задача выводом на дисплей занимается. Вторая обработкой АЦП занимается. И всё это (и ещё куча другого) висит на одном порту. И Вам самое удобное выводить линии порта так, чтобы не задеть "чужие". И если внимательно посмотреть на порты ARM, то увидишь, что именно так они и построены.
Не всё на виду находится. Порой что-то надо переосмысливать.
===
Вот например уже упомянутые мной регисты GPIOR. Очень удобны для флагов. Но запоздали они. Как правило, когда я делаю проект под atmega8, я в первое изделие закладываю atmega88. Проект пишу так, чтобы работало на любом камне. Отлаживаю под JTAG ICE и отдаю в производство. А на серийное изделие устанавливают уже atmega8. А в меге8 регистров GPIOR нет. Поэтому я не применяю.

Короче я стараюсь не применять уникальные решения, которые труднопереносимы с камня на камень. Ты это забудешь, уже ч/з 2 месяца, а переносить придётся года через 3, и ты ругаешься потом на себя громко и в голос. Выстрадано всё.
PS: Я никого ни к чему не призываю. Я к этому пришёл. А Вы возможно своё решение найдёте. Хотя я вижу, что народ поголовно отказывается от битовых флагов. Это видно по примерам.

[tempora]

Биты чаще всего применяют как флаги. ... Ну типа закончилась обработка АЦП, принят пакет по USART, ... Представим, что сработал флаг завершения обработки АЦП. ... Загружаю ..., сбрасываю флаг ... - в этом месте произошло прерывание от USART...

Всё замечательно, но не выглядит как безусловно лучшее решение. Если Вы разрешаете вложенные прерывания, то почему не обеспечиваете атомарность операций с разделяемыми ресурсами? А если уж так не хочется это делать, что почему не храните флаги в регистрах? Инструкции установки/сброса бит в регистрах и быстрее (что в ISR особенно хорошо - 1 такт всего), и дешевле, чем RMW с переменной в ОЗУ, и атомарны, поэтому описанная Вами метода, выгодная в одних ситуациях, проигрывает в других - ?

Вот например уже упомянутые мной регисты GPIOR. Очень удобны для флагов.

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

Я никого ни к чему не призываю.

Вы за последнее время уже, минимум, второй раз об этом пишете и, ЕМНИП, в предыдущем посте выражались несколько категоричнее, чем сейчас. При ближайшем рассмотрении, всё выглядит так, что единственный аргумент "ЗА" - это переносимость, при том, что есть и аргументы "ПРОТИВ", впрочем, я уже писал, что тут возможны варианты ("метода, выгодная в одних ситуациях...").

[niXto]

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

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

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

Я в своих проектах под флаги выделяю регистры старше R17 (R16 и R17 использует компилятор) или GPIOR0 если есть. Полностью атомарный доступ, без RWW. И да, вложенные прерывания на АВР - дурной вкус, и вообще, обработчики прерываний нужно делать как можно короче

А описанная вами проблема как раз встает в полный рост при использовании вместо битовых флагов констант в регистрах. Т.к. ни в АРМах, ни в АВР нет команд "запись константы в ячейку ОЗУ" - только через многоходовые операции загрузки константы в регистр и копирование регистра в ОЗУ. И что будет записано в регистр, если между этими операциями произойдет прерывание? Есть конечно битбандинг в стм32 и аналогичные механизмы в лпц, но это не выход

[SasaVitebsk]

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

2 niXto. Я не считаю вложенные прерывания, где бы то ни было, дурным тоном. Я постоянно этим пользуюсь. Начиналось наверное с х51. Там аппаратно было возможно. Поэтому был удручён, когда в AVR этого не обнаружил. Ну чтож, пришлось софтовым способом. Делал в проектах на ASM и на Си. Не вижу в чём тут "дурной тон". В ARM7TDMI есть аппаратный механизм FIQ/IRQ. Этого хватает. В Cortex всё аппаратно. По-моему в xMega тоже аппартно ввели. Я с ними так и не поработал. В один проект заложил, но он так и не пошёл. А сейчас как-то ориентируюсь на stm32. Они умудрились все ниши закрыть. В 2 проектах применил stm8 - жалею.

[stmfaq]

Отвлеку вас немного , решил проверить сколько мой код займет на STM8, раз уж он на STM32 так сильно раздулся. В качестве компилятора взял IAR, но возникла непонятка, IAR компилирует только тот файл на закладке которого я нахожусь, весь проект полностью скомпилировать не получается, что я не так сделал? получается что если в main.c идет обращение к функции которая находится в des.c а я эту функцию из файла des.c удалил, то компиляция main.c проходит нормально. Я что то не пойму как с этим IAR работать.

[Vov123]

Может прописать его надо в свойствах проекта?

[SasaVitebsk]

Выберите Rebuild All. Если хотите, киньте мне свой проект я попробую скомпилить для stm32

[tempora]

решил проверить сколько мой код займет на STM8, раз уж он на STM32 так сильно раздулся.

... IAR компилирует только тот файл на закладке которого я нахожусь, весь проект полностью скомпилировать не получается, что я не так сделал?

Это разные команды, [F7] - собрать проект, [Ctrl-F7] - компилировать текущий файл.

.. если в main.c идет обращение к функции которая находится в des.c а я эту функцию из файла des.c удалил, то компиляция main.c проходит нормально.

По-моему, что-то пропущено в описании ситуации...