К знатокам, Локальные переменные. Опции

[SasaVitebsk]

Пишу достаточно простую прогу. Пытаюсь оптимизировать.

Столкнулся с одной бедой. Попробую описать.

Построено на прерываниях. Между прерываниями разные промежутки. Есть короткие, есть длинные. Как назло именно короткое прерывание сильно загружено. Дабы разгрузить его я пытаюсь часть вычислений вынести в предыдущее не загруженное прерывание. Уже полностью перешёл на указатели, но всё равно шляпа получается.

Проблема в том, что я не могу ввести локальные переменные на два прерывания. Таким образом я ввожу статик. Но тогда во втором прерывании компилятор пытается сохранить значения. А мне это не надо ни капельки. Чтобы этого избежать я ввёл локальные переменные и во втором прерывании выполнил присваивание локальным статик. Код получился значительно компактнее, но всё равно выполняется никому не нужное присваивание. А это 6 указателей!

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

[Rst7]

Лично я в данном моменте (обмен по RSу, например) предпочитаю использовать костыль собственного изобретения примерно такого плана:

Код

#include "setjmp.h"

#define    CONTEXT_SWT_vect SPM_RDY_vect

#pragma vector=CONTEXT_SWT_vect
__interrupt void CNTX_SWT(void);

#define IN_CSWT ACSR_ACIS1

jmp_buf main_task;
jmp_buf rs_task;
char rs_rstack[8];
char rs_cstack[64];

char rxbuf[16];

#pragma vector=USART0_RXC_vect
__interrupt __raw void rs_rx(void)
{
  UCSR0B_RXCIE0=0;
  if (!IN_CSWT)
  {
    IN_CSWT=1;
    __enable_interrupt();
    ((void(*)(void))CNTX_SWT)();
    __disable_interrupt();
    IN_CSWT=0;
  }
}

#pragma vector=USART0_UDRE_vect
__interrupt __raw void rs_tx(void)
{
  UCSR0B_UDRIE0=0;  //Запретили прерывания
  if (!IN_CSWT)
  {
    IN_CSWT=1;
    __enable_interrupt();
    ((void(*)(void))CNTX_SWT)();
    __disable_interrupt();
    IN_CSWT=0;
  }
}

#pragma vector=USART0_TXC_vect
__interrupt __raw void rs_txc(void)
{
  //UCSR0A=1<<TXC0; //Сбросили флаг
  if (!IN_CSWT)
  {
    IN_CSWT=1;
    __enable_interrupt();
    ((void(*)(void))CNTX_SWT)();
    __disable_interrupt();
    IN_CSWT=0;
  }
}

#pragma vector=TIMER1_OVF_vect
__interrupt __raw void rs_timeout(void)
{
  UCSR0B_RXCIE0=0; //Запретили прерывания от приемника
  if (!IN_CSWT)
  {
    IN_CSWT=1;
    __enable_interrupt();
    ((void(*)(void))CNTX_SWT)();
    __disable_interrupt();
    IN_CSWT=0;
  }
}

#pragma vector=CONTEXT_SWT_vect
__interrupt void CNTX_SWT(void)
{
  if (!setjmp(main_task)) //Запомнили контекст осн. задачи
  {
    longjmp(rs_task,1); //Перешли в контекст RS_TRX
  }
}

void wait_int()
{
  if (!setjmp(rs_task)) //Запомнили контекст RS_TASK
  {
    longjmp(main_task,1); //Перешли в контекст осн. задачи
  }
}

char rxbuf[16];

