Стиль программирования на Си, описание функции Опции

[sKWO]

Добрый день!
Столкнулся со следующей проблемой.
нашол код как сделать восемь таймеров написанный Alechin Jan.
Первое что кидается в глаза та это синтаксис мне непонятный.
Вот к примеру прототип функции остановки тай мера:

Код

void Stop_Timer(IN IDX timer);

ну и сама функция:

Код

/*--------------------------------------------------------------------------------------------*/
/* Процедура остановки таймера.                                                               */
/* Принимает:   номер таймера (0 - 7).                                                        */
/* Возвращает:  ничего не возвращает.                                                         */
/*--------------------------------------------------------------------------------------------*/
__monitor void Stop_Timer(IN IDX timer)
{
  Timer[timer].Timer_Ena = TIMER_DIS;
  return;
}

Непонятно что такое IDX? Ну IN понятно, направление, очень удобно.
IDX по ходу здесь беззнаковый чар.
Ну и соответственно вопрос:
Этот синтаксис возможен через какоето макроопределение?
Может кто знает, подскажите, уверен это интерессно не только мне.
Вот ещё пример

Код

void Start_Timer(IN IDX timer, IN WORD interval, IN pTIMER_FUNC pFunc = NULL, IN bool cycle = TIMER_ONCE);

Спасибо.

[SasaVitebsk]

Вот об этом я и говорю - богатство выбора в рамках языка.

При написании сложных операторов с большим количеством операций по типу ++/-- могут быть грабли. Они достаточно подробно описаны даже в учебниках. Но, как мне кажется, не стоит перегружать операторы. Это неудобно для отладки к примеру и ухудшает читаемость. С другой стороны, совершенно очевидно, что компилятору по барабану написали ли вы формулу одним оператором или тремя. Качество сгенерированного кода не ухудшится

[zltigo]

... совершенно очевидно, что компилятору по барабану написали ли вы формулу одним оператором или тремя. Качество сгенерированного кода не ухудшится

Компиляторы умнеют, но тем не менее пока не умнее Вас и на подсказку вполне вероятно, ответят лучшим кодом.

Более того, при написании 3мя операторами оно может и существенно улучшиться
если знаешь как правильно разбить эти 3 оператора на нужное количество строк...

Вы знаете? Тогда пример в студию......

Поэтому, когда мне закинут в уши мысль типа...

ну зачем-же гордится своей наивностью?

[sKWO]

Компиляторы умнеют, но тем не менее пока не умнее Вас и на подсказку вполне вероятно, ответят лучшим кодом.

К примеру с чем связано столько заморочек в ВИН АВР?
Макрос доступа к битам порта средствами ВИН АВР, например
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)))

[ReAl]

К примеру с чем связано столько заморочек в ВИН АВР?
Макрос доступа к битам порта средствами ВИН АВР, например
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 - переменные-вложенные агрегаты, прибитые гвозядми к адресам, поэтому их наличие или отсутствие препроцессор не видит и нельзя сделать условную компиляцию просто проверив наличие имени регистра.

Допустим нужно установить в единицу четвёртый бит порта ну пускай Б
Настроим его как выход, назовём его 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); // проинвертировали ногу

Называется "макросы Аскольда Волкова", модифицировалось уже под разные процессоры и компиляторы всеми кому не лень. Вот мой вариант:

Прикрепленные файлы

 pin_macros.zip ( 1.32 килобайт ) Кол-во скачиваний: 112

 

[sKWO]

Называется "макросы Аскольда Волкова", модифицировалось уже под разные процессоры и компиляторы всеми кому не лень.

C макросами ядерного физика Аскольда Волкова давно знаком, удобная вещь, когда-то на Телесисах
он его представлял, собственно как и его модификацию которую выложил Сергей Борщ.
Конечно же их использую.

А всё потому, что PORTB да SPMCR у avr-gcc это макросы препроцессора, а у IAR - переменные-вложенные агрегаты, прибитые гвозядми к адресам, поэтому их наличие или отсутствие препроцессор не видит и нельзя сделать условную компиляцию просто проверив наличие имени регистра.

За это большое спасибо!

длинноват, выходит короче

Код

( *(volatile uint8_t *)((0x08) + 0x20) )    |=(1 << (5))

Код

в файле sfr_def.h находим
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
дальше
#define _SFR_BYTE(sfr) _MMIO_BYTE(_SFR_ADDR(sfr))
дальше
#define _MMIO_BYTE(mem_addr) (*(volatile uint8_t *)(mem_addr))
#define _SFR_ADDR(sfr) _SFR_MEM_ADDR(sfr)  
#define _SFR_MEM_ADDR(sfr) ((uint16_t) &(sfr))
получаем
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
подставляем
#define sbi(sfr, bit) (   (*(volatile uint8_t *)(   ((uint16_t) &(sfr))   ))   |= _BV(bit))
смотрим в  pgmspace.h  _BV
#define _BV(bit) (1 << (bit))
видим
#define sbi(sfr, bit)  ((*(volatile uint8_ t *)(((uint16_t) &(sfr)) ))   |=  (1 << (bit)))
всё хорошо получается или чёта провтыкал?
имеем следующее
((*(volatile uint8_t *)(((uint16_t) &(PORTB )) ))   |=  (1 << (5)))
ну и остаётся за малым подставить знач порта
допустим
#define PORTB  _SFR_IO8(0x08)
находим _SFR_IO8 в файле sfrdefs.h
#define _SFR_IO8(io_addr) _MMIO_BYTE ((io_addr) + 0x20)
соответственно _SFR_IO8(0x08) есть_MMIO_BYTE((0x08) + 0x20)
а  _MMIO_BYTE((0x08) + 0x20) есть (*(volatile uint8_t *)((0x08) + 0x20))
отсюда и получается
((*(volatile uint8_t *)(((uint16_t) &((*(volatile uint8_t *)((0x08) + 0x20)))) ))   |=(1 << (5)))

Выходит разные версии компилят , наверное