Могу.
Приведу простенький код на макроассемблере без RTOS, реализующий ваш пример
(мнемоника несколько изменена).

L:
Opros_Knopok
(Knopki = Kn_Pusk) → Pusk ' Переход на режим пуск, если нажата кнопка пуск
(flg_Int0 = 1) → Int0 ' Переход на обработку прерывания, если был установлен флаг Int0
Vyvod_Indikator
→ L ' Переход на метку L

Opros_Knopok — подпрограмма опроса кнопок, результаты которого хранятся в переменной Knopki.
Vyvod_Indikator - подпрограмма вывода на индикатор.

Для ускорения обработки прерывания в подпрограммах Opros_Knopok и Vyvod_Indikator можно поставить команды ускоренного выхода при появлении флага прерывания.
Такой флаг устанавливается программно при возникновении прерывания.
Тут тоже получается простой и понятный код, небольшой по объёму и, наверно, намного быстрее выполняемый. Написал за несколько минут.
И в чём преимущество RTOS?

Как раз по вашему примеру и видно - приходится постоянно опрашивать флаг/флаги. В RTOS потоки, это как бы отдельные программы, которые могут ничего не знать о друг друге - задача ядра по очереди запускать их.

Это только если "потоки" не взаимодействуют. Например, один поток мигает светодиодами, делая бегущие огни, а другой пищит динамиком, наигрывая "в лесу родилась ёлочка". Как только вы вознамеритесь из одного потока в другой передать данные - начнутся флаги и т.п. В простых случаях это будет сделано незаметно для верхнего уровня, типа send_message-функцией, в других будет куча семафоров, мьютексов и т.п. сложноперевариваемой хрени.

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

имхо не очень то и сложноперевариваемо:

The following steps are required to use signals:
In the thread (for example thread ID tid_thread1) that is supposed to wait for a signal, call the wait function:

In another thread (or threads) that are supposed to wake the waiting thread up call:


реальный примерчик блинканья группой светодиодов по кнопке CMSIS-RTOS из паков Кейла:

Спойлер

..

Код:

/*----------
 * blinkLED: blink LED and check button state
 *----------*/
void blinkLED(void const *argument) {
  int32_t max_num = LED_GetCount();
  int32_t num = 0;

  for (;;) {
    LED_On(num);                                           // Turn specified LED on
    osSignalWait(0x0001, osWaitForever);
    LED_Off(num);                                          // Turn specified LED off
    osSignalWait(0x0001, osWaitForever);

    num++;                                                 // Change LED number
    if (num >= max_num) {
      num = 0;                                             // Restart with first LED
    }
  }
}

Код:

osThreadId tid_blinkLED;
osThreadDef (blinkLED, osPriorityNormal, 1, 0);

int main (void) {
  uint32_t button_msk = (1U << Buttons_GetCount()) - 1;

  osKernelInitialize ();                                   // initialize CMSIS-RTOS

  // initialize peripherals
  SystemCoreClockConfigure();                              // configure System Clock
  SystemCoreClockUpdate();

  LED_Initialize();                                        // LED Initialization
  Buttons_Initialize();                                    // Buttons Initialization

  // create threads
  tid_blinkLED = osThreadCreate (osThread(blinkLED), NULL);

  osKernelStart ();                                        // start thread execution

  for (;;) {                                               // main must not be terminated!
    osDelay(500);
    while (Buttons_GetState() & (button_msk));             // Wait while holding USER button
    osSignalSet(tid_blinkLED, 0x0001);
  }
}

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

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

не так страшен... Попробовал AVR порт распространенной FreeRTOS, которая поддерживает большую хучу микроконтроллеров (и даже Quark и x86), на mega8. Две задачи блинканья светодиодами. В протеусе проверил - блинкают.
Заняло половину ресурсов, ram поболее половины:


жить с RTOS можно и на AVR, тем более в наличии AVR имеются экземпляры с более ресурсами, а еще есть xmegи тож AVRы, а на AVR32 линуксы запускают. Основной main файл выглядит не страшно:

Спойлер

Код:

#include "FreeRTOS.h"
#include "task.h"

/*----------*/
/*            Задача #1            */
/*----------*/
void vTask1( void *pvParameters )
{
/* задача построена на базе бесконечного цикла */
 for(;;)
 {
/* Инвертировать бит 0 порта PORTC */
  PORTC ^= (1 << PC0);
/* Задержка на некоторый период Т1 */
  vTaskDelay(200); // T1 = 200 системным тикам
 }
/* Уничтожить задачу если произошел выход
   из бесконечного цикла */
 vTaskDelete(NULL);
}

/*----------*/
/*            Задача #2            */
/*----------*/
void vTask2( void *pvParameters )
{
 for(;;)
 {
/* Инвертировать бит 1 порта PORTC */
  PORTC ^= (1 << PC1);
/* Задержка на некоторый период Т2 */
  vTaskDelay(133); // Т2 = 133 системным тикам
 }
 vTaskDelete(NULL);
}

