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

[muravei]

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

[Rst7]

Случилось-то что?

Я всегда так делаю:

Код

#define BUTTON_INP PINC_Bit3
...
if (BUTTON_INP) blablabla...

[dimka76]

Я всегда так делаю:

Код

#define BUTTON_INP PINC_Bit3

тогда уж напишите как вы определяете

Код

PINC_Bit3

[Rst7]

тогда уж напишите как вы определяете

В названии темы фигурирует IAR в инкарнации AVR. Вы когда-нибудь интересовались, как в .h-файлах, входящих в стандартную поставку EWAVR описана периферия поддерживаемых камней?

[dimka76]

В названии темы фигурирует IAR в инкарнации AVR. Вы когда-нибудь интересовались, как в .h-файлах, входящих в стандартную поставку EWAVR описана периферия поддерживаемых камней?

Нет. У меня IAR 4.30. Сделал поиск файлов, содержащих текст PINC_Bit3 в папке inc и поиск не дал результата. Вот так.

[Rst7]

Сделал поск файлов, содержащих текст PINC_Bit3 в папке inc и поиск не дал результата.

Вы не поверите. Этого текста там действительно нет

[Goodefine]

Не мучайтесь

Код

#define PINC_Bit3 PINC&(1<<3)

[Rst7]

Не мучайтесь

Ответ неверный.

[Goodefine]

Ответ неверный.

Это не к IAR-у. Это вообще...

[dimka76]

Этого текста там действительно нет

Тогда причем тут

Вы когда-нибудь интересовались, как в .h-файлах, входящих в стандартную поставку EWAVR описана периферия поддерживаемых камней?

[Rst7]

Это не к IAR-у. Это вообще...

Хотите, в GCC так сделаю? Будет работать. Причем, не только if (PINC_Bit3), но и PINC_Bit3=1, что, как Вы понимаете, с Вашим define'ом невозможно.

Тогда причем тут

Как это причем? Вы что, думаете, что способ описания PINC_Bit3 может быть только один и это

Код

#define PINC_Bit3 чего-то

? Если да, то Вы ошибаетесь.

[Goodefine]

Хотите, в GCC так сделаю? Будет работать. Причем, не только if (PINC_Bit3), но и PINC_Bit3=1, что, как Вы понимаете, с Вашим define'ом невозможно.

Понимаю, конечно. Но вопрошающему:

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

думаю, для начала, достаточно...

[Rst7]

думаю, для начала, достаточно...

При условиях, указанных топикстартером, Ваш #define - лишний.

[dimka76]

Вы что, думаете, что способ описания PINC_Bit3 может быть только один

Уж не #define SFR_B_BITS вы имеете ввиду

[Rst7]

Уж не #define SFR_B_BITS вы имеете ввиду

Например его.

[dimka76]

Например его.

А что есть еще варианты?

[Rst7]

А что есть еще варианты?

Конкретно в IAR'е для AVR этот макрос разворачивает union со всякими собственными диалектическими словами типа __io и @. Можно реализовать и более стандартно, путем организации приведения типов.

[dimka76]

Конкретно в IAR'е для AVR этот макрос разворачивает union со всякими собственными диалектическими словами типа __io и @. Можно реализовать и более стандартно, путем организации приведения типов.

если Вы имеете ввиду это

Код

/*==========================*/
/* Predefined SFR Addresses */
/*==========================*/

/****************************************************************************
* An example showing the SFR_B() macro call,
* the expanded result and usage of this result:
*
* SFR_B(AVR,   0x1F) Expands to:
* __io union {
*             unsigned char AVR;                 // The sfrb as 1 byte
*             struct {                           // The sfrb as 8 bits
*                     unsigned char AVR_Bit0:1,
*                                   AVR_Bit1:1,
*                                   AVR_Bit2:1,
*                                   AVR_Bit3:1,
*                                   AVR_Bit4:1,
*                                   AVR_Bit5:1,
*                                   AVR_Bit6:1,
*                                   AVR_Bit7:1;
*                    };
*            } @ 0x1F;
* Examples of how to use the expanded result:
* AVR |= (1<<5);
* or like this:
* AVR_Bit5 = 1;
***************************************************************************/

