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

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


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

Очевидно, времени, чтобы прочитать все данные с внешних устройств, обработать их и выдать результат, куда надо, должно хватать. Если так, проблемы нет.

По АЦП в принципе согласен. У меня примерно та же картина была и я расчитывал, оказалось, что при spi 2MHz нет смысла городить огород. Накладные расходы по усложнению обработки режут всё в 0. То есть придётся смирится. Можно попробовать организовать аппаратно... Я не пробовал, если честно. У меня правда лишь один АЦП. Это упрощает.
По 1820 картина попроще на самом деле. Если почитаете, то там диаграмма по всем слотам может в 2 раза отличаться, так что там критичного ничего нет. Формируйте диаграмму по прерыванию от таймера.
1820 уже не рекомендуют к применению. Это раньше был чудо прибор. Лет 10 назад. А сейчас лучше применять TI. И дешевле и точнее и удобнее.

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

Один аппаратный таймер задействован как раз для формирования временной диаграммы опроса АЦП. В обработчиках прерываний по совпадению и переполнению построена логика небольшого конечного автомата, который:
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 - то есть все подчиненные ждут следующего пинка.

Зачем дергать прерывания раз в 1мкс?
У 1-wire все времена указаны как минимум от 15мкс.
Таймер можно перенастраивать "на ходу", используя, конечно, "теневые" регистры.
Поищите исходники готового 1wire на одном аппаратном таймере, благо, тема избитая и обсосанная неоднократно. Интерфейс этот действительно очень архаичный.

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


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

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

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

(круглый)

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

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

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

Зачем мне вечная игла для примуса?

а я было возбудился - думал ышо какой хитропопный способ можно придумать для оптимальности... 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 серии. Изменен код только с учётом скорострельности камней.

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




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

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

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

На УАПП легко реализуется жесткая времянка одного слота, без накладных расходов вообще. Больше нигде жестких времянок в 1-wire нет. Поделитесь сокровенным - чем же это так сильно хуже тупого ногодрыга в прерывании таймера?

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





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

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

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


окейно. понял Вашу мысль. спасибо!
(круглый)

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


Занимаетесь ерундой. У Вас что - CPU уже на 99% загружен?


Чем выше-то? Разъясните - чем вход/выход в ISR с ОС отличается от того же самого без оной?

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

дэжавю?

https://electronix.ru/forum/index.php?s=&am...t&p=1538265

коротко если не трудно(не секрет) изложите своё виденье...


ик...
с наступающим годом усех!
(круглый)

Насколько помню 1-wire - там вроде по длительности импульсов от источника надо определять пришёл '0' или '1'?
Тогда самое правильное - таймер в режиме capture/compare, а никак не UART.


Что именно излагать? Ознакомьтесь с описанием работы 1-wire - там всё ясно: после установки МК уровня на вых '0', запускаем таймер на 1мкс, по окончании интервала - линию на ввод, и либо таймер в режим capture (с ограничем времени) либо просто след. интервал в compare-режиме по окончании которого - ввод данных с линии.

супер.
т.е. вы предлагаете (на примере одного слота)
- выдать не на обработчике прерывания строб, подготовить ловушку.
- на обработке захвата сохранить..
- не на обработчике поллить захваченное значение..
и т.д...?
у вас поллинг тодысь
если вы упрячете логику на обработчик - то вся ваша выгода в слоте чтения (минус одно прерывание, и весь пшик). Кстати по сравнению с юартом -всё равно вы проигрываете по прерываниям...


так, или я что то глючу?






ага...как я и описал - вы экономите на одном прерывании. и нафига козе баян спрашивается???

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

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

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

ближе к делу, если вы профи...

заранее спасибо
(круглый)
ЗЫ
Новый год жешь... Помягше к друг другу что ли...

А если не 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

А на байт получается 24 против 8 или менее в случае использования UART. Как могут испортить жизнь - смотрите исходный пост темы. Формировать микросекундные интервалы всегда лучше без участия софта.

Микросекундный интервал - это стартовый импульс каждого тайм-слота от МК? Там вроде требования для него: "не менее 1 мкс". А максимум - очень гибкий, так что если будет какой-то джиттер 1...10мкс из-за задержек входа в ISR - это не проблема. А если в софте могут быть задержки входа в ISR больше чем неск. мкс на 180МГц тактовой - это надо программеру руки выпрямлять.
Для передачи вообще можно аппаратный вывод с регистра compare таймера использовать. Ну или тот же UART если больше нравится.
Да, конечно прерываний будет немного больше. Но такие частоты прерываний для такого МК некритичны. Зато реализация 1-wire будет правильная, полностью соответствующая спецификации, в отличие от варианта на UART.

Прекрасно делал на таймере обработку данной шины, в МК было 4 уарта и для всех их нашлась работа по прямому назначению. Я понимаю, если в мк 8-10 уартов, тогда на них можно чего угодно делать, хоть скважности считать

