Real-Time Interrupt-driven Concurrency [Коллектив авторов] (fb2) читать онлайн

Real-Time Interrupt-driven Concurrency

Конкурентный фреймворк для создания систем реального времени

Введение

Эта книга содержит документацию пользовательского уровня о фреймворке Real-Time Interrupt-driven Concurrency (RTIC). Справочник по API можно найти здесь.

Также известен как Real-Time For the Masses.

Это документация по RTIC версии v0.6.x; за документацией по другим версиям:

   • v0.5.x сюда.

   • v0.4.x сюда.

Возможности

   • Задачи как единица конкуренции 1. Задачи могут запускаться от событий (срабатывать в ответ на асинхронные воздействия) или вызываться по запросу программы.

   • Передача сообщений между задачами. Если точнее, сообщения можно передавать программным задачам в момент вызова.

   • Очередь таймера 2. Программные задачи можно планировать на запуск в определенный момент в будущем. Эту возможность можно использовать для создания периодических задач.

   • Поддержка приоритета задач, и, как результат, вытесняющей многозадачности.

   • Эффективное, избавленное от гонок данных, разделение ресурсов благодаря легкому разбиению на основанные на приоритетах критические секции 1.

   • Выполнение без Deadlock, гарантируемое на этапе компиляции. Данная гарантия строже, чем та, что предоставляется стандартный абтракцией Mutex.

   • Минимальные расходы на диспетчеризацию. Диспетчер задач иммет минимальную программную базу; основная работа по диспетчеризации происходит аппаратно.

   • Высокоэффективное использование памяти: Все задачи разделяют единый стек вызовов и отсутствует ресурсоемкая зависисмость от динамического аллокатора.

   • Все Cortex-M устройства полностью поддерживаются.

   • К такой модели задач можно применять так называемый анализ WCET (Наихудшего времени выполнения), а также техники анализа диспетчеризации. (Хотя мы еще не разработали дружественный к Rust'у инструментарий для этого.)

   • Приложения должны быть написаны в редакции 2018.

Документация пользователя Справочник по API Чат

Присоединяйтесь к нам, чтобы говорить о RTIC в Matrix-комнате.

Записи еженедельных собраний можно найти в HackMD

Внести вклад

Новые возможности и большие изменения следует проводить через процесс RFC в соответствующем RFC-репозитории.

Благодарности

Этот крейт основан на языке Real-Time For the Masses, созданном Embedded Systems group в Техническом Университете Luleå, под руководством Prof. Per Lindgren.

Ссылки

1

Eriksson, J., Häggström, F., Aittamaa, S., Kruglyak, A., & Lindgren, P. (2013, June). Real-time for the masses, step 1: Programming API and static priority SRP kernel primitives. In Industrial Embedded Systems (SIES), 2013 8th IEEE International Symposium on (pp. 110-113). IEEE.

2

Lindgren, P., Fresk, E., Lindner, M., Lindner, A., Pereira, D., & Pinho, L. M. (2016). Abstract timers and their implementation onto the arm cortex-m family of mcus. ACM SIGBED Review, 13(1), 48-53.

Лицензия

Все исходные тексты (включая примеры кода) лицензированы под одной из лицензий:

   • Apache License, Version 2.0 (LICENSE-APACHE или https://www.apache.org/licenses/LICENSE-2.0)

   • MIT license (LICENSE-MIT или https://opensource.org/licenses/MIT)

на ваш выбор.

Текст книги лицензирован по условиям лицензий Creative Commons CC-BY-SA v4.0 (LICENSE-CC-BY-SA или https://creativecommons.org/licenses/by-sa/4.0/legalcode).

Условия участия

Если вы не укажете этого отдельно, любой вклад, который вы предоставите в эту работу, как указано в тексте лицензии Apache-2.0, будет лицензирован по условиям, указанным выше, без каких-либо дополнительных условий.

RTIC в примерах

В этой части книги фреймворк Real-Time Interrupt-driven Concurrency (RTIC) представляется новым пользователям путем прохода по примерам от простых к более сложным.

Все примеры в этой части книги можно найти в репозитарии проекта. Большинство из них можно пройти, запустив их на эмуляторе QEMU без специального оборудования.

Для запуска примеров на вашем ПК, вам понадобится программа qemu-system-arm. В the embedded Rust book есть инструкции по настройке среды для эмбеддед разработке, в том числе QEMU.

Примеры из реальной жизни

Ниже представлены примеры использования RTIC (RTFM) в реальных проектах.

RTFM V0.4.2

   • etrombly/sandbox. Аппаратный дзэн-сад, рисующий картинки на песке. Картинки передаются по последовательному порту с помощью G-кода.

Атрибут app

Это простейшая из возможных программ на RTIC:

#![allow(unused)]

fn main() {

//! examples/smallest.rs

#![no_main]

#![no_std]

use panic_semihosting as _; // panic handler

use rtic::app;

#[app(device = lm3s6965)]

mod app {

#[shared]

struct Shared {}

#[local]

struct Local {}

#[init]

fn init(_: init::Context) -> (Shared, Local, init::Monotonics) {

(Shared {}, Local {}, init::Monotonics())

}

}

}

Все программы на RTIC используют атрибут app (#[app(..)]). Этот атрибут должен применяться к элементу mod. Атрибут app имеет обязательный аргумент device, который принимает путь как значение. Это должен быть полный путь, указывающий на крейт доступа к периферии (PAC), сгенерированный с помощью svd2rust версии v0.14.x или новее. Более подробно в разделе Создание нового проекта.

Атрибут app будет раскрыт в подходящую точку входа программы, поэтому атрибут cortex_m_rt::entry не нужен.

init

Внутри модуля app атрибут ожидает найти функцию инициализации, помеченную атрибутом init. Эта функция должна иметь сигнатуру fn(init::Context) [-> init::LateResources] (возвращаемый тип нужен не всегда).

Эта функция инициализации будет первой частью программы, выполняемой при запуске. Функция init будет запущена с отключенными прерываниями и будет иметь эксклюзивный доступ к Cortex-M, в котором токен bare_metal::CriticalSection доступен как cs. Опционально, устройство-специфичные периферия доступна через поля core и device структуры init::Context.

static mut переменные, определенные в начале init будут преобразованы в &'static mut ссылки, безопасные для доступа. Обратите внимание, данная возможность может быть удалена в следующем релизе, см. task_local ресурсы.

Пример ниже показывает типы полей core, device и cs, и демонстрирует безопасный доступ к static mut переменной. Поле device доступно только когда аргумент peripherals установлен в true (по умолчанию). В редких случаях, когда вы захотите создать приложение с минимальным потреблением ресурсов, можно явно установить peripherals в false.

#![allow(unused)]

fn main() {

//! examples/init.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use panic_semihosting as _;

#[rtic::app(device = lm3s6965, peripherals = true)]

mod app {

use cortex_m_semihosting::{debug, hprintln};

#[shared]

struct Shared {}

#[local]

struct Local {}

#[init(local = [x: u32 = 0])]

fn init(cx: init::Context) -> (Shared, Local, init::Monotonics) {

// Cortex-M peripherals

let _core: cortex_m::Peripherals = cx.core;

// Device specific peripherals

let _device: lm3s6965::Peripherals = cx.device;

// Locals in `init` have 'static lifetime

let _x: &'static mut u32 = cx.local.x;

// Access to the critical section token,

// to indicate that this is a critical seciton

let _cs_token: bare_metal::CriticalSection = cx.cs;

hprintln!("init").unwrap();

debug::exit(debug::EXIT_SUCCESS);

(Shared {}, Local {}, init::Monotonics())

}

}

}

Запуск примера напечатате init в консоли, а затем завершит процесс QEMU.

$ cargo run --example init

init

idle

Функцию, помеченную атрибутом idle может опционально добавить в модуль. Эта функция используется как специальная задача ожидания и должна иметь сигнатуру fn(idle::Context) - > !.

Если она присутствует, задача idle будет запущена после init. В отличие от init, idle будет запущена с включенными прерываниями и она не может вернуть результат, а значит должна работать вечно.

Если функция idle не определена, среда вполнения устанавливает бит SLEEPONEXIT, а затем отправляет микроконтроллер в сон после запуска init.

Как и в init, static mut переменные будут трансформированы в &'static mut ссылки, безопасные для доступа. Обратите внимание, данная возможность может быть удалена в следующем релизе, см. task_local ресурсы.

Пример ниже показывает, что idle запускается после init.

Примечание: Цикл loop {} в функци ожидания не может быть пустым, так как это сломает микроконтроллер, из-за того, что LLVM компилирует пустые циклы в инструкцию UDF в release mode. Чтобы избежать неопределенного поведения, цикл должен включать "side-effect" путем вставки ассемблерной инструкции (например, WFI) или ключевого слова continue.

#![allow(unused)]

fn main() {

//! examples/idle.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use panic_semihosting as _;

#[rtic::app(device = lm3s6965)]

mod app {

use cortex_m_semihosting::{debug, hprintln};

#[shared]

struct Shared {}

#[local]

struct Local {}

#[init]

fn init(_: init::Context) -> (Shared, Local, init::Monotonics) {

hprintln!("init").unwrap();

(Shared {}, Local {}, init::Monotonics())

}

#[idle(local = [x: u32 = 0])]

fn idle(cx: idle::Context) -> ! {

// Locals in idle have lifetime 'static

let _x: &'static mut u32 = cx.local.x;

hprintln!("idle").unwrap();

debug::exit(debug::EXIT_SUCCESS);

loop {

cortex_m::asm::nop();

}

}

}

}

$ cargo run --example idle

init

idle

Аппаратные задачи

Чтобы объявить обработчик прерывания, фреймворк предоставляет атрибут #[task], который можно применять к функциям. Этот атрибут берет аргумент binds, чье значение - это имя прерывания, которому будет назначен обработчик; функция, декорированная этим атрибутом становится обработчиком прерывания. В фреймворке такие типы задач именуются аппаратными, потому что они начинают выполняться в ответ на аппаратное событие.

Пример ниже демонстрирует использование атрибута #[task], чтобы объявить обработчик прерывания. Как и в случае с #[init] и #[idle] локальные static mut переменные безопасны для использования с аппаратной задачей.

#![allow(unused)]

fn main() {

//! examples/hardware.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use panic_semihosting as _;

#[rtic::app(device = lm3s6965)]

mod app {

use cortex_m_semihosting::{debug, hprintln};

use lm3s6965::Interrupt;

#[shared]

struct Shared {}

#[local]

struct Local {}

#[init]

fn init(_: init::Context) -> (Shared, Local, init::Monotonics) {

// Pends the UART0 interrupt but its handler won't run until *after*

// `init` returns because interrupts are disabled

rtic::pend(Interrupt::UART0); // equivalent to NVIC::pend

hprintln!("init").unwrap();

(Shared {}, Local {}, init::Monotonics())

}

#[idle]

fn idle(_: idle::Context) -> ! {

// interrupts are enabled again; the `UART0` handler runs at this point

hprintln!("idle").unwrap();

rtic::pend(Interrupt::UART0);

debug::exit(debug::EXIT_SUCCESS);

loop {

cortex_m::asm::nop();

}

}

#[task(binds = UART0, local = [times: u32 = 0])]

fn uart0(cx: uart0::Context) {

// Safe access to local `static mut` variable

*cx.local.times += 1;

hprintln!(

"UART0 called {} time{}",

*cx.local.times,

if *cx.local.times > 1 { "s" } else { "" }

)

.unwrap();

}

}

}

$ cargo run --example hardware

init

UART0 called 1 time

idle

UART0 called 2 times

До сих пор все программы на RTIC, которые мы видели, не отличались от программ, которые можно написать, используя лишь крейт cortex-m-rt. С этого момента мы начинаем представлять возможности, уникальные для RTIC.

Приоритеты

Статический приоритет каждого обработчика можно оределить в атрибуте task, используя аргумент priority. Задачи могут иметь приоритет в диапазоне 1..=(1 << NVIC_PRIO_BITS), где NVIC_PRIO_BITS - это константа, определенная в крейте устройства. Когда аргумент priority не указан, предполагается, что приоритет равен 1. Задача idle имеет ненастраиваемый приоритет 0, наименьший из возможных.

Более высокое значение означает более высокий приоритет в RTIC, что противоположно тому, что указано в периферии NVIC Cortex-M. Точнее, это значит, что число 10 обозначает приоритет выше, чем число 9.

Когда несколько задач готовы к запуску, задача с самым большим статическим приоритетом будет запущена первой. Приоритезацию задач можно рассматривать по такому сценарию: сигнал прерывания приходит во время выполнения задачи с низким приоритетом; сигнал переключает задачу с высоким приоритетом в режим ожидания. Разница в приоритетах приводи к тому, что задача с высоким приоритетом вытесняет задачу с низким: выполнение задачи с низким приоритетом замораживается и задача с высоким приоритетом выполняется, пока не будет завершена. Как только задача с высоким приоритетом будет остановлена, продолжится выполнение задачи с низким приоритетом.

Следующий пример демонстрирует диспетчеризацию на основе приоритетов задач.

#![allow(unused)]

fn main() {

//! examples/preempt.rs

#![no_main]

#![no_std]

use panic_semihosting as _;

use rtic::app;

#[app(device = lm3s6965)]

mod app {

use cortex_m_semihosting::{debug, hprintln};

use lm3s6965::Interrupt;

#[shared]

struct Shared {}

#[local]

struct Local {}

#[init]

fn init(_: init::Context) -> (Shared, Local, init::Monotonics) {

rtic::pend(Interrupt::GPIOA);

(Shared {}, Local {}, init::Monotonics())

}

#[task(binds = GPIOA, priority = 1)]

fn gpioa(_: gpioa::Context) {

hprintln!("GPIOA - start").unwrap();

rtic::pend(Interrupt::GPIOC);

hprintln!("GPIOA - end").unwrap();

debug::exit(debug::EXIT_SUCCESS);

}

#[task(binds = GPIOB, priority = 2)]

fn gpiob(_: gpiob::Context) {

hprintln!(" GPIOB").unwrap();

}

#[task(binds = GPIOC, priority = 2)]

fn gpioc(_: gpioc::Context) {

hprintln!(" GPIOC - start").unwrap();

rtic::pend(Interrupt::GPIOB);

hprintln!(" GPIOC - end").unwrap();

}

}

}

$ cargo run --example preempt

GPIOA - start

GPIOC - start

GPIOC - end

GPIOB

GPIOA - end

Заметьте, что задача gpiob не вытесняет задачу gpioc, потому что ее приоритет такой же, как и у gpioc. Однако, как только gpioc возвращает результат, выполненяется задача gpiob, как более приоритетная по сравнению с gpioa. Выполнение gpioa возобновляется только после выхода из gpiob.

Еще одно замечание по поводу приоритетов: выбор приоритета большего, чем поддерживает устройство (а именно 1 << NVIC_PRIO_BITS) приведет к ошибке компиляции. Из-за ограничений языка, сообщение об ошибке далеко от понимания: вам скажут что-то похожее на "evaluation of constant value failed", а указатель на ошибку не покажет на проблемное значение прерывания -- мы извиняемся за это!

Ресурсы

Фреймворк предоставляет абстракцию для разделения данных между любыми контекстами, с которыми мы встречались в предыдущей главе (задачами-обработчиками, init и idle): ресурсы.

Ресурсы - это данные, видимые только функциями, определенными внутри модуля #[app]. Фреймворк дает пользователю полный контроль за тем, какой контекст может получить доступ к какому ресурсу.

Все ресурсы определены в одной структуре внутри модуля #[app]. Каждое поле структуры соответствует отдельному ресурсу. struct-ура должна быть аннотирована следующим атрибутом: #[resources].

Ресурсам могут быть опционально даны начальные значения с помощью атрибута #[init]. Ресурсы, которым не передано начально значение, называются поздними ресурсами, более детально они описаны в одном из разделов на этой странице.

Каждый контекс (задача-обработчик, init или idle) должен указать ресурсы, к которым он намерен обращаться, в соответсятвующем ему атрибуте с метаданными, используя аргумент resources. Этот аргумент принимает список имен ресурсов в качестве значения. Перечисленные ресурсы становятся доступны в контексте через поле resources структуры Context.

Пример программы, показанной ниже содержит два обработчика прерывания, которые разделяют доступ к ресурсу под названием shared.

#![allow(unused)]

fn main() {

//! examples/resource.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use panic_semihosting as _;

#[rtic::app(device = lm3s6965)]

mod app {

use cortex_m_semihosting::{debug, hprintln};

use lm3s6965::Interrupt;

#[shared]

struct Shared {}

#[local]

struct Local {

local_to_uart0: i64,

local_to_uart1: i64,

}

#[init]

fn init(_: init::Context) -> (Shared, Local, init::Monotonics) {

rtic::pend(Interrupt::UART0);

rtic::pend(Interrupt::UART1);

(

Shared {},

// initial values for the `#[local]` resources

Local {

local_to_uart0: 0,

local_to_uart1: 0,

},

init::Monotonics(),

)

}

// `#[local]` resources cannot be accessed from this context

#[idle]

fn idle(_cx: idle::Context) -> ! {

debug::exit(debug::EXIT_SUCCESS);

// error: no `local` field in `idle::Context`

// _cx.local.local_to_uart0 += 1;

// error: no `local` field in `idle::Context`

// _cx.local.local_to_uart1 += 1;

loop {

cortex_m::asm::nop();

}

}

// `local_to_uart0` can only be accessed from this context

// defaults to priority 1

#[task(binds = UART0, local = [local_to_uart0])]

fn uart0(cx: uart0::Context) {

*cx.local.local_to_uart0 += 1;

let local_to_uart0 = cx.local.local_to_uart0;

// error: no `local_to_uart1` field in `uart0::LocalResources`

// cx.local.local_to_uart1 += 1;

hprintln!("UART0: local_to_uart0 = {}", local_to_uart0).unwrap();

}

// `shared` can only be accessed from this context

// explicitly set to priority 2

#[task(binds = UART1, local = [local_to_uart1], priority = 2)]

fn uart1(cx: uart1::Context) {

*cx.local.local_to_uart1 += 1;

let local_to_uart1 = cx.local.local_to_uart1;

// error: no `local_to_uart0` field in `uart1::LocalResources`

// cx.local.local_to_uart0 += 1;

hprintln!("UART1: local_to_uart1 = {}", local_to_uart1).unwrap();

}

}

}

$ cargo run --example resource

UART1: local_to_uart1 = 1

UART0: local_to_uart0 = 1

Заметьте, что к ресурсу shared нельзя получить доступ из idle. Попытка сделать это приведет к ошибке компиляции.

lock

Критические секции необходимы для разделения изменяемых данных таким образом, чтобы избежать гонок данных.

Поле resources, передаваемого Context реализует трейт Mutex для каждого разделяемого ресурса, доступного задаче.

Единственный метод этого трейта, lock, запускает свой аргумент-замыкание в критической секции.

Критическая секция, создаваемая интерфейсом lock основана на динамических приоритетах: она временно повышает динамический приоритет контекста до максимального приоритета, что не дает другим задачам возможности вытеснить критическую секцию. Этот протокол синхронизации известен как Протокол немедленного максимального приоритета (ICPP), и компилируется диспетчером RTIC с Политикой ресурсов стека(SRP).

В примере ниже у нас есть три обработчика прерываний с приоритетами от одного до трех. Два из обработчиков с более низким приоритетом соревнуются за ресурс shared, поэтому должны блокировать доступа к данным ресурса. Обработчик с наивысшим приоритетом, который не имеет доступа к ресурсу shared, может свободно вытеснять критическую секцию, созданную обработчиком с низким приоритетом.

#![allow(unused)]

fn main() {

//! examples/lock.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use panic_semihosting as _;

#[rtic::app(device = lm3s6965)]

mod app {

use cortex_m_semihosting::{debug, hprintln};

use lm3s6965::Interrupt;

#[shared]

struct Shared {

shared: u32,

}

#[local]

struct Local {}

#[init]

fn init(_: init::Context) -> (Shared, Local, init::Monotonics) {

rtic::pend(Interrupt::GPIOA);

(Shared { shared: 0 }, Local {}, init::Monotonics())

}

// when omitted priority is assumed to be `1`

#[task(binds = GPIOA, shared = [shared])]

fn gpioa(mut c: gpioa::Context) {

hprintln!("A").unwrap();

// the lower priority task requires a critical section to access the data

c.shared.shared.lock(|shared| {

// data can only be modified within this critical section (closure)

*shared += 1;

// GPIOB will *not* run right now due to the critical section

rtic::pend(Interrupt::GPIOB);

hprintln!("B - shared = {}", *shared).unwrap();

// GPIOC does not contend for `shared` so it's allowed to run now

rtic::pend(Interrupt::GPIOC);

});

// critical section is over: GPIOB can now start

hprintln!("E").unwrap();

debug::exit(debug::EXIT_SUCCESS);

}

#[task(binds = GPIOB, priority = 2, shared = [shared])]

fn gpiob(mut c: gpiob::Context) {

// the higher priority task does still need a critical section

let shared = c.shared.shared.lock(|shared| {

*shared += 1;

*shared

});

hprintln!("D - shared = {}", shared).unwrap();

}

#[task(binds = GPIOC, priority = 3)]

fn gpioc(_: gpioc::Context) {

hprintln!("C").unwrap();

}

}

}

$ cargo run --example lock

A

B - shared = 1

C

D - shared = 2

E

Множественное блокировка

Это расширение к lock, чтобы уменьшить количесво отступов, блокируемые ресурсы можно объединять в кортежи. Следующий пример это демонстрирует:

#![allow(unused)]

fn main() {

//! examples/mutlilock.rs

//!

//! The multi-lock feature example.

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use panic_semihosting as _;

#[rtic::app(device = lm3s6965)]

mod app {

use cortex_m_semihosting::{debug, hprintln};

use lm3s6965::Interrupt;

#[shared]

struct Shared {

shared1: u32,

shared2: u32,

shared3: u32,

}

#[local]

struct Local {}

#[init]

fn init(_: init::Context) -> (Shared, Local, init::Monotonics) {

rtic::pend(Interrupt::GPIOA);

(

Shared {

shared1: 0,

shared2: 0,

shared3: 0,

},

Local {},

init::Monotonics(),

)

}

// when omitted priority is assumed to be `1`

#[task(binds = GPIOA, shared = [shared1, shared2, shared3])]

fn locks(c: locks::Context) {

let mut s1 = c.shared.shared1;

let mut s2 = c.shared.shared2;

let mut s3 = c.shared.shared3;

hprintln!("Multiple single locks").unwrap();

s1.lock(|s1| {

s2.lock(|s2| {

s3.lock(|s3| {

*s1 += 1;

*s2 += 1;

*s3 += 1;

hprintln!(

"Multiple single locks, s1: {}, s2: {}, s3: {}",

*s1,

*s2,

*s3

)

.unwrap();

})

})

});

hprintln!("Multilock!").unwrap();

(s1, s2, s3).lock(|s1, s2, s3| {

*s1 += 1;

*s2 += 1;

*s3 += 1;

hprintln!(

"Multiple single locks, s1: {}, s2: {}, s3: {}",

*s1,

*s2,

*s3

)

.unwrap();

});

debug::exit(debug::EXIT_SUCCESS);

}

}

}

Поздние ресурсы

Поздние ресурсы - такие ресурсы, которым не передано начальное значение во время компиляции с помощью атрибута #[init], но которые вместо этого инициализируются во время выполнения с помощью значений из структуры init::LateResources, возвращаемой функцией init.

Поздние ресурсы полезны, например, для move (передача владения) периферии, инициализированной в init, в задачи.

Пример ниже использует поздние ресурсы, чтобы установить неблокируемый односторонний канал между обработчиком прерывания UART0 и задачей idle. Для канала использована очередь типа один производитель-один потребитель Queue. Структура очереди разделяется на потребителя и производителя в init, а затем каждая из частей располагается в отдельном ресурсу; UART0 владеет ресурсом производителя, а idle владеет ресурсом потребителя.

#![allow(unused)]

fn main() {

{{#include ../../../../examples/late.rs}}

}

$ cargo run --example late

received message: 42

Только разделяемый доступ

По-умолчанию фреймворк предполагает, что все задачи требуют эксклюзивный доступ (&mut-) к ресурсам, но возможно указать, что задаче достаточен разделяемый доступ (&-) к ресурсы с помощью синтакисиса &resource_name в списке resources.

Преимущество указания разделяемого досупа (&-) к ресурсу в том, что для доступа к ресурсу не нужна блокировка, даже если за ресурс соревнуются несколько задач, запускаемые с разными приоритетами. Недостаток в том, что задача получает только разделяемую ссылку (&-) на ресурс, и ограничена операциями, возможными с ней, но там, где разделяемой ссылки достаточно, такой подход уменьшает количесво требуемых блокировок. В дополнение к простым неизменяемым данным, такой разделяемый доступ может быть полезен для ресурсов, безопасно реализующих внутреннюю мутабельность с самоблокировкой или атомарными операциями.

Заметьте, что в этом релизе RTIC невозможно запросить и эксклюзивный доступ (&mut-) и разделяемый (&-) для одного и того же ресурса из различных задач. Попытка это сделать приведет к ошибке компиляции.

В примере ниже ключ (например криптографический ключ) загружается (или создается) во время выполнения, а затем используется двумя задачами, запускаемымы с различным приоритетом без каких-либо блокировок.

#![allow(unused)]

fn main() {

//! examples/static.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use panic_semihosting as _;

#[rtic::app(device = lm3s6965)]

mod app {

use cortex_m_semihosting::{debug, hprintln};

use lm3s6965::Interrupt;

#[shared]

struct Shared {

key: u32,

}

#[local]

struct Local {}

#[init]

fn init(_: init::Context) -> (Shared, Local, init::Monotonics) {

rtic::pend(Interrupt::UART0);

rtic::pend(Interrupt::UART1);

(Shared { key: 0xdeadbeef }, Local {}, init::Monotonics())

}

#[task(binds = UART0, shared = [&key])]

fn uart0(cx: uart0::Context) {

let key: &u32 = cx.shared.key;

hprintln!("UART0(key = {:#x})", key).unwrap();

debug::exit(debug::EXIT_SUCCESS);

}

#[task(binds = UART1, priority = 2, shared = [&key])]

fn uart1(cx: uart1::Context) {

hprintln!("UART1(key = {:#x})", cx.shared.key).unwrap();

}

}

}

$ cargo run --example only-shared-access

UART1(key = 0xdeadbeef)

UART0(key = 0xdeadbeef)

Неблокируемый доступ к изменяемым ресурсам

Есть две других возможности доступа к ресурсам

   • #[lock_free]: могут быть несколько задач с одинаковым приоритетом, получающие доступ к ресурсу без критических секций. Так как задачи с одинаковым приоритетом никогда не могут вытеснить друг друга, это безопасно.

   • #[task_local]: в этом случае должна быть только одна задача, использующая этот ресурс, так же как локальный static mut ресурс задачи, но (опционально) устанавливаемая с в init.

Программные задачи

В дополнение к аппаратным задачам, вызываемым в ответ на аппаратные события, RTIC также поддерживает программные задачи, которые могут порождаться приложением из любого контекста выполнения.

Программным задачам можно также назначать приоритет и, под капотом, они диспетчеризуются обработчиками прерываний. RTIC требует, чтобы свободные прерывания, были указаны в аргументе dispatchers модуля app, если используются программные задачи; часть из этих свободных прерываний будут использованы для управления программными задачами. Преимущество программных задач над аппаратными в том, что множество задач можно назначить на один обработчик прерывания.

Программные задачи также определяются атрибутом task, но аргумент binds опускается.

Пример ниже демонстрирует три программные задачи, запускаемых 2-х разных приоритетах. Три программные задачи привязаны к 2-м обработчикам прерываний.

#![allow(unused)]

fn main() {

//! examples/task.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use panic_semihosting as _;

#[rtic::app(device = lm3s6965, dispatchers = [SSI0, QEI0])]

mod app {

use cortex_m_semihosting::{debug, hprintln};

#[shared]

struct Shared {}

#[local]

struct Local {}

#[init]

fn init(_: init::Context) -> (Shared, Local, init::Monotonics) {

foo::spawn().unwrap();

(Shared {}, Local {}, init::Monotonics())

}

#[task]

fn foo(_: foo::Context) {

hprintln!("foo - start").unwrap();

// spawns `bar` onto the task scheduler

// `foo` and `bar` have the same priority so `bar` will not run until

// after `foo` terminates

bar::spawn().unwrap();

hprintln!("foo - middle").unwrap();

// spawns `baz` onto the task scheduler

// `baz` has higher priority than `foo` so it immediately preempts `foo`

baz::spawn().unwrap();

hprintln!("foo - end").unwrap();

}

#[task]

fn bar(_: bar::Context) {

hprintln!("bar").unwrap();

debug::exit(debug::EXIT_SUCCESS);

}

#[task(priority = 2)]

fn baz(_: baz::Context) {

hprintln!("baz").unwrap();

}

}

}

$ cargo run --example task

foo - start

foo - middle

baz

foo - end

bar

Передача сообщений

Другое преимущество программной задачи в том, что задачам можно передать сообщения в момент их запуска. Тип передаваемого сообщения должен быть определен в сигнатуре задачи-обработчика.

Пример ниже демонстрирует три задачи, две из которых ожидают сообщение.

#![allow(unused)]

fn main() {

//! examples/message.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use panic_semihosting as _;

#[rtic::app(device = lm3s6965, dispatchers = [SSI0])]

mod app {

use cortex_m_semihosting::{debug, hprintln};

#[shared]

struct Shared {}

#[local]

struct Local {}

#[init]

fn init(_: init::Context) -> (Shared, Local, init::Monotonics) {

foo::spawn(/* no message */).unwrap();

(Shared {}, Local {}, init::Monotonics())

}

#[task(local = [count: u32 = 0])]

fn foo(cx: foo::Context) {

hprintln!("foo").unwrap();

bar::spawn(*cx.local.count).unwrap();

*cx.local.count += 1;

}

#[task]

fn bar(_: bar::Context, x: u32) {

hprintln!("bar({})", x).unwrap();

baz::spawn(x + 1, x + 2).unwrap();

}

#[task]

fn baz(_: baz::Context, x: u32, y: u32) {

hprintln!("baz({}, {})", x, y).unwrap();

if x + y > 4 {

debug::exit(debug::EXIT_SUCCESS);

}

foo::spawn().unwrap();

}

}

}

$ cargo run --example message

foo

bar(0)

baz(1, 2)

foo

bar(1)

baz(2, 3)

Вместимость

RTIC не производит никакого рода аллокаций памяти в куче. Память, необходимая для размещения сообщения резервируется статически. По-умолчанию фреймворк минимизирует выделение памяти программой таким образом, что каждая задача имеет "вместимость" для сообщения равную 1: это значит, что не более одного сообщения можно передать задаче перед тем, как у нее появится возможность к запуску. Это значение по-умолчанию можно изменить для каждой задачи, используя аргумент capacity. Этот аргумент принимает положительное целое, которое определяет как много сообщений буфер сообщений задачи может хранить.

Пример ниже устанавливает вместимость программной задачи foo равной 4. Если вместимость не установить, второй вызов spawn.foo в UART0 приведет к ошибке (панике).

#![allow(unused)]

fn main() {

//! examples/capacity.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use panic_semihosting as _;

#[rtic::app(device = lm3s6965, dispatchers = [SSI0])]

mod app {

use cortex_m_semihosting::{debug, hprintln};

use lm3s6965::Interrupt;

#[shared]

struct Shared {}

#[local]

struct Local {}

#[init]

fn init(_: init::Context) -> (Shared, Local, init::Monotonics) {

rtic::pend(Interrupt::UART0);

(Shared {}, Local {}, init::Monotonics())

}

#[task(binds = UART0)]

fn uart0(_: uart0::Context) {

foo::spawn(0).unwrap();

foo::spawn(1).unwrap();

foo::spawn(2).unwrap();

foo::spawn(3).unwrap();

bar::spawn().unwrap();

}

#[task(capacity = 4)]

fn foo(_: foo::Context, x: u32) {

hprintln!("foo({})", x).unwrap();

}

#[task]

fn bar(_: bar::Context) {

hprintln!("bar").unwrap();

debug::exit(debug::EXIT_SUCCESS);

}

}

}

$ cargo run --example capacity

foo(0)

foo(1)

foo(2)

foo(3)

bar

Обработка ошибок

Интерфейс spawn возвращает вариант Err, если для размещения сообщения нет места. В большинстве сценариев возникающие ошибки обрабатываются одним из двух способов:

   • Паника, с помощью unwrap, expect, и т.п. Этот метод используется, чтобы обнаружить ошибку программиста (например bug) выбора вместительности, которая оказалась недостаточна. Когда эта паника встречается во время тестирования, выбирается большая вместительность, и перекомпиляция программы может решить проблему, но иногда достаточно окунуться глубже и провести анализ времени выполнения программы, чтобы выяснить, может ли платформа обрабатывать пиковые нагрузки, или процессор необходимо заменить на более быстрый.

   • Игнорирование результата. В программах реального времени, как и в обычных, может быть нормальным иногда терять данные, или не получать ответ на некоторые события в пиковых ситуациях. В таких сценариях может быть допустимо игнорирование ошибки вызова spawn.

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

#![allow(unused)]

fn main() {

#[rtic::app(..)]

mod app {

#[init(spawn = [foo, bar])]

fn init(cx: init::Context) {

cx.spawn.foo().unwrap();

cx.spawn.bar().unwrap();

}

#[task(priority = 2, spawn = [bar])]

fn foo(cx: foo::Context) {

// ..

// программа зависнет здесь

while cx.spawn.bar(payload).is_err() {

// повтор попытки вызова spawn, если произошла ошибка

}

}

#[task(priority = 1)]

fn bar(cx: bar::Context, payload: i32) {

// ..

}

}

}

Очередь таймера

В отличие от интерфейса spawn, который немедленно передает программную задачу планировщику для немедленного запуска, интерфейс schedule можно использовать для планирования задачи к запуске через какое-то время в будущем.

Чтобы использовать интерфейс schedule, предварительно должен быть определен монотонный таймер с помощью аргумента monotonic атрибута #[app]. Этот аргумент принимает путь к типу, реализующему трейт Monotonic. Ассоциированный тип, Instant, этого трейта представляет метку времени в соответствущих единицах измерения и широко используется в интерфейсе schedule -- предлагается смоделировать этот тип позднее один из таких есть в стандартной библиотеке.

Хотя это не отражено в определении трейта (из-за ограничений системы типов / трейтов), разница двух Instantов должна возвращать какой-то тип Duration (см. core::time::Duration) и этот Duration должен реализовывать трейт TryInto<u32>. Реализация этого трейта должна конвертировать значение Duration, которое использует какую-то определенную единицу измерения времени, в единицы измерения "тактов системного таймера (SYST)". Результат преобразований должен быть 32-битным целым. Если результат не соответствует 32-битному целому, тогда операция должна возвращать ошибку любого типа.

Для целевых платформ ARMv7+ крейт rtic предоставляет реализацию Monotonic, основанную на встроенном CYCle CouNTer (CYCCNT). Заметьте, что это 32-битный таймер, работающий на частоте центрального процессора, и поэтому не подходит для отслеживания интервалов времени в секундах.

Когда планируется задача, (определенный пользователем) Instant, в который задача должна быть выполнена, должен передаваться в качестве первого аргумента вызова schedule.

К тому же, выбранный monotonic таймер, необходимо сконфигурировать и инициализировать в фазе работы #[init]. Заметьте, что также касается случая использования CYCCNT, предоставляемого крейтом cortex-m-rtic.

Пример ниже планирует к выполнению две задачи из init: foo и bar. foo запланирована к запуску через 8 миллионов циклов в будущем. Далее, bar запланировано запустить через 4 миллиона циклов в будущем. Таким образом, bar запустится до foo, так как и запланировано.

DF:YJ: Примеры, использующие интерфейс schedule или абстракцию Instant не будут правильно работать на эмуляторе QEMU, поскольку счетчик циклов Cortex-M функционально не был реализован в qemu-system-arm.

#![allow(unused)]

fn main() {

//! examples/schedule.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use panic_semihosting as _;

// NOTE: does NOT work on QEMU!

#[rtic::app(device = lm3s6965, dispatchers = [SSI0])]

mod app {

use cortex_m_semihosting::hprintln;

use dwt_systick_monotonic::DwtSystick;

use rtic::time::duration::Seconds;

const MONO_HZ: u32 = 8_000_000; // 8 MHz

#[monotonic(binds = SysTick, default = true)]

type MyMono = DwtSystick<MONO_HZ>;

#[shared]

struct Shared {}

#[local]

struct Local {}

#[init]

fn init(cx: init::Context) -> (Shared, Local, init::Monotonics) {

let mut dcb = cx.core.DCB;

let dwt = cx.core.DWT;

let systick = cx.core.SYST;

let mono = DwtSystick::new(&mut dcb, dwt, systick, 8_000_000);

hprintln!("init").ok();

// Schedule `foo` to run 1 second in the future

foo::spawn_after(Seconds(1_u32)).ok();

// Schedule `bar` to run 2 seconds in the future

bar::spawn_after(Seconds(2_u32)).ok();

(Shared {}, Local {}, init::Monotonics(mono))

}

#[task]

fn foo(_: foo::Context) {

hprintln!("foo").ok();

}

#[task]

fn bar(_: bar::Context) {

hprintln!("bar").ok();

}

}

}

Запусе программы на реальном оборудовании создает следующий вывод в консоли:

init @ Instant(0)

bar @ Instant(4000236)

foo @ Instant(8000173)

Когда интерфейс schedule используется, среда исполнения использует внутри обработчик прерываний SysTick и периферию системного таймера (SYST), поэтому ни тот ни другой нельзя использовать в программе. Это гарантируется изменением типа init::Context.core с cortex_m::Peripherals на rtic::Peripherals. Последняя структура содержит все поля из предыдущей кроме SYST.

Периодические задачи

Программные задачи имеют доступ к моменту времени Instant, в который они были запланированы на выполнение переменной scheduled. Эта информация и интерфейс schedule можно использовать, чтобы реализовать периодические задачи, как показано ниже.

#![allow(unused)]

fn main() {

//!examples/periodic.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use panic_semihosting as _;

// NOTE: does NOT work on QEMU!

#[rtic::app(device = lm3s6965, dispatchers = [SSI0])]

mod app {

use dwt_systick_monotonic::DwtSystick;

use rtic::time::duration::Seconds;

#[monotonic(binds = SysTick, default = true)]

type MyMono = DwtSystick<8_000_000>; // 8 MHz

#[shared]

struct Shared {}

#[local]

struct Local {}

#[init]

fn init(cx: init::Context) -> (Shared, Local, init::Monotonics) {

let mut dcb = cx.core.DCB;

let dwt = cx.core.DWT;

let systick = cx.core.SYST;

let mono = DwtSystick::new(&mut dcb, dwt, systick, 8_000_000);

foo::spawn_after(Seconds(1_u32)).unwrap();

(Shared {}, Local {}, init::Monotonics(mono))

}

#[task]

fn foo(_cx: foo::Context) {

// Periodic

foo::spawn_after(Seconds(1_u32)).unwrap();

}

}

}

Это вывод, создаваемый примером. Заметьте, что здесь пристствует небольшой дрейф / колебания даже несмотря на то, что schedule.foo была вызвана в конце foo. Использование Instant::now вместо scheduled вызвало бы дрейф / колебания.

foo(scheduled = Instant(8000000), now = Instant(8000196))

foo(scheduled = Instant(16000000), now = Instant(16000196))

foo(scheduled = Instant(24000000), now = Instant(24000196))

Базовое время

Для задач, вызываемых из init мы имеем точную информацию о их scheduled времени. Для аппаратных задач такого времени нет, поскольку они асинхронны по природе. Для аппаратных задач среда исполнения предоставляет время запуска (start), которое отражает время, в которое обработчик прерывания будет запущен.

Заметьте, что start не равно времени прихода события, которое вызывает задачу. В зависимости от приоритета задачи и загрузки системы, время start может сильно отдалиться от времени прихода события.

Какое по вашему мнению будет значение scheduled для программных задач, которые вызываются через spawn вместо планирования? Ответ в том, что вызываемые задачи наследуют базовое время того контекста, который их вызывает. Базовое время аппаратных задач - это их время start, базовое время программных задач - их время scheduled, а базовое время init - время старта системы, или нулевое (Instant::zero()). idle на самом деле не имеет базового времени, но задачи вызываемые из нее, используют Instant::now() в качестве базового.

Пример ниже демонстрирует разные смыслы базового времени.

#![allow(unused)]

fn main() {

{{#include ../../../../examples/baseline.rs}}

}

Запуск программы на реальном оборудовании приведет к следующему выводу в консоли:

init(baseline = Instant(0))

foo(baseline = Instant(0))

UART0(baseline = Instant(904))

foo(baseline = Instant(904))

Типы, Send и Sync

Каждая функция в модуле app принимает структуру Context в качесте первого параметра. Все поля этих структур имеют предсказуемые, неанонимные типы, поэтому вы можете написать обычные функции, принимающие их как аргументы.

Справочник по API определяет как эти типы генерируются на основе входных данных. Вы можете также сгенерировать документацию к вашему крейту программы (cargo doc --bin <name>); в документации вы найдете структуры Context (например init::Context и idle::Context).

Пример ниже показывает различные типы, сгенерированные атрибутом app.

#![allow(unused)]

fn main() {

{{#include ../../../../examples/types.rs}}

}

Send

Send - это маркерный трейт для "типов, которые можно передавать через границы потоков", как это определено в core. В контексте RTIC трейт Send необходим только там, где возможна передача значения между задачами, запускаемыми на разных приоритетах. Это возникает в нескольких случаях: при передаче сообщений, в разделяемых static mut ресурсах и при инициализации поздних ресурсов.

Атрибут app проверит, что Send реализован, где необходимо, поэтому вам не стоит волноваться об этом. В настоящий момент все передаваемые типы в RTIC должны быть Send, но это ограничение возможно будет ослаблено в будущем.

Sync

Аналогично, Sync - маркерный трейт для "типов, на которые можно безопасно разделять между потоками", как это определено в core. В контексте RTIC типаж Sync необходим только там, где возможно для двух или более задач, запускаемых на разных приоритетах получить разделяемую ссылку (&-) на ресурс. Это возникает только (&-) ресурсах с разделяемым доступом.

Атрибут app проверит, что Sync реализован, где необходимо, но важно знать, где ограничение Sync не требуется: в (&-) ресурсах с разделяемым доступом, за которые соперничают задачи с одинаковым приоритетом.

В примере ниже показано, где можно использовать типы, не реализующие Sync.

#![allow(unused)]

fn main() {

//! `examples/not-sync.rs`

// #![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use core::marker::PhantomData;

use panic_semihosting as _;

pub struct NotSync {

_0: PhantomData<*const ()>,

}

unsafe impl Send for NotSync {}

#[rtic::app(device = lm3s6965, dispatchers = [SSI0])]

mod app {

use super::NotSync;

use core::marker::PhantomData;

use cortex_m_semihosting::debug;

#[shared]

struct Shared {

shared: NotSync,

}

#[local]

struct Local {}

#[init]

fn init(_: init::Context) -> (Shared, Local, init::Monotonics) {

debug::exit(debug::EXIT_SUCCESS);

(

Shared {

shared: NotSync { _0: PhantomData },

},

Local {},

init::Monotonics(),

)

}

#[task(shared = [&shared])]

fn foo(c: foo::Context) {

let _: &NotSync = c.shared.shared;

}

#[task(shared = [&shared])]

fn bar(c: bar::Context) {

let _: &NotSync = c.shared.shared;

}

}

}

Создание нового проекта

Теперь, когда Вы изучили основные возможности фреймворка RTIC, Вы можете попробовать его использовать на Вашем оборудовании следуя этим инструкциям.

   1. Создайте экземпляр из шаблона cortex-m-quickstart.

$ # например используя `cargo-generate`

$ cargo generate \

--git https://github.com/rust-embedded/cortex-m-quickstart \

--name app

$ # следуйте остальным инструкциям

   2. Добавьте крейт доступа к периферии (PAC), сгенерированный с помощьюsvd2rust v0.14.x, или крейт отладочной платы, у которой в зависимостях один из таких PAC'ов. Убедитесь, что опция rt крейта включена.

В этом примере я буду использовать крейт устройства lm3s6965. Эта библиотека не имеет Cargo-опции rt; эта опция всегда включена.

Этот крейт устройства предоставляет линковочный скрипт с макетом памяти целевого устройства, поэтому memory.x и build.rs нужно удалить.

$ cargo add lm3s6965 --vers 0.1.3

$ rm memory.x build.rs

   3. Добавьте крейт cortex-m-rtic как зависимость.

$ cargo add cortex-m-rtic --allow-prerelease

   4. Напишите свою RTIC программу.

Здесь я буду использовать пример init из крейта cortex-m-rtic.

Примеры находтся в папке examples, а содержание init.rs показано здесь:

//! examples/init.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use panic_semihosting as _;

#[rtic::app(device = lm3s6965, peripherals = true)]

mod app {

use cortex_m_semihosting::{debug, hprintln};

#[shared]

struct Shared {}

#[local]

struct Local {}

#[init(local = [x: u32 = 0])]

fn init(cx: init::Context) -> (Shared, Local, init::Monotonics) {

// Cortex-M peripherals

let _core: cortex_m::Peripherals = cx.core;

// Device specific peripherals

let _device: lm3s6965::Peripherals = cx.device;

// Locals in `init` have 'static lifetime

let _x: &'static mut u32 = cx.local.x;

// Access to the critical section token,

// to indicate that this is a critical seciton

let _cs_token: bare_metal::CriticalSection = cx.cs;

hprintln!("init").unwrap();

debug::exit(debug::EXIT_SUCCESS);

(Shared {}, Local {}, init::Monotonics())

}

}

Пример init использует устройство lm3s6965. Не забудьте настроить аргумент device в атрибуте макроса app так, чтобы он соответствовал пути к PAC-крейту, если он отличается, а также добавить перифериб и другие аргументы если необходимо. Несмотря на то, что в программе могут использоваться псевдонимы типов, здесь необходимо указать полный путь (из корня крейта). Для многих устройств, есть общий подход в крейтах реализации HAL (с псевдонимом hal) и крейтах поддержки отладочных плат реекспортиорвать PAC как pac, что приводит нас к образцу, аналогичному приведенному ниже:

#![allow(unused)]

fn main() {

use abcd123_hal as hal;

//...

#[rtic::app(device = crate::hal::pac, peripherals = true, monotonic = rtic::cyccnt::CYCCNT)]

mod app { /*...*/ }

}

Пример init также зависит от крейта panic-semihosting:

$ cargo add panic-semihosting

   5. Соберите его, загрузите в микроконтроллер и запустите.

$ # ПРИМЕЧАНИЕ: Я раскомментировал опцию `runner` в `.cargo/config`

$ cargo run

init

Советы и хитрости

Обобщенное программирование (Generics)

Все объекты, предоставляющие ресурысы реализуют трейт rtic::Mutex. Если ресурс не реализует его, можно обернуть его в новый тип rtic::Exclusive, который реализует трейт Mutex. С помощью этого нового типа можно написать обобщенную функцию, которая работает с обобщенным ресурсом и вызывать его из различных задач, чтобы производить однотипные операции над похожим множеством ресурсов. Вот один такой пример:

#![allow(unused)]

fn main() {

//! examples/generics.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use cortex_m_semihosting::hprintln;

use panic_semihosting as _;

use rtic::Mutex;

#[rtic::app(device = lm3s6965)]

mod app {

use cortex_m_semihosting::{debug, hprintln};

use lm3s6965::Interrupt;

#[shared]

struct Shared {

shared: u32,

}

#[local]

struct Local {}

#[init]

fn init(_: init::Context) -> (Shared, Local, init::Monotonics) {

rtic::pend(Interrupt::UART0);

rtic::pend(Interrupt::UART1);

(Shared { shared: 0 }, Local {}, init::Monotonics())

}

#[task(binds = UART0, shared = [shared], local = [state: u32 = 0])]

fn uart0(c: uart0::Context) {

hprintln!("UART0(STATE = {})", *c.local.state).unwrap();

// second argument has type `shared::shared`

super::advance(c.local.state, c.shared.shared);

rtic::pend(Interrupt::UART1);

debug::exit(debug::EXIT_SUCCESS);

}

#[task(binds = UART1, priority = 2, shared = [shared], local = [state: u32 = 0])]

fn uart1(c: uart1::Context) {

hprintln!("UART1(STATE = {})", *c.local.state).unwrap();

// second argument has type `shared::shared`

super::advance(c.local.state, c.shared.shared);

}

}

// the second parameter is generic: it can be any type that implements the `Mutex` trait

fn advance(state: &mut u32, mut shared: impl Mutex<T = u32>) {

*state += 1;

let (old, new) = shared.lock(|shared: &mut u32| {

let old = *shared;

*shared += *state;

(old, *shared)

});

hprintln!("shared: {} -> {}", old, new).unwrap();

}

}

$ cargo run --example generics

UART1(STATE = 0)

shared: 0 -> 1

UART0(STATE = 0)

shared: 1 -> 2

UART1(STATE = 1)

shared: 2 -> 4

Условная компиляция

Вы можете использовать условную компиляцию (#[cfg]) на ресурсах (полях структуры #[resources] struct Resources) и задачах (элементах fn). Эффект использования атрибутов #[cfg] в том, что ресурс/ задача будут не доступны в соответствующих структурах Context если условие не выполняется.

В примере ниже выводится сообщение каждый раз, когда вызывается задача foo, но только если программы скомпилирова с профилем dev.

#![allow(unused)]

fn main() {

{{#include ../../../../examples/cfg.rs}}

}

$ cargo run --example cfg --release

$ cargo run --example cfg

foo has been called 1 time

foo has been called 2 times

Запуск задач из ОЗУ

Главной целью переноса описания программы на RTIC в атрибуты в RTIC v0.4.x была возможность взаимодействия с другими атрибутами. Напримерe, атрибут link_section можно применять к задачам, чтобы разместить их в ОЗУ; это может улучшить производительность в некоторых случаях.

ВАЖНО: Обычно атрибуты link_section, export_name и no_mangle очень мощные, но их легко использовать неправильно. Неверное использование любого из этих атрибутов может вызвать неопределенное поведение; Вам следует всегда предпочитать использование безопасных, высокоуровневых атрибутов вместо них, таких как атрибуты interrupt и exception из cortex-m-rt.

В особых функций, размещаемых в ОЗУ нет безопасной абстракции в cortex-m-rt v0.6.5 но создано RFC для добавления атрибута ramfunc в будущем релизе.

В примере ниже показано как разместить высокоприоритетную задачу bar в ОЗУ.

#![allow(unused)]

fn main() {

//! examples/ramfunc.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use panic_semihosting as _;

#[rtic::app(

device = lm3s6965,

dispatchers = [

UART0,

#[link_section = ".data.UART1"]

UART1

])

]

mod app {

use cortex_m_semihosting::{debug, hprintln};

#[shared]

struct Shared {}

#[local]

struct Local {}

#[init]

fn init(_: init::Context) -> (Shared, Local, init::Monotonics) {

foo::spawn().unwrap();

(Shared {}, Local {}, init::Monotonics())

}

#[inline(never)]

#[task]

fn foo(_: foo::Context) {

hprintln!("foo").unwrap();

debug::exit(debug::EXIT_SUCCESS);

}

// run this task from RAM

#[inline(never)]

#[link_section = ".data.bar"]

#[task(priority = 2)]

fn bar(_: bar::Context) {

foo::spawn().unwrap();

}

}

}

Запуск этой программы создаст ожидаемый вывод.

$ cargo run --example ramfunc

foo

Можно посмотреть на вывод cargo-nm, чтобы убедиться, что bar расположен в ОЗУ (0x2000_0000), тогда как foo расположен во Flash (0x0000_0000).

$ cargo nm --example ramfunc --release | grep ' foo::'

00000162 t ramfunc::foo::h30e7789b08c08e19

$ cargo nm --example ramfunc --release | grep ' bar::'

20000000 t ramfunc::bar::h9d6714fe5a3b0c89

Обходной путь для быстрой передачи сообщений

Передача сообщений всегда вызывает копирование от отправителя в статическую переменную, а затем из статической переменной получателю. Таким образом, при передаче большого буфера, например [u8; 128], передача сообщения вызывает два дорогих вызова memcpy. Чтобы минимизировать накладные расходы на передачу сообщения, можно использовать обходной путь: вместо передачи буфера по значению, можно передавать владеющий указатель на буфер.

Можно использовать глобальный аллокатор, чтобы реализовать данный трюк (alloc::Box, alloc::Rc, и т.п.), либо использовать статически аллоцируемый пул памяти, например heapless::Pool.

Здесь приведен пример использования heapless::Pool для "упаковки" буфера из 128 байт.

#![allow(unused)]

fn main() {

//! examples/pool.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use heapless::{

pool,

pool::singleton::{Box, Pool},

};

use panic_semihosting as _;

use rtic::app;

// Declare a pool of 128-byte memory blocks

pool!(P: [u8; 128]);

#[app(device = lm3s6965, dispatchers = [SSI0, QEI0])]

mod app {

use crate::{Box, Pool};

use cortex_m_semihosting::{debug, hprintln};

use lm3s6965::Interrupt;

// Import the memory pool into scope

use super::P;

#[shared]

struct Shared {}

#[local]

struct Local {}

#[init(local = [memory: [u8; 512] = [0; 512]])]

fn init(cx: init::Context) -> (Shared, Local, init::Monotonics) {

// Increase the capacity of the memory pool by ~4

P::grow(cx.local.memory);

rtic::pend(Interrupt::I2C0);

(Shared {}, Local {}, init::Monotonics())

}

#[task(binds = I2C0, priority = 2)]

fn i2c0(_: i2c0::Context) {

// claim a memory block, initialize it and ..

let x = P::alloc().unwrap().init([0u8; 128]);

// .. send it to the `foo` task

foo::spawn(x).ok().unwrap();

// send another block to the task `bar`

bar::spawn(P::alloc().unwrap().init([0u8; 128]))

.ok()

.unwrap();

}

#[task]

fn foo(_: foo::Context, x: Box<P>) {

hprintln!("foo({:?})", x.as_ptr()).unwrap();

// explicitly return the block to the pool

drop(x);

debug::exit(debug::EXIT_SUCCESS);

}

#[task(priority = 2)]

fn bar(_: bar::Context, x: Box<P>) {

hprintln!("bar({:?})", x.as_ptr()).unwrap();

// this is done automatically so we can omit the call to `drop`

// drop(x);

}

}

}

$ cargo run --example pool

bar(0x2000008c)

foo(0x20000110)

Инспектирование раскрываемого кода

#[rtic::app] - это процедурный макрос, который создает код. Если по какой-то причине вам нужно увидеть код, сгенерированный этим макросом, у вас есть два пути:

Вы можете изучить файл rtic-expansion.rs внутри папки target. Этот файл содержит элемент #[rtic::app] в раскрытом виде (не всю вашу программу!) из последней сборки (с помощью cargo build или cargo check) RTIC программы. Раскрытый код не отформатирован по-умолчанию, но вы можете запустить rustfmt на нем перед тем, как читать.

$ cargo build --example foo

$ rustfmt target/rtic-expansion.rs

$ tail target/rtic-expansion.rs

#[doc = r" Implementation details"]

mod app {

#[doc = r" Always include the device crate which contains the vector table"]

use lm3s6965 as _;

#[no_mangle]

unsafe extern "C" fn main() -> ! {

rtic::export::interrupt::disable();

let mut core: rtic::export::Peripherals = core::mem::transmute(());

core.SCB.scr.modify(|r| r | 1 << 1);

rtic::export::interrupt::enable();

loop {

rtic::export::wfi()

}

}

}

Или, вы можете использовать подкоманду cargo-expand. Она раскроет все макросы, включая атрибут #[rtic::app], и модули в вашем крейте и напечатает вывод в консоль.

$ # создаст такой же вывод, как выше

$ cargo expand --example smallest | tail

Деструктуризация ресурса

Если задача требует нескольких ресурсов, разбиение структуры ресурсов может улучшить читабельность. Вот два примера того, как это можно сделать:

#![allow(unused)]

fn main() {

//! examples/destructure.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use panic_semihosting as _;

#[rtic::app(device = lm3s6965)]

mod app {

use cortex_m_semihosting::hprintln;

use lm3s6965::Interrupt;

#[shared]

struct Shared {

// Some resources to work with

a: u32,

b: u32,

c: u32,

}

#[local]

struct Local {}

#[init]

fn init(_: init::Context) -> (Shared, Local, init::Monotonics) {

rtic::pend(Interrupt::UART0);

rtic::pend(Interrupt::UART1);

(Shared { a: 0, b: 0, c: 0 }, Local {}, init::Monotonics())

}

// Direct destructure

#[task(binds = UART0, shared = [&a, &b, &c])]

fn uart0(cx: uart0::Context) {

let a = cx.shared.a;

let b = cx.shared.b;

let c = cx.shared.c;

hprintln!("UART0: a = {}, b = {}, c = {}", a, b, c).unwrap();

}

// De-structure-ing syntax

#[task(binds = UART1, shared = [&a, &b, &c])]

fn uart1(cx: uart1::Context) {

let uart1::SharedResources { a, b, c } = cx.shared;

hprintln!("UART0: a = {}, b = {}, c = {}", a, b, c).unwrap();

}

}

}

Инструкции по миграции

В этом разделе описывается как мигрировать между различными версиями RTIC. Можно также использовать для сравнения версий.

Миграция с v0.5.x на v0.6.0

Этот раздел описывает как обновиться с версии v0.5.x на v0.6.0 фреймворка RTIC.

Cargo.toml - увеличьте версию

Измените версию cortex-m-rtic на "0.6.0".

mod вместо const

С поддержкой атрибутов над модулями трюк с const APP теперь не нужен.

Измените

#![allow(unused)]

fn main() {

#[rtic::app(/* .. */)]

const APP: () = {

[код здесь]

};

}

на

#![allow(unused)]

fn main() {

#[rtic::app(/* .. */)]

mod app {

[код здесь]

}

}

Так как теперь используется обычный модуль Rust, это значит, что можно использовать обычный пользовательский код в этом модуле. Также жто значит, что use-выражения для ресурсов (и т.п.) могут понадобиться.

Перенос диспетчеров из extern "C" в аргументы app.

Измените

#![allow(unused)]

fn main() {

#[rtic::app(/* .. */)]

const APP: () = {

[код здесь]

// RTIC требует, чтобы неиспользуемые прерывания были задекларированы в блоке extern, когда

// используются программные задачи; эти свободные прерывания будут использованы для управления

// программными задачами.

extern "C" {

fn SSI0();

fn QEI0();

}

};

}

на

#![allow(unused)]

fn main() {

#[rtic::app(/* .. */, dispatchers = [SSI0, QEI0])]

mod app {

[код здесь]

}

}

Это работает и для ОЗУ-функций, см. examples/ramfunc.rs

Init всегда возвращает поздние ресурсы

С целью сделать API более симметричным задача #[init] всегда возвращает поздние ресурсы.

С этого:

#![allow(unused)]

fn main() {

#[rtic::app(device = lm3s6965)]

mod app {

#[init]

fn init(_: init::Context) {

rtic::pend(Interrupt::UART0);

}

// [еще код]

}

}

на это:

#![allow(unused)]

fn main() {

#[rtic::app(device = lm3s6965)]

mod app {

#[init]

fn init(_: init::Context) -> init::LateResources {

rtic::pend(Interrupt::UART0);

init::LateResources {}

}

// [еще код]

}

}

Структура Resources - #[resources]

Ранее ресурсы RTIC должны были располагаться в структуре с именем "Resources":

#![allow(unused)]

fn main() {

struct Resources {

// Ресурсы определены здесь

}

}

В RTIC v0.6.0 структура ресурсов аннотируется также, как и #[task], #[init], #[idle]: атрибутом #[resources]

#![allow(unused)]

fn main() {

#[resources]

struct Resources {

// Ресурсы определены здесь

}

}

На самом деле, имя структуры предоставлено на усмотрение разработчика:

#![allow(unused)]

fn main() {

#[resources]

struct Whateveryouwant {

// Ресурсы определены здесь

}

}

будет работать так же хороршо.

Вызов/планирование откуда угодно

С этой новой возвожностью, старый код, такой как:

#![allow(unused)]

fn main() {

#[task(spawn = [bar])]

fn foo(cx: foo::Context) {

cx.spawn.bar().unwrap();

}

#[task(schedule = [bar])]

fn bar(cx: bar::Context) {

cx.schedule.foo(/* ... */).unwrap();

}

}

Теперь будет выглядеть так:

#![allow(unused)]

fn main() {

#[task]

fn foo(_c: foo::Context) {

bar::spawn().unwrap();

}

#[task]

fn bar(_c: bar::Context) {

foo::schedule(/* ... */).unwrap();

}

}

Заметьте, что атрибуты spawn и schedule больше не нужны.

Симметричные блокировки

Теперь RTIC использует симметричные блокировки, это значит, что метод lock нужно использовать для всех доступов к ресурсам. Поскольку высокоприоритетные задачи имеют эксклюзивный доступ к ресурсу, в старом коде можно было следующее:

#![allow(unused)]

fn main() {

#[task(priority = 2, resources = [r])]

fn foo(cx: foo::Context) {

cx.resources.r = /* ... */;

}

#[task(resources = [r])]

fn bar(cx: bar::Context) {

cx.resources.r.lock(|r| r = /* ... */);

}

}

С симметричными блокировками нужно вызывать lock для обоих задач:

#![allow(unused)]

fn main() {

#[task(priority = 2, resources = [r])]

fn foo(cx: foo::Context) {

cx.resources.r.lock(|r| r = /* ... */);

}

#[task(resources = [r])]

fn bar(cx: bar::Context) {

cx.resources.r.lock(|r| r = /* ... */);

}

}

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

Дополнительно

Внешние задачи

Как программные, так и аппаратные задачи теперь можно определять вне модуля mod app. Ранее это было возможно только путем реализации обертки, вызывающей реализацию задачи.

Смотреть примеры examples/extern_binds.rs и examples/extern_spawn.rs.

Миграция с v0.4.x на v0.5.0

Этот раздел описывает как обновить программы, написанные на RTIC v0.4.x на версию v0.5.0 фреймворка.

Cargo.toml

Во-первых, нужно обновить версию зависимости cortex-m-rtic до "0.5.0". Опцию timer-queue нужно удалить.

[dependencies.cortex-m-rtic]

# изменить это

version = "0.4.3"

# на это

version = "0.5.0"

# и удалить Cargo feature

features = ["timer-queue"]

# ^^^^^^^^^^^^^

Аргумент Context

Все функции внутри элемента #[rtic::app] должны принимать первым аргументом структуру Context. Этот тип Context будет содержать переменные, которые были магически инъецированы в область видимости функции версией v0.4.x фреймворка: resources, spawn, schedule -- эти переменные станут полями структуры Context. Каждая функция элемента #[rtic::app] получит отдельный тип Context.

#![allow(unused)]

fn main() {

#[rtic::app(/* .. */)]

const APP: () = {

// change this

#[task(resources = [x], spawn = [a], schedule = [b])]

fn foo() {

resources.x.lock(|x| /* .. */);

spawn.a(message);

schedule.b(baseline);

}

// into this

#[task(resources = [x], spawn = [a], schedule = [b])]

fn foo(mut cx: foo::Context) {

// ^^^^^^^^^^^^^^^^^^^^

cx.resources.x.lock(|x| /* .. */);

// ^^^

cx.spawn.a(message);

// ^^^

cx.schedule.b(message, baseline);

// ^^^

}

// change this

#[init]

fn init() {

// ..

}

// into this

#[init]

fn init(cx: init::Context) {

// ^^^^^^^^^^^^^^^^^

// ..

}

// ..

};

}

Ресурсы

Синтаксис, используемый, для определения ресурсов был изменен с переменных static mut на структуру Resources.

#![allow(unused)]

fn main() {

#[rtic::app(/* .. */)]

const APP: () = {

// измените это

static mut X: u32 = 0;

static mut Y: u32 = (); // поздний ресурс

// на это

struct Resources {

#[init(0)] // <- начальное значение

X: u32, // ПРИМЕЧАНИЕ: мы предлагаем изменить стиль именования на `snake_case`

Y: u32, // поздний ресурс

}

// ..

};

}

Периферия устройства

Если ваша программа получала доступ к периферии в #[init] через переменну device, вам нужно будет добавить peripherals = true в атрибут #[rtic::app], чтобы и дальше получать доступ к периферии через поле device структуры init::Context.

Измените это:

#![allow(unused)]

fn main() {

#[rtic::app(/* .. */)]

const APP: () = {

#[init]

fn init() {

device.SOME_PERIPHERAL.write(something);

}

// ..

};

}

На это:

#![allow(unused)]

fn main() {

#[rtic::app(/* .. */, peripherals = true)]

// ^^^^^^^^^^^^^^^^^^

const APP: () = {

#[init]

fn init(cx: init::Context) {

// ^^^^^^^^^^^^^^^^^

cx.device.SOME_PERIPHERAL.write(something);

// ^^^

}

// ..

};

}

#[interrupt] и #[exception]

Атрибуты #[interrupt] и #[exception] были удалены. Чтобы определять аппаратные задачи в v0.5.x используте атрибут #[task] с аргументом binds.

Измените это:

#![allow(unused)]

fn main() {

#[rtic::app(/* .. */)]

const APP: () = {

// аппаратные задачи

#[exception]

fn SVCall() { /* .. */ }

#[interrupt]

fn UART0() { /* .. */ }

// программные задачи

#[task]

fn foo() { /* .. */ }

// ..

};

}

На это:

#![allow(unused)]

fn main() {

#[rtic::app(/* .. */)]

const APP: () = {

#[task(binds = SVCall)]

// ^^^^^^^^^^^^^^

fn svcall(cx: svcall::Context) { /* .. */ }

// ^^^^^^ мы предлагаем использовать `snake_case` имя здесь

#[task(binds = UART0)]

// ^^^^^^^^^^^^^

fn uart0(cx: uart0::Context) { /* .. */ }

#[task]

fn foo(cx: foo::Context) { /* .. */ }

// ..

};

}

schedule

Интерфейс schedule больше не требует cargo опции timer-queue, которая была удалена. Чтобы использовать интерфес schedule, нужно сначала определить монотонный тамер, который будет использоваьт среды выполнения, с помощью аргумента monotonic атрибута #[rtic::app]. Чтобы продолжить использовать счетчик циклов (CYCCNT) в качестве монотонного таймера, как было в версии v0.4.x, добавьте аргумент monotonic = rtic::cyccnt::CYCCNT в атрибут #[rtic::app].

Также были добавлены типы Duration и Instant, а трейт U32Ext был перемещен в модуль rtic::cyccnt. Этот модуль доступен только на устройствах ARMv7-M+. Удаление timer-queue также возвращает периферию DWT в структуру периферии ядра, включить ее в работу можно внутри init.

Измените это:

#![allow(unused)]

fn main() {

use rtic::{Duration, Instant, U32Ext};

#[rtic::app(/* .. */)]

const APP: () = {

#[task(schedule = [b])]

fn a() {

// ..

}

};

}

На это:

#![allow(unused)]

fn main() {

use rtic::cyccnt::{Duration, Instant, U32Ext};

// ^^^^^^^^

#[rtic::app(/* .. */, monotonic = rtic::cyccnt::CYCCNT)]

// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

const APP: () = {

#[init]

fn init(cx: init::Context) {

cx.core.DWT.enable_cycle_counter();

// опционально, настройка запуска DWT без подключенного отладчика

cx.core.DCB.enable_trace();

}

#[task(schedule = [b])]

fn a(cx: a::Context) {

// ..

}

};

}

Миграция с RTFM на RTIC

В этом разделе описано, как обновить приложение, написанное на RTFM v0.5.x на RTIC той же версии. Это необходимо из-за переименования фреймворка в соответствии с RFC #33.

Примечание: Между RTFM v0.5.3 и RTIC v0.5.3 нет разниц в коде, это исключительно изменение имен.

Cargo.toml

Во-первых, зависимость cortex-m-rtfm должна быть изменена на cortex-m-rtic.

[dependencies]

# измените это

cortex-m-rtfm = "0.5.3"

# на это

cortex-m-rtic = "0.5.3"

Изменения в коде

Единственное изменение в коде, которое нужно сделать - поменять все ссылки на rtfm, чтобы они указывали на rtic:

#![allow(unused)]

fn main() {

//

// Измените это

//

#[rtfm::app(/* .. */, monotonic = rtfm::cyccnt::CYCCNT)]

const APP: () = {

// ...

};

//

// На это

//

#[rtic::app(/* .. */, monotonic = rtic::cyccnt::CYCCNT)]

const APP: () = {

// ...

};

}

Под капотом

Этот раздел в настоящий момент находится в разработке, он появится снова, когда будет завершен

Этот раздел описывает внутренности фреймворка RTIC на высоком уровне. Низкоуровневые детали, такие как парсинг и генерация кода, выполняемые процедурным макросом (#[app]) объясняться не будут. Внимание будет сосредоточено на анализе спецификации пользователя и структурах данных, используемых на этапе выполнения.

Мы настоятельно рекомендуем вам прочитать раздел о конкуренции в embedonomicon перед тем, как погружаться в материал.

Настройка прерываний

Прерывания - это основа работы программ на RTIC. Правильно настроить приоритеты прерываний и убедиться, что они не изменяются во время выполнения обязательно для безопасной работы программы.

Фреймворк RTIC представляет приоритеты прерываний, как нечто, что должно быть определено на этапе компиляции. Однако, статическая настройка должна быть зашита в соответствующие регистры в процессе инициализации программы. Настройка прерываний происходит до запуска функции init.

Этот пример дает представление о коде, запускаемом фреймворком RTIC:

#![allow(unused)]

fn main() {

#[rtic::app(device = lm3s6965)]

mod app {

#[init]

fn init(c: init::Context) {

// .. пользовательский код ..

}

#[idle]

fn idle(c: idle::Context) -> ! {

// .. пользовательский код ..

}

#[interrupt(binds = UART0, priority = 2)]

fn foo(c: foo::Context) {

// .. пользовательский код ..

}

}

}

Фреймворк генерирует точку входа в программу, которая выглядит примерно так:

// настоящая точку входа в программу

#[no_mangle]

unsafe fn main() -> ! {

// преобразует логические приоритеты в аппаратные / NVIC приоритеты

fn logical2hw(priority: u8) -> u8 {

use lm3s6965::NVIC_PRIO_BITS;

// NVIC кодирует приоритеты верхними битами

// большие значения обозначают меньший приоритет

((1 << NVIC_PRIORITY_BITS) - priority) << (8 - NVIC_PRIO_BITS)

}

cortex_m::interrupt::disable();

let mut core = cortex_m::Peripheral::steal();

core.NVIC.enable(Interrupt::UART0);

// значение, определенное пользователем

let uart0_prio = 2;

// проверка на этапе компиляции, что определенный приоритет входит в поддерживаемый диапазон

let _ = [(); (1 << NVIC_PRIORITY_BITS) - (uart0_prio as usize)];

core.NVIC.set_priority(Interrupt::UART0, logical2hw(uart0_prio));

// вызов пользовательского кода

init(/* .. */);

// ..

cortex_m::interrupt::enable();

// вызов пользовательского кода

idle(/* .. */)

}

Нереентерабельность

В RTIC задачи-обработчики не могут использоваться повторно. Переиспользование задачи-обработчика может сломать правила заимствования Rust и привести к неопределенному поведению. Задача-обработчик теоретически может быть переиспользована одним из двух способов: программно или аппаратно.

Программно

Чтобы переиспользовать задачу-обработчик программно, назначенный ей обработчик прерывания должен быть вызван с помощью FFI (смотрите пример ниже). FFI требует unsafe код, что уменьшает желание конечных пользователей вызывать обработчик прерывания.

#![allow(unused)]

fn main() {

#[rtic::app(device = ..)]

mod app {

#[init]

fn init(c: init::Context) { .. }

#[interrupt(binds = UART0)]

fn foo(c: foo::Context) {

static mut X: u64 = 0;

let x: &mut u64 = X;

// ..

//~ `bar` может вытеснить `foo` в этом месте

// ..

}

#[interrupt(binds = UART1, priority = 2)]

fn bar(c: foo::Context) {

extern "C" {

fn UART0();

}

// этот обработчик прерывания вызовет задачу-обработчик `foo`, что сломает

// ссылку на статическую переменную `X`

unsafe { UART0() }

}

}

}

Фреймворк RTIC должен сгенерировать код обработчика прерывания, который вызывает определенные пользователем задачи-обработчики. Мы аккуратны в том, чтобы обеспечить невозможность вызова этих обработчиков из пользовательского кода.

Пример выше раскрывается в:

#![allow(unused)]

fn main() {

fn foo(c: foo::Context) {

// .. пользовательский код ..

}

fn bar(c: bar::Context) {

// .. пользовательский код ..

}

mod app {

// все в этом блоке невидимо для пользовательского кода

#[no_mangle]

unsafe fn USART0() {

foo(..);

}

#[no_mangle]

unsafe fn USART1() {

bar(..);

}

}

}

Аппаратно

Обработчик прерывания также может быть вызван без программного вмешательства. Это может произойти, если один обработчик будет назначен двум или более прерываниям в векторе прерываний, но синтаксиса для такого рода функциональности в RTIC нет.

Контроль доступа

Одна из основ RTIC - контроль доступа. Контроль того, какая часть программы может получить доступ к какой статической переменной - инструмент обеспечения безопасности памяти.

Статические переменные используются для разделения состояний между обработчиками прерываний, или между обработчиком прерывания и нижним контекстом выполнения, main. В обычном Rust коде трудно обеспечить гранулированный контроль за тем, какие функции могут получать доступ к статическим переменным, поскольку к статическим переменным можно получить доступ из любой функции, находящейся в той же области видимости, в которой они определены. Модули дают частичный контроль над доступом к статическим переменным, но они недостаточно гибкие.

Чтобы добиться полного контроля за тем, что задачи могут получить доступ только к статическим переменным (ресурсам), которые им были указаны в RTIC атрибуте, фреймворк RTIC производит трансформацию структуры кода. Эта трансформация состоит из размещения ресурсов (статических переменных), определенных пользователем внутри модуля, а пользовательского кода вне модуля. Это делает невозможным обращение пользовательского кода к статическим переменным.

Затем доступ к ресурсам предоставляется каждой задаче с помощью структуры Resources, чьи поля соответствуют ресурсам, к которым получает доступ задача. Есть лишь одна такая структура на задачу и структура Resources инициализируется либо уникальной ссылкой (&mut-) на статическую переменную, либо с помощью прокси-ресурса (см. раздел критические секции).

Код ниже - пример разных трансформаций структуры кода, происходящих за сценой:

#![allow(unused)]

fn main() {

#[rtic::app(device = ..)]

mod app {

static mut X: u64: 0;

static mut Y: bool: 0;

#[init(resources = [Y])]

fn init(c: init::Context) {

// .. пользовательский код ..

}

#[interrupt(binds = UART0, resources = [X])]

fn foo(c: foo::Context) {

// .. пользовательский код ..

}

#[interrupt(binds = UART1, resources = [X, Y])]

fn bar(c: bar::Context) {

// .. пользовательский код ..

}

// ..

}

}

Фреймворк создает код, подобный этому:

fn init(c: init::Context) {

// .. пользовательский код ..

}

fn foo(c: foo::Context) {

// .. пользовательский код ..

}

fn bar(c: bar::Context) {

// .. пользовательский код ..

}

// Публичное API

pub mod init {

pub struct Context<'a> {

pub resources: Resources<'a>,

// ..

}

pub struct Resources<'a> {

pub Y: &'a mut bool,

}

}

pub mod foo {

pub struct Context<'a> {

pub resources: Resources<'a>,

// ..

}

pub struct Resources<'a> {

pub X: &'a mut u64,

}

}

pub mod bar {

pub struct Context<'a> {

pub resources: Resources<'a>,

// ..

}

pub struct Resources<'a> {

pub X: &'a mut u64,

pub Y: &'a mut bool,

}

}

/// Детали реализации

mod app {

// все, что внутри этого модуля спрятано от пользовательского кода

static mut X: u64 = 0;

static mut Y: bool = 0;

// настоящая точка входа в программу

unsafe fn main() -> ! {

interrupt::disable();

// ..

// вызов пользовательского кода; передача ссылок на статические переменные

init(init::Context {

resources: init::Resources {

X: &mut X,

},

// ..

});

// ..

interrupt::enable();

// ..

}

// обработчик прерывания,с которым связан `foo`

#[no_mangle]

unsafe fn UART0() {

// вызов пользовательского кода; передача ссылок на статические переменные

foo(foo::Context {

resources: foo::Resources {

X: &mut X,

},

// ..

});

}

// обработчик прерывания,с которым связан `bar`

#[no_mangle]

unsafe fn UART1() {

// вызов пользовательского кода; передача ссылок на статические переменные

bar(bar::Context {

resources: bar::Resources {

X: &mut X,

Y: &mut Y,

},

// ..

});

}

}

Поздние ресурсы

Некоторые ресурсы инициализируются во время выполнения после завершения функции init. Важно то, что ресурсы (статические переменные) полностью инициализируются до того, как задачи смогут запуститься, вот почему они должны быть инициализированы пока прерывания отключены.

Ниже показан пример кода, генерируемого фреймворком для инициализации позних ресурсов.

#![allow(unused)]

fn main() {

#[rtic::app(device = ..)]

mod app {

struct Resources {

x: Thing,

}

#[init]

fn init() -> init::LateResources {

// ..

init::LateResources {

x: Thing::new(..),

}

}

#[task(binds = UART0, resources = [x])]

fn foo(c: foo::Context) {

let x: &mut Thing = c.resources.x;

x.frob();

// ..

}

// ..

}

}

Код, генерируемы фреймворком выглядит примерно так:

fn init(c: init::Context) -> init::LateResources {

// .. пользовательский код ..

}

fn foo(c: foo::Context) {

// .. пользовательский код ..

}

// Public API

pub mod init {

pub struct LateResources {

pub x: Thing,

}

// ..

}

pub mod foo {

pub struct Resources<'a> {

pub x: &'a mut Thing,

}

pub struct Context<'a> {

pub resources: Resources<'a>,

// ..

}

}

/// Детали реализации

mod app {

// неинициализированная статическая переменная

static mut x: MaybeUninit<Thing> = MaybeUninit::uninit();

#[no_mangle]

unsafe fn main() -> ! {

cortex_m::interrupt::disable();

// ..

let late = init(..);

// инициализация поздних ресурсов

x.as_mut_ptr().write(late.x);

cortex_m::interrupt::enable(); //~ compiler fence

// исключения, прерывания и задачи могут вытеснить `main` в этой точке

idle(..)

}

#[no_mangle]

unsafe fn UART0() {

foo(foo::Context {

resources: foo::Resources {

// `x` уже инициализирована к этому моменту

x: &mut *x.as_mut_ptr(),

},

// ..

})

}

}

Важная деталь здесь то, что interrupt::enable ведет себя как like a compiler fence, которое не дает компилятору пореставить запись в X после interrupt::enable. Если бы компилятор мог делать такие перестановки появились бы гонки данных между этой записью и любой операцией foo, взаимодействующей с X.

Архитектурам с более сложным конвейером инструкций нужен барьер памяти (atomic::fence) вместо compiler fence для полной очистки операции записи перед включением прерываний. Архитектура ARM Cortex-M не нуждается в барьере памяти в одноядерном контексте.

Критические секции

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

Критическия секция состоит во временном увеличении динамического приоритета задачи. Пока задача находится в критической секции, все другие задачи, которые могут послать запрос переменной не могут запуститься.

Насколько большим должен быть динамический приориткт, чтобы гарантировать запрет изменений определенного ресурса? Анализ приоритетов отвечает на этот вопрос и будет обсужден в следующем разделе. В этом разделе мы сфокусируемся на реализации критической секции.

Прокси-ресурсы

Для упрощения, давайте взглянем на ресурс, разделяемый двумя задачами, запускаемыми с разными приоритетами. Очевидно, что одна задача может вытеснить другую; чтобы предотвратить гонку данных задача с низким приоритетом должна использовать критическую секцию, когда необходимо изменять разделяемую память. С другой стороны, высокоприоритетная задача может напрямую изменять разделяемую память, поскольку не может быть вытеснена низкоприоритетной задачей. Чтобы заставить использовать критическую секцию на задаче с низким приоритетом, мы предоставляем прокси-ресурсы, в которых мы отдаем уникальную ссылку (&mut-) высокоприоритетной задаче.

Пример ниже показывает разные типы, передаваемые каждой задаче:

#![allow(unused)]

fn main() {

#[rtic::app(device = ..)]

mut app {

struct Resources {

#[init(0)]

x: u64,

}

#[interrupt(binds = UART0, priority = 1, resources = [x])]

fn foo(c: foo::Context) {

// прокси-ресурс

let mut x: resources::x = c.resources.x;

x.lock(|x: &mut u64| {

// критическая секция

*x += 1

});

}

#[interrupt(binds = UART1, priority = 2, resources = [x])]

fn bar(c: bar::Context) {

let mut x: &mut u64 = c.resources.x;

*x += 1;

}

// ..

}

}

Теперь давайте посмотрим. как эти типы создаются фреймворком.

#![allow(unused)]

fn main() {

fn foo(c: foo::Context) {

// .. пользовательский код ..

}

fn bar(c: bar::Context) {

// .. пользовательский код ..

}

pub mod resources {

pub struct x {

// ..

}

}

pub mod foo {

pub struct Resources {

pub x: resources::x,

}

pub struct Context {

pub resources: Resources,

// ..

}

}

pub mod bar {

pub struct Resources<'a> {

pub x: &'a mut u64,

}

pub struct Context {

pub resources: Resources,

// ..

}

}

mod app {

static mut x: u64 = 0;

impl rtic::Mutex for resources::x {

type T = u64;

fn lock<R>(&mut self, f: impl FnOnce(&mut u64) -> R) -> R {

// мы рассмотрим это детально позднее

}

}

#[no_mangle]

unsafe fn UART0() {

foo(foo::Context {

resources: foo::Resources {

x: resources::x::new(/* .. */),

},

// ..

})

}

#[no_mangle]

unsafe fn UART1() {

bar(bar::Context {

resources: bar::Resources {

x: &mut x,

},

// ..

})

}

}

}

lock

Теперь давайте рассмотрим непосредственно критическую секцию. В этом примере мы должны увеличить динамический приоритет минимум до 2, чтобы избежать гонки данных. В архитектуре Cortex-M динамический приоритет можно изменить записью в регистр BASEPRI.

Семантика регистра BASEPRI такова:

   • Запись 0 в BASEPRI отключает его функциональность.

   • Запись ненулевого значения в BASEPRI изменяет уровень приоритета, требуемого для вытеснения прерывания. Однако, это имеет эффект, только когда записываемое значение меньше, чем уровень приоритета текущего контекста выполнения, но обращаем внимание, что более низкий уровень аппаратного приоритета означает более высокий логический приоритет

Таким образом, динамический приоритет в любой момент времени может быть рассчитан как

#![allow(unused)]

fn main() {

dynamic_priority = max(hw2logical(BASEPRI), hw2logical(static_priority))

}

Где static_priority - приоритет, запрограммированный в NVIC для текущего прерывания, или логический 0, когда текущий контекств - это idle.

В этом конкретном примере мы можем реализовать критическую секцию так:

ПРИМЕЧАНИЕ: это упрощенная реализация

#![allow(unused)]

fn main() {

impl rtic::Mutex for resources::x {

type T = u64;

fn lock<R, F>(&mut self, f: F) -> R

where

F: FnOnce(&mut u64) -> R,

{

unsafe {

// начать критическую секцию: увеличить динамический приоритет до `2`

asm!("msr BASEPRI, 192" : : : "memory" : "volatile");

// запустить пользовательский код в критической секции

let r = f(&mut x);

// окончить критическую секцию: восстановить динамический приоритет до статического значения (`1`)

asm!("msr BASEPRI, 0" : : : "memory" : "volatile");

r

}

}

}

}

В данном случае важно указать "memory" в блоке asm!. Это не даст компилятору менять местами операции вокруг него. Это важно, поскольку доступ к переменной x вне критической секции привело бы к гонке данных.

Важно отметить, что сигнатура метода lock препятствет его вложенным вызовам. Это необходимо для безопасности памяти, так как вложенные вызовы привели бы к созданию множественных уникальных ссылок (&mut-) на x, ломая правила заимствования Rust. Смотреть ниже:

#![allow(unused)]

fn main() {

#[interrupt(binds = UART0, priority = 1, resources = [x])]

fn foo(c: foo::Context) {

// resource proxy

let mut res: resources::x = c.resources.x;

res.lock(|x: &mut u64| {

res.lock(|alias: &mut u64| {

//~^ ошибка: `res` уже был заимствован уникально (`&mut-`)

// ..

});

});

}

}

Вложенность

Вложенные вызовы lock на том же ресурсе должны отклоняться компилятором для безопасности памяти, однако вложенные вызовы lock на разных ресурсах - нормальная операция. В этом случае мы хотим убедиться, что вложенные критические секции никогда не приведут к понижению динамического приоритета, так как это плохо, и мы хотим оптимизировать несколько записей в регистр BASEPRI и compiler fences. Чтобы справиться с этим, мы проследим динамический приоритет задачи, с помощью стековой переменной и используем ее, чтобы решить, записывать BASEPRI или нет. На практике, стековая переменная будет соптимизирована компилятором, но все еще будет предоставлять информацию компилятору.

Рассмотрим такую программу:

#![allow(unused)]

fn main() {

#[rtic::app(device = ..)]

mod app {

struct Resources {

#[init(0)]

x: u64,

#[init(0)]

y: u64,

}

#[init]

fn init() {

rtic::pend(Interrupt::UART0);

}

#[interrupt(binds = UART0, priority = 1, resources = [x, y])]

fn foo(c: foo::Context) {

let mut x = c.resources.x;

let mut y = c.resources.y;

y.lock(|y| {

*y += 1;

*x.lock(|x| {

x += 1;

});

*y += 1;

});

// середина

x.lock(|x| {

*x += 1;

y.lock(|y| {

*y += 1;

});

*x += 1;

})

}

#[interrupt(binds = UART1, priority = 2, resources = [x])]

fn bar(c: foo::Context) {

// ..

}

#[interrupt(binds = UART2, priority = 3, resources = [y])]

fn baz(c: foo::Context) {

// ..

}

// ..

}

}

Код, сгенерированный фреймворком, выглядит так:

#![allow(unused)]

fn main() {

// опущено: пользовательский код

pub mod resources {

pub struct x<'a> {

priority: &'a Cell<u8>,

}

impl<'a> x<'a> {

pub unsafe fn new(priority: &'a Cell<u8>) -> Self {

x { priority }

}

pub unsafe fn priority(&self) -> &Cell<u8> {

self.priority

}

}

// repeat for `y`

}

pub mod foo {

pub struct Context {

pub resources: Resources,

// ..

}

pub struct Resources<'a> {

pub x: resources::x<'a>,

pub y: resources::y<'a>,

}

}

mod app {

use cortex_m::register::basepri;

#[no_mangle]

unsafe fn UART1() {

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

const PRIORITY: u8 = 2;

// сделать снимок BASEPRI

let initial = basepri::read();

let priority = Cell::new(PRIORITY);

bar(bar::Context {

resources: bar::Resources::new(&priority),

// ..

});

// вернуть BASEPRI значение из снимка, сделанного ранее

basepri::write(initial); // то же, что и `asm!` блок, виденный ранее

}

// так же для `UART0` / `foo` и `UART2` / `baz`

impl<'a> rtic::Mutex for resources::x<'a> {

type T = u64;

fn lock<R>(&mut self, f: impl FnOnce(&mut u64) -> R) -> R {

unsafe {

// определение максимального приоритет ресурса

const CEILING: u8 = 2;

let current = self.priority().get();

if current < CEILING {

// увеличить динамический приоритет

self.priority().set(CEILING);

basepri::write(logical2hw(CEILING));

let r = f(&mut y);

// восстановить динамический приоритет

basepri::write(logical2hw(current));

self.priority().set(current);

r

} else {

// динамический приоритет достаточно высок

f(&mut y)

}

}

}

}

// повторить для ресурса `y`

}

}

Наконец, компилятор оптимизирует функцию foo во что-то наподобие такого:

#![allow(unused)]

fn main() {

fn foo(c: foo::Context) {

// ПРИМЕЧАНИЕ: BASEPRI содержит значение `0` (значение сброса) в этот момент

// увеличить динамический приоритет до `3`

unsafe { basepri::write(160) }

// две операции над `y` объединены в одну

y += 2;

// BASEPRI не изменяется для доступа к `x`, потому что динамический приоритет достаточно высок

x += 1;

// уменьшить (восстановить) динамический приоритет до `1`

unsafe { basepri::write(224) }

// средина

// увеличить динамический приоритет до `2`

unsafe { basepri::write(192) }

x += 1;

// увеличить динамический приоритет до `3`

unsafe { basepri::write(160) }

y += 1;

// уменьшить (восстановить) динамический приоритет до `2`

unsafe { basepri::write(192) }

// ПРИМЕЧАНИЕ: было вы правильно объединить эту операцию над `x` с предыдущей, но

// compiler fences грубые и предотвращают оптимизацию

x += 1;

// уменьшить (восстановить) динамический приоритет до `1`

unsafe { basepri::write(224) }

// ПРИМЕЧАНИЕ: BASEPRI содержит значение `224` в этот момент

// обработчик UART0 восстановит значение `0` перед завершением

}

}

Инвариант BASEPRI

Инвариант, который фреймворк RTIC должен сохранять в том, что значение BASEPRI в начале обработчика прерывания должно быть таким же, как и при выходе из него. BASEPRI может изменяться в процессе выполнения обработчика прерывания, но но выполнения обработчика прерывания в начале и конце не должно вызвать наблюдаемого изменения BASEPRI.

Этот инвариант нужен, чтобы избежать уеличения динамического приоритета до значений, при которых обработчик не сможет быть вытеснен. Лучше всего это видно на следующем примере:

#![allow(unused)]

fn main() {

#[rtic::app(device = ..)]

mod app {

struct Resources {

#[init(0)]

x: u64,

}

#[init]

fn init() {

// `foo` запустится сразу после завершения `init`

rtic::pend(Interrupt::UART0);

}

#[task(binds = UART0, priority = 1)]

fn foo() {

// BASEPRI равен `0` в этот момент; динамический приоритет равен `1`

// `bar` вытеснит `foo` в этот момент

rtic::pend(Interrupt::UART1);

// BASEPRI равен `192` в этот момент (из-за бага); динамический приоритет равен `2`

// эта функция возвращается в `idle`

}

#[task(binds = UART1, priority = 2, resources = [x])]

fn bar() {

// BASEPRI равен `0` (динамический приоритет = 2)

x.lock(|x| {

// BASEPRI увеличен до `160` (динамический приоритет = 3)

// ..

});

// BASEPRI восстановлен до `192` (динамический приоритет = 2)

}

#[idle]

fn idle() -> ! {

// BASEPRI равен `192` (из-за бага); динамический приоритет = 2

// это не оказывает эффекта, из-за значени BASEPRI

// задача `foo` не будет выполнена снова никогда

rtic::pend(Interrupt::UART0);

loop {

// ..

}

}

#[task(binds = UART2, priority = 3, resources = [x])]

fn baz() {

// ..

}

}

}

ВАЖНО: давайте например мы забудем восстановить BASEPRI в UART1 -- из-за какого нибудь бага в генераторе кода RTIC.

#![allow(unused)]

fn main() {

// код, сгенерированный RTIC

mod app {

// ..

#[no_mangle]

unsafe fn UART1() {

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

const PRIORITY: u8 = 2;

// сделать снимок BASEPRI

let initial = basepri::read();

let priority = Cell::new(PRIORITY);

bar(bar::Context {

resources: bar::Resources::new(&priority),

// ..

});

// БАГ: ЗАБЫЛИ восстановить BASEPRI на значение из снимка

basepri::write(initial);

}

}

}

В результате, idle запустится на динамическом приоритете 2 и на самом деле система больше никогда не перейдет на динамический приоритет ниже 2. Это не компромис для безопасности памяти программы, а влияет на диспетчеризацию задач: в этом конкретном случае задачи с приоритетом 1 никогда не получат шанс на запуск.

Анализ приоритетов

Поиск максимального приоритета ресурса (ceiling) - поиск динамического приоритета, который любая задача должна иметь, чтобы безопасно работать с памятью ресурсов. Анализ приоритетов - относительно прост, но критичен для безопасности памяти RTIC программ.

Для расчета максимального приоритета ресурса мы должны сначала составить список задач, имеющих доступ к ресурсу -- так как фреймворк RTIC форсирует контроль доступа к ресурсам на этапе компиляции, он также имеет доступ к этой информации на этапе компиляции. Максимальный приоритет ресурса - просто наивысший логический приоритет среди этих задач.

init и idle не настоящие задачи, но у них есть доступ к ресурсам, поэтому они должны учитываться при анализе приоритетов. idle учитывается как задача, имеющая логический приоритет 0, в то время как init полностью исключается из анализа -- причина этому в том, что init никогда не использует (не нуждается) критические секции для доступа к статическим переменным.

В предыдущем разделе мы показывали, что разделяемые ресусы могут быть представлены уникальными ссылками (&mut-) или скрываться за прокси в зависимости от того, имеет ли задача к ним доступ. Какой из вариантов представляется задаче зависит от приоритета задачи и максимального приоритета ресурса. Если приоритет задачи такой же, как максимальный приоритет ресурса, тогда задача получает уникальную ссылку (&mut-) на память ресурса, в противном случае задача получает прокси -- это также касается idle. init особеннвй: он всегда получает уникальные ссылки (&mut-) на ресурсы.

Пример для иллюстрации анализа приоритетов:

#![allow(unused)]

fn main() {

#[rtic::app(device = ..)]

mod app {

struct Resources {

// доступен из `foo` (prio = 1) и `bar` (prio = 2)

// -> CEILING = 2

#[init(0)]

x: u64,

// доступен из `idle` (prio = 0)

// -> CEILING = 0

#[init(0)]

y: u64,

}

#[init(resources = [x])]

fn init(c: init::Context) {

// уникальная ссылка, потому что это `init`

let x: &mut u64 = c.resources.x;

// уникальная ссылка, потому что это `init`

let y: &mut u64 = c.resources.y;

// ..

}

// PRIORITY = 0

#[idle(resources = [y])]

fn idle(c: idle::Context) -> ! {

// уникальная ссылка, потому что

// приоритет (0) == максимальному приоритету ресурса (0)

let y: &'static mut u64 = c.resources.y;

loop {

// ..

}

}

#[interrupt(binds = UART0, priority = 1, resources = [x])]

fn foo(c: foo::Context) {

// прокси-ресурс, потому что

// приоритет задач (1) < максимальному приоритету ресурса (2)

let x: resources::x = c.resources.x;

// ..

}

#[interrupt(binds = UART1, priority = 2, resources = [x])]

fn bar(c: foo::Context) {

// уникальная ссылка, потому что

// приоритет задачи (2) == максимальному приоритету ресурса (2)

let x: &mut u64 = c.resources.x;

// ..

}

// ..

}

}

Программные задачи

RTIC поддерживает программные и аппаратные задачи. Каждая аппаратная задача назначается на отдельный обработчик прерывания. С другой стороны, несколько программных задач могут управляться одним обработчиком прерывания -- это сделано, чтобы минимизировать количество обработчиков прерывания, используемых фреймворком.

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

Каждый диспетчер задач хранит очередь задач, готовых к выполнению; эта очередь называется очередью готовности. Вызов программной задачи состоит из добавления записи в очередь и вызова прерывания, который запускает соответствующий диспетчер задач. Каждая запись в эту очередь содержит метку (enum), которая идентифицирует задачу, которую необходимо выполнить и указатель на сообщение, передаваемое задаче.

Очередь готовности - неблокируемая очередь типа SPSC (один производитель - один потребитель). Диспетчер задач владеет конечным потребителем в очереди; конечным производителем считается ресурс, за который соперничают задачи, которые могут вызывать (spawn) другие задачи.

Дисметчер задач

Давайте сначала глянем на код, генерируемый фреймворком для диспетчеризации задач. Рассмотрим пример:

#![allow(unused)]

fn main() {

#[rtic::app(device = ..)]

mod app {

// ..

#[interrupt(binds = UART0, priority = 2, spawn = [bar, baz])]

fn foo(c: foo::Context) {

foo.spawn.bar().ok();

foo.spawn.baz(42).ok();

}

#[task(capacity = 2, priority = 1)]

fn bar(c: bar::Context) {

// ..

}

#[task(capacity = 2, priority = 1, resources = [X])]

fn baz(c: baz::Context, input: i32) {

// ..

}

extern "C" {

fn UART1();

}

}

}

Фреймворк создает следующий диспетчер задач, состоящий из обработчика прерывания и очереди готовности:

#![allow(unused)]

fn main() {

fn bar(c: bar::Context) {

// .. пользовательский код ..

}

mod app {

use heapless::spsc::Queue;

use cortex_m::register::basepri;

struct Ready<T> {

task: T,

// ..

}

/// вызываемые (`spawn`) задачи, выполняющиеся с уровнем приоритета `1`

enum T1 {

bar,

baz,

}

// очередь готовности диспетчера задач

// `U4` - целое число, представляющее собой емкость этой очереди

static mut RQ1: Queue<Ready<T1>, U4> = Queue::new();

// обработчик прерывания, выбранный для диспетчеризации задач с приоритетом `1`

#[no_mangle]

unsafe UART1() {

// приоритет данного обработчика прерывания

const PRIORITY: u8 = 1;

let snapshot = basepri::read();

while let Some(ready) = RQ1.split().1.dequeue() {

match ready.task {

T1::bar => {

// **ПРИМЕЧАНИЕ** упрощенная реализация

// используется для отслеживания динамического приоритета

let priority = Cell::new(PRIORITY);

// вызов пользовательского кода

bar(bar::Context::new(&priority));

}

T1::baz => {

// рассмотрим `baz` позднее

}

}

}

// инвариант BASEPRI

basepri::write(snapshot);

}

}

}

Вызов задачи

Интерфейс spawn предоставлен пользователю как методы структурв Spawn. Для каждой задачи существует своя структура Spawn.

Код Spawn, генерируемый фреймворком для предыдущего примера выглядит так:

#![allow(unused)]

fn main() {

mod foo {

// ..

pub struct Context<'a> {

pub spawn: Spawn<'a>,

// ..

}

pub struct Spawn<'a> {

// отслеживает динамический приоритет задачи

priority: &'a Cell<u8>,

}

impl<'a> Spawn<'a> {

// `unsafe` и спрятано, поскольку сы не хотит, чтобы пользователь вмешивался сюда

#[doc(hidden)]

pub unsafe fn priority(&self) -> &Cell<u8> {

self.priority

}

}

}

