[arhiv6 14]

В 31.12.2023 в 19:30, unix сказал:

Да, пример простейшего диспетчера лет 15 назад DiHalt выкладывал на свое ресурсе.

Это обычный планировщик задач, где каждая задача это run-to-complete функция, которая вызывается по какому-то событию. Сам когда-то подобный использовал и знаю как минимум одну ОС, которая работает с таким типом задач (uSmartX). Из плюсов такого подхода - минимальное потребление ресурсов и лёгкость портирования (никакого знания ассемблера не требуется). Из минусов - подходит только для простых задач: как только в задаче потребуется после какого-то события (даже обычный вызов delay()) не перезапускать задачу заново, а продолжать выполнять какую-то её логику, то задачи привычнее и проще для понимания писать в непрерывном стиле, как это делается на "взрослых" ОС. Как пример, что проще для понимания, псевдокод задачи из run-to-complete планировщика:

void task_blink()
{
    static uint8 led_state = 0;
  
    if (led_state == 1)
    {
        led_off();
        led_state = 0;      
        task_restart(task_blink, 500);
    }
    else
    {
        led_on();
        led_state = 1;
        task_restart(task_blink, 100);
    }  
}

или привычный линейный код:

void task_blink()
{
    while(1)
    {
        led_on();
        delay_ms(100);
        led_off();
        delay_ms(500);
    }
}

И там и там обычное мигание светодиода на 100мс с паузой 500мс, но второй код гораздо проще для понимания. Язык Си позволяет такое реализовать на основе Duff's device. При этом остаются те же достоинства планировщиков (минимальные ресурсы, общий стек, лёгкость портирования из-за отсутствия ассемблера) но разработка задач упрощается. Поэтому есть несколько кооперативных ОС, построенных на этом принципе: cocoOS, DemOS (+ protothreads как самая упрощённая, но рабочая реализация). ТС, если поймёте, что своего диспетчера вам уже недостаточно, но есть какие-то опасения для перехода на FreeRTOS, рекомендую их попробовать. С ростом сложности ваших проектов если упрётесь в их ограничения тогда уже осознанно перейдёте на вытесняющую ОС с раздельными стеками для каждой задачи, но уже с минимальными переделками своего кода.

[artemkad 53]

4 часа назад, unix сказал:

В суперцикле не обязательно работать по флагам, можно использовать конечный автомат на состояниях, что правильнее.

Ну так суперцикл тут SystemTask()

#define SYSTEM_TASK(fun) fun ,
__root __flash  void (*system_task_func_table[]) (void) = {
#include "task_list.h"
};
#define MAX_SYSTEM_TASKS (sizeof(system_task_func_table)/sizeof(void(*)(void)))

#pragma inline = forced 
static inline void SystemTask (void)
{
  for (char t=0; t<MAX_SYSTEM_TASKS; t++)
	{		// запуск системных задач
		(*system_task_func_table[t])();// запуск задачи
	} 
//#include "task_list.h"
	
}
#undef SYSTEM_TASK

И там внутри каждой задачи можно делать как угодно...

[unix 2]

arhiv6, пока и метаюсь, с одной стороны диспетчера достаточно и в каждая либа построена как конечный автомат на состояниях. Вызов каждой в суперцикле с передачей флага системного тика 1мс.

С другой стороны есть ощущение, что чтобы шагать в ногу со временем надо юзать взрослую ОСРВ.

И как оказалось, с наскока ее не взять, надо изучать каждую и углубляться в нюансы, из-за этого сомнения, а надо ли..

[gridinp 2]

В 29.12.2023 в 11:29, unix сказал:

какой для FreeRTOS надо выделить объем ОЗУ, создалось впечатление что это делается пальцем в небо

начиная с 9-й версии почти всё можно выделить статически, то есть через static

imho freertos хороша тем, что она много где есть, со временем начинаешь таскать из одной железки в другую готовые куски текста

вот тот же analog devices, мудрили мудрили со своей vdk, а потом перешли на freertos

Изменено 1 января пользователем gridinp

[EdgeAligned 53]

Тут зависит от того, насколько объемные проекты будете делать. По своему опыту скажу, что в принципе то, проекты средней степени "массивности" могут обходиться без РТОС. Например, широкоизвестный проект Marlin для 3D принтера обходится без RTOS, хотя он весьма обширный и кроссплатформенный.

22 минуты назад, gridinp сказал:

аскать из одной железки в другую готовые куски текста

Это можно делать и без РТОС. У операционки же иная основная цель: построение взаимодействия между частями программы и организация многопоточности. FreeRTOS является законченным продуктом и портируется на большое число моделей МК.

