[unix 2]

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

И в общем, не совсем понятен смысл ее использования, только дополнительные расход ресурсов микроконтроллера.

Проще свой диспетчер задач, что думаете?

[arhiv6 14]

Сначала берётся с запасом, потом реальное использование памяти каждой задачей можно уточнить (параметр usStackHighWaterMark из структуры TaskStatus_t, которую можно получить из vTaskGetInfo()). Вот статья про это: https://habr.com/ru/articles/352782/ там пятый раздел "Мониторинг использования ресурсов". Кроме того, есть варианты ОС без выделения отдельных стеков для каждой задачи: начиная от protothreads и их производных, заканчивая теми же Co-Routine из состава FreeRTOS.

[dOb 8]

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

Проще свой диспетчер задач, что думаете?

В простейшем случае - бесконечный цикл с опросом флагов Некоторые даже называют это операционной системой.

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

Но написать самому диспетчер вытесняющей многозадачности? - лучше взять готовый.

[MrYuran 16]

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

Проще свой диспетчер задач, что думаете?

Думаю, надо раскрыть смысл слова "проще".

По-моему, все-таки проще галочку в кубе поставить )

Что до "дополнительных ресурсов микроконтроллера", то вообще сферический конь в вакууме. Дополнительные к чему? Вы что, под завязку МК нагружаете?

Нынешние МК начального уровня имеют столько ресурсов, что FreeRTOS их нисколько не убавит. 

В 29.12.2023 в 12:37, dOb сказал:

В простейшем случае - бесконечный цикл с опросом флагов Некоторые даже называют это операционной системой.

Мне на собесе пояснили - это нынче называется паттерн суперлуп )

[AlexRayne 7]

3 минуты назад, MrYuran сказал:

16 минут назад, dOb сказал:

В простейшем случае - бесконечный цикл с опросом флагов Некоторые даже называют это операционной системой.

Мне на собесе пояснили - это нынче называется паттерн суперлуп )

бесконецный цыкл - это наше отечественное, а суперлуп - это ихнее вражье. еще и людьмиХ попахивает.

FreeRTOS конешно хорош. Но на днях освободили ThreadX - она выглядит посолиднее стеками:  драйвера, ФС, сетевой ПИ4+ИП6.

[MrYuran 16]

В 29.12.2023 в 12:54, AlexRayne сказал:

ThreadX - она выглядит посолиднее

Ну вот запустил я в прошлом году Linux Embedded. Походили, посмотрели, языками поцокали. Но в приборе формата кнопки-экран-модбас он там как телеге пятое колесо. Один лишний геморрой.

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

[jcxz 184]

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

И в общем, не совсем понятен смысл ее использования, только дополнительные расход ресурсов микроконтроллера.

Проще свой диспетчер задач, что думаете?

Если возникают такие вопросы, значит - свой диспетчер вы не написать не сможете.

[dOb 8]

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

В принципе, и FreeRTOS может быть излишним

При необходимости можно сконфигурировать так, чтоб убрать все ненужные фичи.

[EdgeAligned 53]

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

оздалось впечатление что это делается пальцем в небо, "примерно с запасом"

Почти да. Хотя конечно всё можно сосчитать до байта, но считать долго и муторно, тем более, что в процессе написания реализация той или иной задачи может меняться, что-то добавляться, что-то убираться. Поэтому "примерно с запасом". 
Впрочем, так же, как и при обычном, "без-ртос" подходе, вы не можете точно до байта предсказать, каков будет расход стека, сколько конкретно переменных вам потребуется. У РТОС просто добавляются расходы на работу ядра. Каждая задача, очередь, семафор и прочее имеет заголовок (дескриптор) некоторого объема. При динамическом выделении памяти блоки памяти выделяются по некоторому правилу, зависящему от примененной программной модели менеджера памяти, и каждый выделяемый блок имеет тоже заголовок. Эти заголовки имеют некоторый точный размер, но во время цикла работы программы точно до байта подсчитать будет муторно.

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