mod app {

// ..

// Поиск максимального приоритета для конечного производителя `RQ1`

const RQ1_CEILING: u8 = 2;

// используется, чтобы отследить сколько еще сообщений для `bar` можно поставить в очередь

// `U2` - емкость задачи `bar`; максимум 2 экземпляра можно добавить в очередь

// эта очередь заполняется фреймворком до того, как запустится `init`

static mut bar_FQ: Queue<(), U2> = Queue::new();

// Поиск максимального приоритета для конечного потребителя `bar_FQ`

const bar_FQ_CEILING: u8 = 2;

// приоритет-ориентированная критическая секция

//

// это запускае переданное замыкание `f` с динамическим приоритетом не ниже

// `ceiling`

fn lock(priority: &Cell<u8>, ceiling: u8, f: impl FnOnce()) {

// ..

}

impl<'a> foo::Spawn<'a> {

/// Вызывает задачу `bar`

pub fn bar(&self) -> Result<(), ()> {

unsafe {

match lock(self.priority(), bar_FQ_CEILING, || {

bar_FQ.split().1.dequeue()

}) {

Some(()) => {

lock(self.priority(), RQ1_CEILING, || {

// помещаем задачу в очередь готовности

RQ1.split().1.enqueue_unchecked(Ready {

task: T1::bar,

// ..

})

});

// вызываем прерывание, которое запускает диспетчер задач

rtic::pend(Interrupt::UART0);

}

None => {

// достигнута максимальная вместительность; неудачный вызов

Err(())

}

}

}

}

}

}

}

