Файлы  •  Ссылки  •  Прошивки  •  Правила  •  Архив  •   FAQ  •  Участники  •  Поиск
Регистрация  •  Вход

Программный анализ сигналов

Список форумов » Программное обеспечение » Микроконтроллеры На страницу Пред.  1, 2, 3
АвторСообщение
Konstantin_18
Участник
Сообщения: 3369




06-08-2017 17:02

dima080383, DTMF декодер на таком-же проце.
Программный, без использования других микросхем.
Это достаточный уровень ?
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




07-08-2017 09:17

Konstantin_18, Удивил. В нэте море листингов прог с квадратурным перемножением каналов. Другой вопрос че ты сним делать будешь с тремя то свободными ногами (ито если без кварца)?

Добавлено 07-08-2017 09:28

Да, возвращаясь к теме, вчера изменил прогу как описывал выше. Пока все работает, дребезг вроде не мешает, сколько раз включал - столько и отрабатывалось. Погоняю еще некоторое время что бы убедиться в надежности работы.
Eex
Участник
Сообщения: 1522




07-08-2017 09:51

нет ничего более сложно, чем задачи, поставленные перед нами и нет ничего более простого, чем задачи решаемые другими. Нет ничего более организованного и понятного, чем наши программы и нет ничего более нелепого и смешного, чем программы, написанные другими.
Допускается любая форма написания программного кода до тех пор, пока не начинается работа в команде. Вот тут начинаешь понимать, что комментарии надо писать понятные, переменные надо называть по правилам, функции надо разделять по смыслу, а не по размеру и т.д.
В наших же условиях, любая программа, которая работает и есть та самая хорошая программа. Если она тратит кучу ресурсов контроллера, то кого это волнует? Главное чтобы ресурсы контроллера тратились на 99%, а не на 101%.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




07-08-2017 10:17

Давайте все расстивим по полочкам. Я руководствуюсь таким принципом: чем проще - тем надежнее. Пытался писать и на прерываниях от портов и от таймера и от обоих. Эффект был слабый. Теперь у меня в запасе минимум 500 мкс, поскольку после анализа частоты следует пауза, которую мы особо не учитываем. Не учитываем мы ее потому, что последний бит четности вообще не имеет паузы. С другой стороны задача программы постсоянно слушать сигналы в линии, поэтому она и должна большую часть времени этим заниматься.

Добавлено 07-08-2017 10:21

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

Добавлено 07-08-2017 10:27

Вот например если мой контроллер помимо анализа был бы занят еще и динамической индикацией дисплея то, конечно, пришлось бы вводить прерывания. Но моя задача это принять 4 байта информации и включить нужный порт. На эту задачу (анализ принятых байт и переключение портов) я трачу примерно 20 - 30 мкс
Eex
Участник
Сообщения: 1522




07-08-2017 11:26

dima080383 писал:
Я руководствуюсь таким принципом: чем проще - тем надежнее.

Вам никогда не приходилось разобрать датчик температуры, у которого внутри находится 16-ти битный процессор цифровых сигналов, который способен за один такт поделить два числа с плавающей точкой? За чем его поставили? Принцип "чем проще, тем надёжнее", это принцип механического оборудования (сомнительный принцип), а не электронного. Когда вы начинаете решать проблемы, о которых вы даже не задумывались (температурный дрейф, уровень помех в два раза превышает полезный сигнал, передача сигнала на 5км и прочие) начинает казаться, что установить процессор цифровых сигналов и является самым простым решением. В вашей же программе вы избрали способ, который не выполняет требования протокола (видимо этот способ удовлетворяет вашим требованиям, но не протокола), по этому рано судить на сколько он прост. Можно было протянуть дополнительный кабель до коробочки и переключать головки тумблером, это было бы ещё проще, но не отвечало бы требованиям протокола.
dima080383 писал:
Пытался писать и на прерываниях от портов и от таймера и от обоих. Эффект был слабый.

пытаться и преуспеть, это разные вещи. Прерывания для вас в новинку, значит и методикой реализации владеете слабовато. Писать вашим методом, это как писать книгу ручкой, зажатой в кулаке. Можно будет даже достичь какой-то скорости, при достаточной тренировке, но метод заведомо проигрышный по отношению к традиционному. Наступает предел, после которого этот метод безнадёжно уступит традиционному.
dima080383 писал:
Не учитываем мы ее потому, что последний бит четности вообще не имеет паузы.

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

программа может слушать линию даже НАХОДЯСЬ В SLEEP режиме (т.е. без программного кода вообще), но вы решили иначе, значит это ваша правда, но отнюдь не ограничение задачи.
dima080383 писал:
Если взять вышеупомянутый анализ DTMF сигнала то там конечно без прерываний не обойтись

вот тут моя статейка о прерываниях и об операционной системе (вопрос тут поднимался). Прочитайте, может найдёте для себя что-то полезное.

ПС рад, что всё получилось. Что может быть приятнее, чем достигнутая цель улыбка. Поздравляю улыбка
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




07-08-2017 11:57

