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