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

[SasaVitebsk]

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

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