[sonycman 0]

А попробуйте что-то вроде

  if(RSStatus==RS_RECCMD)
{
   memcpy(RSRecCmdBuffer, &RSRecCmdBuffer, 7); 
   RSRecCmdBuffer[7] = b;

memcpy - intrinsic, компилятор может ее реализовать эффективнее, чем компилируя ваш цикл.

 

Дело в том, что memcpy использует в качестве счетчика регистровую пару, работа с которой при переброске маленьких блоков данных выглядит весьма неэффективной...

[Waso 1]

Немного не в тему, потому как речь о версии ИАР 4.3. Но опера та-же. Не понимаю, почему ИАР считает заранее известным условие с volatile переменными:

volatile union {       // для доступа к одной ячейке памяти разными способами 
        unsigned long all;          // для доступа ко всем 4-м байтам
        unsigned char byte[4];      // для побайтного доступа
    } recbuf; 

#pragma vector=INT0_vect
__interrupt void ext_int0_isr(void)
{
...
          recbuf.all>>=1; // сдвиг буфера на 1 бит
      if(bit)recbuf.byte[3]|=0x80;  // добавили единичку, если это она
...
}

void  main(void)
{
__enable_interrupt();
while (1)
  {

  if((recbuf.byte[0] ==~recbuf.byte[1])    // это условие даже не проверяется
  &&(recbuf.byte[2]==~recbuf.byte[3]))   // правда ругается на неопределенный порядок доступа
        {
            //  чтото делаем  - этот код компилятор выкидывает даже на низких уровнях оптимизации
         }
  }
}

Если то условие заменить таким - то все работает:

    tmp = ~recbuf.byte[1];
    if(recbuf.byte[0] == tmp)
     { 
        tmp = ~recbuf.byte[3];
        if(recbuf.byte[2] == tmp)

Присоединяю файл проекта если у кого не развита телепатия ;)

testout.zip

[demiurg_spb 0]

А если так:

union {       // для доступа к одной ячейке памяти разными способами 
         volatile unsigned long all;          // для доступа ко всем 4-м байтам
         volatile unsigned char byte[4];      // для побайтного доступа
     } recbuf;

[DogPawlowa 0]

Немного не в тему

if((recbuf.byte[0] ==~recbuf.byte[1]) // это условие даже не проверяется

Вы предупреждения компилятора вообще не читаете?

Писатель? ;)

 

Правая часть приводится к типу int. После инверсии в старшем байте казывается 0xff.

Результат сравнения 0xXX и 0xFFYY компилятору ясен на этапе компиляции.

[Xenia 38]

Вот так напишите и будет вам щастье: :)

 

void  main(void)
{
__enable_interrupt();
while (1)
  {
    if((recbuf.byte[0] ==(unsigned char)~recbuf.byte[1])
      &&(recbuf.byte[2]==(unsigned char)~recbuf.byte[3]))
    {
        //  что-то делаем
    }
  }
}

[Waso 1]

demiurg_spb, неа, не канает.

 

Xenia, Dog Pawlowa, я фшоке! Это действительно работает!! У меня сорвало крышу! Господа и дамы! Прошу! Объясните мне ради Бога! С какого рожна

Правая часть приводится к типу int.

Это что, происходит всегда, когда я произвожу над операндом какую-либо операцию прямо в условии??? Где прописано что это так делается? Я понимаю, если бы один из операндов был int или я например прибавлял к нему число голое.. Но туут.. %[]

[rezident 0]

Где прописано что это так делается?

В стандарте С99 вестимо.

6.5 Expressions

...

4 Some operators (the unary operator ~, and the binary operators <<, >>, &, ^, and |,

collectively described as bitwise operators) are required to have operands that have

integer type. These operators return values that depend on the internal representations of

integers, and have implementation-defined and undefined aspects for signed types.

[Сергей Борщ 126]

В стандарте С99 вестимо.

А также там (и в предыдущих версиях стандарта тоже) написано, что при любых арифметических действиях операнды размером меньше int (unsigned int) неявно приводятся к int (unsigned int), но потом оптимизатор может выкинуть действия не влияющие на результат. И все это называется integer promotion rules.

[Waso 1]

Спасибо. Каюсь. Грешен. Ненавижу читать стандарты...

 

Уже в который раз я удивляюсь - каким чудом работали мои предыдущие программы??...