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

Чи існує хороший спосіб здійснення зв’язку між ISR та рештою програми для вбудованої системи, яка дозволяє уникнути глобальних змінних?

Здається, що загальною схемою є глобальна змінна, яка поділяється між ISR та рештою програми та використовується як прапор, але це використання глобальних змінних йде проти мене. Я включив простий приклад з використанням ISRs стилю avr-libc:

volatile uint8_t flag;

int main() {
    ...

    if (flag == 1) {
        ...
    }
    ...
}

ISR(...) {
    ...
    flag = 1;
    ...
}

Я не бачу осторонь того, що є, по суті, питанням обстеження; будь-які змінні, доступні як для МСБ, так і для решти програми, повинні бути, власне, глобальними? Незважаючи на це, я часто бачив, як люди говорять про те, що "глобальні змінні є одним із способів здійснення комунікації між ISR та рештою програми" (наголос мій), який, мабуть, означає, що існують інші методи; якщо є інші методи, які вони?

Існує фактично стандартний спосіб зробити це (якщо припустити програмування на С):

• Переривання / ISR є низькорівневими і тому повинні бути реалізовані лише всередині драйвера, пов'язаного з обладнанням, яке генерує переривання. Вони не повинні розташовуватися ніде, а всередині цього водія.
• Вся комунікація з ISR здійснюється лише водієм та водієм. Якщо інші частини програми потребують доступу до цієї інформації, вона повинна запитувати її у драйвера через функції сеттера / геттера або подібні.
• Не слід оголошувати "глобальні" змінні. Глобальні змінні області файлу із зовнішнім зв'язком. Тобто: змінні, які можна викликати за допомогою externключового слова або просто помилково.
• Натомість, щоб примусити приватне капсулювання всередині драйвера, всі такі змінні, що поділяються між драйвером та ISR, повинні бути оголошені static. Така змінна не є глобальною, але обмежується файлом, де вона оголошена.
• Щоб запобігти проблемам оптимізації компілятора, такі змінні також слід оголосити як volatile. Зауважте: це не дає атомного доступу та не вирішує повторної гарантії!
• У драйвері часто потрібен певний механізм повторного вступу, якщо ISR записує до змінної. Приклади: відключення переривання, глобальна маска переривання, семафор / мютекс або гарантовані атомні зчитування.

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

Це справжня проблема. Закінчуй з цим.

Тепер, перш ніж колінчасті моторошні відразу оскаржують, як це нечисто, дозвольте мені трохи це кваліфікувати. Звичайно, існує небезпека в надмірному використанні глобальних змінних. Але вони також можуть підвищити ефективність, що іноді має значення у невеликих обмежених ресурсах системах.

Головне - подумати про те, коли ви зможете їх розумно використовувати і навряд чи ви потрапите в проблеми, порівняно з помилкою, яка лише чекає, що трапиться. Завжди є компроміси. Хоча взагалі уникати глобальних змінних для спілкування між кодом переривання та переднього плану - це прийнятне керівництво, доведення його, як і більшості інших вказівок, до релігійних крайностей є контрпродуктивним.

Деякі приклади, коли я іноді використовую глобальні змінні для передачі інформації між кодом переривання та переднього плану, є:

1. Лічильники годинникових галочок, якими керує переривання системного годинника. У мене зазвичай відбувається періодичне переривання годинника, яке працює кожні 1 мс. Це часто корисно для різних термінів в системі. Один із способів вивести цю інформацію з програми перерв, де решта системи може її використовувати, - це зберегти глобальний лічильник галочок годинника. Рутинна переривання збільшує лічильник кожного галочки годинника. Код переднього плану може прочитати лічильник у будь-який час. Часто я роблю це протягом 10 мс, 100 мс і навіть 1 секунди кліщів.

   Я переконуюсь, що кліщі 1 мс, 10 мс і 100 мс мають розмір слова, яке можна прочитати за одну атомну операцію. Якщо ви використовуєте мову високого рівня, не забудьте сказати компілятору, що ці змінні можуть змінюватися асинхронно. Наприклад, в C ви оголошуєте їх зовнішніми непостійними . Звичайно, це щось, що входить до складу консервованого файлу, тому вам не потрібно пам’ятати про це для кожного проекту.

   Я іноді роблю лічильник 1 галочок загальним лічильником часу, що минув, тому роблю 32 біта в ширину. Це не можна прочитати в одній атомній операції на багатьох малих мікро, які я використовую, щоб вони не стали глобальними. Натомість передбачено розпорядок роботи, який читає багатослівне значення, розглядає можливі оновлення між прочитаними та повертає результат.

   Звичайно, могли бути підпрограми, щоб отримати менші 1 мс, 10 мс тощо, лічильники галочок. Однак це насправді дуже мало для вас, додає багато інструкцій замість читання одного слова та використовує інше місце стека викликів.

   Який мінус? Я припускаю, що хтось міг зробити помилку, яка випадково записується в один із лічильників, що потім може зіпсувати інші терміни в системі. Навмисно писати до лічильника не було б сенсу, тому такий вид помилок повинен бути чимось ненавмисним, як помилка друку. Здається, це дуже малоймовірно. Я не пам'ятаю, щоб коли-небудь траплялося у понад 100 маленьких мікроконтролерів.

