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

[Arlleex]

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

[scifi]

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

[kolobok0]

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

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

(круглый)

[amiller]

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

(круглый)

Предлагаю не путать теплое с мягким.
UART, таймеры с DMA, или GPIO - это реализация интерфейса на физическом уровне.
А "иметь картину по нескольким точкам сразу" - это относится уже к логическому уровню протокола обмена.
И одно другому никак не мешает.

[kolobok0]

Предлагаю не путать теплое с мягким.
UART, таймеры с DMA, или GPIO - это реализация интерфейса на физическом уровне.
А "иметь картину по нескольким точкам сразу" - это относится уже к логическому уровню протокола обмена.
И одно другому никак не мешает.

Внимательней надо читать.
задача (т.е. дано) - в каждый момент(одномоментно) времени иметь сразу температуры ВСЕХ датчиков. Не последовательно, не через 10 секунд, а каждую секунду. со всех датчиков.
uart, dma, gpio - это способ достижения поставленной задачи.
именно в этом разрезе я и постарался изложить.

На УАПП легко ...- чем же это так сильно хуже тупого ногодрыга...

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

[Сергей Борщ]

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

Мне непонятно - чем сканирование с помощью УАПП отличается от сканирования ногодрыгом. Точно так же ищем все подключенные датчики, точно так же запускаем на найденных измерение температуры, точно так же через 0.8 сек сканируем шину снова и считываем с найденных датчиков результат. Алгоритм сканирования описан и в документации (я проверял - работает) и в куче примеров по всему интернету. Все точно так же, как и с ногодрыгом в прерывании таймера, только вместо трех прерываний таймера на битовый слот имеем одно прерывание УАПП на слот и жесткую времянку слота. УАПП передает 0x00 или 0xFC. Для чтения передает 0xFC, одновременно читая эту же линию. Если считано 0xFC - ведомый ответил единицей или не ответил, если считано не 0xFC - подчиненный ответил нулем.

[jcxz]

Если считано 0xFC - ведомый ответил единицей или не ответил, если считано не 0xFC - подчиненный ответил нулем.

А если не 0xFC получилось из-за более длинного восстановления уровня на линии (ёмкость и т.п.)? Или из-за помех (вполне возможно в 3-м состоянии линии на линии)?

То есть нагромождение таймеров и побитный прием с соответствующей загрузкой процессора - это не колхоз, а железная периферия - колхоз? Оригинально.

Почему таймеров? Автор вроде говорит про приём по единственной линии. Я понял что все датчики висят на одной линии.
В чём загрузка процессора-то? В 1-wire значения времянок порядка десятков-сотен мкс, как 3 прерывания в течение этого времени могут значимо нагрузить ARM с частотой 180МГц?
При том, что в каждом прерывании нужно всего несколько команд выполнить.

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

По делу есть что сказать кроме пустого битья себя пяткой в грудь?
"Реализуют" что-то не заглядывая в описание быдлокодеры.
А если прочитать описание и хоть немного включить голову, то из диаграммы работы линии в режиме ввода видно, что есть интервалы времени, когда на линии может быть что угодно. И это никак не противоречит стандарту. Т.е. - если ведомое устройство в эти интервалы выдаст на линию любой мусор, то это никак не будет противоречить протоколу 1-wire, и это всё равно будет 1-wire. Только реализация приёма на основе UART перестанет работать. Реализация на таймере, учитывая все требования 1-wire, будет работать также корректно.
И это уже не говоря про весьма возможные помехи в 3-м состоянии линии ввода.
http://micpic.ru/articles/128-opisanie-int...jsa-1-wire.html