Тогда я еще раз повторю свой вопрос: каким образом бы вы будете принимать паузу последнего бита четности?
Если в статье есть ФИО автора я буду ее читать. Мнения анонимов меня мало инетеруют.

Добавлено 07-08-2017 12:01

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

Добавлено 07-08-2017 12:04

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

Добавлено 07-08-2017 12:10

Вы все время ссылаетесь на протокол, а он на сомом деле не дает ни каких рекомендации по решению вопроса, но только описывает тайминги и погрешности. Как вы считаете почему пауза меняется в зависимости от переданного бита? И на сколько было бы все по другому если бы все паузы были одинаковой длительности (и для 0 и для 1)?

Добавлено 07-08-2017 12:15

А что касается вашего укора в том, что я не владею прерываниями. Первая моя программа с прерываниями это генератор базинтервального пакета АОН стандарта "Расский АОН". Я формировал двухчастотные посылки заданной длительности. Таким образом имитировал работу аппаратуры АОН АТС. Для формирования одной частоты я использовал TMR0, для другой TMR1.

Добавлено 07-08-2017 12:17

И у меня тоже есть статьи на паяльнике и в Радиолоцмане. Просто я не считаю правильным ими раскидываться направо налево)

Добавлено 07-08-2017 12:24

Не думаю что сравнивать поставленный тут вопрос с измерением темепратуры с помощью процессора вообще корректно. У вас там наверняка сложный быстродействующий модуль АЦП поэтому и разрядность большая.
Я ведь не отвергал возможность использования прерываний для моего анализа. Я даже писал программу на прерываниях, но результат ее работы меня не удовлетворил. Поэтому я нашел более простое и понятное мне решение.
Eex
Участник
Сообщения: 1522




07-08-2017 13:00

dima080383 писал:
Тогда я еще раз повторю свой вопрос: каким образом бы вы будете принимать паузу последнего бита четности?

собственно в 4-й раз отвечаю. Смотрите в мою рукописную картинку в раннем посте. Последний бит (как и все остальные биты) начинается частотой, которая длится 0.5 или 1 мс. За частотой обязательно следует пауза 1 или 0.5 мс соответственно. Что следует после этой паузы нас не интересует (снова частота или продолжается пауза). С началом частоты мы запускаем таймер 0.4 мс и считаем импульсы, потом перезаряжаем таймер и опять считаем импульсу, за тем запускаем таймер в последний раз и считаем импульсы. Если в результате получили импульсы-импульсы-нетИмпульсов, то приняли единицу. Если получили импульсы-нетИмпульсов-нетИмпульсов, то получили ноль (все другие комбинации = нет бита). В этой схеме мы нашли паузу в бите (в любом бите, в том числе и в последнем).
dima080383 писал:
На самом деле нет никакой разницы в том как контроллер отрабатывает тут или иную программу: делает он это режиме прерывания или в режиме прямого счета (как у меня). Лиж бы все было в пределах допустимой погрешности.

Вы так и не написали программу, которая отвечает требованиям протокола, по этому и не можете (пока) рассуждать о методе написания программы, которая отвечала бы требованиям. Пользуясь своим методом, вы уже неделю пытаетесь найти паузу в протоколе для анализа полученной информации. Протокол паузу не предусматривает, по этому анализировать надо на лету. Возможно именно ваш тюнер делает паузу в протоколе, возможно вы найдёте некую универсальную паузу, общую для 5-ти ваших тюнеров. Такой метод называется "подогнать под ответ". Такой метод без условно работает. Я же говорю о стабильности. Если начнутся косяки, то вы скажете заказчику "я не нашёл паузу в протоколе, извините, но косяки будут продолжатся". Если вы будете следовать описанию протокола и возникнут косяки, то вы скажете заказчику "мой алгоритм полностью отрабатывает требованиям протокола, разбирайтесь с тюнером или с разработчиком протокола". Чувствуете разницу в том как контроллер выполняет поставленную задачу?
dima080383 писал:
Вы все время ссылаетесь на протокол, а он на сомом деле не дает ни каких рекомендации по решению вопроса, но только описывает тайминги и погрешности.

не есть задача разработчиков протокола думать о конкретной реализации. В из задачу входит только определение цены для приёмника и передатчика. К примеру, перед разработчиками стоит задача "приёмник должен легко реализовываться на 8-ми битных контроллерах среднего класса с частотой до 1 мГц". Эта задача весьма и весьма эфемерная, но "заточенный глаз" разработчиков сразу определит частоту, размах и порядок правил в протоколе для того, чтобы вписаться в эти рамки.
dima080383 писал:
Как вы считаете почему пауза меняется в зависимости от переданного бита? И на сколько было бы все по другому если бы все паузы были одинаковой длительности (и для 0 и для 1)?