Использование bar_FQ для ограничения числа задач bar, которые могут бы вызваны, может показаться искусственным, но это будет иметь больше смысла, когда мы поговорим о вместительности задач.

Сообщения

Мы пропустили, как на самом деле работает передача сообщений, поэтому давайте вернемся к реализации spawn, но в этот раз для задачи baz, которая принимает сообщение типа u64.

#![allow(unused)]

fn main() {

fn baz(c: baz::Context, input: u64) {

// .. пользовательский код ..

}

mod app {

// ..

// Теперь мы покажем все содержимое структуры `Ready`

struct Ready {

task: Task,

// индекс сообщения; используется с буфером `INPUTS`

index: u8,

}

// память, зарезервированная для хранения сообщений, переданных `baz`

static mut baz_INPUTS: [MaybeUninit<u64>; 2] =

[MaybeUninit::uninit(), MaybeUninit::uninit()];

// список свободной памяти: используется для отслеживания свободных ячеек в массиве `baz_INPUTS`

// эта очередь инициализируется значениями `0` и `1` перед запуском `init`

static mut baz_FQ: Queue<u8, U2> = Queue::new();

// Поиск максимального приоритета для конечного потребителя `baz_FQ`

const baz_FQ_CEILING: u8 = 2;

impl<'a> foo::Spawn<'a> {

/// Spawns the `baz` task

pub fn baz(&self, message: u64) -> Result<(), u64> {

unsafe {

match lock(self.priority(), baz_FQ_CEILING, || {

baz_FQ.split().1.dequeue()

}) {

Some(index) => {

// ПРИМЕЧАНИЕ: `index` - владеющий указатель на ячейку буфера

baz_INPUTS[index as usize].write(message);

lock(self.priority(), RQ1_CEILING, || {

// помещаем задачу в очередь готовности

RQ1.split().1.enqueue_unchecked(Ready {

task: T1::baz,

index,

});

});

// вызываем прерывание, которое запускает диспетчер задач

rtic::pend(Interrupt::UART0);

}

None => {

// достигнута максимальная вместительность; неудачный вызов

Err(message)

}

}

}

}

}

}

}

А теперь давайте взглянем на настоящую реализацию диспетчера задач:

#![allow(unused)]

fn main() {

mod app {

// ..

#[no_mangle]

unsafe UART1() {

const PRIORITY: u8 = 1;

let snapshot = basepri::read();

while let Some(ready) = RQ1.split().1.dequeue() {

match ready.task {

Task::baz => {

// ПРИМЕЧАНИЕ: `index` - владеющий указатель на ячейку буфера

let input = baz_INPUTS[ready.index as usize].read();

// сообщение было прочитано, поэтому можно вернуть ячейку обратно

// чтобы освободить очередь

// (диспетчер задач имеет эксклюзивный доступ к

// последнему элементу очереди)

baz_FQ.split().0.enqueue_unchecked(ready.index);

let priority = Cell::new(PRIORITY);

baz(baz::Context::new(&priority), input)

}

Task::bar => {

// выглядит также как ветка для `baz`

}

}

}

// инвариант BASEPRI

basepri::write(snapshot);

}

}

}

INPUTS плюс FQ, список свободной памяти равняется эффективному пулу памяти. Однако, вместо того список свободной памяти (связный список), чтобы отслеживать пустые ячейки в буфере INPUTS, мы используем SPSC очередь; это позволяет нам уменьшить количество критических секций. На самом деле благодаря этому выбору код диспетчера задач неблокируемый.

Вместительность очереди

Фреймворк RTIC использует несколько очередей, такие как очереди готовности и списки свободной памяти. Когда список свободной памяти пуст, попытка выызова (spawn) задачи приводит к ошибке; это условие проверяется во время выполнения. Не все операции, произвожимые фреймворком с этими очередями проверяют их пустоту / наличие места. Например, возвращение ячейки списка свободной памяти (см. диспетчер задач) не проверяется, поскольку есть фиксированное количество таких ячеек циркулирующих в системе, равное вместительности списка свободной памяти. Аналогично, добавление записи в очередь готовности (см. Spawn) не проверяется, потому что вместительность очереди выбрана фреймворком.

Пользователи могут задавать вместительность программных задач; эта вместительность - максимальное количество сообщений, которые можно послать указанной задаче от задачи более высоким приоритетом до того, как spawn вернет ошибку. Эта определяемая пользователем иместительность - размер списка свободной памяти задачи (например foo_FQ), а также размер массива, содержащего входные данные для задачи (например foo_INPUTS).

Вместительность очереди готовности (например RQ1) вычисляется как сумма вместительностей всех задач, управляемх диспетчером; эта сумма является также количеством сообщений, которые очередь может хранить в худшем сценарии, когда все возможные сообщения были посланы до того, как диспетчер задач получает шанс на запуск. По этой причине получение ячейки списка свободной памяти при любой операции spawn приводит к тому, что очередь готовности еще не заполнена, поэтому вставка записи в список готовности может пропустить проверку "полна ли очередь?".