2. Кінцеві відфільтровані та відрегульовані значення A / D. Загальне, що потрібно зробити - це читання рутинного переривання ручки з A / D. Зазвичай я читаю аналогові значення швидше, ніж це потрібно, потім застосовую невелику фільтрацію з низьким проходом. Також часто застосовуються масштабування та компенсація.

   Наприклад, A / D може зчитувати вихід 0 - 3 В дільника напруги для вимірювання напруги 24 В. Багато показань проводяться через деяку фільтрацію, а потім масштабують так, щоб кінцеве значення було в мілівольтах. Якщо джерело живлення становить 24,015 В, то кінцеве значення становить 24015.

   Решта системи просто бачить актуальне оновлене значення із зазначенням напруги живлення. Він не знає і не повинен дбати про те, коли саме це оновлено, тим більше, що він оновлюється набагато частіше, ніж час осідання фільтра низьких частот.

   Знову ж, може бути використаний режим інтерфейсу , але ви отримуєте від цього дуже мало користі. Просто використовувати глобальну змінну, коли вам потрібно напруга живлення набагато простіше. Пам’ятайте, що простота не лише для машини, але й простіша також означає менший шанс помилок людини.

Будь-яке певне переривання буде глобальним ресурсом. Однак іноді може бути корисним, щоб кілька переривань ділили один і той же код. Наприклад, система може мати декілька UART, всі вони повинні використовувати подібну логіку відправлення / отримання.

Приємний підхід до обробки, який полягає в тому, щоб розмістити речі, які використовує обробник переривання або покажчики на них, в об'єкт структури, а потім мати фактичні апаратні засоби обробки переривань як щось подібне:

void UART1_handler(void) { uart_handler(&uart1_info); }
void UART2_handler(void) { uart_handler(&uart2_info); }
void UART3_handler(void) { uart_handler(&uart3_info); }

Об'єкти uart1_info, uart2_infoі т.д. б глобальні змінні, але вони були б тільки глобальні змінні , використовувані обробники переривань. Все інше, що торкнуться обробники, буде оброблятися в межах цих.

Зауважте, що все, до чого отримують доступ і обробник переривання, і код основного рядка, повинні кваліфікуватися volatile. Можливо, найпростіше оголосити як volatileвсе, що взагалі буде використовувати обробник переривання, але якщо важлива продуктивність, можливо, захочеться написати код, який копіює інформацію у тимчасові значення, оперує ними, а потім записує їх назад. Наприклад, замість написання:

if (foo->timer)
  foo->timer--;

написати:

uint32_t was_timer;
was_timer = foo->timer;
if (was_timer)
{
  was_timer--;
  foo->timer = was_timer;
}

Перший підхід може бути простішим для читання та розуміння, але буде менш ефективним, ніж другий. Чи буде це питання, буде залежати від заявки.

Ось три ідеї:

Оголосіть змінну прапора статичною, щоб обмежити область застосування одним файлом.

Зробіть змінну прапора приватною та використовуйте функції getter та setter для доступу до значення прапора.

Використовуйте такий об'єкт сигналізації, як семафор, замість змінної прапора. ISR встановлює / розміщує семафор.

Переривання (тобто вектор, який вказує на ваш обробник) - це глобальний ресурс. Тож навіть якщо ви використовуєте якусь змінну в стеці або на купі:

volatile bool *flag;  // must be initialized before the interrupt is enabled

ISR(...) {
    *flag = true;
}

