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

[Arlleex]

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

[Forger]

То есть как обслуживать низкоскоростной интерфейс, временную диаграмму которого нельзя перебивать для корректной работы, в то же время не повышая приоритет задачи, в которой работает опрос датчиков, и тем более, не вводя критические секции?

Если не переписывать сильно код, то как вариант: снять статистику всех происходящих событий (например, бесплатная SystemView от Segger) и оптимизировать код под эти данные.
Другой вариант: для медленных программных интерфейсов использовать аппаратные таймеры, благо в таких толстых камнях таймеров выше крыши.
Ну и классический совет для любой системы - убирать из обработчиков прерываний длительные расчеты и действия, вынося их в фон задач, "пробуждая" их соотв. сервисами ОС.
Нельзя забывать про DMA, которая, например, отлично подходит для опроса кучи каналов АЦП.
Т.е. в сильно перегруженной системе нужно переносить программные дела в аппаратные по максимуму.

через равные отрезки времени считываются данные с полутора десятков внешних АЦП по SPI, при этом сами таймеры формируют управление CS этих АЦП, а также сам цикл чтения из SPI данных.

В данном случае скорее всего подключать схемотехников для переделки платы. Я бы ставил отдельный дешевый контроллер, который бы делал подобную "тупую" работу.
Как вариант, возможно, стоило сразу ставить двухядерный Cortex, например от NXP.

[Arlleex]

Другой вариант: для медленных программных интерфейсов использовать аппаратные таймеры, благо в таких толстых камнях таймеров выше крыши.

Один аппаратный таймер задействован как раз для формирования временной диаграммы опроса АЦП. В обработчиках прерываний по совпадению и переполнению построена логика небольшого конечного автомата, который:
1) опускает линии CS необходимых АЦП;
2) выжидает минимальное допустимое время между активизацией CS и первым импульсом синхронизации SCK;
3) отправляет посылку по SPI в АЦП (при этом предполагая, что посылка точно отправится за конечное время);
4) читает данные в буфер;
5) выжидает минимальное допустимое время между последним синхроимпульсом SCK и деактивацией CS АЦП;
6) выдает семафор в приоритетную задачу о том, что можно производить расчет на текущем шаге (заложено математикой процесса).

Последний пункт как раз и гарантирует, что вычисление (как времязатратный процесс) производится не в прерывании (на самом деле это довольно очевидные вещи).
Насчет DMA - к сожалению это не вариант, поскольку АЦП - внешние микросхемы (если Вы, конечно, имели в виду внутренний АЦП МК - то там да, я бы задействовал DMA и только).

Таким же образом хотел сделать конечный автомат обслуживания таймслотов 1-Wire на прерываниях аппаратного таймера: но тут есть но - можно прикинуть накладные расходы по времени входа в прерывание по отношению к полезному времени:
- частота работы МК - 180МГц; значит на вход/выход в/из прерывания будет составлять 0,133(3)мкс (24 такта);
- для DS18B20 характерны времена, кратные 1мкс, поэтому в худшем случае получаем 1/0,133(3) = 7,5 полезных команд в теле обработчика прерывания.
Короче говоря, не густо, микросекундные прерывания в топку сразу (хотя это тоже понятно на самом деле, микросекундные прерывания это верх кощунства по отношению к МК).

В общем, скорее всего, я думаю, что я растяну таймслоты для 1-Wire, немного потеряется скорость обмена (но это не критично). Благо интерфейс позволяет забить на шину пока там лог. 1 - то есть все подчиненные ждут следующего пинка.

Сообщение отредактировал Arlleex - Dec 28 2017, 20:32