Вытесняющая многозадачная ОС. Практика AVR

[Мурик]

Если есть FPU, а речь шла о мощных мк, то 128 байт уйдет только на 32 дополнительных регистра.

У них обычно больше 100 КБ ОЗУ , но есть МК по проще, без аппаратной поддержки плавающей точки.

[Аlex]

Мурик писал(а):

А 500 байт - это для мощных МК с кучей служебных регистров

14 регистров это много, согласен.

Ну и зачем Вам тогда минимум 500 байт на задачу ?

[ARV]

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

[Аlex]

Раман, не ругайся, срачи пока нет никакой
Ты почитал доку, которую я прикрепил ? Там достаточно хорошо всё расписано. И про очереди в том числе (на 7 страниц расписано про них).
Меня, например, этот мануальчик очень выручил при въезде в FreeRtos.

PS: Мурик, не пугай людей обманчивой информацией.

[Мурик]

Ну и зачем Вам тогда минимум 500 байт на задачу ?

Разве я писал FreeRTOS?
Это значения по умолчанию.

Код:

#define configUSE_PREEMPTION      1
#define configUSE_IDLE_HOOK         1
#define configUSE_TICK_HOOK         0
#define configCPU_CLOCK_HZ         ( ( unsigned long ) 72000000 )
#define configTICK_RATE_HZ         ( ( TickType_t ) 1000 )
#define configMAX_PRIORITIES      ( 5 )
#define configMINIMAL_STACK_SIZE   ( ( unsigned short ) 128 )
#define configTOTAL_HEAP_SIZE      ( ( size_t ) ( 10 * 1024 ) )
#define configMAX_TASK_NAME_LEN      ( 16 )
#define configUSE_TRACE_FACILITY   0
#define configUSE_16_BIT_TICKS      0
#define configIDLE_SHOULD_YIELD      1
#define configUSE_MUTEXES         1

[Аlex]

Это значения по умолчанию.

И что ?
А если там по-умолчанию будет по 500 КБайт, можно смело заявлять, что меньше ставить нельзя ?
Мурик, сходи на офф сайт ОСи и почитай как расчитывается память под стек задач. А людей тут в заблуждение вводить не нужно.

[Мурик]

Меньше поставить можно, но где гарантия нормальной работы при множестве локальных переменных? В соседнем разделе я приводил пример когда может возникнуть переполнение стека из-за невнимательности. https://radiokot.ru/forum/viewtopic.php ... 0#p3555700

[ARV]

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

[Аlex]

Мурик писал(а):

Меньше поставить можно, но где гарантия нормальной работы при множестве локальных переменных?

Мурик, ты себя хоть слышишь со стороны ?
Ты сказал, что необходимо не менее 500 байт на задачу, т.б. - минимум 500 байт !
Минимум подразумевает - отсутствие дополнительных затрат ! А ты начинаешь про какое-то множество локальных переменных говорить
С дури можно и огромные массивы запихнуть в локальные переменные задач. И что это значит ? Да ничего, кроме отсутствия мозгов у программиста

Повторюсь :

Аlex писал(а):

Мурик, сходи на офф сайт ОСи и почитай как расчитывается память под стек задач. А людей тут в заблуждение вводить не нужно.

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

Добавлено after 2 minutes 49 seconds:

ARV писал(а):

придется взяться за freeRTOS...

Берись, не пожалеешь. Вполне себе нормальная ОСь.
Есть, конечно, нюансики, не без этого. Но это всё - мелочь...

[Ser60]

ARV - может Вам небезынтересно будет посмотреть нa uC/OS-III фирмы Micrium. Она также свободная для некоммерческих проектов. Сам с ней сейчас работаю и советую её по нескольким причинам, возможно субьективным. Помимо того, что прошёл два 3-дневных трейнинга по ней когда фирма к нам приезжала, сейчас плотно работаю с семейством EFM32, где она дефолтная после поглощения фирмы силлабами. Однако, судя по вебсайту фирмы, имеется адаптация этой RTOS под мегу-128 и около 50 других архитектур. Для AVR я её не пробовал, но возился достаточно долго с портированием её на EFM32PG1/ JG1 и уменьшением футпринта и тактированием проекта от RTC для снижения токопотребления во сне, первое скорее для спортивного интереса. Поэтому полагаю, что и с менее жирными мегами работать будет.

