Jump to content

    
Sign in to follow this  
MALLOY2

FreeRTOS общие вопросы

Recommended Posts

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

Точнее время IDLE, которое все-же меньше тика и только в том случае, если прерывание попадет на IDLE. Можно сделать аккуратно обход проблемы, можно и абсолютно бездумно железно-тупо не разбирая очереди влепить заплатку от этого, например, взводить глобальный флаг запроса вызова yield() в IDLE, если было послано сообщение из обработчика прерывания вызванного из IDLE. Для малозагруженных систем, которые в основном в IDLE и пребывают некий эффект даст.

Share this post


Link to post
Share on other sites

Подскажите пожалуйста ответ на два вопроса.

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

2. Какую функцию системы надо вызвать, чтобы при очередном YIELD() (или после portRESTORE_CONTEXT() на выходе из прерывания) стал активным какой-то заданный тред.

Share this post


Link to post
Share on other sites
Подскажите пожалуйста ответ на два вопроса.

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

vTaskSuspendScheduler()/xTaskResumeScheduler() это максимально кошерно с фиксацией пропусков тиков, наверстыванием упущенного.... Ну а если чуть-чуть, то запретить прерывания.

2. Какую функцию системы надо вызвать, чтобы при очередном YIELD() (или после portRESTORE_CONTEXT() на выходе из прерывания) стал активным какой-то заданный тред.

YIELD и RESTORE_CONTEXT это вещи вообще-то несколько разные, хотя первая и включает в себя вторую.

Добавить его в соответствующую очередь (не забыть убрать, если уже в какой-то есть). Либо аккуратно 'ручками', либо тупо изменив/задрав ему приоритет через vTaskPrioritySet().

Только, полагаю, Вы опять зря такие манипуляции делать собираетесь :). Обычно достаточно иметь заранее созданные спящие задачи с нужным, путь максимальным приоритетом и просто xTaskResumeFromISR()

Share this post


Link to post
Share on other sites
Ну а если чуть-чуть, то запретить прерывания.

Эта идея у меня была первой, но она сбиват счётчик тиков таймера и влияет на delay() для других тредов.

Только, полагаю, Вы опять зря такие манипуляции делать собираетесь :). Обычно достаточно иметь заранее созданные спящие задачи с нужным, путь максимальным приоритетом и просто xTaskResumeFromISR()

Я так и собирался делать спящий тред, а потом, в нужный мОмент его активизировать.

Я правильно понимаю, что если у треда максимальный приоритет, то прерывание от таймера FreeRTOS не меняет тред на следующий? Тред сменится только если сам тред вызовет YIELD() ?

Share this post


Link to post
Share on other sites
Я правильно понимаю, что если у треда максимальный приоритет, то прерывание от таймера FreeRTOS не меняет тред на следующий? Тред сменится только если сам тред вызовет YIELD() ?

Нет, если он добровольно отправится спать или ждать сообщения. Вызов yield() ничего не изменит - если задача с максимальным приоритетом одна, то она и продолжится. Если задач с одинаковым приоритетом несколько, то переключится на другую с таким-же.

Share this post


Link to post
Share on other sites
Эта идея у меня была первой, но она сбиват счётчик тиков таймера и влияет на delay() для других тредов.

А какая у Вас частота тиков? Потому что "чуть-чуть" это немного. По мне - до 500 мкс. Неужели у Вас тики больше 1000 Гц?

Share this post


Link to post
Share on other sites
6000 кажется.

Очень странное число. Высокие скорости тактирования, если подумать, реально нужны крайне редко, ибо устраивать что-то типа поллингa, вместо обработки событий, не кошерно. И размазывать время тонкими ломтиками между, например, задачами одного приоритета, тоже весьма не частный случай.

Share this post


Link to post
Share on other sites
...ибо устраивать что-то типа поллингa, вместо обработки событий, не кошерно.

