Зачем нужна RTOS на AVR

[AQ29]

[uquote="viiv",url="/forum/viewtopic.php?p=3070472#p3070472"]Алексей bird, на примере постараюсь показать что можно получить от RTOS.

Допустим, к нашему устройству подключен символьный LCD экранчик и keypad.
Допустим, есть гипотетическая ОС, в которой определен API символьного экранчика и API простенькой клавиатуры...
Вы можете привести код, реализующий такое главное меню, без RTOS?[/uquote]
Могу.
Приведу простенький код на макроассемблере без 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?

[oleg110592]

И в чём преимущество RTOS?

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

[ARV]

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

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

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

[oleg110592]

[uquote="ARV",url="/forum/viewtopic.php?p=3099606#p3099606"]Как только вы вознамеритесь из одного потока в другой передать данные - начнутся флаги и т.п. В простых случаях это будет сделано незаметно для верхнего уровня, типа send_message-функцией, в других будет куча семафоров, мьютексов и т.п. сложноперевариваемой хрени.[/uquote]
имхо не очень то и сложноперевариваемо:

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:

Код: Выделить всё

    osSignalWait (0x0001, osWaitForever); // wait forever for the signal 0x0001

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

Код: Выделить всё

    osSignalSet (tid_thread1, 0x0001);    // set the signal 0x0001 for thread tid_thread1
    osDelay (1000);                       // wait for 1 second

реальный примерчик блинканья группой светодиодов по кнопке 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 некоторые задачи решать лучшее, чем без оной

[ARV]

с RTOS некоторые задачи решать лучшее, чем без оной

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

[oleg110592]

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

Код: Выделить всё

Device: atmega8
Program:    3874 bytes (47.3% Full)
(.text + .data + .bootloader)

Data:        621 bytes (60.6% Full)
(.data + .bss + .noinit)

жить с 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/

[AQ29]

[uquote="oleg110592",url="/forum/viewtopic.php?p=3099558#p3099558"]

И в чём преимущество RTOS?

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

[microbober]

[uquote="AQ29",url="/forum/viewtopic.php?p=3100790#p3100790"]Наверно, «скоростные» задачи без RTOS лучше решаются.[/uquote]
В большинстве RTOS реализована возможность задавать приоритеты потоков.

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

[oleg110592]

[uquote="AQ29",url="/forum/viewtopic.php?p=3100790#p3100790"]Чем флаги не понравились?
Опросить флаги несложно, да и флаги по прерыванию стараюсь минимизировать. А программа получается относительно несложной, скоростной, легко читаемой[/uquote] Дык флагами сам таки и пользуюсь. Речь то о том, что с RTOS программа получается вообще несложной и еще более читаемой, переносимой и надежной. Отдельные задачи могут писать разные программисты.
[uquote="AQ29",url="/forum/viewtopic.php?p=3100790#p3100790"]Наверно, «скоростные» задачи без RTOS лучше решаются.[/uquote]
Ну самая популярная в России RTOS — QNX 4.0 (правда на AVR порта нет) 8К микроядро (да-да, восемь килобайт!) время переключения контекста — 2,5 наносекунды, и ядро полностью написано на ассемблере, что обеспечивает высочайшую скорость. Кроме того, в такой небольшой программе легче находить ошибки, что делает его (ядро) чрезвычайно надежным. QNX
смело можно назвать одной из самых проработанных ОС. Не удивительно, что ей доверяют контроль над ядерными реакторами
и медицинским оборудованием. И то, и другое напрямую связано с жизнью и здоровьем людей.

[Vladimir1962]

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

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

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

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

[ARV]

языка Ада. Правда он похоже давно заброшен

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

[Vladimir1962]

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

[oleg110592]

компилятор 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

Integrity — операционная система реального времени, разработанная калифорнийской компанией Green Hills Software. Сертифицирована на соответствие POSIX. Ориентирована на однопроцессорные встраиваемые системы, в центральном процессоре которых есть блок управления памятью (архитектуры ARM, XScale, Blackfin, Freescale ColdFire, MIPS, PowerPC, x86). Система основана на микроядре µ-velosity. Главная особенность системы — отказоустойчивость (если произойдет отказ в какой-либо программе запущенной в этой операционной системе, система в целом будет продолжать работать в штатном режиме, а перезапуск упавшего приложения попытается провести с предоставлением ему тех областей памяти данных, которые были выделены приложению до его падения).
Используется в американских военных самолетах (например F-16, F-22, F-35) и вертолетах, так же в гражданских Airbus A380, Boeing 787.