То есть, вы продолжаете утверждать, что int может быть беззнаковым?! Жесть.



А где определение GPIOA? Ещё 100500 строк!
Мы же говорим про использование. То есть, библиотеки считаются уже написанными и оттестированными. Это, кстати, тоже большой их плюс.

char - может быть

В некоторых компиляторах, особенно под мелкие 8-битные мк может быть все что угодно.
Я уже наступал на грабли, где по-умолчанию char - знаковый.
Дабы избежать этого, везде писал явно unsigned/signed.
Потом перешел на свои типы (привел выше).
Мне так стало гораздо удобнее, меньше головной боли и ненужных переживаний.

ну вот у меня новая задача. stm32l052. от чего я эту тему и открыл. Нужно быстро код написать....
цепляю #include "stm32l052xx.h"
написал макрос, т.е. написал определение

#define csOn() (GPIOA->BSRR = (1<<4))
использую
csOn();
если нет stm32l052xx.h - можно заглянуть в даташит (а в него всё равно глядеть) и написать
#define csOn() (*(uint32_t*)0x1234'5678 = (1<<4))
не камельфо, но всёже... один раз определил и забыл.


Но, есть замечательный тру с++ с ооп. чо как лох буду макросы. Нада же легкочитаемый код....
можно через Pin<>. Где его взять? вместе с stm32l052xx.h он не поставляется. писать свой? отлаживать? скаченный с гитхаба для Ф4 серии. а если вообще решили на msp430? Я говорю - это 100500 строк кода. Причем, в этом pin используется всё тотже stm32l052xx.h.

Вы не сворачивайте на char. Вы про int скажите.

Я никогда не обращаюсь к одним и тем же пинам из разных потоков, в моем коде это невозможно, т.к. каждый пин - не глобальный ни разу, а является приватным полем какого-нить класса.
У меня совсем иной принцип построения кода - ни одной глобальной переменной/объекта, даже Pin чей-то.
Более того, работа с пинами скрыта внутри реализации какого-то из модулей и модуль сам решает, что и как у него взять/дать.
Это дает возможность прямо в модуле реализовывать механизмы блокировки (мьютексы), чтобы избежать конкуррентного доступа к каким-то объектам.
Поймите, я приучил себя думать иначе, поэтому повторюсь еще раз для потомственных "танкистов": каждая сущность кому-то принадлежит, не НИ ОДНОГО ГЛОБАЛЬНОГО ОБЪЕКТА.


У меня эта "мина" никогда не сработает, проекты изначально построены иначе. Поэтому подобные "затычки" просто не нужны.
Это позволяет строить код более свободно, не ломая голову над такими граблями.


Стандарт тут ни при чем, я говорю про особенности некоторых компиляторов под некоторые МК. Я сталкивался с таким.
В частности под PIC-контроллеры: то ли PICC-компилятор, то ли MCC, уже не упомню где именно.
Поэтому проверять так это или нет в новом компиляторе не хочу, мне проще прикрутить несколько строк, которые ЯВНО тайпдефят эти типы на привычные МНЕ.


Не скажу, давно это было, не помню, где именно. Но почему-то запомнилось что int там был 16-битный.

Ну, выбор, конечно, за вами. Вы каждый раз готовы писать
GPIOA->MODER = (GPIOA->MODER & ~(3UL << pin * 2)) | (2 << pin * 2);
и лазать в даташит на каждом проекте. (Или, может быть, вы способны выучить все режимы ножек и перечень альтернативных функций для каждой ножки - тогда не нужно лазать). Я лично потратил некоторое время на написание модуля, который сам знает про все эти подробности, и теперь пишу CS::Mode(INPUT_PULLUP) и не парюсь.
Я думаю, что в долгосрочной перспективе мой подход лучше. Но выбор, естественно, за вами.

ЗЫ. Для L0/F0 серии тоже есть pin.h

По стандарту char/int/long - без указания знаковости считаются знаковые. Во всех компиляторах. Нет других компиляторов. По крайней мере я не встерчал. если встретите - маякните, поизучаю.

что касательно этих граблей.... можно дать ключ компилятору, считать char без явного указания unsigned/signed как беззнаковый. у int/short/long это не поменять, только у char.
я char использую всегда как занковый, как стандартный дефолтный. ибо если собрать на другой платформе без ключа - то упс!!! Но, в идэ, например в IAR в гуях есть галочка "char как беззнаковый". При создании нового проекта, эта галочка установлена, т.е. иар в тихушку просовывает этот ключ компиялтору меняя у чара знак. Я тоже на это наступал.... решил проблему отказом от char взамен на uint8_t в качестве байтовой переменной. или же всегда указываю у чара явно знаковость. а если мне нужно хранить текст, например char *p = "hello world"; - тут без разницы - есть знак или нет, тут можно упустить знак.

Для чара это тру!!!
из-за таких тихих подстав от IDE у некоторых складывается впечатление, что char по дефолту беззнаковый.


Спасибо большое!!!! А есть для f1 и вообще... огласите полный список? )))) может и для авр кто написал такие классы? ))

Беззнаковый?

пишете мне Читайте внимательней, а сами невнимательны . Я писал
давайте перефразирую


вы в одном потоке дергаете cs? который есть PA13, а в другом потомке маргаете диодом который сидит на PA5.

В моей явной реализации типов вообще не нужно разбираться с особенностями конкретного компилятора, галочками и т.п.
Один раз составил эти тайпдефы под новый компилятор, проверил соответствие разрядности (при сомнениях) и ЗАБЫЛ.
При написании очередного кода категорически не хочу держать в голове, что там у компилятора по-умолчанию, а что нет. У меня других забот хватает )))


Ага, я понял к чему вы - я имел ввиду не порт, а пин.
Но и в данном случае проблем тоже не будет - в MODER пишется маска, меняющая всего лишь ОДИН соотв. бит, а не группу битов.
Даже если переключение задач произойдет прямо посреди переписывания MODER или формирования этой маски, ничего страшного не будет - доступ к MODER атомарный, он не переписывается кусками.

я вам не говорю, что явно не надо задавать. я вам говорю, что int - всегда знаковый. и объяснил вам от куда у вас были грабли с чаром. и что компиляторы одинакого компилят.

У меня нет граблей с char-ом и другими типами уже давно, очень давно )))

Вот собственно главный pin.h, который подключает уже нужный pin_xxx.h, в зависимости от контроллера. Список поддерживаемых контроллеров - там же. Это для STM32.
Для AVR есть вот такой набор макросов. Это знаменитые в узких кругах "Макросы Аскольда Волкова". Собственно, я от них отталкивался, когда писал свой pin.h.

Ещё известные мне варианты pin.h:

• для ADuc70xx;
• для LPC17xx;
• для STM8

бррррр... а при чем тут модер? )))) от куда вброс про многопоточность? вот от куда

тогел потоко не защищённый. Осторожно, тут мины!! ))


я вам про фому - вы мне про ерёму ))))