Рассматривая примеры программ в Embedded (для ARM) обратил внимание, что нигде не встречается работа с регистрами микроконтроллеров с использованием битовых полей. Интересно, почему так?
Помнится еще студентами ставили эксперимент, сравнивая скорость работы через битовые поля и использование масок со сдвигами. Пришли к выводу что битовые поля как-то побыстрее.
Полная версия этой страницы: Битовые поля
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > Программирование
Цитата(Ivan_Kov @ Feb 6 2007, 11:07) 
Рассматривая примеры программ в Embedded (для ARM) обратил внимание, что нигде не встречается работа с регистрами микроконтроллеров с использованием битовых полей. Интересно, почему так?
А просто так.
Цитата
Помнится еще студентами ставили эксперимент, сравнивая скорость работы через битовые поля и использование масок со сдвигами. Пришли к выводу что битовые поля как-то побыстрее.
Смотря как что реализовано в компиляторе, ну и естественно заточенность системы команд процессора.
В случае чисто 32bit ARM, полагаю один черт.
скорее дело в удобстве использования: описал один раз как макром SETBIT & CLRBIT - и юзай откуда хочешь.. А битовые поля каждый раз описывать надо.
а насчет скорости утверждение спорное: все сдвиги-то просчитываются препроцессором _до_ компиляции. выходит что из операций остается только логическое и(/или) с _константой_ и сохранение результата в ту же ячейку памяти.
а в случае битовых полей - тут уже надо смотреть что там компилятор нагенерит - но очень сомнительно, что получится быстрее чем с масками и сдвигами
а насчет скорости утверждение спорное: все сдвиги-то просчитываются препроцессором _до_ компиляции. выходит что из операций остается только логическое и(/или) с _константой_ и сохранение результата в ту же ячейку памяти.
а в случае битовых полей - тут уже надо смотреть что там компилятор нагенерит - но очень сомнительно, что получится быстрее чем с масками и сдвигами
что-то мне не верится что просто-так. хотя бы потому, что битовые поля - удобнее.
некоторое время назад писал софт для ЦОС, взаимодействующий с ПЛИС. и я софт разрабатывал и человек проект для ПЛИС тоже разрабатывал. естественно были всякие регистры с битовыми полями, формат которых менялся в процессе разработки. Если-бы я не использовал структуры с битовыми полями, то намного сложнее было бы адаптировать софт под новые версии проекта ПЛИС.
Почему это каждый раз? один раз описал формат для конкретного регистра, и используй сколько хочешь.
А в случае с масками, это надо каждый раз при использовании учитывать расположение битов.
А если формат измениться, скажем поле шире станет, так это надо будет по всему проекту исправлять, запаришься.
некоторое время назад писал софт для ЦОС, взаимодействующий с ПЛИС. и я софт разрабатывал и человек проект для ПЛИС тоже разрабатывал. естественно были всякие регистры с битовыми полями, формат которых менялся в процессе разработки. Если-бы я не использовал структуры с битовыми полями, то намного сложнее было бы адаптировать софт под новые версии проекта ПЛИС.
Цитата(Doka @ Feb 6 2007, 12:21)
... А битовые поля каждый раз описывать надо....
Почему это каждый раз? один раз описал формат для конкретного регистра, и используй сколько хочешь.
А в случае с масками, это надо каждый раз при использовании учитывать расположение битов.
А если формат измениться, скажем поле шире станет, так это надо будет по всему проекту исправлять, запаришься.
Цитата(Ivan_Kov @ Feb 6 2007, 12:27)
Цитата(Doka @ Feb 6 2007, 12:21)
... А битовые поля каждый раз описывать надо....
Почему это каждый раз? один раз описал формат для конкретного регистра, и используй сколько хочешь.А в случае с масками, это надо каждый раз при использовании учитывать расположение битов.
ок. 1:1 =)
ибо биты маски тоже через #define определить можно:
Код
#define DMAINT0 (1<<2) /* IFR1 */
#define DMAINT1 (1<<9) /* IFR0 */
#define DMAINT1 (1<<9) /* IFR0 */
ну а по поводу начального вопроса: думаю тут еще играют роль другие факторы:
описал я например регистр в пространстве ввода-вывода (уже существующий) как:
Код
#define DMA_CSSA_L0 (*(volatile ioport unsigned int *)(0x0C04)) /* DMA Channel 0 Source Start Address, lower bits, register */
и потом его спокойно юзаю через всякие:Код
#define SETBIT(REG,BIT) REG |= (BIT)
как для того же самого декларировать битовые поля - не было времени разбираться. А дальше - просто привычка)
Цитата(Ivan_Kov @ Feb 6 2007, 12:27)
Почему это каждый раз? один раз описал формат для конкретного регистра, и используй сколько хочешь.
А в случае с масками, это надо каждый раз при использовании учитывать расположение битов.
А если формат измениться, скажем поле шире станет, так это надо будет по всему проекту исправлять, запаришься.
А в случае с масками, это надо каждый раз при использовании учитывать расположение битов.
А если формат измениться, скажем поле шире станет, так это надо будет по всему проекту исправлять, запаришься.
Не забывайте еще про то, что расположение полей в структуре - строго говоря, определяется компилятором (и упаковка то же). Так что если хотите переносимости и детерминированности - маски, если компактности и обозримости - битовые поля. Я использую и то, и другое. Как карта ляжет.
Цитата(Ivan_Kov @ Feb 6 2007, 11:27)
что-то мне не верится что просто-так. хотя бы потому, что битовые поля - удобнее.
Ну а много-ли Вы в периферии контроллера найдете вообще битовых полей (не одиночных битов а групп )? А насколько удобнее одно другого при работе с одиночным битом? А вот насколько удобнее
и быстрее устанавливать за одно обращение несколько не сгруппированных битов в одном регистре а?
Цитата
нигде не встречается работа с регистрами микроконтроллеров с использованием битовых полей
Ну и "нигде не встречается" - да все IAR-овские хидеры так (и только так
) написаны.Приходится дублировать обычными описаниями битов.
Код
#ifdef __IAR_SYSTEMS_ICC__
#ifndef _SYSTEM_BUILD
#pragma system_include
#endif
/* External interrupt register */
typedef struct{
__REG32 EINT0 : 1;
__REG32 EINT1 : 1;
__REG32 EINT2 : 1;
__REG32 EINT3 : 1;
__REG32 :28;
} __extint_bits;
/* External interrupt wakeup register */
typedef struct{
__REG32 EXTWAKE0 : 1;
__REG32 EXTWAKE1 : 1;
__REG32 EXTWAKE2 : 1;
__REG32 EXTWAKE3 : 1;
__REG32 :10;
__REG32 BODWAKE : 1;
__REG32 RTCWAKE : 1;
__REG32 :16;
} __extwake_bits;
..............
#ifndef _SYSTEM_BUILD
#pragma system_include
#endif
/* External interrupt register */
typedef struct{
__REG32 EINT0 : 1;
__REG32 EINT1 : 1;
__REG32 EINT2 : 1;
__REG32 EINT3 : 1;
__REG32 :28;
} __extint_bits;
/* External interrupt wakeup register */
typedef struct{
__REG32 EXTWAKE0 : 1;
__REG32 EXTWAKE1 : 1;
__REG32 EXTWAKE2 : 1;
__REG32 EXTWAKE3 : 1;
__REG32 :10;
__REG32 BODWAKE : 1;
__REG32 RTCWAKE : 1;
__REG32 :16;
} __extwake_bits;
..............
Цитата(zltigo @ Feb 6 2007, 12:57)
Ну и "нигде не встречается" - да все IAR-овские хидеры так (и только так ) написаны.
Приходится дублировать обычными описаниями битов.
) написаны.Приходится дублировать обычными описаниями битов.
с IAR не работал, не знал поэтому.
Ну а вобще я понял, что каждому инструменту - свое применение.
Цитата(Ivan_Kov @ Feb 6 2007, 12:07)
Ну а вобще я понял, что каждому инструменту - свое применение.
Естественно, но для периферии ARM контроллеров я явно предпочитаю банальное описание битов.
Код
// External interrupt mode register
#define EXTMODE_EXTMODE0 BIT0
#define EXTMODE_EXTMODE1 BIT1
#define EXTMODE_EXTMODE2 BIT2
#define EXTMODE_EXTMODE3 BIT3
#define EXTMODE_EXTMODE0 BIT0
#define EXTMODE_EXTMODE1 BIT1
#define EXTMODE_EXTMODE2 BIT2
#define EXTMODE_EXTMODE3 BIT3
Ну а структуры с битовыми полями это уже для, например, протокольных вещей
Код
// Internet Group Management Protocol Packet
typedef struct IGMP_packet {
WORD type : 4;
WORD version : 4;
BYTE mbz;
WORD checksum;
DWORD address;
} IGMP_packet;
typedef struct IGMP_packet {
WORD type : 4;
WORD version : 4;
BYTE mbz;
WORD checksum;
DWORD address;
} IGMP_packet;
А вот теперь возникла конкретная проблемка. Стал работать с регистрами микроконтроллера lpc2378, описав их через битовые поля. Возникла сложность. Если работаю с регистром как со структурой битовых полей непосредственно - нифига не работает. Если формирую значение регистра в переменной и затем присваиваю - работает.
Похоже, что обращение к регистрам может идти только как к 32-разрядным словам, а компилятору (arm-elf-gcc) дела до этого нет, и обращается он к отдельным байтам. Можно-ли побороть эту проблемку какими-нибудь опциями?
Похоже, что обращение к регистрам может идти только как к 32-разрядным словам, а компилятору (arm-elf-gcc) дела до этого нет, и обращается он к отдельным байтам. Можно-ли побороть эту проблемку какими-нибудь опциями?
>> Стал работать с регистрами микроконтроллера lpc2378,
>> описав их через битовые поля. Возникла сложность.
вот как раз поэтому в общем случае не хочется описывать периферию битовым полями. Тоже на такое напоролся в GCC - сохранение байта в регистр VIC (щас не помню какой) вызывало Data Abort. Теперь только маски.
>> описав их через битовые поля. Возникла сложность.
вот как раз поэтому в общем случае не хочется описывать периферию битовым полями. Тоже на такое напоролся в GCC - сохранение байта в регистр VIC (щас не помню какой) вызывало Data Abort. Теперь только маски.
Цитата(Ivan_Kov @ Feb 12 2007, 17:39)
А вот теперь возникла конкретная проблемка. Стал работать с регистрами микроконтроллера lpc2378, описав их через битовые поля. Возникла сложность. Если работаю с регистром как со структурой битовых полей непосредственно - нифига не работает. Если формирую значение регистра в переменной и затем присваиваю - работает.
Выбор из 2-х стилей: битовые поля или маски - дело вкуса.
Но - при текстах чуть более сложных студенческих работ (где очень рекомендуются бировые поля) - IMHO ! : битовые поля - это большая гадость.
Связано это с тем, что работая с битовыми полями, но не инициализируя всю структур в целом - вы рискуете иметь итоговый "мусор", даже при корректности вашего кода. Попробую показать на примере - прошу прощения, я спешил, и выхватил кусок кода из живого проекта, из-за этого куска мои коллеги имели "много времени неприятности"
Код
typedef uint16_t dt_t;
...
typedef union _sv_set {
dt_t state;
struct {
dt_t color :4;
dt_t regim :3;
};
} sv_set_t;
...
sv_set_t Lsvetofor::set_color( dt_t cmd ) {
sv_set_t st;
...
st.color = new_state;
return;
};
...
typedef union _sv_set {
dt_t state;
struct {
dt_t color :4;
dt_t regim :3;
};
} sv_set_t;
...
sv_set_t Lsvetofor::set_color( dt_t cmd ) {
sv_set_t st;
...
st.color = new_state;
return;
};
- как вы понимаете, в return - полный мусор, определяющийся историей отведения стека, там только 1-но корректное поле и есть: color
.Если то же будет записоно как-то грубо так:
Код
sv_set_t Lsvetofor::set_color( dt_t cmd ) {
sv_set_t st;
...
st = SV_SET_COLOR_WHITE | SV_SET_COLOR_YELLOW | SV_SET_COLOR_ZAPRET;
};
sv_set_t st;
...
st = SV_SET_COLOR_WHITE | SV_SET_COLOR_YELLOW | SV_SET_COLOR_ZAPRET;
};
- то мусорных неинициализированных полей возникнуть не может.
Это пример - примитивный, но если нечто подобное - в 1000 строк кода ... хорошее времяпрепровождение вам гарантировано
В описываемой вами симптоматике очень даже может быть нечто подобное - это слеует исключить раньше, чем грешить на компилятор.
Цитата(Olej @ Feb 12 2007, 22:43)
В описываемой вами симптоматике очень даже может быть нечто подобное - это слеует исключить раньше, чем грешить на компилятор.
Я уверен, что дело именно в том, как реализована работа с битовыми полями компилятором. При формировании значения поля, операции производятся не со всем 32-х разрядным словом, а с одним из его байт.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.