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

[Demiurg]

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

[ARV]

на ассемблере не стоит... если вы не сделали нормальную совместимость с avr-gcc

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

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

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

[Мурик]

Вот я и предлагаю узнать сколько памяти нужно под задачу с определенным размером стека. Под STM32 со стеком 128 байт, нужно около 608 байт на каждую задачу (не проверял, пишу то что прочитал в статье на хабре). Под AVR возможно потребуется меньше, т. к. адресация 2-ух байтная и регистры одно байтные.

[ARV]

вообще-то тему я создал, чтобы самому спрашивать, а вы тут мне предлагаете ответы для вас искать
до freeRTOS еще руки не дошли, но с упомянутой ранее YAVRTOS на задачу типа "мигалка светодиодом" хватало только 64 байт на стек, а на такую же задачу с printf-выводом было надо порядка 300 байт, точно не помню.

[Мурик]

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

За вас вашу работу делать не будут. Могут только указать правильное направление.

хватало только 64 байт на стек, а на такую же задачу с printf-выводом было надо порядка 300 байт

Возьмите ATMega16/32 или подобную. Подключитесь к ней отладчиком через JTAG и сможете смотреть содержимое переменных без всяких printf.

[ARV]

За вас вашу работу делать не будут

работа и вопросы об инструменте для работы - разные вещи.

Возьмите ATMega16/32 или подобную.

у меня at90can128

Подключитесь к ней отладчиком через JTAG

не подключается тот отладчик, что куплен в Китае - безымянный клон AVR JTAGice.

смотреть содержимое переменных без всяких printf

printf мне нужен сам по себе

[Аlex]

[uquote="Мурик",url="/forum/viewtopic.php?p=3557455#p3557455"]Под STM32 со стеком 128 байт, нужно около 608 байт на каждую задачу (не проверял, пишу то что прочитал в статье на хабре).[/uquote]
Не 128 байт, а 128 слов ! Для 32-ух битных платформ, умножаем это значение на 4, соответственно.
Не отсебятину всяких "писателей" нужно читать, а офф. доку.

[Demiurg]

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

Кооперативный: этот диспетчер тупо переключает задачи. А смысл, если можно сделать просто список-вызовы подпрограмм (асм) или функций (си).

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

Main:
   wdr
   rcall   Service_Timers
   rcall   KBD_DRV
   rcall   Proc_Emerg_Sens
   rcall   Proc_Heater
   rcall   Proc_Fan
   rcall   Proc_ADC
   rcall   Proc_Pump
   rcall   Proc_Heat_Err
   rjmp   Main

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

__C_task main (void)
{
   wdt_enable (WDTO_15_MS);

   sleep_mode_init ();

   init_soft_timers ();
   Init_Events ();

   io_init ();

   __enable_interrupt ();

#ifdef __LOGO__
   logo ();
#endif

   while (1)
   {
      __watchdog_reset ();

      proc_device ();

      kbd_drv ();
      info_service ();
      proc_outputs ();

      Process_Events ();
   }
}

Вытесняющий: переключение по квантам времени. В этом случае процесс выполняется квант времени. Если полезные действия выполнены, процесс тупо висит в цикле. Вопрос: зачем, какой смысл, никакой полезной работы.

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

И конечно же знание архитектуры и возможностей МК AVR.

Используя эти правила я до сих пор не дошел до той ситуации, что мне жизненно потребовалось бы использование диспетчеров или RTOS.

[ARV]

Используя эти правила я до сих пор не дошел до той ситуации, что мне жизненно потребовалось бы использование диспетчеров или RTOS.

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

метод дробления процессов и последовательного вызова таких вот "дробленых" функций я в полной мере реализовал в своем последнем "большом" проекте. вот главная функция этого проекта в подтверждение:

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

MAIN(){
   uint8_t nosleep;

   while(1){
      power_off();
      nosleep = 1;
      reset_power_timeout();

      do{
         if(!lock_input){
            // получение семплов и FFT-разложение
            sample_and_fft();         //  1 mS (7 mS without DOUBLE_BUFFERED_SAMPLING)
            // подготовка параметров мелодии
            prepare_samples(&music);   // ~1 mS
         }
         // затухание
         fade();                  // < 60 uS
         // формирование светового эффекта
         execute_effect(&music);
         // обновление линейки светодиодов
         ws2812_show();            // ~1.6 mS
         // управление (кнопки, энкодер, ДУ)
         do_control(&music);         // ~2 uS
         // автоотключение питания
         nosleep = !power_timeout(&music);
         // синхронизация
         synchronize();            //
      } while(nosleep);
   }
}

