Портативная ISR-безопасная передача данных

Один из простых и распространенных способов сделать это — заставить функцию чтения гарантировать, что она не была вытеснена во время чтения. ISR обновляет счетчик при каждом выполнении, а функция чтения гарантирует, что счетчик не изменился во время доступа. Если счетчик изменился, чтение выполняется снова.

typedef struct
{
    int32_t value;
    uint32_t counter;
} sSafeI32_Fore2Back;

void SafeI32_InitFore2Back(volatile sSafeI32_Fore2Back * si)
{
    si->value = 0;
    si->counter = 0;
}

int32_t SafeI32_ReadFromBack(volatile sSafeI32_Fore2Back * si)
{
    int32_t rtn;
    uint32_t ctr;

    do {
        ctr = si->counter;
        rtn = si->value;
    } while(ctr != si->counter);

    return rtn;
}

void SafeI32_WriteFromFore(sSafeI32_Fore2Back * si, int32_t v)
{
    si->value = v;
    si->counter++;
}

Я выполнил обход кода и не смог найти каких-либо явных проблем с реализацией. Я верю, что это будет работать безопасно. Тем не менее, это, вероятно, слишком сложно с использованием двух флагов (занято и чтение_из_А), что немного усложняет просмотр. Важная часть заключается в том, что только фоновая функция записывает в флаги (reading_from_A и Busy), а не передняя функция.

ниже показано возможное упрощение, которое, как мне кажется, также будет безопасно работать. Я использовал аналогичную реализацию на процессоре 8051.

typedef struct
{
    uint8_t pendingData;
    uint8_t index;
    int32_t value[2];
} sSafeI32_Fore2Back;

void SafeI32_InitFore2Back(sSafeI32_Fore2Back * si)
{
    si->pendingData = 0;
    si->index = 0;
    si->value[0] = 0;
    si->value[1] = 0;
}

int32_t SafeI32_ReadFromBack(sSafeI32_Fore2Back * si)
{
    if (si->pendingData) {
        if (si->index == 0) {
            si->index = 1;
        } else {
            si->index = 0;
        }
        si->pendingData = 0;
    }
    return si->value[index];


    // Note 1: you could change the above if;then;else to
    //  index = (index+1) % 2;
    // but this is not an atomic operation and the ISR could
    // fire after the sum and before the modulo 2.
    // Perhaps index would take on an intermediate value of 2 before
    // the modulo and lead to a memory corruption by indexing out of
    // range when the ISR fires.  The ISR could mask the upper bits out
    // to ensure an out of range condition does not occur, but I think
    // the if;then;else is inherently safer.

    // Note 2: You need to assume that the ISR has fired at least once before this
    // function is called. Otherwise the function will return the initialized
    // value of 0. I believe the original post would do the same....

    // Note 3: I believe the original post is correct (at least I didn't find any
    // glaring issue with it.)  The important part is that only the background
    // function writes to the flags (reading_from_A and the busy) and not the
    // foreground function. Likewise, in this implemention, only the background
    // write to index and the forground function only reads it.However, the
// pendingData flag is read and written by both functions. Note that it is
// only written if its in a particular state which is mutually exclusive
}

void SafeI32_WriteFromFore(sSafeI32_Fore2Back * si, int32_t v)
{
    si->value[(si->index + 1) % 2] = v;  // write to the other location than what is
                                         // is being read from.
    if (!si->pendingData) {
        si->pendingData = 1;
    }
}

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

static volatile bool changed = false;
static uint32_t value;

void isr (void) // it is an interrupt; it can't be interrupted by the caller
{
  changed = true;
  value = something;
}

void caller (void)
{
  ...
  changed = false;
  uint32_t val = value;
  if(changed)
  {
    // handle error, discard val
  }
}

Переменная changed даже не должна иметь атомарного доступа.

Обратите внимание, однако, что все переменные, совместно используемые ISR и вызывающей стороной, должны быть volatile, иначе могут возникнуть всевозможные странные и очень тонкие ошибки оптимизации.