Разработайте один (только один) протокол и вы поймёте, что протокол решает кучу проблем, которые всплывают только при отладке и тестах. Протоколы разрабатывают группами или даже компаниями ибо задача не простая. По вашему вопросу о паузе. Вот ситуация, на линии уже 3 секунды идёт не прерывная частота и тюнер передаёт первый бит. Бит начинается с частоты, после которой идёт пауза. В вашем случае это одинаковая пауза в 0.5мс. Какой бит передал тюнер 1 или 0? 3 секунды частоты и пауза 0.5 мс по оригинальному протоколу, это единица, а по вашей версии они не отличаются. Не пытайтесь найти и другие методы упростить правила протокола, поверьте его придумала не группа дураков, а группа инженеров. Они подумали обо всём и написали правила протокола.
dima080383 писал:
А что касается вашего укора в том, что я не владею прерываниями.

да бог с вами, любезный, я и не думал укорять кого-либо в недостатке знаний. Пошли мне проведение учителя, который укажет мне более рациональный путь в решении моих задач и будет возиться со мной так, как я возился с вами. Ан нет, приходится самому наступать на грабли и решать проблемы через упорный труд. Не стесняйтесь учитывать советы других, даже если они знают меньше вашего.
Если тема решена, то я пропадаю. Понадобится что пишите в личку.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




07-08-2017 13:11

Вы упустили из виду самое главное: перед передачей Diseq комманды если в линии была непрерывная частота, то вначале выдерживается тишина! Так что частотная посылка бита приходит обособленно (перед ней тишина и после нее тишина). Вижу вы так толком в протоколе и не разобрались...

Добавлено 07-08-2017 13:14

А теперь я скажу вам для чего паузы имеют различную длительность (именно те паузы, которые идут между частотными посылками битов). Они компенсируют длинну частотной посылки для того что бы в совокупности длинна одного бита (а значит и байта) была всегда одинаковой. Подобная унификация чрезвычайно распространена.

Добавлено 07-08-2017 13:29

Т.е. получается, что пауза должна быть обрамлена двумя смежными частотными посылками предыдущего и последующего битов. Поскольку пауза последнего бита четности далее ни чем не обрамляется (следующего бита по просту нет), то определить ее мы НЕ МОЖЕМ! Зато можем определить все частотные посылки битов. Поэтому анализ нужно производить только по ЧАСТОТНЫМ ПОСЫЛКАМ!

Добавлено 07-08-2017 14:06

Теперь о моей программе: она отслеживает частоту длительностью от 300 мкс до 1000 мкс и максимально длинную паузу (не более 1000 мкс). Если все эти нормы соблюдены то можно говорить об успешно принятом бите.

22kHz-command-22kHz.jpg



dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




08-08-2017 07:40

Добрый день. Вчера снова повторился косяк с дребезгом. Придется признать, что мой алгоритм слишком упрощенный и не имеет защиты от дребезга.

Добавлено 08-08-2017 07:45

Прописал таймер TMR0 по синхронизации от порта по возрастающему фронту, но проблемма не решилась.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




11-08-2017 07:51

На выходных доработал алгоритм: вместо циклического опроса порта во время паузы поставил опрос таймера. Анализ частоты так же реализовал на таймере TMR0 с выборками в 100 мкс. Преимущество таймера перед обычным опросом порта безспорно. При наличии частоты в 22 кГц он накапливает значение равное 2 за время 100 мкс (либо по возрастающему либо по спадающему фронту). Дребезг же такого значения иметь не будет. У меня еще один вопрос: как можно реализовать проверку на четность байта за минимальное количество машинных циклов?
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




11-08-2017 10:46

Нашел интересную прогу, которая в отличие от подобных не модифицирует исходный байт:

; CheckParity:
swapf tmp, w ; John's idea: reducing byte to nibble
xorwf tmp, w
addlw 41H ; bit 1 becomes B0^B1 and bit 7 becomes B6^B7
iorlw 7CH ; for carry propagation from bit 1 to bit 7
addlw 2 ; Done! the parity bit is bit 7 of W
andlw 80H ; set NZ if odd parity, and leave 00 or 80 in W


BTFSC STATUS, Z ; если результат =0...
BSF TEMP,0

NOP

Добавлено 11-08-2017 10:48

Если байт tmp содержит четное количество единиц (нулей) то в нулевой бит регистра TEMP записывается "1".
Список форумов » Программное обеспечение » Микроконтроллеры » Программный анализ сигналов На страницу Пред.  1, 2, 3
Перейти:  
Текущий раздел » Программное обеспечение » Микроконтроллеры (Микроконтроллеры - AVR-ы, PIC-и и другие)


Похожая информация:
  • PIC18F442-I/P как правильно считать программный код?
  • ПРИБОРЫ - способы измерения, параметры сигналов







  • Электроника
    Прошивки и схемы на телевизоры, мониторы, dvd, телефоны. Schematic, Service Manual (mode), eeprom dumps Информация по ремонту для специалистов - справочники, инструкции, энциклопедия, советы и секреты ремонта,  настройка, сервисные режимы поиск и продажа электронных компонентов, магазины, datasheet, pdf, размещение в интернете рекламы на сайтах электронной тематики
    Powered by phpBB 2.0.18 © 2001, 2002 phpBB Group!