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

[Алексей bird]

Собственно вот и вопрос, а зачем всё это? Имеется ввиду архитектура Mega, в xMega там ресурсов поболее и прочие няшки есть. Но вот зачем городить RTOS на Mege, какой выигрыш и в чем это даст. Спасибо!

[viiv]

Собственно вот и вопрос, а зачем всё это? Имеется ввиду архитектура Mega, в xMega там ресурсов поболее и прочие няшки есть. Но вот зачем городить RTOS на Mege, какой выигрыш и в чем это даст. Спасибо!

Если спрашиваете, то Вам это (RTOS) не нужно.

Регулярно такие вопросы возникают. Если "на пальцах", любая ОС (как RT так и не RT) предоставляет набор функций (API). Например, если я пишу код тектового интерфейса с пользователем (терминал), то у меня появляется новая абстрация - символьный поток. И мне:
1) "по барабану" на какам процессоре будет выполнятся мой код (хоть на меге, хоть на xМеге, хоть на ARMе)
2) совершенно не важно, как подключен терминал ползователя (к UART-у, или, например, это telтet клиент)
А RTOS обеспечит, чтобы "общение с пользователем" не мешало более важным задачам.

[oleg110592]

ОСРВ позволяет программисту сосредоточить свои усилия на решении конкретных задач (алгоритмических, математических и т.п.), не отвлекаясь на задачи второстепенные. Она берет на себя:

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

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

http://www.pic24.ru/doku.php/osa/ref/in ... %D0%B5_osa
Примеры применения, в том числе и для мелкого PIC10F 8 ног:
http://www.pic24.ru/doku.php/osa/ref/examples/intro

[Алексей bird]

Если спрашиваете, то Вам это (RTOS) не нужно.

Интересные выводы.
Только как понять нужна ли мне САПР, ведь я рисую на миллиметровке и мне нравится.

[Аlex]

Но вот зачем городить RTOS на Mege, какой выигрыш и в чем это даст

Вы задаёте вопрос так, как будто Вам её навязывают, или заставляют писать код, используя её.
Не нужна он Вам ? - не пользуйтесь. В чём проблема ?

Только как понять нужна ли мне ...

Лучше 1 раз увидеть, чем 100 раз услышать. Возьмите и попробуйте. А потом сами определитесь, нужна ли она Вам.

[dimmer]

Алексей bird, Вы видимо имели в виду применимость OS в контроллерах с небольшим объёмом памяти (1-16 kB). Для таких МК, по моему скромному мнению, использование RTOS избыточно (или невозможно), и к тому же программы таких размеров я пишу на ассемблере. Для себя я написал фрагменты кода (затем оформил их в виде макросов), которые позволяют структурировать программу на ассемблере, разбивая её на отдельные подзадачи. Если Вам будет интересно, можете посмотреть статьи "RTOS для маленьких" и "Изобретение велосипеда" (avr-assm.ru).

[Алексей bird]

Да причем тут заставляют? Как можно оценить инструмент, если не знать какие он даёт преимущества? Взять и попробовать мысль хорошая, но для начала всё-таки хочу понять какие выгоды мне это даст(или может дать).
dimmer нет не применимость, а именно зачем это нужно.
Как я понял использование RTOS в простых задачах ни к чему. А вот при сложных, может дать серьёзный плюс. Спасибо всем, буду пробовать

[DimAlt]

Более интересно, если кто нибудь дал рабочий пример проекта (не демонстрацию процессов), с небольшим описанием. Сам пытался использовать, сначала понравилось, но потом на AVR уперся в количество процессов. Как выход, в процессе использовал суперцикл. Получился старый подход к написанию программы, но с быстрым переключением нескольких суперциклов. Вообщем как писать правильно программы на ОС я не понял.

[viiv]

Если спрашиваете, то Вам это (RTOS) не нужно.

Интересные выводы.
Только как понять нужна ли мне САПР, ведь я рисую на миллиметровке и мне нравится.