То в моей версии IAR, как видите, это закоментировано и дано как образец. Т.е. это все самому прописывать надо

[Rst7]

То в моей версии IAR, как видите, это закоментировано и дано как образец. Т.е. это все самому прописывать надо

Шутите? Это комментарий. На самом деле надо поставить в свойствах проекта галочку "Enable Bit Definition in I/O-Include files". Либо разместить то ли в предопределенных символах, то ли перед #include <ioavr.h> определение ENABLE_BIT_DEFINITIONS

[dimka76]

Все разобрался.
В файле iom<номер контроллера>.h есть объявление SFR_B(PINC, 0x13), а также подключен зыголовочный файл iomacro.h, в котором SFR_B определено как

Код

#define SFR_B(_NAME, _ADDR) SFR_B_BITS(_NAME, _ADDR, \
                                    Bit0,Bit1,Bit2,Bit3,Bit4,Bit5,Bit6,Bit7)

В свою очередь SFR_B_BITS определено как

Код

#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;

[Rst7]

Ойц. Прошу прощения. Enable Bit Definition - это даже еще более веселее. Это можно типа так написать

Код

if (TIFR_TOV1) blablabla...

[Dog Pawlowa]

А что есть еще варианты?

Вариантов полно, главное проявить фантазию
Мне, из-за моей забывчивости и постоянного переключения между проектами , нравится типа так:
if (GetPin(ALARM_BUTTON)) SetPin(LOCK_THE_DOOR);
Ну а дальше работает оптимизация, приводящая все к нескольким командам.

[muravei]

Вариантов полно, главное проявить фантазию

А почему так : if ((PIND & 0x04)==0)...
прокатывало , а уже вот так : if ((PIND & 0x02)==0) ..... нет ?

[Sergey'F]

Может дело не в IAR?
- не включена ли альтернативная функция (некоторые сажают вход на регистр PIND на 0)?
- где-то ошиблись с DDRD и в результате конфликт и считывание неправильного значения.
- ножка сгорела, наконец?

[SasaVitebsk]

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

[zltigo]

Кстати в IAR ...

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

[rezident]

PINSEL1_bit.P0_27 = 1; // TRST
или
U0FCR_bit.FCRFE=1; // Разрешить фифо

Не нравятся мне эти битовые поля и union-ы.
ИМХО битовые маски рулят!

[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; } }

[rezident]

Где все-таки грань навороченности макросов, не только для портов?

Грань на границе HAL стоит.

Я наоборот, от простых макросов описания конкретных портов перехожу к более универсальным.

Зачем? Опишите функцию (имею в виду не программное понятие, а функциональную модель аппаратуры), которую выполняет hardware и работайте дальше с этой абстракцией. Все равно то, что в пределах HAL лежит аппаратнозависимо и некроссплатформенно. Нафига зачем какие-то универсальные порты описывать-то?

[AHTOXA]

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

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

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

[zltigo]

удобно.

Нафиг лишние сущности.

Опишите функцию (имею в виду не программное понятие, а функциональную модель аппаратуры), которую выполняет hardware..

Именно так. Иначе за ненужной "универсальностью" ногодрыгания теряется смысл нужной функциональной универсальности.

[AHTOXA]

Нафиг лишние сущности.

Ваше мнение понятно, зачем повторяться?

----
Кто-то пишет HAL, кому-то хватает макросов.
У меня в разных проектах на AVR, MB90, MSP430 и STM32 используется, например, один и тот же файл dflash.c:

Код

void df_init(void)
{
    off(FLASH_CS);
    direct(FLASH_CS, O);
}
...
void df_read(...)
{
    on(FLASH_CS);
...
}