//txsize - количество байт без контрольной суммы
__x char DO_RS(char *out, char txsize, char n_rs, char CRC8RX)
{
  char CRC8;
  char c;
  char rxerr=0;
  UCSR0A=1<<TXC0; //Сбросили флаг от предыдущего прерывания
  CRC8=CRC8tab[c=(*out++)]; //ПУ всегда начинает с нуля
  __disable_interrupt();
  UDR0=c;
  while(PINE_Bit1); //Ждем начала стартового бита
  if (n_rs) EnaTX2; else EnaTX0; //Разрешаем передатчик
  __enable_interrupt();
  while(--txsize)
  {
    CRC8=CRC8tab[CRC8^(UDR0=(*out++))];
    UCSR0B_UDRIE0=1; //Разрешили прерывания от UDRIE
    wait_int(); //Ждем освобождения буфера
  }
  UDR0=CRC8;
  UCSR0B_TXCIE0=1; //Разрешили прерывание от TXC
  wait_int(); //Байт контрольной суммы - последний байт
  UCSR0B_TXCIE0=0; //Запретили прерывания от TXC
  DisTX2; //Выключили каналы передачи
  DisTX0;
  if (n_rs) EnaRX2; else EnaRX0; //Разрешили приемник (пока только на драйвере)
  TCNT1=Time1000;
  TIFR=1<<(TOV1);
  TIMSK_TOIE1=1; //Разрешили прерывание от таймера
  wait_int(); //Ждем 1 мс пока переходные процессы
  UCSR0B_RXEN0=1; //Разрешили приемник
  //txsize здесь равен 0
  CRC8RX=CRC8tab[CRC8RX]; //Нач. значение
  out=rxbuf;
  TCNT1=Time2200; //Время ожидания первого байта
  for(;;)
  {
    UCSR0B_RXCIE0=1; //Разрешили прерывания от приемника
    wait_int();
    if (!UCSR0A_RXC0)
    {
      //Выход по таймауту
      if (CRC8RX) txsize=0; //Не срослась контрольная сумма
      break; //Выходим из цикла
    }
    //Приняли байт
    if (UCSR0A_FE0||UCSR0A_DOR0)
    {
      rxerr=1; //Ошибки
    }
    c=UDR0;
    if (txsize<sizeof(rxbuf))
    {
      CRC8RX=CRC8tab[CRC8RX^(*out=c)]; // Читаем принятый байт в буфер приема и перерасчет CRC
      txsize++;
      out++;
    }
    else
    {
      rxerr=1; //Слишком много байт
      break;
    }
    TCNT1=Time1600;
  }
  UCSR0B_RXEN0=0; //Запретили приемник
  TIMSK_TOIE1=0; //Запретили таймер
  DisRX0;
  DisRX2;
  if (rxerr) txsize=0;
  return(txsize); //Количество принятых байт, если 0 - нет ответа
}


__task __noreturn RS_TRX(void)
{
  struct
  {
    char PPKP;
    char Cmd;
  };
  char abon=0;
  char c;
  char CurRS=0;
  for(;;)
  {
    c=DO_RS(&PPKP,1,CurRS,abon);
    switch(c)
    {
    case 4:
      //Есть событие
      //Записываем событие в стек
      Event2FIFO(abon,rxbuf[1],rxbuf[2],0);
    case 2:
      //Нет события
      //.......
      break;
    default:
      //Ошибка
      //.............
      break;
    }
    if (!(abon=(abon+1)&0x7F))
    {
      CurRS^=1;
    }
  }
}
    
void InitRS(void)
{
  __disable_interrupt();
  DDRE=0xFE;
  PORTE=0xFF;
  UBRR0L=25;
  UCSR0B_TXEN0=1; //Разрешили передатчик
  TCCR1B=2;
  ((unsigned int *)rs_task)[10]=((unsigned int)rs_rstack)+7; //SP
  ((unsigned int *)rs_task)[8]=((unsigned int)rs_cstack)+64; //Y
  ((unsigned int *)rs_task)[9]=(unsigned int)RS_TRX; //Адрес перехода
  if (!setjmp(main_task)) longjmp(rs_task,1); //Переходим в RS_TRX
  __enable_interrupt();
}

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

Вот этот код (как заготовка) кочует из проекта в проект, с минимальными изменениями. Очень удобно.

Теперь хотелось бы услышать от адептов C++, что мне даст применение плюсов в данном месте? Чем мне облегчит жизнь? Положить все переменные в класс? А смысл?

[Непомнящий Евген...]

Теперь хотелось бы услышать от адептов C++, что мне даст применение плюсов в данном месте? Чем мне облегчит жизнь? Положить все переменные в класс? А смысл?

