Всем привет.
Есть девайс : stm + 1-wire шина (реализованная аппаратным UART'ом) + ethernet (обслуживается стеком Lwip), управляется FreeRTOS.

Есть 2 задачи (есть и другие, но они на работу не влияют):
1) Обслуживание Ethernet (приоритет realtime (highest))
2) Обслуживание шины 1 wire. (задача выполняется раз в секунду с osDelay(1000) Этапы:
- поиск устройств на шине
- запись инициализирующих данных (для каждого по серийнику из найденных)
- конвертация температуры (для всех)
- osDelay(100);
- конвертация напряжения/тока (для всех СКИП РОМ)
- osDelay(5);
- чтение памяти каждого датчика (по серийнику)

Если приоритет 2й задачи нормал или хай (ниже езернетного таска), езернет работает отлично (пинг без потерь, время ответа 1 мс), однако датчики Даллас работают с перебоем - видимо нарушаются задержки в протоколе общения (задержки аппаратные, т.к. 1-wire шина эмулируется ЮАРТом).
Если приоритет 2й задачи = приоритету езернета, езернет работает неситабильно, регулярно время ответа увеличивается до 10-100мс (при 3 датчика Даллас на шине 1-wire) (в этот момент видимо проц занят работой 2й задачи, по обслуживанию шины 1-wire).

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



Второй вопрос по тему: FreeRTOS к девайсу прикрутил совсем недавно. Разбираюсь с распределением памяти. На данный момент определяюсь, сколько памяти отдать каждой задачи. Вроде как нужно определить функцию диагностики стэка ОС, которой определять, у какой задачи переполняется стек, увеличивать стек каждой задачи пока не прекратится переполнение. Верно? Как определить такую диагностическую функцию? не могу найти ее в исходниках. Как посчитать (хотя бы ориентировочно), сколько кучи выделить в целом ОС (configTOTAL_HEAP_SIZE) ? И влияет ли размер памяти, выделяемой для Ос на настройки стека/кучи всего Си проекта?

Есть понятие системного тика. Это время переключения м/у задачами. Чем оно меньше, тем больше накладных расходов на обслуживание ОС, но при этом, более равномерно, так сказать выполняются задачи.
Когда вы формируете задержки, то просто приостанавливается выполнение данной задачи.
Судя по всему, вам надо делать приоритеты задач равными. А системный тик уменьшать. Либо переносить часть работы второй задачи в прерывание (наверное я пошёл бы по этому пути).
Не совсем понятно, почему у вас нарушается работа Ethernet. Если честно.

Теперь по второму вопросу.
в файле FreeRTOSConfig включается опция контроля стека.
#define configCHECK_FOR_STACK_OVERFLOW 2
Можно поставить 0/1/2.
При 0, выключаете. При 1 осуществляется контроль указателя стека при переключении задачи в планировщике. То есть это не гарантирует 100% диагностики, так как стек может залезть а потом вернуться на место и всё будет Ok. При 2 стек заполняется определённым кодом, например 55 и проверяется реальный размер стека в момент переключения.
Рекомендуется выбрать режим 2. Задать заведомо больший размер стека, поработать значительное время в разных режимах и визуально оценить куда добрался стек. Потом подкорректировать его с запасом.
Размер кучи надо (можно) задавать максимально свободный. Если у вас ОС, то куда ещё может пойти эта куча кроме как на Ос? ))
Последнюю вашу фразу я, простите, не осилил.
Если у вас ОСь, то она сама распределяет стеки и сама работает с кучей.

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

То есть когда в задаче стоит osDelay - ОС не отдает тики на работу другой задачи?

В задаче есть места с while(..) ; - ожидания ответов и тд. может в эти циклы что то вставить для отдачи тиков другой задаче на это время?

с фриртос (как в общем с ОС) только начинаю работать...


Если выставить 2, как узнать, что стек переполнился?
Всей ос или какой то определенной задаче, которой необходимо выставить больше?

как я понимаю configTOTAL_HEAP_SIZE = сумма стеков каждой задачи + накладные расходы?