В нашем запущенном примере задача bar не принимает входных данных, поэтому мы можем пропустить проверку как bar_INPUTS, так и bar_FQ и позволить пользователю посылать неограниченное число сообщений задаче, но если бы мы сделали это, было бы невозможно превысить вместительность для RQ1, что позволяет нам пропустить проверку "полна ли очередь?" при вызове задачи baz. В разделе о очереди таймера мы увидим как список свободной памяти используется для задач без входных данных.

Анализ приоритетов

Очереди, использемые внутри интерфейса spawn, рассматриваются как обычные ресурсы и для них тоже работает анализ приоритетов. Важно заметить, что это SPSC очереди, и только один из конечных элементов становится ресурсом; другим конечным элементом владеет диспетчер задач.

Рассмотрим следующий пример:

#![allow(unused)]

fn main() {

#[rtic::app(device = ..)]

mod app {

#[idle(spawn = [foo, bar])]

fn idle(c: idle::Context) -> ! {

// ..

}

#[task]

fn foo(c: foo::Context) {

// ..

}

#[task]

fn bar(c: bar::Context) {

// ..

}

#[task(priority = 2, spawn = [foo])]

fn baz(c: baz::Context) {

// ..

}

#[task(priority = 3, spawn = [bar])]

fn quux(c: quux::Context) {

// ..

}

}

}

