zltigo 0 17 ноября, 2009 Опубликовано 17 ноября, 2009 · Жалоба Т.е. получается, что в худшем случае высокоприоритетная задача будет ждать 1 тик? Точнее время IDLE, которое все-же меньше тика и только в том случае, если прерывание попадет на IDLE. Можно сделать аккуратно обход проблемы, можно и абсолютно бездумно железно-тупо не разбирая очереди влепить заплатку от этого, например, взводить глобальный флаг запроса вызова yield() в IDLE, если было послано сообщение из обработчика прерывания вызванного из IDLE. Для малозагруженных систем, которые в основном в IDLE и пребывают некий эффект даст. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 19 ноября, 2009 Опубликовано 19 ноября, 2009 · Жалоба Подскажите пожалуйста ответ на два вопроса. 1. Как "кошерно" заблокировать переключение нужного (или текущего) треда во FreeRTOS-овском прерывании от таймера. То есть, работая в этом треде чтобы не произошло (неожиданного) переключения на другой тред. 2. Какую функцию системы надо вызвать, чтобы при очередном YIELD() (или после portRESTORE_CONTEXT() на выходе из прерывания) стал активным какой-то заданный тред. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 19 ноября, 2009 Опубликовано 19 ноября, 2009 · Жалоба Подскажите пожалуйста ответ на два вопроса. 1. Как "кошерно" заблокировать переключение нужного (или текущего) треда во FreeRTOS-овском прерывании от таймера. То есть, работая в этом треде чтобы не произошло (неожиданного) переключения на другой тред. vTaskSuspendScheduler()/xTaskResumeScheduler() это максимально кошерно с фиксацией пропусков тиков, наверстыванием упущенного.... Ну а если чуть-чуть, то запретить прерывания. 2. Какую функцию системы надо вызвать, чтобы при очередном YIELD() (или после portRESTORE_CONTEXT() на выходе из прерывания) стал активным какой-то заданный тред. YIELD и RESTORE_CONTEXT это вещи вообще-то несколько разные, хотя первая и включает в себя вторую. Добавить его в соответствующую очередь (не забыть убрать, если уже в какой-то есть). Либо аккуратно 'ручками', либо тупо изменив/задрав ему приоритет через vTaskPrioritySet(). Только, полагаю, Вы опять зря такие манипуляции делать собираетесь :). Обычно достаточно иметь заранее созданные спящие задачи с нужным, путь максимальным приоритетом и просто xTaskResumeFromISR() Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 19 ноября, 2009 Опубликовано 19 ноября, 2009 · Жалоба Ну а если чуть-чуть, то запретить прерывания. Эта идея у меня была первой, но она сбиват счётчик тиков таймера и влияет на delay() для других тредов. Только, полагаю, Вы опять зря такие манипуляции делать собираетесь :). Обычно достаточно иметь заранее созданные спящие задачи с нужным, путь максимальным приоритетом и просто xTaskResumeFromISR() Я так и собирался делать спящий тред, а потом, в нужный мОмент его активизировать. Я правильно понимаю, что если у треда максимальный приоритет, то прерывание от таймера FreeRTOS не меняет тред на следующий? Тред сменится только если сам тред вызовет YIELD() ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 19 ноября, 2009 Опубликовано 19 ноября, 2009 · Жалоба Я правильно понимаю, что если у треда максимальный приоритет, то прерывание от таймера FreeRTOS не меняет тред на следующий? Тред сменится только если сам тред вызовет YIELD() ? Нет, если он добровольно отправится спать или ждать сообщения. Вызов yield() ничего не изменит - если задача с максимальным приоритетом одна, то она и продолжится. Если задач с одинаковым приоритетом несколько, то переключится на другую с таким-же. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
HARMHARM 0 19 ноября, 2009 Опубликовано 19 ноября, 2009 · Жалоба Эта идея у меня была первой, но она сбиват счётчик тиков таймера и влияет на delay() для других тредов. А какая у Вас частота тиков? Потому что "чуть-чуть" это немного. По мне - до 500 мкс. Неужели у Вас тики больше 1000 Гц? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 19 ноября, 2009 Опубликовано 19 ноября, 2009 · Жалоба Неужели у Вас тики больше 1000 Гц? 6000 кажется. А сидеть в треде приходится до 1/200 сек, то есть 30 тиков. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 19 ноября, 2009 Опубликовано 19 ноября, 2009 · Жалоба 6000 кажется. Очень странное число. Высокие скорости тактирования, если подумать, реально нужны крайне редко, ибо устраивать что-то типа поллингa, вместо обработки событий, не кошерно. И размазывать время тонкими ломтиками между, например, задачами одного приоритета, тоже весьма не частный случай. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 20 ноября, 2009 Опубликовано 20 ноября, 2009 (изменено) · Жалоба ...ибо устраивать что-то типа поллингa, вместо обработки событий, не кошерно. А как насчёт поллинга состояния внешнего пина, который не в состоянии вызывать прерывание? Тред например смотрит, пин не в нужном состоянии. Тред делает YIELD(). Прерывания не ожидается, другие треды этот пин вообще не анализируют. Пока не пройдёт несколько тиков и управление не вернётся к первыому треду, он так и не узнает, что пин изменился. Реакция затормозится (можно даже пропустить активность пина). Понятно, что такие важные нюансы работы системы нужно изначально притягивать к прерываниям, но если эта фича всплыла уже после изготовления девайса, то что? Другой вариант решения есть, кроме быстрых тиков? Сам "родил". Сделать частое прерывание от таймера, для выполнение короткого кода анализа пина. А треды пусть обычно (медленно) переключаются. Из IRQ в нужный мОмент активизируется нужный тред и всё. Хотя, если взвесить оверхед, то не пойму что лучше. Разве что реакция ускорится. Изменено 20 ноября, 2009 пользователем GetSmart Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 20 ноября, 2009 Опубликовано 20 ноября, 2009 · Жалоба Сам "родил".... Вполне естественно. Хотя, если взвесить оверхед, то не пойму что лучше. Слова-то какие. Дергать всю систему под опрос "забытого" пина не оверхед, а несколько команд в обработчике таймерного прерывания .... что за "весы" у Вас? У меня довольно часто используется сканирование в обработчике системного прерывания для фиксации факта неких внешних событий, хотя без проблем можно использовать отдельное прерывание (переферия у меня обычно в 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} } Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 20 ноября, 2009 Опубликовано 20 ноября, 2009 · Жалоба void PreemptiveTick_Ext( void ) ... } Спасибо за пример. Но я не понял в нём кое-что. Если это обработчик IRQ, в котором используется xTaskResumeFromISR(), то почему он без макросов сохр/восст. контекста? И правильно ли я понял, что этот обработчик работает для FreeRTOSовских тиков, а оригинальный не используется? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 20 ноября, 2009 Опубликовано 20 ноября, 2009 · Жалоба правильно ли я понял, что этот обработчик работает для 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() из него НЕ вызывается, а возвращается только признак перепланировки по которому можно вызвать переключение контекста( и тогда обертки нужны ), а можно и не вызывать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DSP-Starter 0 1 марта, 2010 Опубликовано 1 марта, 2010 (изменено) · Жалоба А никто не видел порт для blackfin? Изменено 1 марта, 2010 пользователем DSP-Starter Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 63 1 марта, 2010 Опубликовано 1 марта, 2010 · Жалоба А никто не видел порт для blackfin? В 5.3.0 был среди Unsupported_Demos. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dead_cell 0 1 июня, 2010 Опубликовано 1 июня, 2010 · Жалоба объясните непонятливому: как можно корректно отлаживать проект под freertos? среда IAR... скорее всего я что то недопонимаю в настройках проекта или еще где то.... когда берет управление сама ось, начинаются тормоза, переключение задач происходит за какие миллисекунды :) без отладчика переключение происходит значительно быстрее (не оценивал). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться