IAR меня игнорирует . :(, Причем , молча.... собака! Опции

[muravei]

Подскажите, как правильно (и каасиво) проверять пины в условии if . ( AVR)

[SasaVitebsk]

Кстати в IAR для ARM тоже можно кое чего.
Например:
PINSEL1_bit.P0_27 = 1; // TRST
или
U0FCR_bit.FCRFE=1; // Разрешить фифо

[zltigo]

Кстати в IAR ...

Баловство все эти фирменные навороты или навороченные (переболел в свое время) макросы. Портам имена и алиасы, биты/поля именовать и обыденных очевидных средств более чем достаточно, читабельно, портируемо, лаконично! и не заставляет вспоминать что это тут наворотил. Повторяющиеся вещи в разумные специализированные (а не "универсальные" макросы) или inline.

[Dog Pawlowa]

Баловство все эти фирменные навороты или навороченные (переболел в свое время) макросы....

Где все-таки грань навороченности макросов, не только для портов?
Я наоборот, от простых макросов описания конкретных портов перехожу к более универсальным.

Ниже - перебор? (много поскипано, но идея, думаю, понятна)

Код

  OUTPUT  (   PulseWdt        ,   P1  , 0x01    )
  INPUT   (   KeyStIn         ,   ~P1 , 0x10    )
...
#pragma inline=forced
unsigned char GetPin(unsigned int name);
#pragma inline=forced
void  OnPin(unsigned int name);
...
// generation of inputs functions
unsigned char GetPin( unsigned int name)
{ switch (name) {
#define INPUT( name, port, bit)  case name: return (port##IN & bit);
#include pins_file
default: return 0; } }

[AHTOXA]

Ниже - перебор? (много поскипано, но идея, думаю, понятна)

Так есть же макросы имени Волкова. Очень удобно.

Я так привык к ним, что для плюсов тоже соорудил аналог, правда для stm32 и msp430.

[Dog Pawlowa]

Так есть же макросы имени Волкова. Очень удобно.

Спасибо за ссылку. Я сделал немного по другому по сравнению с Волковым, и делал это последним на долгой дороге структуризации текущих проектов, после структуризации состояний, многоязычных сообщений, сигналов с датчиков, ошибок и прочей ерунды. Основная причина - самодокументируемость, файл описания должен быть понятен заказчику , ну а порты - чтобы было в одном стиле.

В части использования макросов Волкова, я больше склоняюсь к мнению zltigo, поскольку до недавнего времени прямое ногодрыганье было описано функциональными макросами.
Вот только поддержка режимов работы в бэкграунде все-таки следующий уровень модели OSI , и правильно не опускаться до портов сквозь уровень функциональных макросов, даже если это кажется проще.
Ладно, дискуссия немного остра получается, и подобная тема возникает раз в пол-года, вот попробую укрепиться в своем мнении и порву всех

это чистое, как слеза, ногодрыгание и переноситься на три варианта конструкции-разводки.

Как это выглядит? Я понимаю, условная компиляция, но на каком этапе.
Дело в том, что меня клинит, если по тексту разбросаны ifdef/endif. Все, что не помещается на экран, не помещается в мозг

Вышеприведенное, на мой взгляд описание одной простейшей операции с LCD.

У нас lcd разные, и тут все выглядит не очень противно

Код

void WriteByte1(uchar ch)
{ uchar i;
  OffPin(LcdCsb);
  for (i = 0; i<8; i++)
  { if (ch & 0x80) OnPin(LcdSi); else OffPin(LcdSi);
    OffPin(LcdClk);
    OnPin(LcdClk);
    ch <<= 1;
  }
  OnPin(LcdCsb);
}
void WriteLcdControl(char D)
{ OffPin(LcdRs);
  WriteByte1(D);
}

void WriteLcdData(char D)
{ OnPin(LcdRs);
  WriteByte1(D);
}

[zltigo]

Как это выглядит? Я понимаю, условная компиляция, но на каком этапе.
Дело в том, что меня клинит, если по тексту разбросаны ifdef/endif. Все, что не помещается на экран, не помещается в мозг

Макросы, только без притензий на "универсальность", а по месту, и таблицы в ROM.
Пример заполнения одной из таблиц

Код

#define MELODY( a, b, c, d ) (((d)<<9)|((c)<<6)|((b)<<3)|(a))
#define DUALTON( a, b ) (((b)<<14)|((a)<<12))

const ushort gtact[GEN_TAKTS] =
{
    MELODY(1,1,1,4) | DUALTON(TOFF,DUAL),
    MELODY(2,0,2,5) | DUALTON(DUAL,DUAL),
    MELODY(3,2,3,6) | DUALTON(TOFF,SINGLE),
....
....
....