Вот как будет проходить анализ приоритетов:

   • idle (prio = 0) и baz (prio = 2) соревнуются за конечный потребитель foo_FQ; это приводит к максимальному приоритету 2.

   • idle (prio = 0) и quux (prio = 3) соревнуются за конечный потребитель bar_FQ; это приводит к максимальному приоритету 3.

   • idle (prio = 0), baz (prio = 2) и quux (prio = 3) соревнуются за конечный производитель RQ1; это приводит к максимальному приоритету 3

Очередь таймера

Функциональность очередь таймера позволяет пользователю планировать задачи на запуск в опреленное время в будущем. Неудивительно, что эта функция также реализуется с помощью очереди: очередь приоритетов, где запланированные задачи сортируются в порядке аозрастания времени. Эта функция требует таймер, способный устанавливать прерывания истечения времени. Таймер используется для пуска прерывания, когда настает запланированное время задачи; в этот момент задача удаляется из очереди таймера и помещается в очередь готовности.

Давайте посмотрим, как это реализовано в коде. Рассмотрим следующую программу:

#![allow(unused)]

fn main() {

#[rtic::app(device = ..)]

mod app {

// ..

#[task(capacity = 2, schedule = [foo])]

fn foo(c: foo::Context, x: u32) {

// запланировать задачу на повторный запуск через 1 млн. тактов

c.schedule.foo(c.scheduled + Duration::cycles(1_000_000), x + 1).ok();

}

extern "C" {

fn UART0();

}

}

}