Идеология "задачи" (task) состоит в функционально законченной части кода по типу "черного ящика", взаимодействующей с другими задачами посредством уведомлений, семафоров (сигналов-флагов), очередей обмена данными. 

[Ruslan1 16]

RTOS имеет смысл использовать. Всегда.

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

Только не нужно рассказывать про ресурсожручесть. Я впервые RTOS на PIC16 с 370 байт RAM пробовал, и уже там это имело смысл.

 

FreeRTOS- замечательный образчик RTOS. И сам на нем уже много лет сижу, и всем советую именно его как базу для нового софта. Бесплатен, популярен, исходники доступны.

[jcxz 184]

18 минут назад, Ruslan1 сказал:

RTOS имеет смысл использовать. Всегда.

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

С этим никто не спорит.

Но - Ваши бы слова да разработчикам того же Марлина в уши. Ну и прочим упёртым суперлуперам.  

ЗЫ: Если люди, которые когда-то что-то освоили. Давно. Чуть-чуть. И потом, даже под страхом пытки не хотят изучать ничего нового, лучшего. И никакие разумные аргументы не действуют.  

[EdgeAligned 53]

Во-во, Марлин бы на РТОСе 🙂 Хотя, и без РТОСы он весьма запутанно написан из-за кросплатформенности. Если они втуда втолкнут РТОС, это будет засада полная.

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

[vov4ick 35]

А ещё говорят что лень - двигатель прогресса 😉

[Ruslan1 16]

27 минут назад, jcxz сказал:

ЗЫ: Если люди, которые когда-то что-то освоили. Давно. Чуть-чуть. И потом, даже под страхом пытки не хотят изучать ничего нового, лучшего. И никакие разумные аргументы не действуют.  

Я тоже из этих. Базы данных с индексированием и поиском на ассемблере на PIC18 писал (с внешней RAM с батарейкой). И перешел на Си наверное лет на 5 позже чем это было уже возможно. То же самое и с RTOS, но тут меня подтолкнули (проект на юкосе подсунули). И обратно на ассемблер и суперлуп не перейду.

Это как пересел в машине на атомат после ручки- я ее поюзал лет 20 и в любой момент могу снова потому что умею, но! только в случае сильной нужды и точно не по собственному желанию 🙂

 

[jcxz 184]

7 минут назад, Ruslan1 сказал:

То же самое и с RTOS, но тут меня подтолкнули (проект на юкосе подсунули).

Ого! Юкос уже лет 20 как в лучшем из миров. Хотя на железке бочки с его названием ещё встречаются. Получается, что вы здесь - один из ветеранов РТОС-пользования?!  

[Ruslan1 16]

1 час назад, jcxz сказал:

Ого! Юкос уже лет 20 как в лучшем из миров. Хотя на железке бочки с его названием ещё встречаются. Получается, что вы здесь - один из ветеранов РТОС-пользования?!  

я тут в 2006 зарегился, как раз когда первую свою борду на ARM разрабатывал (AT91RM9200), тогда параллельно как раз и uC/OS-II изучал для него же (был честно купленный микриум под исследовательский грант в НИИ). И то и другое успешно заработало, а я зауважал системы реального времени.

[Arlleex 131]

2 часа назад, Ruslan1 сказал:

RTOS имеет смысл использовать. Всегда.

Не-а. И нет, я не приверженец суперлупов, или ОСРВ, или что там еще крутит процессорное время. Без разницы. RTOS не всегда гибка по расходу памяти, а на некоторых контроллерах добавление очередной задачи может все похерить, несмотря на казалось бы "достаточность" ОЗУ. Вытесняющей операционке к стеку каждой задачи нужно добавить размер стека для прерываний с их максимальной теоретической глубиной вложенности. В Cortex-M в силу двух указателей SP можно сэкономить, прибавив одиночный фреймстек. А в МК без такой хухры-мухры так не прокатит. Вот и казалось бы, ОЗУ вроде и хватает (в отрыве от других задач), а в целом - не лезет. И это - один из примеров.

Ну а во-вторых, какая RTOS, если надо по UART/SPI/I2C че-то настроить, пару раз отправить показания датчика и заснуть? Мне лично будет даже лень расчехлять RTOS для этого.

[EdgeAligned 53]

И это - тоже верно! 🙂 Как водится - истина где-то посередине! 

[jcxz 184]

51 минуту назад, Ruslan1 сказал:

я тут в 2006 зарегился, как раз когда первую свою борду на ARM разрабатывал (AT91RM9200), тогда параллельно как раз и uC/OS-II изучал для него же

ааа.... Я уж было подумал, что вы реально на Юкос работали. И в нефти купались.