Микросекунди материя: намаляване на латентността на прекъсванията в индустриалните системи за управление

Building Apps for Mobile, Gaming, IoT, and more using AWS DynamoDB by Rick Houlihan (Юли 2019).

$config[ads_text] not found
Anonim

Нулевата добавена RTOS латентност при прекъсване

Изпълнението е тема, която никога не се отклонява далеч от съзнанието на повечето разработчици на вградени системи. Въпреки това, относително казано, много от нас имат лесно. Разработваме меки системи в реално време, при които няколко допълнителни микросекунди, или дори милисекунди, на забавяне на реакцията на дадено събитие не са причина за безпокойство.
Има обаче много други разработчици, които не се радват на този лукс. Проектите за промишлен контрол са област на приложение, където изискванията за реално време са много чести. За разработчиците в тази област, особено тези, чиято работа включва контрол на двигателя, микросекундите, които някои от нас приемат за даденост, могат да бъдат от жизненоважно значение.
За да се отговори на кратките срокове за реакция, може да е необходимо инженерите в индустриалния контрол да направят компромиси, които иначе биха изглеждали абсурдни. Някои инженери, които вземат такива решения, имат тенденция да избягват използването на операционна система в реално време (RTOS). Докато в много кръгове RTOS се разглежда като ефективна софтуерна платформа за писане на кодиране на множество задачи, не е необичайно за разработчиците да се откажат от RTOS, поради възприеманите режийни разходи и по-специално въздействието им върху прекъсването на латентността.

Основи на прекъсване на латентността

Защо RTOSes, въпреки техния етикет в реално време, са придобили тази отрицателна репутация сред някои разработчици на вградени системи? За да отговоря на този въпрос, първо трябва първо да прегледаме концепцията за латентност на прекъсванията.
Въпреки че прекъсванията могат да бъдат описани като средство за незабавно реагиране на хардуерни събития, преходът от събитие към изпълнението на кодовото обслужване, това събитие със сигурност не е моментно. Всяка рутинна услуга за прекъсване (ISR) в дадена система има известна степен на закъснение или латентност. Както показва фигура 1, това латентност може да бъде разделено на хардуерни и софтуерни компоненти.

Фигура 1: Хардуер и софтуер, както и латентност при прекъсване на прекъсването.

Латентността на прекъсванията на хардуера обикновено отразява времето, необходимо за операциите, като завършване на текущата изпълняваща инструкция в процесора, намиране на адреса на оператора за прекъсване и записване на всички регистри - операции, които в по-голямата си част са извън програмите, контрол. И, разбира се, това се влияе от архитектурата на процесора. От друга страна, латентността на софтуера се основава на времето на прекъсване на системата и размера на прозореца ISR на системата - кода, който ръчно записва регистрите и изпълнява други операции по почистването преди стартирането на оператора за прекъсване. Най-малко в програмния код разработчиците често могат да ограничават тези количества и по този начин да намалят латентността на прекъсванията на системата до приемливо ниско ниво.
Уравнението се променя малко, ако се използва RTOS. RTOS често ще има свой ISR формат - включително пролог, както и епилог - и може би по-важно ще включва многобройни критични секции от кода, по време на които прекъсванията са забранени. Критичните секции представляват допълнителен източник на латентност при прекъсване за всяка система, която иначе би имала нулево прекъсване на времето за изключване.
Разбира се, за да се улесни приемането на техния софтуер, разработчиците на RTOS се опитват да запазят критичните секции възможно най-кратки и да намалят броя на тези пасажи от код. Това обаче може да е предизвикателна работа, тъй като всяка RTOS променлива или структура от данни, която има потенциал да бъде достъпна в ISR (вероятно чрез API повикване), трябва да бъде защитена с критична секция, за да се избегнат расови условия. Дори в ефективни, добре написани RTOSes, най-дългите критични сектори може да надхвърлят допустимите граници за твърда система за управление в реално време.
Проблемът с латентността при прекъсване оставя разработчиците на такива системи в трудна позиция, тъй като RTOS може да предостави редица предимства. Въпреки всички режийни, които могат да наложат, RTOS е в крайна сметка инструмент за ефективно използване на процесора. Разработчиците, които използват RTOS, имат преносима софтуерна платформа за множество задачи, която може да бъде поддържана и разширена с относителна лекота.

