STM32F4 Ethernet + Dallas: перетягивание каната Опции

[k000858]

Всем привет.
Есть девайс : 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) ? И влияет ли размер памяти, выделяемой для Ос на настройки стека/кучи всего Си проекта?

[scifi]

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

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

[k000858]

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

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


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

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

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

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

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

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

Если у вас включен контроль стека, и произойдёт его переполнение то будет вызван системный обработчик vApplicationStackOverflowHook. По умолчанию там зацикливание. Но Вы можете обработать это своим способом.
Но я вам предлагал выставить 2, задать заведомо больший размер стека,

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

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

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

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

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

[SasaVitebsk]

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

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

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

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

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

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

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

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

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

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