[spectr 0]

Привет, друзья!

 

Вот изучаю как делают RTOS и имею ряд нубских вопросов:

 

1. Для чего каждая задача в ртосах оформляется в вечный цикл? Чтобы не быть завершенной и забытой "естественным путем"? А если задача больше не нужна, то ее надо прибивать самому с помощью какой-нибудь, условно говоря, os_task_kill(this_task)?

2. Конкретно под Cortex-M4. Как понять какие именно регистры сохранять, а какие - не сохранять при переключении контекста (не считая R0-R3, SP, LR, PC)?

3. Для начала достаточно ли будет делать только переключение контекста в PendSV_Handler шедулером или есть еще какие-либо тонкости?

4. Где физически находятся все эти стеки, на которые указывают регистры?

 

Спасибо!

[AlexandrY 2]

Спасибо!

 

Не в каждой RTOS надо делать в задачах циклы.

В MQX RTOS когда задача доходит до конца ее RTOS стирает из системы без следа а заодно и все ресурсы которые задача захватила, и освобождает все объекты синхронизации захваченные задачей и не освобожденные ею.

 

Какие регистры сохранять решает компилятор на основании соглашения с производителем чипов. Для ARM есть такое соглашение которое соблюдают все производители компиляторов под ARM.

 

В вытесняющих RTOS есть как минимум два типа переключателей контекста: переключатель по прерываниям и переключатель программный.

 

Стеки где скажете там и будут.

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

Динамически выделяются из менеджеров памяти которые сами память распределяют из статических областей.

Сами области указываются в конфигурационном файле линковщика.

[yes 5]

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

 

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

 

3. какая RTOS? ну и вряд ли скажу "за все RTOS". как правило пишется один переключатель контекста на ассемблере (из С не получится) и его вызывают из нескольких мест.

 

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

 

[AlexandrY 2]

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

 

Развитые RTOS, как MQX например, сохраняет и регистры сопроцессора.

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

Есть и другие ухищрения при переключении контекста для уменьшения количества сохраняемых регистров.

 

[spectr 0]

Не в каждой RTOS надо делать в задачах циклы.

В MQX RTOS когда задача доходит до конца ее RTOS стирает из системы без следа а заодно и все ресурсы которые задача захватила, и освобождает все объекты синхронизации захваченные задачей и не освобожденные ею.

Понятно, т.е. если задача не удаляется, то после завершения остается висеть в idle и шедулер ее в общем случае тупо пропускает при переключениях?

 

Какие регистры сохранять решает компилятор на основании соглашения с производителем чипов. Для ARM есть такое соглашение которое соблюдают все производители компиляторов под ARM.

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

 

 

 

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

3. какая RTOS?

Не портирую, а пишу свой велосипед. Чисто из интереса и ради лулзов.

 

 

 

Есть и другие ухищрения при переключении контекста для уменьшения количества сохраняемых регистров.

А можно парочку примеров?

[AlexandrY 2]

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

 

Не портирую, а пишу свой велосипед. Чисто из интереса и ради лулзов.

 

А можно парочку примеров?

 

Извиняю конечно, мне ж не известен ваш уровень.

Я написал про случай с автоматическим сохранением. Вполне вариант для кооперативных осей.

 

И где пример посмотреть указал - MQX.

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

 

[spectr 0]

И где пример посмотреть указал - MQX.

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

Ага спасибо, изучаю.

[ViKo 1]

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

Ради чего такие муки? Нескольких тактов, нескольких байтов?

[spectr 0]

Вопрос по стеку задачи.

У каждой задачи есть свой стек, в котором хранятся все её локальные переменные, указатели "на куда-то туда и вон туда", а также указатели на стеки вызываемых внутри функций. Верно?

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

 

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

Ради чего такие муки? Нескольких тактов, нескольких байтов?

Согласен что проще сохранять/восстанавливать все подряд. Ну я думал, может это моветон так просто и четко делать.

[yes 5]

Не портирую, а пишу свой велосипед. Чисто из интереса и ради лулзов.

 

посмотреть советую

1) scmrtos (сильно связана с данным форумом :)

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

3) freeRTOS - серьезный проект с кучей саппорта и т.д.

 

еще есть всякие ecos, rtems

у всего перечисленного ++ в том, что доступны исходники.

 

---------

 

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

 

[AlexandrY 2]

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

 

Скорее так:

 

scmrtos - это не то что RTOS, а такой же велосипед как тут думает делать TC. А на велосипеды доки не бывает в принципе. Т.е. это не пример для изучения.

 

uC/OS это безусловно сила. Именно её и надо изучать OSестроителям за интерес.

 

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

 

А вот если надо изучить RTOS и одновременно сделать Вещь, то MQX самое то.

MQX по движку аналогична uC/OS и freeRTOS.

К линуксу никакого отношения не имеет. Если не думать что родство с линуксом определяется по наличию функций read и write в структурах драйверов.

 

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

Поэтому MQX очень легко связать с линуксом в мультикристальных SoC-ах

[yaghtn 0]

MQX по движку аналогична uC/OS и freeRTOS.

А кому из них аналогичнее?

Возврат из прерывания в MQX происходит как в uC/OS-II через выяснение и переключение на самую приоритетную из задач?

Или как во FreeRTOS, прерывание может вернуть управление именно туда, что прервалось, без переключений контекста?

 

MQX сейчас доступен для чего-либо, кроме kinetis?

Судя по тому, что freescale.com редиректит на nxp.com, стоит ли ждать MQX для NXP?

 

[becopt 0]

Вопрос по стеку задачи.

У каждой задачи есть свой стек, в котором хранятся все её локальные переменные, указатели "на куда-то туда и вон туда", а также указатели на стеки вызываемых внутри функций. Верно?

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

 

Начните с того, что поиграйтесь с дизасмом и посмотрите где и как компилятор размещает глобальные/локальные переменные, аргументы функций и прочее. Очень интересно и по-новому позволяет смотреть на свой код :)

 

А по велосипедству: сначала очень полезно почитать классику (Танненбаум)) и полистать чужие реализации (замечательная статья про TNeo).

[dxp 32]

А на велосипеды доки не бывает в принципе.

А что такое?

 

[AHTOXA 14]

scmrtos - это не то что RTOS, а такой же велосипед как тут думает делать TC. А на велосипеды доки не бывает в принципе. Т.е. это не пример для изучения.

Всё понятно, "Пастернака не читал, но осуждаю". К вашему сведению, scmRTOS издавна поставляется с отличной документацией.

 

ЗЫ. Вам хоть приплачивают за рекламу MQX? Или это вы добровольно? :)