Выше Вы задали вопрос начального уровня насчёт очередей. По нему проконсультировать смогу, но это и по мануалу API несложно понять, похоже и Вы с этим тоже разобрались. А дальше, на вебсайте фирмы имеется оперативный форум, где на вопросы отвечают профессиональные разработчики фирмы. Думал даже статью написать сюда о создании процессов, работе с семафорами, очередями и пр. под этой RTOS, не знаю будет-ли интересно сообществу (?) Кстати, для визуального контроля использования стека и многого другого советую попробовать системы SystemView от Segger и uC/Probe от самой Micrium. Правда, не задавался вопросом будут-ли они работать с чем-то помимо ARM.

[ARV]

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

[Мурик]

Ты сказал, что необходимо не менее 500 байт на задачу, т.б. - минимум 500 байт !

Я написал.

Это значения по умолчанию.

Т. е. это необходимый минимум с настройками по умолчанию. Не верите мне, посмотрите что пишут другие. https://habr.com/ru/post/249273/

Спойлер

В общем все однотипно.

Компилируем, заливаем … и получаем фигу. Полную. Ни один светодиод не мигает.

Путем отладки методом комментирования выясняем, что 3 потока работают, а 4 – уже нет. В чем проблема? Проблема в выделенной памяти для шедулера и стека.

Смотрим в FreeRTOSConfig.h

Код:

#define configMINIMAL_STACK_SIZE ((unsigned short)128)
#define configTOTAL_HEAP_SIZE ((size_t)3000)

3000 байт на все и каждой задаче 128 байт. Плюс еще где-то надо хранить информацию о задаче и прочем полезном. Вот поэтому, если ничего не делать, планировщик при нехватке памяти даже не стартует.

Судя по факам, если включить полную оптимизацию, то сам FreeRTOS возьмет 250 байт. Плюс на каждую задачу по 128 байт для стека, 64 для внутреннего списка и 16 для имени задачи. Считаем: 250+3*(128+64+16)=874. Даже до килобайта не дотягивает. А у нас 3 …

Втыкаем брекпоинты и получаем следующие цифры: перед созданием задачи было 2376 свободных байт, а после 1768. То есть на одну задачу уходит 608 байт. Проверяем еще. Получаем цифры 2992-2376-1768-1160. Цифра совпадает. Путем простых логических умозаключений понимаем, что те цифры из фака взяты для какого-нибудь дохлого процессора, со включенными оптимизациями и выключенными всякими модулями. Смотрим дальше и понимаем, что старт шедулера отьедает еще примерно 580 байт.

В общем, принимаем для расчетов 610 байт на задачу с минимальным стеком и еще 580 байт для самой ОС. Итого в TOTAL_HEAP_SIZE надо записать 610*9+580=6070. Округлим и отдадим 6100 байт – пусть жирует.

Компилируем, заливаем и наблюдаем, как мигают все светодиоды разом. Пробуем уменьшить стек до 6050 – опять ничего не работает. Значит, мы подсчитали правильно

[ARV]

любые рассуждения о требуемом ОЗУ - пустые разговоры без уточнения типа МК. для "пустого" AVR-проекта цифра даже в 128 байт под стек выглядит устрашающей, должно хватать 64 байт, а если никаких иных, кроме "тика", прерываний нет, то и 32 должно хватать (в теории).

[Мурик]

В ваших проектах вложенность вызовов функций не больше 1?
В функциях нет ни одного аргумента?
Нет локальных переменных?
Все прерывания запрещены?

[ARV]

не могу сказать, что разбираюсь в RTOS лучше всех, но кой-какой анализ могу сделать на основе своего опыта.
итак.
1. вложенность функций. поскольку я имею дело исключительно с avr-gcc, который передает параметры функций практически всегда через регистры, на каждую вложенную функцию тратится всего 2 байта стека. а если писать с небольшим старанием, то многие вложенные функции (как минимум - самописные) в рамках многозадачной ОС будут проинлайнены в "главную" функцию задачи.
2. про аргументы уже сказал
3. локальные переменные... да. но, поскольку я уточнил, что говорил о "пустом" проекте, в частности, страшно популярном проекте параллельного мигания светодиодами, таки да, локальных переменных там нет
4. прерывания - особый случай. с одной стороны, в RTOS функция прерывания "должна" быть сведена к установке семафора, с другой стороны, такой подход де-факто мало применяется по очевидным причинам. тем не менее, для многих проектов, где взаимодействие с периферией ведется поллингом (а при наличии RTOS так работать можно почти с любой периферией!), прерывания, кроме системного тика, не нужны.