Меняется только файл с макросами (под процессор), и описание ноги чипселекта (под схему, в отдельном инклюде).

Ну и чем это не HAL? И где здесь лишние сущности?

[zltigo]

Ну и чем это не HAL?

Для тех, кто пишет контроллеры светодиодов это может и "HAL" а для меня это махание ножкой через заднепроходное отверстие.
Вместо одной походя написанной банальной и однозначно читаемой строчки.
Когда нужно ПОНЯТНО согласовано и эффективно махать хотя-бы несколькими пинами, все эти макросы или идут лесом, или становятся совершенно невразумительными. Глупо обсуждать разнообразные способы лепки куличей из песка - эти "проблемы" интересны только младшей ясельной группе. А лично я уже давно вырос .
Для меня, например, уровень абстракции даже для банального светодиода совсем другой:

Код

typedef enum{
    LM_OFF = 0,
    LM_ON,
    LM_BLINK_SLOW,
    LM_BLINK_NORMAL,
    LM_BLINK_FAST,
    LM_FLASH_1,
    LM_FLASH_2,
    LM_FLASH_3,
    LM_FLASH_1_OFF,
    LM_FLASH_2_OFF,
    LM_MAX

} led_mode_e;

void led_mode( bint led, led_mode_e mode )
{
    if( mode >= LM_MAX )
        mode = LM_MAX-1;
    ledstat &= ((~0x11111111)  <<led);
    ledstat |= (led_const[mode]<<led);
}
led_mode( LED_RED, LM_BLINK_FAST );

И где-то уже дальше-дальше в самом конце

Код

void led_process( int counter )
{
..........

    if( curstat )
        IOlCLR = curstat;
    
    curstat = (~curstat)&(P_LED_RED|P_LED_GREEN|P_LED_INUSE|P_LED_TEST);
    
    if( curstat )
        IOlSET = curstat;
}

И потуги на дивные навороты на банальном включить/выключить "светодиод" мне, как минимум, не интересны.

[AHTOXA]

Для тех, кто пишет контроллеры светодиодов это может и "HAL" а для меня это махание ножкой через заднепроходное отверстие.
Вместо одной походя написанной банальной и однозначно читаемой строчки.

Одна понятная строчка, индивидуальная для каждого проекта vs одна понятная строчка на все проекты. Что лучше? Имхо, ответ очевиден.

Когда нужно ПОНЯТНО согласовано и эффективно махать хотя-бы несколькими пинами, все эти макросы или идут лесом, или становятся совершенно невразумительными.

Когда приходится согласованно махать несколькими пинами - надо использовать возможности периферии. Вручную махать эффективно всё равно не выйдет. Если до такого дошло, надо что-то править в консерватории.

Глупо обсуждать разнообразные способы лепки куличей из песка - эти "проблемы" интересны только младшей ясельной группе. А лично я уже давно вырос .

Ох, не похоже

Для меня, например, уровень абстракции даже для банального светодиода совсем другой:

Таки балуетесь "контроллерами светодиодов"?

[dxp]

Вопрос не по теме, пардон.

Код