А то! U for Universal.

Можно вообще без прерываний... на ДМА... типа аппаратно... Это уже кому как больше нравится...

Forger,

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

scifi,

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

AlexandrY,

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

jcxz,

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

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

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

1 мкс - НЕКУДЫШНЫЙ случай. Можно прекрасно ограничиться 5мкс, например.


Вы уж определитесь, наконец, какую помощь ожидаете тут получить?

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

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

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

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

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

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

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

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

1-wire не делал, а одновременный прием четырех и передачу восьми независимых каналов ARINC429 на stm32f050 реализовывал. Там скорость 100 кбит, если что. В памяти массив, в этот массив пишется желаемая выходная диаграмма. Этот массив по таймеру через ПДП загоняется в выходной регистр порта. Если в порту есть ноги, которые надо дергать независимо - пишем желаемое их состояние в соответствующий бит всех элементов массива, после чего дергаем ногой. Второй канал ПДП по тому же таймеру заносит в кольцевой буфер состояние входного регистра. Заполнили половину буфера - обрабатываем, ПДП в это время заполняет вторую половину буфера. 1-wire можно реализовать по тому же принципу.

Совершенно верно... Там даже все проще чем кажется... при куче вариантов... В простейшем варианте... один массив из двух значений по ЖПИО... другой - времянки слотов... третий - чтение состояния шины.... Заюзав прелоад там все отрабатывается автоматически... Остаётся распарсить принятые данные... Даже если там 16 каналов... это уже не напряжно...
Заюзав два эвента на один канал ДМА... можно сэкономить на канале ДМА...

Сергей Борщ,

Коллегам с оборонки (авиация?) отдельный привет

Собственно говоря, чего тут уже изобретать. Сделал автомат формирования времянки слотов 1-Wire на прерывании по переполнению таймера.
Код в прерывании меньше 1мкс, сколько точно не скажу, ибо мерял таймером с шагом 1мкс. Но это уже допустимый вариант. Прерывание имеет бОльший приоритет относительно всех используемых прерываний FreeRTOS, поэтому прерывание не может быть перебито RTOS. В прерывании выдается статичный флаг в низкоприоритетную задачу опроса датчиков. Соответственно на критичных временных интервалах перебития контекста происходить не будет.

Не, все гораздо приземленнее - любители-строители домашних полноразмерных кабин самолетов для авиасимуляторов. "Оживление" настоящих приборов.

Поправил ссылку. Еще одна.

Не очень понятно что такое "перебитие контекста" и чем оно так страшно?
Также не понимаю - зачем FreeRTOS-у использовать какие-то прерывания кроме прерывания SysTick? (PendSV можно не учитывать, так как оно априори должно иметь приоритет ниже любого аппаратного прерывания).

Ну в общем аналогичный способ я применяю для изготовления 8ми I2S-интерфейсов на LPC1768. 3Mbps (48к*32 бита * 2 канала) на каждом получается. Причем, BICK (клок битов) приходит снаружи, а не генерируется внутри, это, правда, потребовало некоторых извращений - внешний клок подается на таймер в режиме счета импульсов снаружи, а максимальное значение таймера установлено в 1, вот он и генерирует DMAREQ каждый фронт (или спад, зависит от режима детектора у таймера) внешнего сигнала.

CPU load просто смешной. Хотя, конечно, есть нюансы в транспонировании битовой матрицы, чтобы из принятой колбасы битов получить обычные int32.

Обработать так один канал 1-wire - это просто как два пальца.

Кстати, а как вы его меряете?

Да есть же масса способов. Самый простой - измерить сначала в основном потоке количество богомипсов без обработки периферии, а потом - с обработкой.

Лишь хотел уточнить учитывается загрузка лишь голого ядра или загрузку всего проца с учетом его встроенной периферии

Ну и как, мой ответ Вас удовлетворил? Я достаточно понимаю разницу?

Дело в том, что мне приходилось сталкиваться с тем, что некоторые "программеры" в упор не видят разницу:
нагромоздятгде надо и не надо гору из мудреных DMA-конструкций с периферией, а после этого хвастают о том, что "загрузка" CPU даже не упала.

Мои сомнения вызвала фраза "CPU load просто смешной". Ваш последующий ответ эти сомнения развеял

Почему для 1820 упоминается только ногодрыг/таймер и UART?
По мне так SPI подходит для этих целей ничуть не хуже, а, может даже и, лучше!
Формируем нужную последовательность в памяти, по DMA принимаем/отправляем биты. По завершении транзакции вызываем задачу и обрабатываем данные.

Думаю потому, что разработчики МК сочли этот интерфейс устаревшим или никому не нужным и не сделали его аппаратную реализацию в МК, вот народ и извращается, как может