Работа с медленной периферией Опции

[Arlleex]

Использую микроконтроллер на процессорном ядре Cortex-M4F - STM32F429.
Программа построена на основе ОСРВ FreeRTOS.
Есть 5 независимых задач, внутри которых обрабатываются некоторые массивы данных.
Есть аппаратные прерывания от таймеров с жесткой временной диаграммой, нарушать которую нельзя: через равные отрезки времени считываются данные с полутора десятков внешних АЦП по SPI, при этом сами таймеры формируют управление CS этих АЦП, а также сам цикл чтения из SPI данных. По завершению сканирования (около 200 выборок) выдается семафор в приоритетную задачу FreeRTOS о готовности результата.
Одна из задач отвечает за опрос датчиков температуры DS18B20, подключенной к обычной линии GPIO (не к UART-у), т.е. вся организация протокола 1-Wire программная. Я решил, что настраивать прерывания для временных параметров таймслотов слишком накладно и непроизводительно, поэтому сделал опрос флагов совпадения таймера и рулил ножкой GPIO в низкоприоритетной задаче RTOS. Однако логично было предположить (а позже и убедиться на отладочной плате), что высокоприоритетные задачи могут перебить эту задачу, например, в момент таймслота чтения, и целостность временного отрезка таймслота будет нарушена - считаются неправильные данные.
Поместил обращения с датчиком в критическую секцию, но сам понимаю что это так себе выход - времянка более приоритетных прерываний таймера для АЦП куда важнее, поэтому никаких критических секций быть не должно. И тут я задумался: а как вообще в таких ситуациях поступать? То есть как обслуживать низкоскоростной интерфейс, временную диаграмму которого нельзя перебивать для корректной работы, в то же время не повышая приоритет задачи, в которой работает опрос датчиков, и тем более, не вводя критические секции? Ведь как бы получается самоблокирующие критерии расстановки приоритетов задач...

[kolobok0]

..задач отвечает за опрос датчиков температуры DS18B20..

Если Вы внимательно посмотрите на диаграммы данного датчика, то
1) нет необходимости все времена чего то ждать. достаточно выделить критичные ко времени участки выполнения и засунуть их в обработчик таймера.
2) из опыта - всего таких критичных участка два. время между стробом чтения и самим чтением слота. и время между началом формирования и выхода из записи единички при записи в слот. всё остальное,
даже если будет немного плавать не критично.
3) вычисление результата делаете в задаче, а не в обработчике.
4) все обработчики делаете лаконичными.


удачи вам
(круглый)
ЗЫ
у меня в проекте на F4 крутиться ниток 15, и датчиков сканируется штук 8 постоянно. проблем нет...