Лично у меня подход примерно следующий: есть класс, назовем его TCanal. У него есть методы типа getByte и onByteRecieve, которые вызываются из прерываний УАРТа. Этот класс реализует логику посылки запроса и получения ответа (или не получения - по таймауту ожидания). Логика обработки принятых байт лежит в производном классе (она своя для каждого протокола), где подключается соответствующий обработчик.

Преимущества: есть совершенно не меняющийся файл canal.h / canal.cpp, общий для всех проектов. Есть также куча не меняющихся файлов canalXXX.h / canalXXX.cpp, которые реализуют логику получения пакета для конкретного протокола.

Далее для конкретного проекта просто создаются объекты нужных классов, пишутся обработчики прерываний (равно 1 строка в каждом) и ВСЕ! Никакой ручной подгонки кода! Любое количество уартов!

То же самое вполне можно писать на чистом C. Примерно так:

Код

typedef struct _TCanalData
{
       ..........
} TCanalData;

byte canal_getByteForSend(TCanalData *pData);
void canal_onByteRecieved(TCanalData *pData, byte dt);

Преимущества C++ при таком подходе - код выглядит красивее.
Кстати, куча функций в WinAPI (чистый C) написаны примерно в таком духе - первым аргументом идет указатель на специфическую структуру данных, а затем - собственно аргументы ф-ции.

[Rst7]

Лично у меня подход примерно следующий: есть класс, назовем его TCanal. У него есть методы типа getByte и onByteRecieve, которые вызываются из прерываний УАРТа. Этот класс реализует логику посылки запроса и получения ответа (или не получения - по таймауту ожидания). Логика обработки принятых байт лежит в производном классе (она своя для каждого протокола), где подключается соответствующий обработчик.

Не понятен мне смысл навешивать классы на код (аналогичный код на приеме)

Код

while(--txsize)
{
   CRC8=CRC8tab[CRC8^(UDR0=(*out++))];
   UCSR0B_UDRIE0=1; //Разрешили прерывания от UDRIE
   wait_int(); //Ждем освобождения буфера
}

Ради чего?

Преимущества C++ при таком подходе - код выглядит красивее.

Т.е. делать обработчики, передавать параметры, указатели и т.д - не важно, это делается через классы или структуры. Непонятна мне такая красота. Куда уж красивее? Цикл и все. В соответствии с идеологией цпп я должен тут обязятельно навесить кучу методов. Но зачем??? Неужели будет красивее и понятнее?

[Непомнящий Евген...]

Вдогонку

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

1. В соответствии с идеологией не цпп, а ООП. Это совершенно разные понятия
2. Нужен баланс - каждый класс должен иметь конкретную, вполне определенную функциональность. Если эта функциональность мизерна - можно удалить класс, перенеся его функциональность в тем места, где он использовался. Если класс имеет очень большую функциональность - хорошо бы его разбить на несколько более мелких. Цель - сделать программу понятнее, ее куски - независимыми от других (по возможности) и повторно используемыми.
Это вполне работает и в чистом С - иметь миллион мелких функций плохо, равно как и иметь несколько гигантских...

[Rst7]

Вдогонку
1. В соответствии с идеологией не цпп, а ООП. Это совершенно разные понятия

Безусловно. Я, конечно, имел в виду ООП. С++ как среду реализации идей ООП.

2. Нужен баланс - каждый класс должен иметь конкретную, вполне определенную функциональность. Если эта функциональность мизерна - можно удалить класс, перенеся его функциональность в тем места, где он использовался. Если класс имеет очень большую функциональность - хорошо бы его разбить на несколько более мелких. Цель - сделать программу понятнее, ее куски - независимыми от других (по возможности) и повторно используемыми.
Это вполне работает и в чистом С - иметь миллион мелких функций плохо, равно как и иметь несколько гигантских...

Программа понятна. Читабельна. Обозрима. Какой плюс мне даст переделка этого кода в соответствии с ООП? Как бы вы порекомендовали разложить это по классам/методам? Какой выигрыш я получу?