Определение полярности и порядка следования импульсов

Degussa

Доброго всем времени суток.

Прошу подсказать в какую сторону копать/гуглить.
Имеется единичный сигнал в точно неизвестный момент времени, в вариантах как на картинке.

Два близких (заведомо противоположных по полярности) импульса (или один одной полярности), не математической формы с минимальной длительностью порядка сотен наносекунд, между неизвестный промежуток от 0 до 50u, амплитуда около 5мВ-1В. (Точно известно что ничего другого на входе не будет)
Необходимо определить их последовательность (первым был положительный или отрицательный) или единичность и каким то способом передать информацию об этом микроконтроллеру (esp/arduino). На обработку и прочее есть приличное время до 500мс.
Пока пришёл в симуляторе к тому, что бы пиковыми детекторами "задержать" импульсы и отправить на аналоговый вход МК, итого уже можно отделить 4, 3, 1-2 варианты.
Остался вопрос как определить их последовательность и отличить 1 от 2, при условии что АЦП жутко медленный, да и прерывания тоже, точные значения сигнала не нужны и тратиться на внешний АЦП, строить его обвязку и прочее не хочется/дорого/сложно, важно узнать порядок следования.
Что то подсказывает что здесь имеется красивое аналоговое решение, как задержать/передать информацию.

Допустим после компаратора будут прямоугольные импульсы, но все равно они будут слишком узкими для МК..

Реклама

mickbell

После компаратора можно поставить одновибратор.

Реклама

Ivanoff-iv

Я бы поставил 2 компаратора для ловли событиев
затем 3 RS триггера: 1 взводится от положительного компаратора, сбрасывается от отрицательного - он будет хранить окончание сигнала
2 взводятся каждый от своего компаратора и блокируют друг друга, сбрасываются контроллером - они хранят начало сигнала
итого задействуется 4 ноги микроконтроллера (3 входа и 1 выход).

Добавлено after 22 minutes 8 seconds:
хотя... даже взаимоблокировка не нужна...
если сработали оба - то по третьему можно определить кто сработал позже.

Николай_С

[uquote="Degussa",url="/forum/viewtopic.php?p=4584568#p4584568"]Точно известно что ничего другого на входе не будет.[/uquote]
А потом где-то сверкнула молния и...

[uquote="Degussa",url="/forum/viewtopic.php?p=4584568#p4584568"]Что то подсказывает что здесь имеется красивое аналоговое решение, как задержать/передать информацию.[/uquote]
Аналоговые решения - сплошные компромиссы. Особенно в деле обработки, хранения и передачи информации. Если уж перешли в цифру, то и работайте с ней.

Реклама

Ivanoff-iv

если бы минимальная амплитуда сигнала была бы побольше, то можно было бы применить "красивое аналоговое решение"... да и скорости высоковаты - не каждый конденсатор успеет пере/зарядиться

Реклама

AlexS4

а помоему скорости смешные для несовсем древних mcu и ничего кроме встроенных компараторов с выходами на прерывания ненужно. для общего случая различить какое из прерываний пришло раньше можно чисто логическими операциями над 1 байтом (или 3мя его битами).
ставим начальное число 01
+ прерывание делает and 02
- прерывание делает xor 07

+ > 00
- > 06
+- > 02
-+ > 07

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

Реклама

Ivanoff-iv

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

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

Martian

Два таймера с запуском внешним триггером. Положительный запускает один, отрицательный запускает другой. Разница счётчиков = порядок следования. Ядро, наверное, не участвует (не разбирался, но было бы логично, что старт происходит самостоятельно).

Ivanoff-iv

АВР так не умеет, но у неё есть тактовый вход таймера и вход захвата... и этого достаточно.

Martian

Да, это даже лучше.

AlexS4

avr умеет по любому из фронтов

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

напр в avr архитектуре обработчики будут состоять каждый из 2 команд:
логической операции с регистром и хардкод константой (как в примере писал) (1 такт)
и reti

это 4-5 тактов всего!

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

можно смело поставить им высший приоритет и все!, в avr никто не задержит их дольше чем на 4 такта (200ns @20MHz at tiny13/2313 напр) снаружи останется только вовремя зачитывать и инициализировать регистр с результатом с интервалом меньше минимального ожидаемого времени следования сэмплов.

Ivanoff-iv

АВР не умеет приоритеты прерываний, поэтому надо чтоб АЛУ был всегда на изготовке, а если программа сложнее чем мигание светодиодом - это трудновыполнимо.

AlexS4

нуда, неумеет гибко их задавать но есть глобальные и индивидуальные блокировки. в долгих обработчиках можно маскировать только другие долгие прерывания, а пару коротких (int0,int1) не маскировать.

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

The complete list of vectors is shown in “Interrupts” on page 44. The list also
determines the priority levels of the different interrupts. The lower the address the higher is the
priority level. RESET has the highest priority, and next is INT0 – the External Interrupt Request
0. ...

Degussa

[uquote="Ivanoff-iv",url="/forum/viewtopic.php?p=4584670#p4584670"]Я бы поставил 2 компаратора для ловли событиев
затем 3 RS триггера[/uquote]
Благодарю, в симуляторе работает отлично, не доводилось просто использовать триггеры и логические схемы

PS теперь хочется пихать подобное везде, с мыслью а зачем нам в половине случаев вообще МК

[uquote="Николай_С",url="/forum/viewtopic.php?p=4584688#p4584688"]А потом где-то сверкнула молния и...

[/uquote]
Диоды, TVS и прочее никто не отменял (это если про выживаемость) + уже программная фильтрация и обработка ошибок (если про адекватность данных) (Событие плюс-минус 500мкс неизвестно только, а так периодически повторяющееся, шансы есть

)
[uquote="Ivanoff-iv",url="/forum/viewtopic.php?p=4584731#p4584731"]а он может быть сильно занят каким-то более требовательным и первостепенным процессом... а может просто код быть насквозь ардуиновый...[/uquote]
Тут и у МК других дел полно в ровно тот же момент времени и код.. Скажем так, дурино-любительский

Собственно, именно этот огород в итоге ловит ошибку для других измерений, хочется просто.. снять мгновенное кол-во работы с МК (То есть проблема не только в длительности прерываний и том, что они вывалятся в неподходящий момент, но и в том что эту информацию хочется обработать чуууть позже когда МК уже пьёт чай)
Но на прерываниях ради интереса попробую всё равно проверить позже на реальном прототипе.

Ivanoff-iv

ещё бы не мешало учесть возможность ситуации, когда МК совсем свободен и может отчитаться об одиночном импульсе просто не дождавшись второго...

AlexS4

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