Мой смайлик ввел Вас в заблуждение. На самом деле ответ был без сарказма. На мой взгляд, при увеличении сложности задач, Вы придете к выводу, что затраты на разработку неприемлемые и нужен новый уровень абстракции. Даже сейчас Вы на XMEGA видите преимущества, но и меги разные бывают 128 или 256K программной памяти - это прилично.

"Зачем мне экскаватор, если я за день выкопаю траншею, а подъезд экскаватора затруднен?" Если задается такой вопрос, то экскаватор спрашивающему не нужен.

----------
Я предполагаю, если Вы знаете, что на AVR можно запустить RTOS, то Вы хоть что-то прочитали про эту RTOS.
Так же предполагаю, что прочитав хоть самую малость, Вы в общих чертах поняли, что дает использование RTOS.
На мой взгляд основные: 1) использование "чужого" кода (и многократное использование своего) 2) переносимость (когда пишется большая часть кода, не важно на каком целевом микроконтролле он будет работать), 3) "изолированность" кода. Т.е. все это ведет к уменьшению затрат на разработку и увеличению надежности ПО.
Естественно, это все не бесплатно. Например, может понадобится больше памяти, большая производительность...

[ARV]

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

надежды, что применение RTOS для AVR развяжет программисту руки и даст невиданную свободу, никогда не оправдаются.
RTOS не для AVR, даже если применяется "монстр" atmega2560.
И не надо добиваться невиданных успехов, насилуя RTOSами жалкое ядро... надо именно что использовать по-максимуму возможности "старых" подходов.
Вы уверены, что исчерпали эти "старые" подходы?
А вспомните ZX Spectrum - процессор там был примерно в 5-8 раз менее производительный, чем AVR, ресурсов там было заметно меньше, чем в той же atmega128, а тем не менее такое там вытворялось!
Посмотрите на UzeBox - та же мега, разве что немного разогнанная, и что вытворяет!
И при этом ни в спектруме, ни в UzeBox-е не то что реального времени, а вообще никакой ОС нет.
Раз уж судьба толкает вас применять AVR - не подражайте другим, идите традиционным путем, просто тщательнее разрабатывайте программы

[Алексей bird]

Мой смайлик ввел Вас в заблуждение. На самом деле ответ был без сарказма. На мой взгляд, при увеличении сложности задач, Вы придете к выводу, что затраты на разработку неприемлемые и нужен новый уровень абстракции. Даже сейчас Вы на XMEGA видите преимущества, но и меги разные бывают 128 или 256K программной памяти - это прилично.

"Зачем мне экскаватор, если я за день выкопаю траншею, а подъезд экскаватора затруднен?" Если задается такой вопрос, то экскаватор спрашивающему не нужен.

----------
Я предполагаю, если Вы знаете, что на AVR можно запустить RTOS, то Вы хоть что-то прочитали про эту RTOS.
Так же предполагаю, что прочитав хоть самую малость, Вы в общих чертах поняли, что дает использование RTOS.
На мой взгляд основные: 1) использование "чужого" кода (и многократное использование своего) 2) переносимость (когда пишется большая часть кода, не важно на каком целевом микроконтролле он будет работать), 3) "изолированность" кода. Т.е. все это ведет к уменьшению затрат на разработку и увеличению надежности ПО.
Естественно, это все не бесплатно. Например, может понадобится больше памяти, большая производительность...

Я думаю можно на "ты", а то как-то глаз режет, всё-таки это не официальная переписка
Ну вот например:
1) А разве код не нужно будет "прилизывать" к каждой RTOS? Ведь они используют разные имена, переменные и прочее.
2) А разве без RTOS это сложно?
3) Поподробней можно?

Вот зачем нужна ОС на обычном компьютере я понимаю, но там есть тот же HAL, GUI которые сильно помогают(облегчают работу) в написании программ. Но ведь того же HAL'а для AVR нет, или я ошибаюсь?

[Z_h_e]

И при этом ни в спектруме, ни в UzeBox-е не то что реального времени, а вообще никакой ОС нет.

На счет спектрума не соглашусь. Роль ОС в спектруме выполнял встроенный в 16КБ ПЗУ Бэйсик. Разработчики программ активно пользовались его функциями, экономя тем самым драгоценное ОЗУ. В русифицированных спектрумах был несколько изменен код в ПЗУ из-за чего не все игры работали на таких компах. Но это так, ремарка, не имеющая значения для данной темы.

[viiv]

1) А разве код не нужно будет "прилизывать" к каждой RTOS? Ведь они используют разные имена, переменные и прочее.

Нужно. Но можно использовать и другой подход. Класс своих задач представляшь? Выбери себе одну ОС, которая предоставляет Вам наиболее полный список сервисов, которые могут понадобится (остальное придется самому реализовывать). Желательно, чтобы выбранная ОС кроме AVR работала и на других платформах, возможность перехода на которые может понадобиться в будущем: Cortex, MSP430...

2) А разве без RTOS это сложно?

Я и говорю, что если ты спрашиваеш, либо нет задач, на которых можно "прочуствовать", либо ты крут. Пример: было у нас устройство на mege103, которое реализовывало необходимую заказчику функцию. Другой заказчик говорит: нам подходит устройство по функцоионалу, но нам необходимо удаленно мониторить/управлять устройствами по SNMP протоколу. Если у тебя нет проблем быстро "запихнуть" реализацию ARP/IP/UDP/SNMP в свое устройство, тогда - ты крут.

[DimAlt]

но и меги разные бывают 128 или 256K программной памяти - это прилично.

Флеш в ОС не основное, главное ОЗУ. Оно определяет сколько процессов можно использовать. У меня получалось только 4 процесса на 1к ОЗУ. Сколько у Вас обычно процессов крутится? Думаю, что набор/заготовка пустого проекта, если следовать пунктам 2 и 3, будет стандартной.

[viiv]

Флеш в ОС не основное, главное ОЗУ. Оно определяет сколько процессов можно использовать. У меня получалось только 4 процесса на 1к ОЗУ. Сколько у Вас обычно процессов крутится? Думаю, что набор/заготовка пустого проекта, если следовать пунктам 2 и 3, будет стандартной.

У меги128 4К (если я правильно помню), кроме того есть интерфейс к внешней SRAM

[ARV]

Роль ОС в спектруме выполнял встроенный в 16КБ ПЗУ Бэйсик

это не аналог ОС, это аналог библотеки подпрограмм - libc иначе говоря. все это сейчас вместе с компилятором доступно.

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

[Z_h_e]

это не аналог ОС, это аналог библотеки подпрограмм

Я знаю что Вас нельзя переубедить, так что не буду пробовать. Однако замечу, что при таком подходе MS-DOS тоже не ОС. А в спектруме, кроме встроенного бэйсика управляющего компом при его старте, еще существует TR-DOS.
Ну и определение из википедии

Операцио́нная систе́ма, сокр. ОС (англ. operating system, OS) — комплекс взаимосвязанных программ, предназначенных для управления ресурсами компьютера и организации взаимодействия с пользователем.

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

Ну вроде никто обратного и не утверждал.

[viiv]

Алексей bird, на примере постараюсь показать что можно получить от RTOS.

Допустим, к нашему устройству подключен символьный LCD экранчик и keypad.
Допустим, есть гипотетическая ОС, в которой определен API символьного экранчика и API простенькой клавиатуры.

Спойлер

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

/* включает/выключает питание экрана */
void lcd_power (bool_t on);
/* Очистка экрана */
void lcd_clear ();
/* установить текущую позицию */
void lcd_goto (u8_t row, u8_t col);
/* выводит строку (inv: флаг инвертирования) */
void lcd_puts (bool_t inv, const char *s);

/* возвращает ID нажатой кнопки, если !nblock, вызывающий блокируется до момента нажатия */
u8_t get_key (bool_t nblock);
#define KEY_NONE      0
#define KEY_UP        1
#define KEY_DOWN      2
#define KEY_LEFT      4
#define KEY_RIGHT     5
#define KEY_SELECT    6
#define KEY_ESC       7