как видите, в главном цикле последовательно вызываются "процессы", каждый из которых сам занимается тем, что по внутренним состояниям что-то там делает свое. в основном, состояний два: пропустить работу (аналог sleep) и выполнить работу. синхронизация в конце цикла - это тупое ожидание момента истечения отрезка в 10 мс по таймеру, чтобы получилась жесткая привязка всех процессов к "тикам". чем не RTOS?
в этом проекте у меня задействовано только одно-единственное прерывание - для работы с IR-датчиком дистанционного управления, все остальные функции реализованы именно вышеописанным способом:
- семплирование звука
- FFT-анализ звука
- расчет "эффекта"
- обновление информации в цепочке WS2812B (до 128 штук)
- обработка кнопки и энкодера
- обработка команд ДУ
- вывод на ЖКИ (в том числе и "динамического спектра")
то есть я хочу сказать, что принцип вполне работает и дает неплохие результаты.
но!
все-таки это не красиво. громаднейшая куча if-ов по "состояниям", постоянные локально-статические переменные для этих состояний, постоянная слежка за тем, чтобы ничего дольше нескольких миллисекунд в теле "процесса" не было... не красиво, не радует больше.

сейчас затеял некий проект (очередной велосипед - но я никогда не повторяю чужие проекты 1 в 1), в котором использую GSM-модем и MP3-плейер, которые управляются по USART. и оба этих чудесных модуля имеют весьма занятный алгоритм работы: получив команду они могут ответить на неё спустя непредсказуемое количество времени, доходящее до единиц минут! представляете, каково ожидать эти ответы "по состояниям"? причем в процессе ожидания ответа на команду "А" оба девайса могут (и часто должны это делать по общему алгоритму) продолжать принимать команды... то есть вполне реальна сиуация, когда ожидаяя ответ на команду "А" придет ответ на команду "В", или вообще на команду "Y", отправленную "пять минут назад"... не, без нормальной ОС, которая позволит мне сделать любое количество "тупых циклов" ожидания чего угодно, сохранив при этом возможность реакции на "неожиданные" события, решить мои задумки будет хоть и можно, но просто душераздирающе ужасным кодом...

хочу красиво.

[Demiurg]

Подталкиваю в нужном направлении - возьмем простейший пример: опрос клавиатуры. Никто не знает, когда нажмут кнопку. Может быть вообще ни разу за одно включение устройства. Но никто же не парится по этому поводу...
Мои учителя мне советовали так: если код превращается в нечто неудобоваримое, пересматривай программу, подходы. И это работает. Доходило до дого, что я выкидывал прежние наработки и переписывал ПОЛНОСТЬЮ весь проект.
Проблему можно решить только поднявшись над ней. Абстрагироваться от нее. Перестать вариться внутри и смотреть со стороны. Сверху, снизу, всяко разно. Декомпозиция, анализ, синтез. Между прочим - это жизненно важный подход. И работает не только в программировании.

[ARV]

зачем меня подталкивать в том направлении, откуда я ушел?

Добавлено after 1 minute 9 seconds:

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

золотые люди были ваши учителя. умные вещи говорили я и намерен поменять подход. принципиально.

Добавлено after 1 hour 13 minutes 29 seconds:
по техническим причинам пока руки до "пощщупать" не доходят, но доходят до "продолжать искать". и наткнулся на пару занятных вещей попроще (как мне кажется) freeRTOS, но со всеми необходимыми мне возможностями: FunkOS и Mark3 RTOS - одного и того же автора. заодно и на симулятор AVR наткнулся из-под его "пера" flAVR.

однако, если с FunkOS понятно, как её к своему проекту прилепить, и как модифицировать под другую архитектуру (странно: этот автор как-то игнорирует atmega128, делая свои оси в расчете на 32-е меги или сразу 256-е...), то с Mark3 все гораздо хуже (для меня): она на С++ написана и, как я понял из документации, собирается какими-то приблудами не из комплекта avr-gcc в библиотеку, которую затем можно присоединить к своему проекту... может, кто-либо разбирающийся в процессах сборки при помощи утилит CMake и др. расскажет мне, как скомпоновать свой проект привычными способами? привычно для меня - это "положить исходник/папку с исходниками в папку проекта" (идеология Eclipse CDT), и на этом все...

и еще: симулятор flAVR доступен в исходниках... собрать-то я его смогу, пожалуй, MingW есть, но вот о том, как ео к gdb из Eclipse подключить - не понятно... и как под мой камушек настроить тоже. найдется кто-либо, чтобы подсказать?

[Demiurg]

[uquote="ARV",url="/forum/viewtopic.php?p=3557946#p3557946"]золотые люди были ваши учителя. умные вещи говорили [/uquote]
Эти "золотые люди" на caxapa.ru сидят. Попробуй туда обратиться. Либо на electronix.ru

[ARV]

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

и вот что получилось.

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

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

вы возразите: так увеличился подпорченой памяти в куче! сэкономил в старших адресах ОЗУ - потерял в младших. натянул одеяло доступной памяти на ноги - голова замерзнет!

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