typedef enum{
    LM_OFF = 0,

Зачем тут явная инициализация?

[MrYuran]

Зачем тут явная инициализация?

Для наглядности, я тоже так всегда делаю.

Код

enum eAnswerCommonParameters
{
    acp_Preamble = 0,           // преамбула
    acp_Status,                 // слово состояния
    acp_Ktermo_0,               // коэффициент термокомпенсации
    acp_Ktermo_1,
    acp_Ktermo_2,               //
    acp_Ktermo_3,
    acp_Csens_0,                // постоянная датчика
    acp_Csens_1,
    acp_Csens_2,
    acp_Csens_3,
    acp_Rt0_x_10_Low,           // калибровочная константа датчика температуры
    acp_Rt0_x_10_Hi,
    acp_Rref_x_10_Low,          // сопротивление опорного резистора термоканала
    acp_Rref_x_10_Hi,
    acp_CS,
    acp_PacketLen
};

[zltigo]

Если до такого дошло, надо что-то править в консерватории.

Давайте покажите мастеркласс обновления консерватории, например, переписав ногомахание для одного из примитивов работы с LCD:

Код

void lcd_writedata( bint data )
{
    lcd_waitready( RDY_DATA|RDY_COMMAND );
    // Setup DATA
    PIOlCLR = T6963_CE|T6963_WR|T6963_CD|(0xFFUL<<T6963_D0);
    PIOlSET = (data & 0xFFUL) << T6963_D0;
    PIOlSET = T6963_CE|T6963_WR;
    PIOlSET = T6963_CD;
}

Вышеприведенное, на мой взгляд описание одной простейшей операции с LCD. Рассыпать ее на более мелкие ногодрыгания одиночных пинов в стиле " on(FLASH_CS)" просто гробить и здравый смысл и программу.
Всякие навороченные макросы БЕЗУСЛОВНО полезно читать, разбирать, уметь писать и ПРИМЕНЯТЬ - это упражнение для ума, приобретение навыков и прочеее.... Макросы того-же Волкова это типа шахматного этюда и с этой точки зрения они ОЧЕНЬ полезны. Но реальное программирование отличается, как реальная игра а шахматы от решения надуманных шахматных этюдов. К реальному программированию такого типа макросы можно притянуть только за уши. Нет, конечно, многие так делают и считают использование подобных "штампов" и трюков признаком мастерства . Но совершенно зря.

Таки балуетесь "контроллерами светодиодов"?

Разумеется. Только не контроллерами светодиодов, а устройствами на которых помимо всего прочего железа из которого чип контроллера обычно самый маленький, есть и светодиоды. И я ими разнообразно мигаю, только не на уровне примитива on( RED_LED ) - слишком примитивно
Хотя встречаются и почти чистые контроллеры светодиодов - месяц назад 64 светодиода и 32 кнопки на голой ATmega16 походя написал. И даже ума не приложу через какую задницу там можно было макросы типа приведенных Вами использовать , хотя вся "программа" это чистое, как слеза, ногодрыгание и переноситься на три варианта конструкции-разводки.

Зачем тут явная инициализация?

Банальная наглядность - уточнение с долей привычки. Абсолютно безобидная привычка.

[AHTOXA]

Давайте покажите мастеркласс, например, переписав ногомахание для одного из примитивов работы с LCD:

Я где-то призывал использовать макросы Волкова повсеместно? Всему своё место и время.

Вышеприведенное, на мой взгляд описание одной простейшей операции с LCD. Рассыпать ее на более мелкие ногодрыгания одиночных пинов в стиле " on(FLASH_CS)" просто гробить и здравый смысл и программу.

Вы говорите какие-то банальности. Даже несерьёзно. Расскажите ещё, что при 16-битной шине использовать "on(FLASH_CS)" глупо
Однако же, существует SPI с его чипселектами, множество микросхем имеет ножки готовности (опять же одиночные), да мало ли примеров одиноких ножек, замечательно ложащихся под эти макросы.

Всякие навороченные макросы БЕЗУСЛОВНО полезно читать, разбирать, уметь писать и ПРИМЕНЯТЬ - это упражнение для ума, приобретение навыков и прочеее....

Да что же в них навороченного-то? Там всё достаточно прозрачно. Это просто полезные макросы.

Но реальное программирование отличается, как реальная игра а шахматы от решения надуманных шахматных этюдов. К реальному программированию такого типа макросы можно притянуть только за уши. Нет, конечно, многие так делают и считают использование подобных "штампов" и трюков признаком мастерства . Но совершенно зря.

Я так понимаю, под "реальным программистом" вы имеете в виду себя?
У меня несколько другое представление о реальном программировании. Реальное программирование - это когда человек способен применять разнообразные инструменты и приёмы в зависимости от задачи. А ваш подход больше напоминает узколобый догматизм, уж извините.

месяц назад 64 светодиода и 32 кнопки на голой ATmega16 походя написал. И даже ума не приложу через какую задницу там можно было макросы типа приведенных Вами использовать

Ну и о чём это говорит? О том что инструмент плохой? Нет. Просто неподходящий для данного конкретного случая.

[SasaVitebsk]

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

Там (ARM7) кстати не всегда и применишь данные макросы. Смотреть надо. Не везде однозначность.
Например установка бита, порождает конструкцию вида чтение-модификация-запись. То есть, если есть флаги (попутные), которые сбрасываются единицей, то они уйдут незаметно. Что-то я ищё подобное для себя отмечал.

Короче, в общем случае, порождает неоднозначность. То есть порождает отрыв программиста от железа. Когда человек пишет "установить бит в 1" то он не учитывает попутные действия компилятора.

Поэтому, если честно, я тоже не пользуюсь такими конструкциями ни в AVR ни в ARM. Не хочется запоминать и анализировать.

Но в инициализации применял, для наглядности. Сразу видно.

[zltigo]

Ну и о чём это говорит? О том что инструмент плохой? Нет. Просто неподходящий для данного конкретного случая.

Когда некий инструмент подходит исключительно для очень конкретного И ПРОСТЕЙШЕГО случая, а рядом с этим случаем, в этом-же проекте 99 других случаев идущих в разрез с этим "инструментом" . Причем инструменты оставшиеся задачи спокойно решают и "конкретную" задачу, то поминаемый Вам "хороший" инструмент становится именно той лишней сущностью . А его использование, как Вы там сказали -
"напоминает узколобый догматизм, уж извините."

Однако же, существует SPI с его чипселектами, множество микросхем имеет ножки готовности (опять же одиночные)....

SPI? Их есть у нас. Вот, например:

Код

__arm void send_spi_start_int( SPI_bcb *sp, int data )
{
    IO0CLR = sp->msel;
    S0SPDR  = data;                       // Data
    if( S0SPSR_check() )
        return;
    IO0SET = P0B_S0SEL_MASK;
    sp->flag &= (~BCB_TX_START);
}

int work_spi_modgal( bint modul, WORD adrdat )
{
int i = 1000; // Total timeout

    if( modul )
        IO0CLR = P0B_M1_CSEL;
    else
        IO0CLR = P0B_M0_CSEL;
    do     // Timeout if not ready
    {   IO0CLR = S0SSEL_SOFT;
        if( !(IO0PIN & P0B_MX_RDY)  )          // Ready?
        {   IO0CLR = P0B_MX_AC;                // Select 'Address' byte
            S0SPDR = (adrdat>>8);             // Send Hi byte(address)
            if( S0SPSR_check() )            // Wait end of transmit
                goto dsl_exit_error;
            IO0SET = (S0SSEL_SOFT|P0B_MX_AC);        // Disable Select and set 'Data'
            do     // Timeout if not ready
            {    IO0CLR = S0SSEL_SOFT;        // Select
                if( !(IO0PIN & P0B_MX_RDY)  )      // Ready?
                {   S0SPDR = adrdat;              // Send Lo byte(data/dummy)
                    if( S0SPSR_check() )        // Wait end of transmit
                        goto dsl_exit_error;
                    IO0SET = (P0B_MASK_CSEL|S0SSEL_SOFT|P0B_MX_AC); // Disable SHDSL
                    return( S0SPDR );              // Get any data
                }
                IO0SET = S0SSEL_SOFT;    // Disable Select
                delay_us( 10 );
                i--;
            }
            while( i > 0 );
        }
        IO0SET = S0SSEL_SOFT;    // Disable Select
        delay_us( 10 );
        i--;
    }
    while( i > 0 );
dsl_exit_error:
    IO0SET = (P0B_MASK_CSEL|S0SSEL_SOFT|P0B_MX_AC); // Disable SHDSL
    return( -1 );
}

Куда прикажете вставлять макрос для махания shipselect?

...да мало ли примеров одиноких ножек, замечательно ложащихся под эти макросы.

Ничножно мало и повторюсь еще раз, рядом с этими одиночными "замечательно ложащимися" еще куча не одиночных... Плодить лишнюю сущность для работы с 1-2 одиночными, когда рядом еще десятки "неудобных" пинов просто незачем.

[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),
....
....
....

[AHTOXA]

Когда некий инструмент подходит исключительно для очень конкретного И ПРОСТЕЙШЕГО случая, а рядом с этим случаем, в этом-же проекте 99 других случаев идущих в разрез с этим "инструментом"

Вовсе не вразрез. Ортогонально. Не подходит - не пользуешь, подходит - почему нет?

Причем инструменты оставшиеся задачи спокойно решают и "конкретную" задачу, то поминаемый Вам "хороший" инструмент становится именно той лишней сущностью .

Я собственно уже всё обосновал. Вы упорно не желаете слушать, и приводите однообразные примеры.

А его использование, как Вы там сказали -
"напоминает узколобый догматизм, уж извините."

Неизящно. Как "сам дурак" в детском садике Использование инструмента по месту - никак не догматизм. А вот упорное отрицание возможной полезности инструмента - да.

SPI? Их есть у нас. Вот, например:

Ужас. Вам что, платят по количеству строчек кода, как индусам?

Код

int put_byte(uint08_t b)
{
    int i = 1000; // Total timeout
    int res = -1;

    do
    {   on(S0SSEL_SOFT);
        if((signal(MX_RDY))
        {
            S0SPDR = adrdat;
            if(!S0SPSR_check())
                res = S0SPDR;
            break;
        }
        off(S0SSEL_SOFT);
        delay_us( 10 );
        i--;
    }
    while( i > 0 );
    off(P0B_MASK_CSEL);
    off(S0SSEL_SOFT);
    off(P0B_MX_AC);
    return res;
}

int work_spi_modgal( bint modul, WORD adrdat )
{
    int i = 1000; // Total timeout
    int res;

    if( modul )
        on(M1_CSEL);
    else
        on(M0_CSEL);
    res = put_byte(adrdat>>8);
    if (res != -1)
        res = put_byte(adrdat);
    return res;
}

Куда прикажете вставлять макрос для махания shipselect?

Вот, как-то так...

[zltigo]

.... и приводите однообразные примеры.

сказал, АНТОХА и в очередной раз написал on()

Ужас. Вам что, платят по количеству строчек кода, как индусам?

Нет, за рабочий код в том числе работающий с железом так, как нужно железу а не мерещится специалистам по макросам описывающим ножку. Не Вам обижать индусов.

Вот, как-то так...

Выше просто абсолютно нерабочая отсебятина из которой выброшен почти смысл, зато, например, простые вещи типа

Код

   IO0SET = (P0B_MASK_CSEL|S0SSEL_SOFT|P0B_MX_AC); // Disable SHDSL

заменены на три

Код

  off(P0B_MASK_CSEL);
    off(S0SSEL_SOFT);
    off(P0B_MX_AC);

И после этого "Вам что, платят по количеству строчек кода, как индусам?" . Глупо.
О том, что даже эти три строчки совсем другая диаграмма и другие времена помолчим, и тот-же P0B_MASK это совсем не бит.. Но объяснять это счастливому обладателю "отвертки" желающему неприменно запихнуть ее куда попало видимо, пока? невозможно . Может со временем и сами переболеете, как переболел желанием абстрагировать всякую мелочь я.

[Dog Pawlowa]

простые вещи типа

Код

   IO0SET = (P0B_MASK_CSEL|S0SSEL_SOFT|P0B_MX_AC); // Disable SHDSL

заменены на три...
о том, что это совсем другая диаграмма

Справедливости ради ... механизм макросов позволяет назвать сразу группу бит и применить одну команду.

[dimka76]

Макросы вещь небезопасная с точки зрения контроля типов, как минимум.
В С++ введены шаблоны.
Почему же никто про них не вспомнил ?

[zltigo]

Справедливости ради ... механизм макросов позволяет назвать сразу группу бит и применить одну команду.

Возможно, что какие-то позволяют, какие-то не позволяют.... Для этого, вместо абсолютно самодостаточного однострочного выражения предлагаете вычитывать макрос on() и думать о последствиях его применения?

[AHTOXA]

В С++ введены шаблоны.
Почему же никто про них не вспомнил ?

Вообще-то, вспомнили

сказал, АНТОХА и в очередной раз написал on()

Дык, потому что zltigo написал:

SPI? Их есть у нас. Вот, например:
Куда прикажете вставлять макрос для махания shipselect?

Вот я и вставил

Нет, за рабочий код в том числе работающий с железом так, как нужно железу а не мерещится специалистам по макросам описывающим ножку.

Что рабочий - верю. Но ужасный...

Выше просто абсолютно нерабочая отсебятина из которой выброшен почти смысл, зато, например, простые вещи типа

Код

   IO0SET = (P0B_MASK_CSEL|S0SSEL_SOFT|P0B_MX_AC); // Disable SHDSL

заменены на три

Код

  off(P0B_MASK_CSEL);
     off(S0SSEL_SOFT);
     off(P0B_MX_AC);

И в чём же её нерабочесть? Конкретно пожалуйста. За исключением P0B_MASK - я не догадался, что это два бита. Замените
off(P0B_MASK_CSEL);
на
off(M1_CSEL);
off(M0_CSEL);
. Что там ещё нерабочее?

И после этого "Вам что, платят по количеству строчек кода, как индусам?" . Глупо.

Ну тут просто надо было показать концепцию. В реальной системе, если это критично, я, конечно взвожу и чищу биты одновременно.

О том, что даже эти три строчки совсем другая диаграмма и другие времена помолчим, и тот-же P0B_MASK это совсем не бит.. Но объяснять это счастливому обладателю "отвертки" желающему неприменно запихнуть ее куда попало видимо, пока? невозможно . Может со временем и сами переболеете, как переболел этим я.

Я ими не болею Я их примененяю по месту. Уже лет десять как. Не думаете же вы, что я всё пишу на on() и off()?

[Dog Pawlowa]

Возможно, что какие-то позволяют, какие-то не позволяют.... Для этого, вместо абсолютно самодостаточного однострочного выражения предлагаете вычитывать макрос on() и думать о последствиях его применения?

Ну, над тремя-четырьмя битами в одной строчке все равно думать надо. А группу бит можно назвать по человечески один раз и больше не думать.
Я не то, что предлагаю... рассматриваю реально существующие альтернативы.

О последствиях применения макросов уже поздно думать, мой "структурированный" проект на днях ушел заказчику, сегодня досылал файлы с подобными определениями. Иначе пришлось бы отдельные документы вместо такого исходного кода:

Код

//          number                   name          name2       condition          
SENSOR( CanEmpty           ,    "Can empty"         , "AC,A2" , GetAdc(CanAdc) > se.CanEmptyLevel               )
SENSOR( NivBelowEmpty    ,    "Niv below empty" , "AC,A3" , GetAdc(NivEmptyAdc)>se.NiveauLevel              )
SENSOR( LowPower            ,    "Low power    "     , "DC,A6" , GetAdc(PowerAdc)  <  se.LowPowerLevel          )

[zltigo]

Ну, над тремя-четырьмя битами в одной строчке все равно думать надо. А группу бит можно назвать по человечески один раз и больше не думать.

Так у меня в той строчке есть и группа бит, и обозвана прилично, только что это меняет?

Код

.....

Слишком много букофф - для создания видимости простоты понимания заказчиком, который хочет иметь иллюзии того, что способен сколь-нибудь серьезно разобраться или просто иметь кучу документов по причине того, что "так принято" - вариант совершенно изумительный (ну разве только буквы почему-то не русские ). Но для работы .
Лично я предпочитаю даже в таких случаях писать пояснительные записки - заодно и для себя польза - пишется и немного подчищается. В противном проект стремиться к горе хлама, хоть и "самодокументированной".

И в чём же её нерабочесть? Конкретно пожалуйста. За исключением P0B_MASK - я не догадался, что это два бита.

Совсем другой алгоритм. Всякие махания пинами должны быть разные для разных транзакций по SPI, таймаут хитрее, процедура проверки готовности сложнее, лишние чтения SPDR (и уж тем более анализ ненужно считанного) не нужны, причем чтения должны быть ПОСЛЕ определенных ногомаханий а не просто быть, где попало. Для Вас по барабану время исполнения. Вы написали ПОЛНУЮ ЕРУНДУ не соответствующую исходному алгоритму (да от такой не потому, что я его сдуру написал, а по той причине, что на встречной стороне AVR с софтовым, блин, SPI от стороннего производителя ) и если действительно этого не видите и "Уже лет десять как", то дела плохи . Я думал студент какой

[Dog Pawlowa]

В противном проект стремится к горе хлама

Да сам боюсь Посмотрим ...

[AHTOXA]

Совсем другой алгоритм. Всякие махания пинами должны быть разные для разных транзакций по SPI,

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

Я думал студент какой

Ой да ладно. Если судить по юношескому максимализму и желанию доказывать, что его мнение единственно верное, то студент из нас двоих - однозначно не я.

[dxp]

Для наглядности, я тоже так всегда делаю.

"Это короче, чем я могу написать, а компилятор должен понимать умолчания" (с) Б.Страуструп.

Банальная наглядность - уточнение с долей привычки. Абсолютно безобидная привычка.

Обидного в такой привычки и правда нет.

А когда заводите просто глобальные/статические переменные:

int a;
int b;

int main()
{
...
return 0;
}

тоже инициализируете:

int a = 0;
int b = 0;

?

Или нет?

[zltigo]

Или нет?

Разумеется нет, ибо такую привычку совсем безобидной уже назвать не могу, ибо в общем случае не знаю, как компилятор будет их инициализировать. Может туповато будет инициализировать из ROM.
Хотя в отдельных случаях - бывает пишу инициализацию, например, тем-же самым нулевым enum - ну что-то типа комментария о начальном состоянии.
А с enum никаких побочных эффектов быть не может. И тут накладывается еще одна привычка - начинающиеся с нуля я стараюсь не использовать, там, где это возможно.
Да и если с '0', то часто пишу такие с 'дырками'. Тоже, считайте, привычка иногда помогающая быстрее в каом-нибудь дампе разобраться.

Код

    
typedef enum {
    S_MODE_LOGO = 0x00,
    S_MODE_MAIN,
    S_MODE_BOOK,
    S_MODE_LIST,
    S_MODE_DIAL,
    S_MODE_MENU,

    S_STATE_IDLE = 0x10,
    S_STATE_OFFHOOK,
    S_STATE_SPEAKER,

    S_SHOW_RINGING = 0x20,
    S_SHOW_NO_RINGING,

    S_RING_ENABLE = 0x50,
.......

И явный ноль при этом смотрится в одном стиле.
Посему мною уже на автомате пишутся enum начинающиеся с инициализации.

(с) Б.Страуструп.

Не знаю, как там исходники Страуструпа а мои исходники не только компиляторы, но и люди читают

P.S.
А в чем проблема-то?

[dxp]

P.S.
А в чем проблема-то?

Да, нету проблемы. Просто явно лишняя писанина, вот и поинтересовался, в чем может быть смысл. Оказалось, в личных эстетических предпочтениях. Вопросов больше не имею.

Не знаю, как там исходники Страуструпа а мои исходники не только компиляторы, но и люди читают

P.S. Люди тоже должны знать правила языка и понимать умолчания.