або об'єктно-орієнтований код з функцією "віртуальний":

HandlerObject *obj;

ISR(...) {
    obj->handler_function(obj);
}

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

Усі ці механізми додають опосередкованість, тому зазвичай цього не робиться, якщо ви хочете вичавити останній цикл з обробника переривання.

Я кодую Cortex M0 / M4 на даний момент, і підхід, який ми використовуємо в C ++ (немає тегів C ++, тому ця відповідь може бути поза темою) наступна:

Ми використовуємо клас, CInterruptVectorTableякий містить усі підпрограми служби переривань, які зберігаються у фактичному векторі переривання контролера:

#pragma location = ".intvec"
extern "C" const intvec_elem __vector_table[] =
{
  { .__ptr = __sfe( "CSTACK" ) },           // 0x00
  __iar_program_start,                      // 0x04

  CInterruptVectorTable::IsrNMI,            // 0x08
  CInterruptVectorTable::IsrHardFault,      // 0x0C
  //[...]
}

Клас CInterruptVectorTableреалізує абстракцію векторів переривання, тому ви можете прив’язати різні функції до векторів переривання під час виконання.

Інтерфейс цього класу виглядає приблизно так:

class CInterruptVectorTable  {
public :
    typedef void (*IsrCallbackfunction_t)(void);                      

    enum InterruptId_t {
        INTERRUPT_ID_NMI,
        INTERRUPT_ID_HARDFAULT,
        //[...]
    };

    typedef struct InterruptVectorTable_t {
        IsrCallbackfunction_t IsrNMI;
        IsrCallbackfunction_t IsrHardFault;
        //[...]
    } InterruptVectorTable_t;

    typedef InterruptVectorTable_t* PinterruptVectorTable_t;


public :
    CInterruptVectorTable(void);
    void SetIsrCallbackfunction(const InterruptId_t& interruptID, const IsrCallbackfunction_t& isrCallbackFunction);

private :

    static void IsrStandard(void);

public :
    static void IsrNMI(void);
    static void IsrHardFault(void);
    //[...]

private :

    volatile InterruptVectorTable_t virtualVectorTable;
    static volatile CInterruptVectorTable* pThis;
};

Вам потрібно зробити функції, які зберігаються у векторній таблиці, staticоскільки контролер не може надати this-показник, оскільки векторна таблиця не є об'єктом. Тож для подолання цієї проблеми у нас є статичний pThis-показник всередині CInterruptVectorTable. Після введення однієї зі статичних функцій переривання, він може отримати доступ до pThis-показника, щоб отримати доступ до членів одного об'єкта CInterruptVectorTable.

Тепер у програмі ви можете використовувати SetIsrCallbackfunctionдля надання вказівника на staticфункцію, яку потрібно викликати, коли відбувається переривання. Покажчики зберігаються в InterruptVectorTable_t virtualVectorTable.

А реалізація функції переривання виглядає приблизно так:

void CInterruptVectorTable::IsrNMI(void) {
    pThis->virtualVectorTable.IsrNMI(); 
}

Отже, викликме staticметод іншого класу (який може бути private), який потім може містити інший static this-показник для отримання доступу до змінних членів цього об'єкта (лише однієї).

Я думаю, ви могли б створити та інтерфейсувати, як IInterruptHandlerі зберігати покажчики на об’єкти, тож вам не потрібен static this-показник у всіх цих класах. (можливо, ми спробуємо це в наступній ітерації нашої архітектури)

Інший підхід для нас працює чудово, оскільки єдиними об'єктами, дозволеним реалізувати обробник переривань, є ті, що знаходяться в шарі апаратної абстракції, і ми зазвичай маємо лише один об'єкт для кожного апаратного блоку, тому добре працювати з static this-інструментами. А апаратний рівень абстракції забезпечує ще одну абстракцію переривань, називається ICallbackяка потім реалізується в шарі пристрою над апаратним забезпеченням.

Ви маєте доступ до глобальних даних? Зрозуміло, що ви робите, але ви можете зробити більшість необхідних глобальних даних приватними, як this-показчики та функції переривання.

Це не куленепробивна, і це додає накладні витрати. Ви будете намагатися реалізувати стек IO-Link, використовуючи такий підхід. Але якщо ви не дуже тісні з часом, це добре працює, щоб отримати гнучку абстракцію переривань і зв’язок в модулях без використання глобальних змінних, доступних звідусіль.