Это как раз говорит о том, что вы неверно спроектировали задачу.
Высокий приоритет должна иметь задача, которая по сути ничего не делает а только ждёт семафора, например. Типовой вариант - обслуживание UART. Задача имеет высокий приоритет, но по сути постоянно находится в ожидании. Приходит прерывание, прерывание принимает байт (к примеру, или пакет) и включает семафор. При выходе из прерывания планировщик разблокирует задачу, она отрабатывает обработку и захватывает семафор (то есть опять блокируется).

Наоборот. osDelay блокирует задачу, которая вызывает данную функцию на указанное время. Остальные задачи обслуживаются согласно приоритету.

Есть несколько способов как этого избежать. Попробую описать в конце. Пустые циклы в Оси совершенно непонятный приём.

Если у вас включен контроль стека, и произойдёт его переполнение то будет вызван системный обработчик vApplicationStackOverflowHook. По умолчанию там зацикливание. Но Вы можете обработать это своим способом.
Но я вам предлагал выставить 2, задать заведомо больший размер стека, запустить прибор и посмотреть стек визуально. Просто отладчиком. Вы всё там увидите. Видно как он заполняется.
Стек не выделяется из кучи. Стек распределяется статически. Я про FreeRTOS. Другое дело, что это не имеет отношения к инициализации стека компилятором. Каждой задаче FreeRTOS выделяет свой кусок памяти, где хранится стек. Глобальные переменные распределяются компилятором. Куча общая и из неё берутся динамические переменные, вне зависимости из какой задачи пришёл запрос на выделение памяти. Единственное отличие, что у FreeRTOS свой аллокатор памяти. Их там 5 уже в последней версии. Вы должны к проекту подключить тот, который вам больше подходит. У меня, к примеру heap_4.с подключен. Вы можете почитать отличия. Можете написать свой и подключить. На самом деле ничего там суперсложного нет. Всё очень понятно.

Лично я для такой задачи ртос бы не использовал. Либо пишите работу 1wire на прерываниях, хотябы критичные ко времени процедуры.

Как формируются задержки при работе с ОСью.
Моё виденье такое:
Если задержка очень малая (меньше тика ОСи), то объявляется защищённая секция и в ней формируется задержка тем либо иным способом. Я обычно формирую его аппаратным.
Если задержка значительно больше тика ОСи и точность не превышает 1 тика, то есть несколько способов.
1. Если точность не очень важна, то используется osDelay.
2. Если задержками формируется общая диаграмма (по моему ваш вариант), то я использую формирование задержки на таймере, а её контроль полингом в данной задаче. В этом случае, собственно задержка учитывается даже когда выполняется другая задача.
3. Иногда использую прерывания меток времени. Например запускается таймер, который отсчитывает 1 мс задержки. В нём есть переменные которые уменьшаются до 0. По этому событию формируется либо флаг либо семафор. При формировании задержки вы задаёте время (инициализируете нужную переменную и ждёте семафора).
4. При точном формировании временных интервалов (не ваш случай) задаче присваивается высокий приоритет задержки формируются на таймере с прерыванием. В этом случае на данную задачу монопольно выделяется 1 таймер.
Можно ещё разных способов по напридумывать... ))
На сколько я помню 1-ware шину там задержки могут в 2 раза отличаться. То есть её сформировать достаточно просто.

Дурдом. Можно подумать, настройкой приоритетов можно решить все задачи. Так и программу писать не надо, просто приоритеты расставил - и всё готово.
А не пробовали для начала разобраться, почему 1-wire сбоит? А не гадать но кофейной гуще.

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


ранее (в стэндэлон варианте) езернет при работе 1-wire так же притормаживал (без него все ок).

может есть предположения, почему может сбоить 1-wire?


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



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



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

к слову, в проекте используется Lwip стек, который так же юзает кучу + ни мало приложений так же юзающих lwIP а значит кучу.



то есть фриРТОС берет об общей памяти данных мк, размещает в ней стек (= сумму стеков всех задач + накладные расходы) ?

Сообщение отредактировал k000858 - Aug 27 2015, 06:37

Проблема с нестабильностью 1-wire скорее всего связана с несоблюдением временных интерваов. У Вас как интерфейс реализован - ногодрыг, UART?
RTOS только добавляет проблем с программными задержками. Решение есть - использовать UART+DMA. На easyelctronics есть неплохая статья о реализации именно этой идеи.

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

