Ну да, вполне. Конечно, команды и данные должны быть расписаны. Я бы и однобитные маски сделал через (1<<12) типа, что бы не вычислять разряд. Всё должно быть максимально наглядно. ИМХО. Но, конечно, и от ситуации зависит. На то он и скетч == черновик.)
я не понимаю, чего вы хотите от форума то?
выясняли, стандарта нет, каждый для себя решает как этим пользоваться.
вы хотите признания , что правильно писать все в хексе?
так его не будет.
Стандарта нет, но есть рекомендации. По читаемости кода, по переносимости, по минимизации возможных ошибок. Да и самому часто не хочется делать лишнюю/дурную работу.
Я так понимаю, @andriano и для себя хочет выбрать наиболее удобный вариант.) Хотя, кто ж тут может знать мотивы…) Дискутировать ведь никто не запрещает.)
Насчет наглядности - полностью согласен. А вот насчет сдвигов - нет. Притом “нет” в данном случае означает не отсутствие согласия, а категорическое несогласие. Во-первых, сдвиг - это не универсально. Если нам надо загрузить число, ни о каких сдвигах речь вообще не идет - загружаем в регистр, как есть. То есть явное нарушение единообразной процедуры. Во-вторых - если речь идет о многобитовом поле, то загружать его побитно - вообще абсурд. Представьте, Вы передаете это поле в качестве параметра. Вместо того, чтобы сдвинуть и загрузить, его нужно сначала разобрать на биты, потом собрать обратно и только после этого загружать. В-третьих, единственное не противоречащее здравому смыслу использование сдвигов - в случае однобитных флагов. О том, что это нарушает методологическое единство, я ужа писал. Но даже если рассматривать только случай однобитных флагом, Майкрософт, например, пошла по другому пути. И лично мне путь Майкрософт в данном случае представляется более логичным. И наглядным - тоже. Представьте, что Вам нужно совместить штук 6 флагов, да еще и с нормальными “говорящими” именами - в одну строку это не поместится. А если добавить к ним еще и 1<<, получится вообще каша.
Читаемость кода. Timer1_Overflow_Interrupt_Enable - читаемо. А TOIE1 - не читаемо. Чтобы “прочесть” это - нужен дэйташит. А уж коль скоро мы залезли в дэйташит - там без разницы символическое имя или цифровая константа - они все равно на одной странице.
Переносимость. Она отсутствует. Напрочь. Притом, непереносимы не только символьные константы, но даже принцип их формирования: в AVR - один, в STM32 - другой. А в ESP мы вообще имеем дело не с регистрами, а в командами РТОС. О какой переносимости может идти речь?
Минимизация ошибок? Вряд ли. Можно, конечно, переврать HEX константу, но гораздо проще переврать буковки в короткой аббревиатуре. Потому что самих аббревиатур - сотни, если не тысячи, что вполне сопоставимо с количеством всевозможных сочетаний по 2-3 буквы.
Вот о том и речь: что бы мы ни применяли, хоть символьные имена, хоть HEX-константы, все равно лезть в дэйташит.
Опять же, это работает только в одну сторону. То есть читать - без разницы как, а вот с написанием - серьезные проблемы ввиду отсутствия стандартного алгоритма перевода обозначений из дэйташита в символьные имена.
То есть символьные константы vs HEX-константы при чтении - безразлично, а при написании кода - намного хуже.
Цитирую по ссылке:
Искать в 500 кб неструктурированного текста - то еще удовольствие.
Чуть выше было приведено мнение (притом, по меньше мере дважды), что правила преобразования символов из дэйташита в символьные константы не существует.
Если Вы не согласны с этим утверждением, приведите эти правила.
Не возникает только потому, что такой потребности не возникало. А навскидку слово TIMSK0 я бы не угадал. Ну а TIMER1_BASE-> я просто помню. Не так много в МК периферийных устройств, чтобы их нельзя было все запомнить. А вот запомнить все названия всех полей - моей запоминалки не хватает. Поэтому и спрашиваю: как быть в моем случае?
Я тоже не умею!
Меня тоже научите!
Вы серьезно?
500 к неструктурированного текста и “без утомительного поиска”? Это больше 300 страниц даже в случае сплошного текста. А с укороченными строками заголовочного файла - пачки бумаги в 500 листов не хватит.