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

[Arlleex]

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

[scifi]

1-wire удобно делается на уарте, там нет всей этой головной боли.

[kolobok0]

1-wire удобно делается на уарте...

если поделка, типа померять температуру любимого проца - то да.
если надо каждую секунду иметь картину по нескольким точкам сразу - то юарт мягко говоря убогость...

(круглый)

[AlexandrY]

.... юарт мягко говоря убогость...
(круглый)

Не, ошибкой было назвать 1Wire медленной периферией, а потом выводить ее на GPIO.
После чего героически бороться за прерывания в контексте RTOS, где их цена выше чем на bare metal.
Самое гибкое ИМХО решение - это использовать capture/compare функции таймеров и DMA
Тут надо помнить, что прывания не поддаются планировке на подобии задач и для них не действует правило 70%
Прерывания все надо профайлить до такта чтобы узнать бюджет задержек, что автор как бы и начал делать, но видимо решил, что и так сойдёт. Т.е. продолжает цепь ошибок.

[kolobok0]

...Самое гибкое ИМХО решение - это использовать capture/compare функции таймеров и DMA ..

в плоскости сканирования за одно обращение сразу X (скажем 8) датчиков - раскройте тему... как будет выглядеть реализация захвата? или это такой тонкий стёб?

Сообщение отредактировал kolobok0 - Dec 29 2017, 07:56

[AlexandrY]

в плоскости сканирования за одно обращение сразу X (скажем 8) датчиков - раскройте тему... как будет выглядеть реализация захвата? или это такой тонкий стёб?

Я же написал ИМХО, т.е. утверждение не предусматривает доказательств.
Хотите , можете опровергнуть.

[kolobok0]

Я же написал ИМХО, ...

а я было возбудился - думал ышо какой хитропопный способ можно придумать для оптимальности... DMA - да заманчиво. но протокол двунаправленный и имхо - в конечном счёте всё выливается опять в обработку на прерывании.

у мну прописаны
reset - 3 фазы
read - 3 фазы
write - 3 фазы
wait - 1 фаза
loop - 1 фаза
stop - 1 фаза
start calculated - 1 фаза
wait calculated - 1 фаза

ну и чистые замороты для ds1821
изменение направления - 1 фаза
выключение питания - 1 фаза
сброс логики термостата - 3 фазы
включение питалова - 1 фаза

ну и далее тупо набираем под нужный сценарий нужные команды.
прерывание от таймера тупо отрабатывает очередную команду.
кол-во датчиков определяется дефайнами (от 1 до 8 штук, но можно на все лапы мк)

по такой схеме работает не только на stm-ках, но и на avr, 51 серии. Изменен код только с учётом скорострельности камней.

с новым годом
(круглый)

Зачем мне вечная игла ..

ну вот таки да - заказчик с примусами больше.

[scifi]

ну вот таки да - заказчик с примусами больше.

Фу, грубиян.
Хотя да, я бы попроще сделал...