1-wire реализован с помощью аппаратного UART с использованием DMA
все задержки соблюдаются аппаратно самим UART'ом

мое предположение таково:
есть задача 1wire (считай UART), который отправляет/принимает (тут задержки).
в какие то моменты эту задачу (с нормальным приоритетом) зажимает более приоритетная задача (езернет на прерывании, прием данных по семафоре, в прерывании выставляется семафора), поэтому между отправкой/получением байт по UART происходят задержки (на время работы таска с езернет). нарушается работа 1-wire шины

вариант решения вижу в переработке алгоритма работы UART согласно описанию SasaVitebsk.

Проблема где-то в другом месте. Для 1-wire критична только времянка передачи/приема одного бита, а она у вас формируется аппаратно. Между битами времени может пройти сколько угодно, оно ни на что не влияет. Как вы сделали обмен через УАПП? Передаете байт 0xFF|0x00 на скорости 150000 и сравниваете принятое с отправленным? А импульс сброса/присутствия формируете передачей 0x0F на скорости около 10400? Я делал именно так, работает железно.

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

Если честно - нифига не понял. Рассматривайте каждую задачу как самостоятельное приложение. Лучше всего если каждая задача не зависела от другой. В Оси найболее сложным является грамотное построение связи между задачами. А вы, похоже, наоборот рассматриваете приложение в целом.

Да. Но так не надо делать. Я сопровождаю сейчас одну прогу, написанную другим программистом, так он вообще в явную прямо по ходу выполнения задачи передаёт управление другой задаче. Это как раз показывает неправильность построения. Такие возможности используются крайне редко и в особых случаях. А не повсеместно.
Ещё раз чтобы у вас отложилось в голове.
В нормальной системе у вас все задачи выполняются с равным приоритетом. Планировщик сам распределит время м/у задачами. Стороннему наблюдателю кажется что задачи выполняются одновременно. Лучше на мешать планировщику. В оптимале, каждая задача работает независимо, обмен данными м/у ними осуществляются путём передачи сообщений. Высокий приоритет у тех задач, которые являются продолжением прерываний. То есть те которые обычно ждут прихода события. Далее они быстро обрабатывают данное событие и ждут следующего.

Общий стек вам не нужен. )) Считайте что его нет.
Есть стек в каждой задаче. Рассматривайте его как статический массив данных в глобальной памяти.
Планировщик именно этим и занимается. Переключение контекста = это он берёт сохраняет указатель стека текущей задачи, переходит к следующей задаче и загружает указатель стека этой задачи. потом переходит на инструкцию на которой произошла предыдущая остановка...

Он юзает кучу путём вызыва функций получения/ освобождения памяти. Эти функции ему подсовываются из файла heap_x.c FreeRTOS.
Куча общая. К стекам, задачам, и прочему отношения не имеет. Не совсем понимаю, что вас смущает?

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

И. А. Крылов "Мартышка и очки"

Ой. У автора темы 1-wire висит на UARTe. Это и так железнее некуда.

Что-то у Вас там каша....
На 100% согласен с scifi.

Разделите каждую задачу на драйвер (с жёсткой времянкой, выполняющийся возможно в ISR) и прикладную часть (прикладная обработка протокола 1-wire и TCP-стек для Ethernet-задачи) выполняющуюся
в одной из задач ОС (или даже вместе в одной задаче).

1. Изменение приоритета задачи ОС не должно влиять на корректность её выполнения! Иначьте - правьте консерваторию (учитесь правильно работать в многозадачной среде).
2. Почему у Вас тяжёлая задача (TCP-стек) вынесена на высокий приоритет? TCP-стек работает в пакетном режиме (обрабатывает данные большими фрагментами (полученными от драйвера ISR Ethernet)).
И вообще не должна быть чувствительна к задержкам распределения времени ОС до десятков мсек. Если не так - правьте свою Ethernet-задачу.
В моих проектах TCP-стек всегда работает на одном из самых низших приоритетов (в некоторых случаях - 10-й по счёту задачей) и это никак не мешает ему корректно работать (и даже работать с большой скоростью). Скорость его обеспечивается буферизацией в Ethernet-драйвере.