Управление контекстом БЕЗ RTOS Опции

[yanvasiij]

Я понимаю, что сейчас речь пойдет об изобретении велосипеда. Но мне это важно для понимания. В ОСРВах переключение между задачами осуществляется за счет переключения контекста. Мне интересно каким образом можно организовать такое переключения самостоятельно. Например, есть две функции ledBlinking1() и ledBlinking2():

Код

void ledBlinging1 (vodi)
{
    led1On();
    delayms(1000);
    led1Off();
    delayms(1000);
}

void ledBlinging2 (vodi)
{
    led2On();
    delayms(1000);
    led2Off();
    delayms(1000);
}

При размещении этих функций внутри задач rtos они будут моргать не влияя друг на друга. А если я озадачусь сделать тоже моргание без rtos, так чтобы они моргали независимо, то мне придется накидать витиеватый алгоритм запоминания предыдущего состояния и следить, сколько времени прошло, не пора бы потушить или зажечь... Но если я реализую функцию загрузки и выгрузки контекста функции, то такой алгоритм городить не придется. Пусть такая функция есть и называется она downloadContext (), а функция приостановки и сохранения контекста yeld(). Тогда, то же моргание без РТОС будет выглядеть следующим образом:

Код

void ledBlinging1 (void)
{
    led1On();
    timer1.setMs(1000);
    while (timer1.expired() == FALSE) yeld();
    led1Off();
    timer1.setMs(1000);
    while (timer1.expired() == FALSE) yeld();

}

void ledBlinging2 (void)
{
    led1On();
    timer1.setMs(1000);
    while (timer2.expired() == FALSE) yeld();
    led2Off();
    timer2.setMs(1000);
    while (timer2.expired() == FALSE) yeld();
}

int main (void)
{
    while (1)
    {
        downloadContext (ledBlinging1);
        downloadContext (ledBlinging2);
    }
}

Может я чего неправильно сказал, но надеюсь смысл понятен. Вопрос: как сделать такое сохранение и загрузку контекста? Где про это можно почитать, посмотреть пример и т.п.
Спасибо!

[Golikov A.]

чего то я видать безнадежно устарел

Код

for (const Point & point : pointsArray)

вот это что за на?

[Slash]

Сколько не читал битв "C vs C++", почему то противники С++ "заставляют" его использовать в самых "тяжелых" проявлениях - RTTI, виртуальные функции (хотя они не тяжелые).
С++ можно использовать только за более жесткий контроль типов. И все.
Потом понять, что ссылки - это удобно и код становится чище.
Потом начать применять приведение типов static_cast(безопасное) и reinterpret_cast(опасное, на усмотрение программиста) вместо С-ного приведения типа (uint32_t *)var. Представьте, как легко найти в коде места, где вы приводите типы рискованно и которые надо проверить в случае ошибки.
Потом понять, что конструктор - это удобно. И их можно использовать в структурах.
Пространства имен.
Все эти возможности несут нулевой оверхед и делают код удобнее и понятнее.

чего то я видать безнадежно устарел

Код

for (const Point & point : pointsArray)

вот это что за на?

Это нововведение стандарта С++ за 2011 год - "range-based for".
Отлично описано в этой статье

Вся эта си-плюс-плюсная объектно-инкапсулированная хрень хороша только для тех, кто не заглядывает в файлы листинга компилятора.
А если Вы задумываетесь об оптимальности не исходников (как здесь), а результирующего кода (скорости выполнения и размера), то выбирайте наиболее стандартные конструкции, типа for (int i = 0; i < n; ++i). Оптимизаторы компиляторов на них наиболее "натасканы" и код будет оптимальным.

А не нужно туда заглядывать.
Задач, где нужна оптимальность кода, не так много. Чаще пишется обычный, не критичный ко времени исполнения код, развесистая логика. Тут важнее читабельность исходников. И не только для автора.
Разговоры "я пишу один и мне все понятно" в пользу бедных.

Я, после опыта оптимизации по скорости DSP-кода, взял это себе за правило - если хочется чтобы код был наиболее оптимален после компилятора, конструкции в исходнном коде должны быть наиболее простыми.
На входе у меня был вот такой вот весь правильный С++ код, со всеми конструкторами/деструкторами и т.п. и при этом он безбожно тормозил и алгоритм не успевал обработать поток данных. После убиения всей этой плюсовой красоты и полного переписывания на простой си-код, скорость выполнения того-же самого алгоритма увеличилась в несколько сотен раз!
Потому что оптимизатор простой код сумел многократно распараллелить.

Очень хотелось бы поверить. Но слишком много неизвестных - какой был компилятор (сейчас компиляторы совершенствуются), каков Ваш уровень мастерства как С++ программиста, каков уровень как С программиста, в каком конкретно месте была потеря скорости?

Вот пример, который привел Александр, хороший с точки зрения проверки С vs C++, т.к. хорошо переводится на С++.

Сообщение отредактировал Slash - Nov 28 2014, 16:31

[jcxz]

Очень хотелось бы поверить. Но слишком много неизвестных - какой был компилятор (сейчас компиляторы совершенствуются), каков Ваш уровень мастерства как С++ программиста, каков уровень как С программиста, в каком конкретно месте была потеря скорости?

Компилятор - CCS, cgtools - довольно свежие. И дело не в компиляторе.
Плюсовой код порождал множественные вызовы функций, что страшное зло для DSP-циклов, плюс - как я понимаю из-за сложности для оптимизатора, он не мог правильно рассчитать кол-во проходов циклов, распараллелить обработку так как не мог просчитать зависимости переменных друг от друга и т.п.
Потеря была во всех критичных местах - фильтрах, обработках массивов сэмплов и т.д.. Остальные места меня не интересовали.

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

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