вопросы быстродействия не очень актуальны, т.к. память нужна задачам, которые сами по себе не быстрые: запись на SD-карту, чтение с нее, общение по USART с GSM-модемом или MP3-плейером... все это по сути своей довольно неторопливое, и несколько микросекунд на работу malloc/free ничего в их судьбе не изменят...

как считаете, логично я рассуждаю или нет? стоит в этом направлении дальше думать или ... ?

[Мурик]

Есть такое понятие как фрагментация памяти. Смысл в том что malloc может выделить только непрерывный участок памяти и если раньше память выделялась и освобождалась, может возникнуть ситуация что необходимый объем есть, но он фрагментирован и непрерывной области нет. Из-за этого malloc будет возвращать 0.
Во FreeRTOS на этот случай есть аналог malloc/free с дефрагментацией памяти.

heap_4.c — Динамическое выделение памяти, может дефрагментировать память, чтобы получить нужный кусок. Разумеется за все приходится платить. Временем в первую очередь.

http://purebasic.mybb.ru/viewtopic.php?id=616

[ARV]

Во FreeRTOS на этот случай есть аналог malloc/free с дефрагментацией памяти.

я в курсе

имхо, проблема зарат времени на дефрагментацию сильно преувеличена: под кучу в рассматриваемом случае будет выделено от силы 2,5 килобайта ОЗУ (думаю, это сильно завышенная оценка), обращение к куче будет вестись из одних и тех же задач с одними и теми же запросами фиксированных размеров. то есть, если в одной задаче под манипуляцию со строками я выделяю 64 байта, то и в другой задаче тоже 64 потребуется. соответственно, шансы попасть на фрагментацию уменьшаются. но и в том случае, если необходимость возникнет - сколько времени потребуется на это? 100 мкс? 500 мкс? или сколько? USART на скорости 9600 за это время не успеет даже 1 байт передать/принять! за 500 мкс 2,5 килобайта можно раз 50 дефрагментировать при тактовой 8 МГц.
в чем проблема-то?

[ARV]

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

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

так вот: самый большой стек потребовался задаче, которая при помощи FatFS в минимально-полнофункциональной конфигурации (чтение/запись) осуществляет прием сообщений от других задач и выводит их на SD-карту. и размер стека под эту задачу должен быть не менее 360 байт - я выделил 400. Chan много локальных переменных у себя использует в функциях... ничего не поделать.

остальные задачи пока что обходятся стеком в 128 байт, а пара задач (в т.ч. Idle) и того меньше - 80.

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

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

хуже всего дело обстоит с USART-ом на прием... пока сделал буфер 60 байт, но временами приходится его отключать, чтобы принять уже поллингом сплшной пакет в 300 с лишним байт. корявенько, но работает.

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

в общем, я все сильнее укрепляюсь в мысли, что RTOS для AVR вполне приемлема и даже удобна. особенно, если ОЗУ имеется ну никак не менее 2К, а лучше 4. если кто решится испытать судьбу - рекомендую, и даже смогу дать советы по упомянутой ОС. теперь я могу считать себя практиком в этой области

[Аlex]

я не применяю в "традиционном" для OS смысле: обрабатываю прерывания по-старинке, и лишь по необходимости посылаю сообщения в задачи.

Тут нужно быть аккуратнее.
Не знаю как в FunkOS , а например в FreeRTOS использование сервисов ОС в прерываниях можно только в прерываниях, подконтрольных самой ОС.
Что значит "подконтрольных самой ОС". Это те прерывания, обработка которых передаётся и возвращается с помощью неких сервисов (работающих с контекстом) с применением АСМ-вставок. Ну и приоритетом не выше установленного в настройках ОС.
В противном случае глюки неизбежны.

[Мурик]

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

Посмотрите. http://purebasic.mybb.ru/viewtopic.php?id=616
Там правда другой МК, но принцип создания проекта с FreeRTOS примерно такой же.

[ARV]

Тут нужно быть аккуратнее.

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

Там правда другой МК

в том и проблема, что другой. как ни странно, я так не смог понять, надо ли при портировании учитывать кое-какие особенности внутреннего устройства, и если надо, то каким образом. самое простое: у МК с более чем 64К FLASH для доступа к этой памяти исползуется отдельный регистр RAMPZ, коорый по идее должен входить в "контекст" задачи. но конкретно об этом я нигде упоминаний не встречал... удивительно, но почти все доступные мне RTOS имеют порт либо на МК с памятью не более 64К, либо сразу 256 и лучше, а 128, как назло, нет... приходится самому додумывать.

[7seg]

@ARV , не смотрел в сторону отечественных ОСРВ ? был на презентации FX-RTOS , уж очень вкусная на слова она. (сам не щупал).
Мб есть у кого опыт ? просто сам хочу начать знакомство с RTOS именно с нее в будущем.