Нулевата добавена RTOS латентност при прекъсване

Има, за щастие, средство за премахване на латентността на прекъсванията, наложена от RTOS, и се оказва доста просто, при условие, че RTOS работи на процесор, оборудван с достатъчно конфигурируем хардуер за прекъсване. Идеята на подхода е, че изключването на всички прекъсвания на системата по време на критични секции на RTOS е ненужно, ако само част от операторите за прекъсване на системата имат потенциала (отново чрез API повиквания) да имат достъп до RTOS променливи. Вместо да се използва глобално прекъсване, деактивиране и активиране, RTOSes като този подход просто обновява приоритет на прекъсване или регистър на ниво в началото и края на критичните сектори, като се предполага, че процесорът, който е в основата си, предлага такъв регистър. Псевдокодът, илюстриращ този подход, е показан по-долу. (Обърнете внимание, че това е сравнително опростено изпълнение, което не поддържа вложени критични секции.)

#define CRITICAL_ENTER () set_int_prio (5)

#define CRITICAL_EXIT () set_int_prio (0)

void RTOS_function (void)

{

CRITICAL_ENTER (); / * Увеличаване на приоритета * /

Достъп до RTOS променливи;

CRITICAL_EXIT (); / * Връщане на приоритет на ниско ниво * /

}

За приоритетните настройки за работа по предназначение, разработчиците на приложения, използващи RTOS, който използва тази техника за критични сектори, трябва да приоритизират своите прекъсвачи съгласно схемата, илюстрирана на фиг.2 . Най-високите приоритети в тази схема съответстват на операторите, които не правят RTOS обаждания и не зависят от RTOS услуги. Тези оператори (понякога известни като ISRs, които не познават ядрото) имат приоритети, превишаващи нивото, свързано с критичните сектори, така че те никога не трябва да се забавят от RTOS.

Фигура 2: Прекъсванията с най-висок приоритет никога не се изключват от RTOS.

Следващите "оператори, които не знаят за ядрото" са ISRs, които са "информирани за ядрото", които могат да се възползват от услугите на RTOS. Прекъсвачният контролер, използван за внедряването на тази схема за приоритизиране, би трябвало да предотврати изпълнението на ISR от "ядрото", което да се изпълнява по време на критични секции. По този начин, латентността на прекъсванията за тези работници ще надхвърли тази на "необяснимите за ядрото" рутинни процедури. Опровержението е, че администраторите с по-нисък приоритет могат да се позовават на API RTOS, например, да сигнализират за една от задачите, които лежат в дъното на йерархията за приоритизиране.

Хардуерна и софтуерна поддръжка

Манипулирането на приоритетите с цел установяване на критични участъци не е възможно с всички хардуери за прекъсване или с всички микроконтролери / процесори. Приоритетните контролери за прекъсване обаче са се превърнали в стандарт за модерните 32-битови модули за управление и много от хардуерните платформи, които понастоящем са избрани за проекти за промишлен контрол, са оборудвани с високо конфигурируеми изпълнения на такива контролери. Това означава, че разработчиците на твърди системи в реално време, които някога са избягвали RTOSes, вече имат възможност да предложат ефикасни възможности за многозадачност на своите проекти. Например, повечето или всички микроконтролери ARM Cortex-M и серията Renesas RX работят добре с тази схема за прекъсване. Необходимите ресурси представляват малко повече от приоритетен контролер за прекъсване с възможност за приспособяване на приоритетните нива в софтуера.
При вземането на решение кои конкретни RTOS да използват за такива възможности, разработчиците трябва да се придържат внимателно. Забавките в обхвата на наносекунди, микросекунди и милисекунди могат да бъдат интерпретирани от доставчиците на RTOS като "ниски", но един потенциален потребител на RTOS, който има изисквания за оперативна скорост, може да има различно виждане.
Два RTOS примера са μC / OS-II на Micrium и μC / OS-III. И двата са с продължителна употреба в индустриалните системи за управление и поддържат формата на критичния раздел, описан в тази статия. Те са две жизнеспособни възможности за разработчиците, които се надяват да донесат мощните многобройни задачи на RTOS, за да се справят с предизвикателствата на трудните системи в реално време в индустриалните дизайни.

От МАТ ГОРДОН, директор инженерни приложения, Micrium, www.Micrium.com