тем не менее, анализ без цифр - пустая болтовня. попробую посчитать. в AVR контекст - это 32 рабочих регистра и SREG. ну, в некоторых случаях еще и RAMPZ - итого 34 байта. так как в AVR вложенные прерывания скорее экзотика, чем реальность, требуется стек только на 1 вход, т.е. 34 байта. плюс адрес возврата - итого 36 (погорячился я ранее). Пусть вложенность функций равна 3 (довольно много на самом деле), еще 6 байт, итого 40. накидываем на локальные переменные еще 24 - итого 64 байта. это и есть тот минимум, начиная с которого можно надеяться на нормальную работу задачи в RTOS. кстати, в attiny13 именно столько ОЗУ, и при имеющихся прерываниях мне до сих пор никогда в голову не приходило ограничивать вложенность функций в своих проектах. как и сильно переживать насчет локальных переменных (правда, соответственно "мощности" МК и нужды в локальных переменных сильно не возникало).

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

допустим, мы разрешаем вложенные прерывания. в известных уже мне RTOS это равносильно тому, что системное прерывание может возникать в то время, как идет обработка "несистемного" - не более того. т.е. 2 входа в стек, т.е. к ранее озвученным 64 байтам надо добавить еще 36, итого 100. плюс на что-то неучтенное, фантастическое - 128 байт должно хватить даже с "лишними" прерываниями.

я в чем-то не прав? это, естественно, теория. не факт, что на самом деле все именно так, но порядок цифр должен сохраняться. 500 байт для AVR - это явно избыточная величина, в эти байты должны поместиться локальные буферы по 64 байта в каждой вложенной функции - для самодельных проектов на AVR это, имхо, просто фантастические предположения.

а вот для других семейств МК все может быть страшнее, но сейчас речь не о них.

[Мурик]

Запустите FreeRTOS на AVR и посмотрите методом вызова функции xPortGetFreeHeapSize() до и после создания задачи, сколько памяти на нее требуется при известном размере стека. В ссылке выше про это написано.

[Аlex]

посмотрите методом вызова функции xPortGetFreeHeapSize() до и после создания задачи, сколько памяти на нее требуется при известном размере стека

Результат будет = "предыдущее значение - размер стека задачи". Можете даже не проверять. Сервис xTaskCreate выделяет в куче сразу необходимое кол-во памяти.
xPortGetFreeHeapSize реально может понадобится только в случае интенсивного динамического выделения/освобождения памяти в программе.

[Demiurg]

Я когда писал самодельный вытесняющий диспетчер, получились следующие цифры: 16 либо 32 регистра. Этот параметр на уровне компилятора. SREG, стек, и запас для вложенных функций и прерываний. Я не стал заморачиваться, и сделал блок на задачу размером 64 байта. Не помню как сделал стек задач, вверх или вниз, вечером гляну. Адреса переменных, массивов были заданы жёстко. Динамическое выделение памяти у меня не было реализовано.

[ARV]

посмотрите методом вызова функции xPortGetFreeHeapSize() до и после создания задачи

система кучи в freeRTOS мне пока не полностью понятна, но я подозреваю, что если сделать размер кучи точно равной потребностям задач, и отказаться от динамического выделения памяти (что вполне традиционно для embedded), то на остальное (т.е. на стеки задач) останется приличное количество.

куча - это под нужды самой RTOS, или под запросы от задач тоже? в альтернативных RTOS видел всегда статическое выделение памяти под все нужды ОС - под дескрипторы задач, под стеки, под стек системы и т.п. никаких куч.

как работает malloc-free в реализации avr-libc я тоже не очень понял. в экспериментах с YAVRTOS столкнулся со странным фактом: до запуска планировщика malloc вделет память, а после запуска попытка выделить память в любой из задач всегда неудачна. планировщик, судя по исходнику, динамическим распределением памяти никак не занимается... как так то?

Добавлено after 2 minutes:

Я когда писал самодельный вытесняющий диспетчер, получились следующие цифры: 16 либо 32 регистра

16 регистров для AVR - очень опасная величина. теоретически это возможно только при условии не применения никаких библиотечных функций из libc. но и то только теоретически.

[Мурик]

Сервис xTaskCreate выделяет в куче сразу необходимое кол-во памяти.

Вот и необходимо узнать сколько байт на это требуется. Как узнать написал выше.

отказаться от динамического выделения памяти (что вполне традиционно для embedded)

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