schedule

Давайте сначала взглянем на интерфейс schedule.

#![allow(unused)]

fn main() {

mod foo {

pub struct Schedule<'a> {

priority: &'a Cell<u8>,

}

impl<'a> Schedule<'a> {

// `unsafe` и спрятано, потому что мы не хотим, чтобы пользовать сюда вмешивался

#[doc(hidden)]

pub unsafe fn priority(&self) -> &Cell<u8> {

self.priority

}

}

}

mod app {

type Instant = <path::to::user::monotonic::timer as rtic::Monotonic>::Instant;

// все задачи, которые могут быть запланированы (`schedule`)

enum T {

foo,

}

struct NotReady {

index: u8,

instant: Instant,

task: T,

}

// Очередь таймера - двоичная куча (min-heap) задач `NotReady`

static mut TQ: TimerQueue<U2> = ..;

const TQ_CEILING: u8 = 1;

static mut foo_FQ: Queue<u8, U2> = Queue::new();

const foo_FQ_CEILING: u8 = 1;

static mut foo_INPUTS: [MaybeUninit<u32>; 2] =

[MaybeUninit::uninit(), MaybeUninit::uninit()];

static mut foo_INSTANTS: [MaybeUninit<Instant>; 2] =

[MaybeUninit::uninit(), MaybeUninit::uninit()];

impl<'a> foo::Schedule<'a> {

fn foo(&self, instant: Instant, input: u32) -> Result<(), u32> {

unsafe {

let priority = self.priority();

if let Some(index) = lock(priority, foo_FQ_CEILING, || {

foo_FQ.split().1.dequeue()

}) {

// `index` - владеющий укачатель на ячейки в этих буферах

foo_INSTANTS[index as usize].write(instant);

foo_INPUTS[index as usize].write(input);

let nr = NotReady {

index,

instant,

task: T::foo,

};

lock(priority, TQ_CEILING, || {

TQ.enqueue_unchecked(nr);

});

} else {

// Не осталось места, чтобы разместить входные данные / instant

Err(input)

}

}

}

}

}

}

Это очень похоже на реализацию Spawn. На самом деле одни и те же буфер INPUTS и список сободной памяти (FQ) используются совместно интерфейсами spawn и schedule. Главное отличие между ними в том, что schedule также размещает Instant, момент на который задача запланирована на запуск, в отдельном буфере (foo_INSTANTS в нашем случае).

TimerQueue::enqueue_unchecked делает немного больше работы, чем просто добавление записи в min-heap: он также вызывает прерывание системного таймера (SysTick), если новая запись оказывается первой в очереди.

Системный таймер

Прерывание системного таймера (SysTick) заботится о двух вещах: передаче задач, которых становятся готовыми из очереди таймера в очередь готовности и установке прерывания истечения времени, когда наступит запланированное время следующей задачи.

Давайте посмотрим на соответствующий код.

#![allow(unused)]

fn main() {

mod app {

#[no_mangle]

fn SysTick() {

const PRIORITY: u8 = 1;

let priority = &Cell::new(PRIORITY);

while let Some(ready) = lock(priority, TQ_CEILING, || TQ.dequeue()) {

match ready.task {

T::foo => {

// переместить эту задачу в очередь готовности `RQ1`

lock(priority, RQ1_CEILING, || {

RQ1.split().0.enqueue_unchecked(Ready {

task: T1::foo,

index: ready.index,

})

});

// вызвать диспетчер задач

rtic::pend(Interrupt::UART0);

}

}

}

}

}

}

Выглядит похоже на диспетчер задач, за исключением того, что вместо запуска готовой задачи, она лишь переносится в очередь готовности, что ведет к ее запуску с нужным приоритетом.

TimerQueue::dequeue установит новое прерывание истечения времени, если вернет None. Он сязан с TimerQueue::enqueue_unchecked, который вызывает это прерывание; на самом деле, enqueue_unchecked передает задачу установки нового прерывание истечения времени обработчику SysTick.

Точность и диапазон cyccnt::Instant и cyccnt::Duration

RTIC предоставляет реализацию Monotonic, основанную на счетчике тактов DWT (Data Watchpoint and Trace). Instant::now возвращает снимок таймера; эти снимки DWT (Instantы) используются для сортировки записей в очереди таймера. Счетчик тактов - 32-битный счетчик,работающий на частоте ядра. Этот счетчик обнуляется каждые (1 << 32) тактов; у нас нет прерывания, ассоциированног с этим счетчиком, поэтому ничего ужасного не случится, когда он пройдет оборот.

Чтобы упорядочить Instantы в очереди, нам нужно сравнить 32-битные целые. Чтобы учесть обороты, мы используем разницу между двумя Instantами, a - b, и рассматриваем результат как 32-битное знаковое целое. Если результат меньше нуля, значит b более поздний Instant; если результат больше нуля, значит b более ранний Instant. Это значит, что планирование задачи на Instant, который на (1 << 31) - 1 тактов больше, чем запланированное время (Instant) первой (самой ранней) записи в очереди приведет к тому, что задача будет помещена в неправильное место в очереди. У нас есть несколько debug assertions в коде, чтобы предотвратить эту пользовательскую ошибку, но этого нельзя избежать, поскольку пользователь может написать (instant + duration_a) + duration_b и переполнить Instant.

Системный таймер, SysTick - 24-битный счетчик также работающий на частоте процессора. Когда следующая планируемая задача более, чем в 1 << 24 тактов в будущем, прерывание устанавливается на время в пределах 1 << 24 тактов. Этот процесс может происходить несколько раз, пока следующая запланированная задача не будет в диапазоне счетчика SysTick.

Подведем итог, оба Instant и Duration имеют разрешение 1 такт ядра, и Duration эффективно имеет (полуоткрытый) диапазон 0..(1 << 31) (не включая максимум) тактов ядра.

Вместительность очереди

Вместительность очереди таймера рассчитывается как сумма вместительностей всех планируемых (schedule) задач. Как и в случае очередей готовности, это значит, что как только мы затребовали пустую ячейку в буфере INPUTS, мы гарантируем, что способны передать задачу в очередь таймера; это позволяет нам опустить проверки времени выполнения.

Приоритет системного таймера

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

Чтобы понять, почему это нужно, рассмотрим вариант, когда две ранее запланированные задачи с приоритетами 2 и 3 становятся готовыми в примерно одинаковое время, но низкоприоритетная задача перемещается в очередь готовности первой. Если бы приоритет системного таймера был, например, равен 1, тогда после перемещения низкоприоритетной (2) задачи, это бы привело к завершению (из-за того, что приоритет выше приоритета системного таймера) ожидания выполнения высокоприоритетной задачи (3). Чтобы избежать такого сценария, системный таймер должен работать на приоритете, равном наивысшему из приоритетов планируемых задач; в этом примере это 3.

Анализ приоритетов

Очередь таймера - это ресурс, разделяемый всеми задачами, которые могут планировать (schedule) задачи и обработчиком SysTick. Также интерфейс schedule соперничает с интерфейсом spawn за списки свободной памяти. Все это должно уситываться в анализе приоритетов.

Чтобы проиллюстрировать, рассмотрим следующий пример:

#![allow(unused)]

fn main() {

#[rtic::app(device = ..)]

mod app {

#[task(priority = 3, spawn = [baz])]

fn foo(c: foo::Context) {

// ..

}

#[task(priority = 2, schedule = [foo, baz])]

fn bar(c: bar::Context) {

// ..

}

#[task(priority = 1)]

fn baz(c: baz::Context) {

// ..

}

}

}

Анализ приоритетов происходил бы вот так:

   • foo (prio = 3) и baz (prio = 1) планируемые задачи, поэтому SysTick должен работать на максимальном из этих двух приоритетов, т.е. 3.

   • foo::Spawn (prio = 3) и bar::Schedule (prio = 2) соперничают за конечный потребитель baz_FQ; это приводит к максимальному приоритету 3.

   • bar::Schedule (prio = 2) имеет экслюзивный доступ к конечному потребителю foo_FQ; поэтому максимальный приоритет foo_FQ фактически 2.

   • SysTick (prio = 3) и bar::Schedule (prio = 2) соперничают за очередь таймера TQ; это приводит к максимальному приоритету 3.

   • SysTick (prio = 3) и foo::Spawn (prio = 3) оба имеют неблокируемый доступ к очереди готовности RQ3, что хранит записи foo; поэтому максимальный приоритет RQ3 фактически 3.

   • SysTick имеет эксклюзивный доступ к очереди готовности RQ1, которая хранит записи baz; поэтому максимальный приоритет RQ1 фактически 3.

Изменения в реализации spawn

Когда интерфейс schedule используется, реализация spawn немного изменяется, чтобы отслеживать baseline задач. Как можете видеть в реализации schedule есть буферы INSTANTS, используемые, чтобы хранить время, в которое задача была запланирована навыполнение; этот Instant читается диспетчером задач и передается в пользовательский код, как часть контекста задачи.

#![allow(unused)]

fn main() {

mod app {

// ..

#[no_mangle]

unsafe UART1() {

const PRIORITY: u8 = 1;

let snapshot = basepri::read();

while let Some(ready) = RQ1.split().1.dequeue() {

match ready.task {

Task::baz => {

let input = baz_INPUTS[ready.index as usize].read();

// ADDED

let instant = baz_INSTANTS[ready.index as usize].read();

baz_FQ.split().0.enqueue_unchecked(ready.index);

let priority = Cell::new(PRIORITY);

// ИЗМЕНЕНО instant передан как часть контекста задачи

baz(baz::Context::new(&priority, instant), input)

}

Task::bar => {

// выглядит также как ветка для `baz`

}

}

}

// инвариант BASEPRI

basepri::write(snapshot);

}

}

}

И наоборот, реализации spawn нужно писать значение в буфер INSTANTS. Записанное значение располагается в структуре Spawn и это либо время start аппаратной задачи, либо время scheduled программной задачи.

#![allow(unused)]

fn main() {

mod foo {

// ..

pub struct Spawn<'a> {

priority: &'a Cell<u8>,

// ADDED

instant: Instant,

}

impl<'a> Spawn<'a> {

pub unsafe fn priority(&self) -> &Cell<u8> {

&self.priority

}

// ADDED

pub unsafe fn instant(&self) -> Instant {

self.instant

}

}

}

mod app {

impl<'a> foo::Spawn<'a> {

/// Spawns the `baz` task

pub fn baz(&self, message: u64) -> Result<(), u64> {

unsafe {

match lock(self.priority(), baz_FQ_CEILING, || {

baz_FQ.split().1.dequeue()

}) {

Some(index) => {

baz_INPUTS[index as usize].write(message);

// ADDED

baz_INSTANTS[index as usize].write(self.instant());

lock(self.priority(), RQ1_CEILING, || {

RQ1.split().1.enqueue_unchecked(Ready {

task: Task::foo,

index,

});

});

rtic::pend(Interrupt::UART0);

}

None => {

// достигнута максимальная вместительность; неудачный вызов

Err(message)

}

}

}

}

}

}

}

Оглавление

Введение

  Возможности

  Документация пользователя Справочник по API Чат

  Внести вклад

  Благодарности

  Ссылки

  Лицензия

    Условия участия

RTIC в примерах

  Примеры из реальной жизни

    RTFM V0.4.2

Атрибут app

  init

  idle

  Аппаратные задачи

  Приоритеты

Ресурсы

  lock

  Множественное блокировка

  Поздние ресурсы

  Только разделяемый доступ

  Неблокируемый доступ к изменяемым ресурсам

Программные задачи

  Передача сообщений

  Вместимость

  Обработка ошибок

Очередь таймера

  Периодические задачи

  Базовое время

Типы, Send и Sync

  Send

  Sync

Создание нового проекта

Советы и хитрости

  Обобщенное программирование (Generics)

  Условная компиляция

  Запуск задач из ОЗУ

  Обходной путь для быстрой передачи сообщений

  Инспектирование раскрываемого кода

  Деструктуризация ресурса

Инструкции по миграции

Миграция с v0.5.x на v0.6.0

  Cargo.toml - увеличьте версию

  mod вместо const

  Перенос диспетчеров из extern "C" в аргументы app.

  Init всегда возвращает поздние ресурсы

  Структура Resources - #[resources]

  Вызов/планирование откуда угодно

  Симметричные блокировки

  Дополнительно

    Внешние задачи

Миграция с v0.4.x на v0.5.0

  Cargo.toml

  Аргумент Context

  Ресурсы

  Периферия устройства

  #[interrupt] и #[exception]

  schedule

Миграция с RTFM на RTIC

  Cargo.toml

  Изменения в коде

Под капотом

Настройка прерываний

Нереентерабельность

  Программно

  Аппаратно

Контроль доступа

Поздние ресурсы

Критические секции

  Прокси-ресурсы

  lock

  Вложенность

  Инвариант BASEPRI

Анализ приоритетов

Программные задачи

  Дисметчер задач

  Вызов задачи

  Сообщения

  Вместительность очереди

  Анализ приоритетов

Очередь таймера

  schedule

  Системный таймер

  Точность и диапазон cyccnt::Instant и cyccnt::Duration

  Вместительность очереди

  Приоритет системного таймера

  Анализ приоритетов

  Изменения в реализации spawn