А как насчёт поллинга состояния внешнего пина, который не в состоянии вызывать прерывание? Тред например смотрит, пин не в нужном состоянии. Тред делает YIELD(). Прерывания не ожидается, другие треды этот пин вообще не анализируют. Пока не пройдёт несколько тиков и управление не вернётся к первыому треду, он так и не узнает, что пин изменился. Реакция затормозится (можно даже пропустить активность пина). Понятно, что такие важные нюансы работы системы нужно изначально притягивать к прерываниям, но если эта фича всплыла уже после изготовления девайса, то что? Другой вариант решения есть, кроме быстрых тиков?

 

Сам "родил". Сделать частое прерывание от таймера, для выполнение короткого кода анализа пина. А треды пусть обычно (медленно) переключаются. Из IRQ в нужный мОмент активизируется нужный тред и всё. Хотя, если взвесить оверхед, то не пойму что лучше. Разве что реакция ускорится.

Edited by GetSmart

Share this post


Link to post
Share on other sites
Сам "родил"....

Вполне естественно.

Хотя, если взвесить оверхед, то не пойму что лучше.

Слова-то какие. Дергать всю систему под опрос "забытого" пина не оверхед, а несколько команд в обработчике таймерного прерывания .... что за "весы" у Вас? У меня довольно часто используется сканирование в обработчике системного прерывания для фиксации факта неких внешних событий, хотя без проблем можно использовать отдельное прерывание (переферия у меня обычно в FPGA и все, включая дополнительный контроллер прерываний, свое). Но дело в том, что если частота таких внешних событий приближается к частоте системного тика, что происходит под нагрузкой, то потери на отдельный обработчик много больше, нежели на проверку бита в чужом регулярном обработчике. А уменьшение оверхеда в ненагруженной системе меня волнует мало :). "Типичный" обработчик системного прерывания со сканированием пина:

void PreemptiveTick_Ext( void )
{
#if( USE_KVV_IO )
    if( IO0PIN & P0B_SRQ_KVV )
    {
        xTaskResumeFromISR( handle_KVV_task );
    }
#endif
    // Increment the tick counter.
    vTaskIncrementTick();

    // The new tick value might unblock a task.  Ensure the highest task that
    // is ready to execute is the task that will execute when the tick ISR
    // exits.
    vTaskSwitchContext();
    // Ready for the next interrupt.
    EXTINT = EXTINT_EINT1;        // Clear the EXT interrupt flag
    VICVectAddr    = 0;            // Dummy write to signal end of interrupt}
}

Share this post


Link to post
Share on other sites
void PreemptiveTick_Ext( void )
...
}

Спасибо за пример. Но я не понял в нём кое-что. Если это обработчик IRQ, в котором используется xTaskResumeFromISR(), то почему он без макросов сохр/восст. контекста? И правильно ли я понял, что этот обработчик работает для FreeRTOSовских тиков, а оригинальный не используется?

Share this post


Link to post
Share on other sites
правильно ли я понял, что этот обработчик работает для FreeRTOSовских тиков, а оригинальный не используется?

Да, это обработчик тиков который висит вообще не на таймере, а на внешнем прерывании - в данном случае это связное оборудование для которого имеет место быть понятие "сверцикловая синронизация" и удобно иметь 2ms синхронизированное прерывание сверхцикла. Но принципиального значения это не имеет - просто скопипастил из проекта в котором сидел. Обертки находятся снаружи, бо они на ASM.

#if configUSE_PREEMPTION_EXT == 1
vPortPreemptiveTickEntry_Ext:
        portSAVE_CONTEXT                    ; Save the context of the current task...
        ldr     r0, =PreemptiveTick_Ext;   before selecting the next task to execute.
        mov     lr, pc
        bx      r0
        portRESTORE_CONTEXT        ; Restore the context of the selected task.
#endif

Кстати, именно xTaskResumeFromISR() в отличии от vTaskResume() совершенно не требует сохранения/восстановления контекста :), ибо yield() из него НЕ вызывается, а возвращается только признак перепланировки по которому можно вызвать переключение контекста( и тогда обертки нужны ), а можно и не вызывать.

Share this post


Link to post
Share on other sites

объясните непонятливому:

 

как можно корректно отлаживать проект под freertos? среда IAR...

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

без отладчика переключение происходит значительно быстрее (не оценивал).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this