Требуется написать реализацию простого главного меню устройства. С учетом приведенных выше API получается простой и понятный код, который не зависит от того, как подключен I2C, SPI, внешней шине... Кроме того, этому коду все равно, на AVR-е он выполняется или на Cortex-M3...

Спойлер

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

void do_main_menu (void)
{
#define MAIN_MENU_ROW 0
#define MAIN_MENU_COL 0
        static const char* help_str __AT_FLASH__ = "Up/Down to navigate.";
        static const char* conf_str __AT_FLASH__ = "Configure...        ";
        static const char* save_str __AT_FLASH__ = "Save config         ";
        static const char* dflt_str __AT_FLASH__ = "Load default config ";
#define MAIN_MENU_ITEMS       3
        const char* const items [MAIN_MENU_ITEMS] = {
                conf_str,
                save_str,
                dflt_str,
        }
        u8_t key;
        u8_t i;
        u8_t current_item = 0;

        lcd_power (1);  /* включаем LCD */

        do {
                lcd_clear ();
                for (i = 0; items [i]; i++) {
                        lcd_goto (i + MAIN_MENU_ROW, MAIN_MENU_COL);
                        lcd_puts (i == current_item, items [i]);
                }
                lcd_goto (i + MAIN_MENU_ROW, MAIN_MENU_COL);
                lcd_puts (0, help_str);
                do {
                        key = get_key (0);
                        if (key == KEY_SELECT) {
                                switch (current_item) {
                                case 0: configure_menu ();   break
                                case 1: save_config ();         break;
                                case 2: default_config ();      break;
                                }
                                break;  /* redraw menu */
                        }
                        if (key == KEY_UP || key == KEY_DOWN) {
                                /* гасим активный пункт */
                                lcd_goto (current_item + MAIN_MENU_ROW, MAIN_MENU_COL);
                                lcd_puts (0, items [current_item]);
                                if (key == KEY_UP) {
                                        current_item = (current_item > 0) ?
                                                ((current_item - 1) : (MAIN_MENU_ITEMS - 1);
                                } else {
                                        /* нажата кнопка вниз */
                                        if (++current_item >= MAIN_MENU_ITEMS)
                                                current_item = 0;
                                }
                                /* активируем новый пункт */
                                lcd_goto (current_item + MAIN_MENU_ROW, MAIN_MENU_COL);
                                lcd_puts (1, items [current_item]);
                        }
                } while (key != KEY_ECS);
        } while (key != KEY_ESC);

        lcd_clear ();
        lcd_power (0);  /* выключаем LCD */
}

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

Вы можете привести код, реализующий такое главное меню, без RTOS?

PS. К возможным ошибкам в коде не предираться, написано в попыхах и код не просматривал.

[ARV]

Эта функция выполняется в потоке взаимодейтвия с пользователем

при классическом подходе это ГЛАВНЫЙ ЦИКЛ

данный поток не мешал более высоприоритетным задачам

в классическом подходе это ОБРАБОТЧИКИ ПРЕРЫВАНИЙ
и никакой ОС не надо...

P.S. меню и покруче писывали... и тоже максимально от архитектуры отделено. на AVR далеко от ограничений архитектуры не уйдешь, но попробовать можно. в частности, я давно и весьма успешно работаю с ЖКИ и/или USART при помощи printf... пробовал и при помощи scanf, но не понравился вообще подход, предлагаемый классикой Си...

[uni]

RTOS нужна, когда код стал слишком сложным и нужно разделить сервисный и прикладной код. Используя главный цикл подразумевается знакомство с его архитектурой и ограничениями, пользователь должен знать как именно работает этот главный цикл. В RTOS всю эту сложность скрывают и делается предположение, что у вас есть несколько ядер, работающих параллельно. Это упрощение для прикладного программиста. Задачи держать в голове возможно одному человеку. С главным циклом это гораздо сложнее или очень трудно в сопровождении. Поэтому при определённости сложности не имеет смысла использовать главный цикл, его заменяют на RTOS. Это тот же главный цикл, но знать как он работает нужно лишь в общих чертах.