Цитата(sKWO @ Apr 7 2008, 13:40)
К примеру с чем связано столько заморочек в ВИН АВР?
Макрос доступа к битам порта средствами ВИН АВР, например
sbi(PORTB, 5);
Подняв несколька файлов и сделав соответствующие подстановки получаем
следующее ( адрес порта Б к примеру 0x08)
Код
((*(volatile uint8_t *)(((uint16_t) &((*(volatile uint8_t *)((0x08) + 0x20)))) )) |=(1 << (5)))
средствами ИАР это дело обстоит намного проще и находится в одном файле avr_macros.h
Код
/* Set BIT in ADDRESS */
#define SETBIT(ADDRESS,BIT) ((ADDRESS) |= (1<<(BIT)))
Средствами WinAVR это "всё" тоже было одной практически такой же строкой
Код
#define sbi(port, bit) (port) |= (1 << (bit))
Зачем её было раскручивать? Какая разница что там, если оно всё равно компилируется в одну такую же команду ассемблера, что и у IAR ?
Ведь для SETBIT(PORTB,5) вы же у IAR не раскручивали, что такое PORTB и не сравнивали с WinAVR?
А он выглядит так
WinAVR:
Код
#define _MMIO_BYTE(mem_addr) (*(volatile uint8_t *)(mem_addr))
#define _SFR_IO8(io_addr) _MMIO_BYTE((io_addr) + 0x20)
...
#define PORTB _SFR_IO8(0x18)
Кстати, что-то Ваш вариант раскрутки sbi(port,bit) длинноват, выходит короче
Код
( *(volatile uint8_t *)((0x08) + 0x20) ) |=(1 << (5))
IAR:
Код
#define __BYTEBITS(_NAME,_A,_B,_C,_D,_E,_F,_G,_H) \
unsigned char _NAME ## _ ## _A:1, \
_NAME ## _ ## _B:1, \
_NAME ## _ ## _C:1, \
_NAME ## _ ## _D:1, \
_NAME ## _ ## _E:1, \
_NAME ## _ ## _F:1, \
_NAME ## _ ## _G:1, \
_NAME ## _ ## _H:1;
#define SFR_B_BITS(_NAME, _ADDR, _A,_B,_C,_D,_E,_F,_G,_H) \
__io union { \
unsigned char _NAME; /* The sfrb as 1 byte */ \
struct { /* The sfrb as 8 bits */ \
__BYTEBITS(_NAME, _A,_B,_C,_D,_E,_F,_G,_H) \
}; \
} @ _ADDR;
#define SFR_B(_NAME, _ADDR) SFR_B_BITS(_NAME, _ADDR, \
Bit0,Bit1,Bit2,Bit3,Bit4,Bit5,Bit6,Bit7)
...
SFR_B(PORTB, 0x18)
Так что у IAR просто наворочено в другом месте, до которого просто Вы не добрались :-)
Как лучше - тяжело сказать. Вариант IAR позволяет написать
Код
SPMCR.SPMIE = 1;
вместо
Код
SPMCR |= (1 << SPMIE);
или
SPMCR |= _BV(SPMIE);
зато не позволяет сделать то, что позволяет avr-gcc
(к чему это приводит - см, например,
http://electronix.ru/forum/index.php?s=&am...st&p=377042 )
Код
#if defined(SPMCSR)
# define SPM_CONTROL_REG SPMCSR
#elif defined(SPMCR)
# define SPM_CONTROL_REG SPMCR
#else
# error "SPM control register not defined"
#endif
...
SPM_CONTROL_REG |= (1 << SPMIE);
Таким образом для всех кристаллов, у которых есть либо SPMCR либо SPMCSR - можно обойтись несколькими строками кода и получить исходник, компилирующийся для всего. У IAR для этого придётся персонально проверять типы процесоров через
Код
#if defined(__AT90Mega88__) || defined(__AT90Mega168__) || ...
А всё потому, что PORTB да SPMCR у avr-gcc это макросы препроцессора, а у IAR - переменные-вложенные агрегаты, прибитые гвозядми к адресам, поэтому их наличие или отсутствие препроцессор не видит и нельзя сделать условную компиляцию просто проверив наличие имени регистра.
Цитата(sKWO @ Apr 7 2008, 14:07)
Допустим нужно установить в единицу четвёртый бит порта ну пускай Б
Настроим его как выход, назовём его HELS
Код
#define HELSp B
#define HELSb 4
CLRDDR(HELS);// направление
SETPORT(HELS);// бит 4 порта Б единичка
Это вообще уже лет 10 не так делается.
Код
#define LED1 B,0,L /* светодиод анодом на питание, зажигаем низким уровнем - L */
#define LED2 D,1,H /* светодиод катодом на землю, зажигаем высоким уровнем */
#define KEY1 C,2,L /* кнопка на землю, при нажатии низкий уровень */
#define KEY2 A,3,H /* кнопка на питание, при нажатии высокий уровень */
...
// теперь не глядя на полярности сигналов пишем ON, чтобы включить, а включается
// нулём или единичкой - макрос разбирается
DRIVER(LED1,OUT);
DRIVER(LED2,OUT);
DRIVER(KEY1,IN);
DRIVER(KEY1,PULLUP); // к примеру тут обходимся внутренней подтяжкой
DRIVER(KEY2,IN);
DRIVER(KEY2,HIZ); // а тут внешняя подтяжка на землю
...
if( ACTIVE(KEY1) ) {
ON(LED1);
OFF(LED2);
}
if( ACTIVE(KEY2) ) OFF(LED1);
if( flag) ) CPL(LED2); // проинвертировали ногу
Называется "макросы Аскольда Волкова", модифицировалось уже под разные процессоры и компиляторы всеми кому не лень. Вот мой вариант:
- сначала сдвиги, потом маскирования (так как сдвиги С часто компилируются в ассемблерные сдвиги с последующим маскированием, маскирования, разделённые сдвигом, часто остаются, хотя они и ихбыточные, а вот два маскирования подряд компиляторы как правило объединяют