Real-Time Interrupt-driven Concurrency

В дополнение к аппаратным задачам, вызываемым в ответ на аппаратные события, 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) {

// ..

}

}

}