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

[Arlleex]

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

[Arlleex]

Forger,

Зачем дергать прерывания раз в 1мкс? 01.gif
У 1-wire все времена указаны как минимум от 15мкс.

Если Вы внимательно прочитаете мое сообщение, то увидите, что я говорил по ХУДШИЙ случай. Конечно, в большинстве случаев такие реакции таймера не нужны.

scifi,

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

Будем считать, что ног в корпусе не осталось. И это не допущение, а факт.

AlexandrY,

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

Я не решил, что и так сойдет. Я попытался найти оптимальный выход из ситуации. Напомню, что переделывать железо никто не будет, а то, что 180МГц Cortex-M4F не сможет правильно и лаконично обработать датчик на фоне других процессов - не поверю.

jcxz,

Работу 1-wire естественно эмулировать при помощи capture- и compare- режимов какого-либо таймера. Ногодрыг или UART - это колхоз.

Если бы 1-Wire был выведен на ножку аппаратного таймера, я бы не задавал таких вопросов.
Очевидно, я спрашивал не про то, как мне переделать железо, а про то, как архитектурно продумать программную часть. Тут товарищи некоторые осциллографы с ЖК-экранами на сраных 8-битных AVR-ках делают с красивым меню, и памяти хватает, и более-менее опрятно выглядит, а меряет как китайщина с Aliexpress (то есть вполне допустимо для радиолюбительских поделок для монитора SPI, I2C и пр.). Поверьте, перезаполнять регистр совпадения таймера в прерывании по каждому прерыванию для автомата состояний, ЛИБО делать то же самое но дополнительно дернуть ножкой при этом программно - разница не существенная абсолютно в данном случае, ибо не двигателем управляем.

P.S.: На ум все-таки приходит вариант с DMA на регистр совпадения... Но в прерывании ножку дергать, так как заведена не на таймер...

В общем, почитав Ваши комментарии, я пришел к выводу, что... что никакого вывода, собственно, и нет. Кто-то делал так, кто-то делал так. Кто-то кого-то поливает говном, называя последнего быдлокодером, кто-то, в свою очередь, считает наоборот. Из всего прочитанного можно лишь сделать одно заключение - что бы ты ни делал - другие буду считать сделанным через одно место... Люблю этот форум
Изящное решение найду в любом случае, поскольку не сдаюсь на "и так сойдет" (перфекционизм в душе ликует). Всех с наступающим Новым Годом!

Сообщение отредактировал Arlleex - Dec 29 2017, 23:31

[kolobok0]

...никакого вывода, собственно, и нет. Кто-то делал так, кто-то делал так. ...Изящное решение найду...Всех с наступающим Новым Годом!

Вы правы - пока прозвучала реализация двумя путями:
- ногодрыг в прерываниях
- уарт

всевозможные потуги на захватах и дма = нас всех туда тянет, но увы отличия от ногодрыга минимальные, что нивелирует (ну или почти) весь колхоз и нагромождение... по крайней мере
раздувание в эту степь щёк - так и осталось хотелками (у тех кто прямо заявлял что это кашэрно)...
Из всех озвученных вариантах - для варианта промышленного (куча датчиков и каждый датчик = свой вход) остаётся одын единственный вариант - ногодрыг.

вот своё изящное решение - это правильная колбаса. ведь всё зависит от поставленной задачи.

и Вас с новым годом!

с уважением
(круглый)

[HHIMERA]

всевозможные потуги на захватах и дма = нас всех туда тянет, но увы отличия от ногодрыга минимальные, что нивелирует (ну или почти) весь колхоз и нагромождение... по крайней мере
раздувание в эту степь щёк - так и осталось хотелками (у тех кто прямо заявлял что это кашэрно)...
Из всех озвученных вариантах - для варианта промышленного (куча датчиков и каждый датчик = свой вход) остаётся одын единственный вариант - ногодрыг.

Это просто один вариант вы и знаете... Так бывает...

[kolobok0]

Это просто ..

я с удовольствие(на полном серьёзе) послушаю Вас, про ваше виденье решения. Вы кажется декларировали опыт использования ПДП(DMA) для поддержки 1-Wire протокола?

с уважением
(круглый)

Сообщение отредактировал kolobok0 - Dec 30 2017, 14:58