что думаете?

Думаю, что "для каких целей конкретно?" В том плане, что если "кнопочки и УАРТом", грубо говоря, тогда FreeRTOS как "из пушки по воробьям". А если наворотили дисплей с тачскрином, езернет, флешку и еще доталова всякой всячины, тогда РТОС не будет лишний.

[haker_fox 60]

On 12/29/2023 at 4:29 PM, unix said:

Проще свой диспетчер задач, что думаете?

А чем он будет лучше имеющихся? ОСРВ - это не просто переключатель контекста. По архитектуре ОС целые книги написаны. И создание подобного продукта потребует некого  образования в области программирования, знания архитектуры, теории алгоритмов и т.д. и т.п. Почему Вы предполагаете, что сможете с нуля создать проект, превосходящий уже существующий, которому, кстати, более 10 лет?

[Arlleex 131]

Я бы сказал, что при разработке ПО под ОСРВ нужно чутка качать скилл в сторону построения соответствующей архитектуры ПО. Сама по себе ОСРВ - вещь довольно простая: механизм вытеснения/передачи контекста/управления + семафоры. В принципе, на основе этих двух уже можно писать весьма объемные проекты, а все остальное, что щас накручено в том же FreeRTOS - рюшечки, работающие поверх базовых примитивов (в случае упомянутого FreeRTOS - очередей).

Поэтому написать свою ОСРВ - дело нехитрое, при должном понимании процессов.

ИМХО: ОСРВ использовать можно и нужно, но не универсальной таблеткой. Я закладываю там, где проект под пиво за пару вечеров не написать, а на горизонте еще будут видны постоянные доработки и нововведения. Так проще сопровождать и вносить новшества.

А насчет выделения стека - естественно, все гуру для начала полагаются на натренированное чутье, которое, ежели чего, скорректируют активированные ловушки самой ОСРВ.

[x893 35]

3 hours ago, Arlleex said:

А насчет выделения стека - естественно, все гуру для начала полагаются на натренированное чутье, которое, ежели чего, скорректируют активированные ловушки самой ОСРВ.

А начинающие просто смотрят Call Stack Depth и сразу ставят + 10%

[artemkad 53]

В 29.12.2023 в 12:18, jcxz сказал:

Если возникают такие вопросы, значит - свой диспетчер вы не написать не сможете.

А че его писать?

__no_init volatile unsigned char task_timer_flags;
__no_init unsigned char work_task_timer_flags;			// рабочий регистр текущих обрабатываемых флагов


/// Диспетчер задач
void DispatchTask (void)
{
	  {
		__disable_interrupt();
		
			work_task_timer_flags=task_timer_flags;
			task_timer_flags=0;	// все таймера обработаны
		__enable_interrupt();	
	  }
	SystemTask();

	   
	for (char t=0; t<MAX_TASKS; t++)
	  {		// запуск отключаемых задач
		if(work_task_timer_flags & task_table[t].mask)
		  {			// есть ли нужный таймер
			if ( task_table_state[t]> 0x01)
			  {		// отсчет до запуска
				task_table_state[t]--;
			  }
		  }
		if ( task_table_state[t]== 0x01)
		  {		// задача требует запуска
			task_table_state[t]--;
			if(task_table[t].fun)
			  {// запускаю если такая задача существует
				(*task_table[t].fun)();// запуск задачи
			  }
		  }
	  }

}

...

[unix 2]

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

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

Как мне видится FreeRTOS имеет смысл использовать, только если над проектом работает много людей, проще разрулить, если кто-то накосячил.

 

[haker_fox 60]

1 hour ago, unix said:

Как мне видится FreeRTOS имеет смысл использовать, только если над проектом работает много людей, проще разрулить, если кто-то накосячил.

Впервые слышу об использовании ОСРВ в качестве лакмусовой бумажки. Надо обдумать этот необычный и ранее не озвученный нигде опыт.

1 hour ago, unix said:

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

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