Предлагаю не путать теплое с мягким.
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-режиме по окончании которого - ввод данных с линии.

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


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






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

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

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

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

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

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

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

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