/*----------*/
/*           Entry Point           */
/*----------*/
int main( void )
{
/* Биты 0,1 порта PORTC будут работать как выходы */
 DDRC |= (1<<DDC0) | (1<<DDC1);

/* Установка задачи #1. В этом примере не используется
   проверка на коректную установку */
 xTaskCreate( vTask1, /* Указатель на исполняемую функцию */
             (signed char *) "Task1", /* Имя задачи */
             configMINIMAL_STACK_SIZE,  /* Размер стэка задачи */
             NULL,  /* Передаваемый параметр */
             1,  /* Приоритет задачи */
             NULL );  /* Дескриптор задачи */

/* Установка задачи #2 */
 xTaskCreate( vTask2, /* Указатель на иполняемую функцию */
             (signed char * ) "Task2", /* Имя задачи */
             configMINIMAL_STACK_SIZE, /* Размер стэка задачи */
             NULL, /* Передаваемый параметр */
             1, /* Приоритет задачи */
             NULL ); /* Дескриптор задачи */

/* Запустить планировщик */
 vTaskStartScheduler();
 return 0;
}

Не знаю насчет практической ценности порта RTOS под 8 бит AVR, но поучится можно, с целью получить потом престижную работу . Вроде для промышленных применений микроконтроллеров, где жизнь человека может быть подвергнута опасности применяют сертифицированные безопасные RTOS типа:
https://www.highintegritysystems.com/em ... lications/

Чем флаги не понравились?
Опросить флаги несложно, да и флаги по прерыванию стараюсь минимизировать. А программа получается относительно несложной, скоростной, легко читаемой.
Насчёт того, что «В RTOS потоки, это как бы отдельные программы, которые могут ничего не знать о друг друге».
Даже если потоки логически не связаны друг с другом, думаю, есть ещё важный
связывающий фактор — временной, когда МК должен быстро отработать некоторые процессы.
Наверно, «скоростные» задачи без RTOS лучше решаются.

В большинстве RTOS реализована возможность задавать приоритеты потоков.

Для примера: первый поток - работа с SD-картой, низкий приоритет; второй поток - обработка сообщений от UART, высокий приоритет. При некоторых допущениях (например, обработку нельзя вынести в прерывание), в реализации на флагах работа с SD будет приводить к потере сообщений, получаемых по UART.

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

Ну самая популярная в России RTOS — QNX 4.0 (правда на AVR порта нет) 8К микроядро (да-да, восемь килобайт!) время переключения контекста — 2,5 наносекунды, и ядро полностью написано на ассемблере, что обеспечивает высочайшую скорость. Кроме того, в такой небольшой программе легче находить ошибки, что делает его (ядро) чрезвычайно надежным. QNX
смело можно назвать одной из самых проработанных ОС. Не удивительно, что ей доверяют контроль над ядерными реакторами
и медицинским оборудованием. И то, и другое напрямую связано с жизнью и здоровьем людей.

Попробую дополнить этот топик...позанудничаю, можно?

ОС, как и есть в Вики: "набор подпрограмм для .. и взаимодействия с ползателями". То есть ОС решает задачи запуска программ на данном железе, управления ресурсами этого железа И взаимодействия с человеком.
Перенося это на AVR как управляющий контроллер, имеем: чтобы данная библиотека могла носить гордое название "Операционная Система", требуется выполнение условий (с конца):
а) типовой комплект средств взаимодействия с пользователем. В целом если и нет, то нетрудно ввести некий "стандарт" на базе libc: printf() и т.д.;
б) управления ресурсами .. вот тут уже хорошо выходит. Ибо контроллер .. управляющий и его "ресурсы" практически индивидуальны в данном конкретном применении. Разве что "процессорное время" и "распределение памяти"...
в) запуск программ .. и тут совсем "засада": управляющий контроллер предназначен для решения некой конкретной задачи управления в строго этом, конкретном окружении .. управление термостатом, пробник-осцилограф, ПИД-регулятор гоночной тележки, контроль работы видеокамеры и системы её включения/выключения, поворота .. КАК это все совместить в рамках одной "ОС" с единым механизмом управления?
Ну и где тут "Операционная Система", когда каждое применение можно считать уникальным?

Можно вести речь за "кусок RTOS", а именно за систему прозрачного распараллеливания задач - "диспетчер задач". Он интересен и полезен больше в рамках "автоматного" программирования. Когда каждый ресурс управляется своим конечным автоматом и разработчику неважно в каком конкретно порядке исполняются эти автоматы .. порядок их действий все равно определяется сменой их состояний. Но, как ни странно, "юникс-подобный" стиль распараллеливания задач .. внезапно не подходит для такой работы. Куда интереснее в этом плане механизмы межзадачного взаимодействия языка Ада. Правда он похоже давно заброшен..

P.S. несколько сумбурно написал .. ну да ладно.

Очень даже не заброшен, даже конкурсывсякие проводятся...

Пасибки, не знал. Жаль что ну очень давно, ещё до стандарта "Ада-95" пользовал этот язык. Да и как-то конкрус исключительно под STM32F4xx .. есть STM32F405, но я его ещё не распаковывал. Срок до сентября .. маловато времени, чтобы вспомнить язык, разобраться с новым для себя процом и что-то закодить "оригинальное".

компилятор ADA с IDE AdaMULTI по прежнему выпускает успешно Green Hills
http://www.ghs.com/products/AdaMULTI_IDE.html
ADA задействована в INTEGRITY-178 RTOS.
http://www.ghs.com/products/safety_crit ... -178b.html