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]

Я бы никаких критических секций не делал. И даже не сталбы синхронизировать.
массив структур. 1-ая задача заполняет текущую структуру и передаёт сообщением указатель на неё 2-ой задаче.
2-ая отображает.
Если вторая работает быстрее первой, что логично, то по выполнению она засыпает, ожидая нового сообщения. В этом случае, в массиве требуется лишь 2 экземпляра структур.
Если вторая задача работает медленней первой, то количество структур надо рассчитать. Ну и иногда будут пропуски. Это некритично. Можно конечно усыплять и 2 задачи, но я бы не стал. Я придерживаюсь принципа регулярной работы с оборудованием и асинхронной её обработки.

[jcxz]

Я бы никаких критических секций не делал. И даже не сталбы синхронизировать.
массив структур. 1-ая задача заполняет текущую структуру и передаёт сообщением указатель на неё 2-ой задаче.
2-ая отображает.
Если вторая работает быстрее первой, что логично, то по выполнению она засыпает, ожидая нового сообщения. В этом случае, в массиве требуется лишь 2 экземпляра структур.
Если вторая задача работает медленней первой, то количество структур надо рассчитать. Ну и иногда будут пропуски. Это некритично. Можно конечно усыплять и 2 задачи, но я бы не стал. Я придерживаюсь принципа регулярной работы с оборудованием и асинхронной её обработки.

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

В описанном Вами случае, сколько Вы будете резервировать экземпляров структур под передачу?
Как задача 1 узнает что какая-то структура освободилась? Никак? Будет писать в неё наугад в тот момент когда задача 2 как раз обрабатывает данные этой структуры?
Как Вы передаёте сообщения между задачами? С помощью какого-то механизма ОС? Почему он лучше чем семафор/кр.секция?

То что Вы попытались описать называется FIFO (элементарная единица его - упомянутая структура).
Этот механизм можно применять для межзадачной синхронизации (и даже - межпроцессорной что тяжелее), но в данном случае он избыточен и неэффективен для данной задачи.
Если не синхронизировать межзадачный доступ к указателям записи/чтения FIFO, то в один прекрасный момент FIFO переполнится и будет каша.
А синхронизировать их - с помощью тех-же кр.секций или семафоров.
Ну или нужно гарантировать что задача 2 всегда успевает вычитать FIFO до его переполнения, тогда не нужна синхронизация доступа к указателям FIFO.