juvf 10 5 февраля, 2014 Опубликовано 5 февраля, 2014 · Жалоба для этого существуют эвэнты. в v8.0 наконецто их добавили. задачи Б, С, Д блокируй в ожидании установки флага (эвента). Задачи Б, С, Д могут ждать одного флага, а можно для каждой задачи сделать отдельный флаг в группе флагов. А с проверкой хэндлера..... дак это прийдется в задачах Б, С, Д с какимто периодом проверять хендлер. С таким же успехом можно завести глобальную переменную и проверять её в Б, С, Д и не заморачиваться с хендлером. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Timma 0 5 февраля, 2014 Опубликовано 5 февраля, 2014 · Жалоба Вопрос по организации алгоритма : Допустим начала работать задача А(была создана, была разблокирована), и пока она работает должны заблокироваться задачи Б, С, Д. Когда задача А завершила работу, Б С Д должны разблокироваться. Как это принято делать так, что бы было наименее путано ? Сделать очередь из одного элемента, из которой задачи Б С Д читают этот элемент без удаления, а задача А его либо удаляет либо возвращает ? Нет ли способа проверять внутри задачи Д чему равен хэндлер задачи А, так что бы когда он не NULL задача Д блокировалась бы, а когда снова стал NULL разблокировалась бы? Спасибо. Может просто сделать приоритет А выше других? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MiklPolikov 0 12 февраля, 2014 Опубликовано 12 февраля, 2014 · Жалоба Ещё вопрос: Как я понял , для того что бы использовать флаги событий нужно добавить в FreeRTOSConfig.h следующие строки, без них не компилируется. Из каких соображений нужно выбирать то, что я отметил //// ? Рассуждаю так : configTIMER_TASK_PRIORITY 0 самый верхний приоритет для того что бы всё что с этим будет связано обрабатывалось быстрее моих задач, так будет работать гарантированно однозначно. configTIMER_QUEUE_LENGTH 1 маленькая длинна очереди т.к. приоритет всё равно самый верхний, очередь не должна переполнится Заранее спасибо за ответ ! #define INCLUDE_xEventGroupSetBitFromISR 1 #define configUSE_TIMERS 1 #define configTIMER_TASK_PRIORITY 0 //// #define configTIMER_QUEUE_LENGTH 1 //// #define configTIMER_TASK_STACK_DEPTH configMINIMAL_STACK_SIZE //// #define INCLUDE_xTimerPendFunctionCallFromISR 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 10 14 февраля, 2014 Опубликовано 14 февраля, 2014 · Жалоба Я работал с флагами (эвентами) в др ртос. В ФрииРТОС пока не доводилось, не разбирался. С чем их есть во фри - не знаю. :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MiklPolikov 0 14 февраля, 2014 Опубликовано 14 февраля, 2014 · Жалоба Настроил как написал выше, и вроде бы всё хорошо. Ещё один вопрос, мучает уже давно : Почему в примерах в объявлениях семафоров , мьютиксов и т.п. нет директивы volatile, и почему без неё работает когда семафор выдаётся в прерывании ? Заранее спасибо за объяснение ! /*volatile*/ xSemaphoreHandle x_RTC_Second_Change; //разве тут не нужен volatile ? //..... xSemaphoreGiveFromISR(x_RTC_Second_Change,&xHigherPriorityTaskWoken); Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MiklPolikov 0 15 февраля, 2014 Опубликовано 15 февраля, 2014 · Жалоба И ещё вопрос по флагам событий : Я верно понимаю, что xEventGroupWaitBits работает только по факту наличия флага, сделать так чтоб работало по моменту выставления способа не предусмотрено ? Иными словами : пользователь жмёт кнопку, при этом выставляются и снимаются флаги "кнопка была нажата" "кнопка была отпущена". В задаче нужно чтоб программа проходила строку xEventGroupWaitBits после нажатия, а при следующем попадании на неё же ждала следующего отпускания + нажатия. Сбрасывать флаги нельзя, т.к. они используются в других функциях. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Артём__ 0 15 февраля, 2014 Опубликовано 15 февраля, 2014 · Жалоба /*volatile*/ xSemaphoreHandle x_RTC_Second_Change; //разве тут не нужен volatile ? //..... xSemaphoreGiveFromISR(x_RTC_Second_Change,&xHigherPriorityTaskWoken); Не нужен volatile, потому что xSemaphoreHandle - это указатель и он в прерывании не изменяется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MiklPolikov 0 24 апреля, 2014 Опубликовано 24 апреля, 2014 · Жалоба Ещё один вопрос, по архитектуре кода : Перевожу свои старые коды без ОС на FreeRTOS. К примеру есть функция, инициализирующая SD карту, в ней в каких-то циклах ожидание чего-то. Как теперь с этим поступить наиболее правильно ? а) Вставить в функцию команды переключения контекста. Функция будет вызываться в задаче, но выполняться будет не быстро, т.к. функция чего-то ждёт внутри себя. С одной стороны контекст будет переключатся, т.е. система в целом работать правильно, но с другой та задача, которая функцию вызвала, будет останавливаться на этой функции на большое время, что на мой взгляд криво. б) Сделать из функции отдельную задачу. Создавать её когда надо проинициализировать карту, когда инициализация прошла удалять, а о том что инициализация прошла узнавать через эвенты или симафоры. Заранее спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DASM 0 24 апреля, 2014 Опубликовано 24 апреля, 2014 · Жалоба Б Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kolobok0 0 24 апреля, 2014 Опубликовано 24 апреля, 2014 · Жалоба ...есть функция, инициализирующая SD карту... в) всю работу с карточкой убрать в нитку. обслуживать запросы можно и синхронно и асинхронно - в зависимости от дальнейшей надобности. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MiklPolikov 0 24 апреля, 2014 Опубликовано 24 апреля, 2014 · Жалоба в) всю работу с карточкой убрать в нитку. обслуживать запросы можно и синхронно и асинхронно - в зависимости от дальнейшей надобности. Объясните пожалуйста на пальцах, что значит "убрать в нитку" и "обслуживать запросы синхронно и асинхронно" ? Это всё значит сделать один линейный код в одной задаче ? Но тогда непонятно во-первых как переходить в разные места этого кода так что бы не было путаного синтаксиса, а во-вторых придётся в одном коде смешивать и хардварную часть, и высокоуровневую аппаратно-независимую, а зачем это надо ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kolobok0 0 25 апреля, 2014 Опубликовано 25 апреля, 2014 · Жалоба Объясните пожалуйста на пальцах, что значит "убрать в нитку" и "обслуживать запросы синхронно и асинхронно" ? ..один линейный код в одной задаче ?... если юзаете ось, то во фриртосе есть понятие поток. вам ничего не мешает отдельно поток завести на ваши медленно играющие проблемы. асинхронно (по отношению к этому потоку) вы сможете вызывать необходимые вам функции (рядом с потоком лежащие и реализующие синхонизацию). Вам никто не мешает порождать, посылать запрос, ждать, по возврату управления удалять объект синхронизации. это есть синхронное обращение. как пример см. стэки изернет, синхроные натификэшены во всяких форточках и иже... вам никто не мешает, завести объект синхронизации в вызывающем коде, передать его на вызове и продолжать работу периодически проверяя обратный натификэшен. как пример реализации см. те же форточки раздел асинхронный доступ к файлам, портам и т.д., либо в других осях - типа новела, льюникса, юникса и т.д... про линейный код нифига не понял. как пример разжовывания на пальцах(да и пользительно под форточками) - почитайте толковую книгу "WINDOWS для профессионалов" автор Джеффри Рихтер там есть и асинхронный пласт и синхронный...возможно не по теме но как консерватория - вполне... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 10 26 апреля, 2014 Опубликовано 26 апреля, 2014 · Жалоба в) всю работу с карточкой убрать в нитку. обслуживать запросы можно и синхронно и асинхронно - в зависимости от дальнейшей надобности. на сколько я понял вопрос в другом. Какая разница что в какой нитке? Допустим есть отдельняя нитка в которой ведется работа с SD Картой. есть функция, инициализирующая SD карту, в ней в каких-то циклах ожидание чего-то. Как теперь с этим поступить наиболее правильно? Когда идет инициализация, то процессор простаивает. как правильно организовать работу, чтобы во время ожиданий процессор не простаивал? если сделать так while(waitForSdCard); то процессор будет стоять в этом месте (ну если конечно более приоритетные задачи не прервыт эту задачу). самое простое сделать ожидание через vTaskDelay(); for(int i = 0; i<100; i++) { if(waitForSdCard) { //дождались... дальше пишем код } vTaskDelay(10); } //сюда попадем, если недождались. исключение Если то событие, которое ожидаем, может сегенрировать прерыванеи, то можно сделать двоичный симафор (или эвэнт). из прерывания выдавать симафор. тогда if(xSemaphoreTake(smSdCardReady, 1000) == pdPASS)//ждём симафор { //дождались... дальше пишем код } else { //сюда попадем, если недождались. исключение } Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MiklPolikov 0 29 апреля, 2014 Опубликовано 29 апреля, 2014 · Жалоба Ещё один вопрос: Требуется экономить потребляемый ток. Раньше, без ОС, в тех местах кода, где надо чего-то ждать,я использовал какой-то из спящих режимов, а дождавшись вновь увеличивал частоту. Сейчас всё ожидание, очевидно, будет в задаче Idle. В ней я могу снизить тактовую частоту. А вот как её обратно повысить ? Я ведь не знаю ни когда это потребуется, ни где программа окажется когда выйдет из IDLE . Как быть ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kolobok0 0 29 апреля, 2014 Опубликовано 29 апреля, 2014 · Жалоба ...Когда идет инициализация, то процессор простаивает. как правильно организовать работу... Вы вот прочитали но не поняли скорее всего, что я написал выше. Окейно. по другому.. откуда это у Вас? "Когда идет инициализация, то процессор простаивает" я бы сказал заблуждение... Или логику так построили? Ну а кто мешает по другому, религия если только??? вот у меня паралельно идёт инициализация(читай подъём или инициализация) железа...uSD, Ehernet, ADC, стэки, оси, MODBAUS, запуск ниток, изернет клиенты-сервера, wifi (и прочий звериниц), всё это делается параллельно (ну есть конечно же последовательные действия), но они не создают узких мест для общей картины а больше, как это лучше сказать - по общей готовности все подождут самого отстающего... ну и принимается решения для подключения или отключения функционала блоков или логики... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться