u
uis
struct st{
bool b:1;
};
bool b:1;
};
Тип такое?
Size: a a a
2020 June 11
СС
Голые битовые числа зло. Сам через полгода-год забудешь что к чему, поддерживать нереально. Лучше вместо битовых сдвигов делать структуру с битовыми полями
Не работает когда состояние кодится более чем одним битом
СС
uis
Тип такое?
Оно вроде не совсем так пишется но тип того
СК
Типа struct State { uint8_t normalWork : 1; uint8_t sendAnswer : 1; uint8_t other : 3;};
СК
Использовать так: State state = { .normalWork = true; .other = 5};
u
Типа struct State { uint8_t normalWork : 1; uint8_t sendAnswer : 1; uint8_t other : 3;};
Сразу говорю минусы:
1) Implementation-dependent
2) В большинстве реализаций биты выделяются со старшего
1) Implementation-dependent
2) В большинстве реализаций биты выделяются со старшего
u
uis
Сразу говорю минусы:
1) Implementation-dependent
2) В большинстве реализаций биты выделяются со старшего
1) Implementation-dependent
2) В большинстве реализаций биты выделяются со старшего
Самый главный минус - первый
D
hardegor
#define NORMAL_WORK 1<<5
#define SEND_ANSWER 1<<2
а постоянную команду:
#define DEFAULT_STATE NORMAL_WORK|SEND_ANSWER
и тогда можно так:
state |= NORMAL_WORK|SEND_ANSWER
или так:
state |= DEFAULT_STATE
#define SEND_ANSWER 1<<2
а постоянную команду:
#define DEFAULT_STATE NORMAL_WORK|SEND_ANSWER
и тогда можно так:
state |= NORMAL_WORK|SEND_ANSWER
или так:
state |= DEFAULT_STATE
Это херня.
u
hardegor
#define NORMAL_WORK 1<<5
#define SEND_ANSWER 1<<2
а постоянную команду:
#define DEFAULT_STATE NORMAL_WORK|SEND_ANSWER
и тогда можно так:
state |= NORMAL_WORK|SEND_ANSWER
или так:
state |= DEFAULT_STATE
#define SEND_ANSWER 1<<2
а постоянную команду:
#define DEFAULT_STATE NORMAL_WORK|SEND_ANSWER
и тогда можно так:
state |= NORMAL_WORK|SEND_ANSWER
или так:
state |= DEFAULT_STATE
Прям cmsis
u
Это херня.
Почему?
D
Например:
#define NORMAL_WORK 1<<5
#define OTHER_WORK 0<<5
#define NORMAL_WORK 1<<5
#define OTHER_WORK 0<<5
D
Когда от одного бита зависят два разных варианта работы, 0 или 1 в конкретной позиции
D
Например из подручного:
//RGB or BGR order
#define MADCTL_RGB (0 << 3)
#define MADCTL_BGR (1 << 3)СК
uis
Сразу говорю минусы:
1) Implementation-dependent
2) В большинстве реализаций биты выделяются со старшего
1) Implementation-dependent
2) В большинстве реализаций биты выделяются со старшего
Если брать кортексы и современные компиляторы то всё совпадает. Покрыть тестами и норм. Проверено на IAR, GCC, clang, msvc
СК
Зато читаемость на высоте и нет проблем с многобитовыми полями
СК
Биты с младшего
D
Например из подручного:
//RGB or BGR order
#define MADCTL_RGB (0 << 3)
#define MADCTL_BGR (1 << 3)Никто не мешает задуматься и написать MADCTL_RGB | MADCTL_BGR. Так же проблема с присвоением одного конкретного бита.
СС
Например из подручного:
//RGB or BGR order
#define MADCTL_RGB (0 << 3)
#define MADCTL_BGR (1 << 3)Ну да верно писать
#defene DA 1
#define NYET 0
#define WORK_POS
state |= DA<<WORK_POS
#defene DA 1
#define NYET 0
#define WORK_POS
state |= DA<<WORK_POS
СК
Из минусов битовых сдвигов и девайнов - нет строгой типизации, можно любой другой дефайн присвоить
h
Никто не мешает задуматься и написать MADCTL_RGB | MADCTL_BGR. Так же проблема с присвоением одного конкретного бита.
Ну так на всём можно задуматься и неправильно написать.