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

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

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




04-08-2017 16:13

В самом устройстве Diseq нет никаких фильтров! На порт приходит частота! Как он ее анализирует, что он там считает: периоды или огибающую это науке не известно. Так например есть специализированная ИС которая анализирует код DTMF в телефонии или наоборот ИС, которая формирует DTMF посылки. Для пик-контроллера эти задачи на грани фола!

Добавлено 04-08-2017 16:17

Я так понимаю частотные импульсы вы будете считать по прерыванию от порта? Тогда скажите пожалуйста сколько таких прерываний вы получите в течении 400 мкс пока идет частота?
Eex
Участник
Сообщения: 1522




04-08-2017 16:23

dima080383 писал:
В самом устройстве Diseq нет никаких фильтров! На порт приходит частота!

все устройства придумали люди и у каждого свои задачи. К примеру если планируется выпустить 100 000 штук изделия, то затраты на железный фильтр (пара конденсаторов и тройка резисторов + запайка) будут исчисляться сотнями долларов на всю партию. При таком раскладе лучше заплатить программисту за лишний час работы, чем городить фильтр. Если планируется выпустить 1000 штук, то пару долларов на партию никого не волнуют, вот цена программиста уже повлияет на результат.
реализация частотных анализаторов не такая уж и космическая задача, есть математические приёмы для расклада сигнала на спектральные всплески (как в случае с DTMF сигналами) и математика там не такая уж и тяжёлая. Наш случай не подойдёт для реализации.

Добавлено 04-08-2017 15:31

dima080383 писал:
Я так понимаю частотные импульсы вы будете считать по прерыванию от порта? Тогда скажите пожалуйста сколько таких прерываний вы получите в течении 400 мкс пока идет частота?

ну так 11 прерываний!? Вас что-то смущает? Это прерывание не делает ничего кроме инкрементирования счётчика. Сброс этого счётчика будет в другом прерывании. Это только в том случае, если вы "раб железа" и сигнал не приходит на ногу внешнего входа таймера. В прочем мы пока разрабатываем стратегию, предлагайте варианты....
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




04-08-2017 16:33

Чисто эмпирическим путем я написал программу, которая вроде пока работает на обоих тюнерах (в том числе и с дребезгом). Сейчас я хочу понять закономерности ее работы. А именно почему после приема частотной посылки я должен ослеживать тишину в течении 2 мс (именно 2, а не 1!!!) и если она продлится эти 2 мс без опознования "1" на порту, то это будет считаться ошибкой и процесс анализа повторится. Т.е. для успешного опознавания бита тишина должна быть прервана до истечения 2 мс.

Добавлено 04-08-2017 16:37

так вот именно, что не 11 прерываний! Один период чатоты это как минимум 2 прерывания - переход через ноль в отрицательную полуволну и обратно)))))) кроме того в зависимости от уровня сигнала на разных тюнерах этих прерываний будет разное количество

Добавлено 04-08-2017 16:40

ведь прерывания считаются как по фронту так и по спаду, а выбрать конкретное направление (фронт или спад) от GP2 в моем случае мы не можем
Eex
Участник
Сообщения: 1522




04-08-2017 17:54

Вас смущает количество прерываний или что другое? Поделите счётчик на два или каждое второе прерывание пропускайте (btfsc gp2 retfie) или сравнивайте не с 11, а с 22. Мы обсуждаем концепцию или частности? Реализовывать алгоритм, это уже вторая задача, сейчас нам надо найти оптимальное решение задачи. Я не качал даташит на ваш контроллер. С головы тоже не помню по каким фронтам у какого контроллера какие прерывания. Может на этом порту сидит внешний вход таймера? В таком случае всё в разы упрощается. Сейчас мы говорим только о том, что надо считать импульсы, а каким именно способом их считать, это уже по месту решите.
Eex
Участник
Сообщения: 1522




05-08-2017 00:01

dima080383 писал:
ведь прерывания считаются как по фронту так и по спаду, а выбрать конкретное направление (фронт или спад) от GP2 в моем случае мы не можем

прерывание - таки по фронтам, а не два за такт. Или что вы имели ввиду говоря "выбрать фронт мы не можем"?

Добавлено 04-08-2017 23:05

о, смотрите как интересно:
GP2/T0CKI/INT/COUT
оказывается, что GP2 является внешним сигналом для таймера 0. Так почему бы нам просто не запускать таймер0 и смотреть чего он там насчитает от внешнего пина?

Untitled.png



Konstantin_18
Участник
Сообщения: 3370




05-08-2017 19:58

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




06-08-2017 06:43

Konstantin_18 писал:
Eex, Можно еще проще. Включить его в режим счетчика и анализировать по второму таймеру сколько первый насчитает за период.
Я думал о том, что пустить оба таймера в работу + прервания от порта, но это ужасно сложно! А если мне сложно, то будет сложно и контроллеру)

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

Eex писал:
dima080383 писал:
ведь прерывания считаются как по фронту так и по спаду, а выбрать конкретное направление (фронт или спад) от GP2 в моем случае мы не можем

прерывание - таки по фронтам, а не два за такт. Или что вы имели ввиду говоря "выбрать фронт мы не можем"?

Добавлено 04-08-2017 23:05

о, смотрите как интересно:
GP2/T0CKI/INT/COUT
оказывается, что GP2 является внешним сигналом для таймера 0. Так почему бы нам просто не запускать таймер0 и смотреть чего он там насчитает от внешнего пина?


Действительно GP2 интересный порт. В нем как раз таки можно выбирать активный фронт прерывания (по переднему фронту или по заднему фронту). Только для этого GP2 нужно перевести в режим работы INT. Буду изучать как это делается. А пока вот набросал исходя из прошлого анализа.



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

Здесь я считаю в цикле 100 мкс как наличие лог"1" на порту, так и наличие лог"0". Кроме того проверяю минимальную длинну полученной частоты - не менее 300 мкс. В принципе данный вариант работает стабильнее чем предыдущий, но из 10 включений тюнера 1 все таки не срабатывает.
Eex
Участник
Сообщения: 1522




06-08-2017 09:12

dima080383, вы бы выкладывали код не текстом, а файлом. А то у вас нет объявлений и дефиниций. Я же начну смотреть ваш код только после того как вы представите работоспособный алгоритм отлова сигнала. Ибо чего искать ошибки в коде, который даже в теории не понятно будет ли работать
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




06-08-2017 09:27

Eex, Весь текст проги выкладывать не вижу смысла, т.к. там еще полно других функциональных особенностей. Данный фрагмент вылавливает частоту и паузу. Вернее сказать, что если в течении 1 мс после исчезновения чястоты мы поймаем лог.1 на порту, то процедура будет считаться выполненной успешно. Код работает не только в теории, но и на практике.

Добавлено 06-08-2017 09:30

К данной подпрограмме мы обращаемся 8 раз, 9й бит четности пропускаем небольшой выдержкой времени, эквивалентной длительности частоты для "0" бита (поскольку у самого последнего бита четности пауза не будет определена).
По сути здесь заложена защита от ложного определения дребезка как бита данных. Поскольку при ошибочном захвате дребезка (распознование его как частоты) пауза будет дольше, чем этого требует протокол.
Eex
Участник
Сообщения: 1522




06-08-2017 09:54

dima080383, если для вас код работает, то закрывайте тему. Однако, если код не оаботает один раз из 10, то я считаю, что код не работает. Было бы правильно не задавать общий вопрос "помогите найти косяк в коде", а указать конкретную проблемную функцию. К примеру так:
Если пакеты идут 3 подряд, то последний пакет не распознаётся, а если с паузами, то нет проблем. Высший пилотаж, если подкрепить сказанное осцилограммой дефекта. А то получается, что у вас всё работает, но коды для проверки вы выкладываете.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




06-08-2017 10:07

Eex, В том то и дело, что дребезг понятие не определенное. Его временные характеристики не поддаются описанию и моделированию. Думаю моя проблемма еще и в том, что необходимо еще и нормировать время между прохождениями соседних частот. Так, например, если дребезг все же выл воспринят как тот или иной бит, а паузу мы попросту проигнорировали, дав задержку на ее прохождение в 1 мс, то при очередном входе в подпрограмму ANALIZ мы должны сразу поймать частоту, ведь так? Значит даже 100 мкс задержки до появления лог"1" на порту должно быть воспринято как ошибка! Значит надо в начале подпрограммы поставить цикл на 100 мкс с определением лог"1". Если цикл выработается и лог"1" не будет определена нужно уходит в самое начало ... т.е. на прием самого первого бита.
Eex
Участник
Сообщения: 1522




06-08-2017 10:36

dima080383, и ещё раз по поводу дребезга...... если дребезг отвечает требованиям бита, то ЕГО СЛЕДУЕТ СЧИТАТЬ ПРИНЯТЫМ БИТОМ!!!!!! Сейчас займитесь не тем, что вы приняли пакет, а тем, что вы УВЕРЕННО приняли КАЖДЫЙ бит. Анализом принятых битов мы займёмся потом.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




06-08-2017 10:58

Eex, В моем алгоритме дребезг может отвечать требованиям пакета, т.к. он сильно упрощен. Что бы гарантированно отличить бит от дребезга нужно нужно посчитать его периоды и длительность паузы после него. Но в том то и казус, что чем сложнее прога, тем она хуже работает!!! Вот эта простая работает на 90 %. Напишу с прерываниями вообще работать не будет! И какой выход? Ломать голову в 45й раз? Или довести эту версию до логического конца? И еще раз напомню, что кроме 22 кГц и паузы у нас там ничего быть не может. ТОГДА ЕСТЬ ЛИ СМЫСЛ СЧИТАТЬ ПЕРИОДЫ И АНАЛИЗИРОВАТЬ ЧАСТОТУ???

Добавлено 06-08-2017 11:02

Eex, Что же касается данногоо алгоритма, то верность принятия каждого предшествующего бита можно подтвердить только после принятия последующего (как бы смешно это не казалось). Если временные рамки будут нарушены, то это нужно расценивать как ошибку.
Eex
Участник
Сообщения: 1522




06-08-2017 11:31

Если дребезг будет отвечать требованиям именно ПАКЕТА (не бита), то это уже косяк разработчиков протокола. Я ставлю 10 к 1, что ошибаетесь вы, а не разработчики. Касаемо сложности программы. Вы боитесь неизвестного, это нормально. Попробуйте написать программу, в которой таймер0 будет считать импульсы, а таймер1 - время. Вы увидите, что такая программа займёт в 5 раз меньше команд и при этом освободит 70% ресурсов контроллера. Ресурсы контроллера можно будет задействовать для анализа и при этом не раздвигать код при каждой новой введённой инструкции. В вашем же коде контроллер занят на 100%, при таком раскладе вы вынуждены подстраивать время всего цикла под КАЖДУЮ инструкцию и в панике думаете о том, что будет, если мне потребуется добавить 10 лишних строк кода. В вашем коде 10 лишних строк могут уже не вписаться в тайминк, а в схеме с прерываниями, 10 строк, это код с паузах и не влияет не на что. При этом код будет считать и частоту и паузу, как требует протокол. Вы же говорите "хочу стабильной работы, но считать паузы не буду". Реальность такова, что есть описание протокола и ему надо следовать. Если вы игнорируете описание, то принимайте риски в виде не стабильной работы.

Добавлено 06-08-2017 10:44

По поводу подтверждения принятых битов. Это не более, чем процесс отладки программы. У меня устоялся следующий метод:
Временно задействую ногу контроллера для вывода диагностики. К этой ноге подключаю один канал логического анализатора (10-ти доллоровый прибор). Другой канал анализатора подключаю к ноге контроллера, на которой сидит входной сигнал (gp2) . Если бит принят, то на тестовой ноге ставлю единицу. После всех подключений запускаю тюнер, пока не проявится косяк в приёме пакета. Анализатор пишет всё это время. Потом в анализаторе смотрю какой именно бит не подтвердился на диагностическом выводе. Анализирую конкретные причины сбоя.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




06-08-2017 12:04

Eex, Тогда скажите каким образом я должен считать паузу у последнего бита четности?

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

Ну вот вам прервания:



ВЫ ПОНИМАЕТЕ ЧТО ВРЕМЕННЫЕ ИНТЕРВАЛЫ ПЕРИОДА ОЧЕНЬ КОРОТКИЕ ЧТО БЫ СЧИТАТЬ ЧАСТОТУ???! ОН ЕЩЕ НЕ УСПЕЕТ ОТРАБОТАТЬ ОДНО ПРЕРЫВАНИЕ КАК У НЕГО УЖЕ ФЛАГ ВТОРОГО ПОЯВИТСЯ!

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

Если бы речь шла о пике на 10 МГц тогда бы ладно, но вы посчитайте сколько времени уйдет на обработку прерывания!

Добавлено 06-08-2017 12:31

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

Добавлено 06-08-2017 12:33

Что же касается анализатора за 10 баксов: у нас в Узбекистане не то что анализатор спектра, осциллографа нормального купить невозможно! Я в качестве осциллографа приспособил звуковой редактор на компьютере Cool Edit)
Eex
Участник
Сообщения: 1522




06-08-2017 13:20

dima080383 писал:
Что же касается анализатора за 10 баксов: у нас в Узбекистане не то что анализатор спектра,

вы не внимательны, я писал не о анализаторе спектра, а о логическом анализаторе (доставка бесплатная по всему миру). Можно нарыть и бесплатные варианты, правда потребуется LPT порт.
dima080383 писал:
Eex, Тогда скажите каким образом я должен считать паузу у последнего бита четности?

давайте опять обратимся к описанию и посмотрим как они предлагают принять бит:

Команды DiSEqC передаются по линии постоянного питающего напряжения 12-20 В при помощи тоновых посылок частотой 22 кГц (±20 %).....................
Время передачи одного бита составляет 1,5 мс и условно разделено на 3 равные части по 500 мкс (±100 мкс). Для бита 0 ширина огибающей составляет 1.0мс...........

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

dima080383 писал:
ВЫ ПОНИМАЕТЕ ЧТО ВРЕМЕННЫЕ ИНТЕРВАЛЫ ПЕРИОДА ОЧЕНЬ КОРОТКИЕ ЧТО БЫ СЧИТАТЬ ЧАСТОТУ???! ОН ЕЩЕ НЕ УСПЕЕТ ОТРАБОТАТЬ ОДНО ПРЕРЫВАНИЕ КАК У НЕГО УЖЕ ФЛАГ ВТОРОГО ПОЯВИТСЯ!

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

dima080383 писал:
пусть мы ловим тупо лог.1. и лог.0 в течении 100 мкс, но длительность этого дребезка и пауза после него полжны соответствовать протоколу! А это мы и безо всяких прерываний можем посчитать.

ну во первых ловить что-то там за 100мкс, это сугубо ваша реализация. В протоколе же идёт речь только об интервалах в 500мкс. Во вторых дребезг ничему не должен соответствовать, это помеха и она имеет форму как бог на душу положит. В третьих, использование инструментов контроллера (к примеру прерываний) требуется для того, чтобы разгрузить контроллер. Может вы и справитесь без прерываний, но я уже описал гигантскую проблему вашего кода - добавление в него пары строк требует перерасчёта всех таймингов функции. Я не вижу всей программы, но предполагаю, что после принятия бита, вы не проверяете его на соответствие байту "начало пакета" и по последнему биту не проверяете пакет на чётность этого бита. В вашем коде, где контроллер занят на 100%, ввести проверку пакета, означает вывалиться из всех тайминговых рамок. У вас после приёма байта просто нет времени проверить его на "начало пакета", ведь надо срочно бежать и принимать второй байт (биты идут спина-к-спине в протоколе). В случае с прерыванием, контроллер будет "курить" ещё 400мкс после принятия бита. За это время можно исполнить 400 инструкций - более чем достаточно для любого анализа в нашем протоколе.

  DSC07504.JPG  94,07 КБ  Скачано: 16 раз(а)

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




06-08-2017 13:28

Ну да: "Бит или не бит - вот в чем вопрос..."

Добавлено 06-08-2017 13:39

А я думаю так: коль уж пауза последнего бита четности не определена то и относиться к ней не нужно так серьезно.
Допустим мы поймали частоту (выборками по 100 мкс) в течении от 300 мкс до 1000 мкс. Далее должна быть пауза от 500 мкс до 1000 мкс... Мы можем подождать в цикле до 1000 мкс наличия лог.1 т.е. начало уже следующего бита... Если поймали 1 то вышли из подпрограммы и определили какой бит получили:
и тут же проверяем полученный бит на равенство "1" (помните: 11100000 для первого байта)


Добавлено 06-08-2017 13:41

в принципе во время определения первого бита в блоке ***************1*************** у нас уже пойдет следующая честота, но времени мы займем не много порядка 10 - 15 мкс - это в пределах допустимой погрешности...так что при входе в ANALIZ мы ее определим без особых проблемм

Добавлено 06-08-2017 13:46

И в принципе без учета дребезга все работает идеально!
А теперь представьте, что пошел дребезг и по какой то причине его временные характеристики совпали с таймингами частоты и паузы: допустим дребезг продолжался 400 мкс, а во время выдержки паузы он повторился - т.е. ANALIZ его определил как бит.

Добавлено 06-08-2017 13:48

Далее программа выходит из ANALIZ, обрабатывает полученный бит и возвращается в ANALIZ для приема следующего бита *********2*********

Добавлено 06-08-2017 13:49

Если дребезг продолжается, но его длительность недостаточна для 300 мкс , то прием прерывается и программа сбрасывает все счетчики и вновь ожидает приема самого первого бита

Добавлено 06-08-2017 13:54

А вот если самый последний дребезг был принят как бит данных и по какой то причине он был распознан и вроде как была определена следующая частота, но при очередном входе в ANALIZ образовалась пауза (т.е. за те 10-15 мкс что обрабатывался мнимый бит дребезг прекратился. И началось самое страшное: один или несколько бит уже приняты (ложные биты) дальше в линии тишина, ANALIZ ждет появления лог"1" и вот приходит настоящий пакет : но он уже записываетяс не с первого бита, а с 3го или со 2го....

Добавлено 06-08-2017 13:55

т.е. весь пакет сдвигается - байты принимаются неправильно - комманда не отрабатывается - конец пакета - тишина...

Добавлено 06-08-2017 13:56

А все потому, что мы бесконечно долго ждем появления лог"1" в начале пп ANALIZ.

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

т.е. мы в данном случае не учитываем время от конца одной частоты до начала следующей

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

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

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

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



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

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

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

В самом начале процесса контроллер будет выкидывать нас из пп ANALIZ каждую 1 мс при отсутствии "1" на порту и возвращать назад через 5-10 мкс, так что частоту (или дребезг) мы поймаем без проблемм. Далее если частота будет в пределах 300 - 1000 мкс, то мы обработаем то, что получили и перейдем занова в ANALIZ для приема последующего бита. Если частота не появится по истечении 1000 мкс то нас снова выкинет в самое начало программы. Если же в указанном интервале времени появится снова короткий дребезг, то он будет подсчитан как частота, принят и т.д. Но в конце концов величина паузы превысит допустимую. Пусть это будет 5й, или 6й бит...
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




06-08-2017 14:33

Т.е. суть всего вышескзанного в том, что бы не потерять время и не упустить реальную частоту бита. Поэтому выборки именно в 100 мкс - это 2 периода рабочей частоты (т.е. больше вероятности поймать и 0 и 1 на порту) и одновременно минимальная кратная и 500 и 1000 мкс рабочая единица анализа.

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

Eex, Так как вас все таки звать-величать, коллега?
Eex
Участник
Сообщения: 1522




06-08-2017 14:57

dima080383 писал:
коль уж пауза последнего бита четности не определена то и относиться к ней не нужно так серьезно.

пауза чётко определена! Пауза для нулевого бита составляет 1мс+-20%, а пауза для единичного бита составляет 0.5мс+-20%. Как относиться к паузе дело ваше, но придётся снизить своё отношение к стабильности работы устройства.
dima080383 писал:
Допустим мы поймали частоту (выборками по 100 мкс) в течении от 300 мкс до 1000 мкс. Далее должна быть пауза от 500 мкс до 1000 мкс... Мы можем подождать в цикле до 1000 мкс наличия лог.1 т.е. начало уже следующего бита...

допустим паузы не было вообще (не прерывная частота для нужд головки). Тогда вы поймаете частоту и через 1000мкс ещё раз частоту. Вы подумаете, что это два бита, на самом же деле там нет ни одного бита. Протокол придуман для надёжной работы, если вам надёжность не столь важна, то можно игнорировать в нём то сё по мелочи. Если вы делаете единичное устройство для своей мамы, то она, конечно перезапустит тюнер пару тройку раз, пока он заработает. Если же устройство на продажу или для установки клиенту, то они не поймут работу через раз и отдадут его по гарантии на замену (замена на такое же глючное устройство). Быть вам битому при таком раскладе улыбка. Вы пытаетесь выкрасть время в протоколе для нужд проверки протокола, вместо того, чтобы освободить время в контроллере.
dima080383 писал:
А теперь представьте, что пошел дребезг и по какой то причине его временные характеристики совпали с таймингами частоты и паузы: допустим дребезг продолжался 400 мкс, а во время выдержки паузы он повторился - т.е. ANALIZ его определил как бит.

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

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

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

dima080383 писал:
Eex, Так как вас все таки звать-величать, коллега?

Еех вполне годится, я же так сам себя назвал улыбка. Будем знакомы улыбка.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




06-08-2017 15:03

Eex, Так давайте проясним: каким образом я поймаю 2 бита на непрерывной частоте?

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

ладно, отвечу сам
если частота непрерывна то анализ насчитает нам число выборок по 100 мкс более чем 11 (т.е. более 1100 мкс) - это переполнение и сброс.
Konstantin_18
Участник
Сообщения: 3370




06-08-2017 15:19

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




06-08-2017 15:24

Konstantin_18, Константин, а какого ваше мнение по вышеизложенному?

Добавлено 06-08-2017 15:25

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




06-08-2017 15:30

раз уж мы сходимся в том, что импульсы надо считать, то предлагаю вначале разобраться с этим.
Моя идея будет будет отлично работать, если считать импульсы таймером от внешнего источника. Ваша текущая идея так же не пострадает, если подсчёт возьмёт на себя таймер. Давайте сделаем так:
PIC12F629 datasheet писал:
The Timer0 module timer/counter has the following features:
• Internal or external clock select

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




06-08-2017 15:31

Eex, Тогда уже давайте листинг. Я то давал)
Konstantin_18
Участник
Сообщения: 3370




06-08-2017 15:39

Цитата:
Konstantin_18, Константин, а какого ваше мнение по вышеизложенному?

dima080383, Это не вам - это бесконечному терпению Eex.

dima080383, перестаньте пож. выкладывать куски вашей программы. Они абсолютно не читаемы.
И предлагать разбираться в подобном - это просто не уважать собеседника, да и самого себя тоже.
dima080383, вас же Eex ТРИЖДЫ просил об этом.

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




06-08-2017 15:42

Konstantin_18, Ну простите великодушно. А просто думал тут люди разбираются в ассемблере.

Добавлено 06-08-2017 15:42

Удалю
Konstantin_18
Участник
Сообщения: 3370




06-08-2017 15:42

dima080383 писал:
GOTO $+.10

я то понимаю, что это перейти на 10 команд вперед ( прибавить к РС 10 ), но вы понимаете
что заставляете всех СЧИТАТЬ строки вашего листинга.

Вы что про метки ничего не слышали ?

ПС. Это только один из примеров

ПСС. Нравится вам подобный стиль (в простонародье "говнокод" недовольство, огорчение ) - используйте, но предлагать другим не стОит.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




06-08-2017 15:46

Konstantin_18, Слишком много меток не люблю - в глазах рябит. ANALIZ_1, ANALIZ_2 - разве не метка?

Добавлено 06-08-2017 15:48

Konstantin_18, А я вам его и не предлогаю. Может вы мне тогда свой "говнокод" продемонстрируете? Мы его тоже обсудим.

Добавлено 06-08-2017 16:00

Konstantin_18, Прошу вас удалить свое последнее сообщение. В противном случае буду вынужден обратиться к администрации сайта.
Eex
Участник
Сообщения: 1522




06-08-2017 16:01

dima080383 писал:
Eex, Тогда уже давайте листинг. Я то давал)

если дойдёт до того, что вы не сможете подключить таймер, то я выложу, но не листинг, а помогу понять как это делается. Речь идёт не о том, что у меня есть листинг, но я не хочу его выкладывать. Речь идёт о том, что мне надо написать прогу и выложить её. Если я выложу прогу с ошибкой, то это будет не правильно, значит мою прогу придётся отладить перед выкладыванием. Один мой друг говорил, что он слышал о программисте, который пишет код без ошибок, но я в это не верю. Да, я тоже допускаю ошибки при наброске программы улыбка. Так что выложить листинг, это труд с моей стороны. К тому же вы просите не написать для вас программу, а помочь советом. Мои советы вы оспариваете, но и свою стратегию защищать вам нечем. Так что у меня нет другого выхода, кроме подкидывать вам мои идеи и искать дыры в ваших. Думаю через время вы для себя признаете правильность критики и учтёте опыт чуть более опытных программистов улыбка.
Если нужна помощь по подключению таймера, дайте мне знать.
Преимущества перехода на таймер в том, что он всё считает сам на заднем фоне, без участия цикла программы. Просто в нужный момент вам надо получить значение таймера и дальше работать уже с числом импульсов.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




06-08-2017 16:26

Eex, Я вам очень признателен за помощь и советы, ведь они так или иначе подталкивали меня к правильному решеню задачи. В принципе как работает таймер и прерывания от портов я знаю. Я считаю что ошибаться не зазорно никому. В конце концов для того и создан форум что бы обсуждать вопросы. Но вот называть "говном" то, что делает другой человек это самое последнее. И если даже человеку, который так говорит, 18 лет, это его не оправдывает.

Добавлено 06-08-2017 16:31

Eex, Честно признаюсь вам, что не люблю прерывания потому, что нужно выбирать точку в которой контроллер будет топтаться на месте ожидаю получения каких либо данных. А потом как выйти из этой точки? Некоторые умельци компонуют программу таким образом, что бесконечный цикл находится в самом конце, а все остальное прописывается наверху. Такой алгоритм, признаюсь, мне не понятен. Другое дело линейная прога, где все идет сверху вниз... Отработал одно, перешел ниже...Закончил полный цикл - перешел снова на верх...
Eex
Участник
Сообщения: 1522




06-08-2017 16:40

Код назвали не "гоаном" а "говнокодом", это слынговый термин. Таким же термином является термин "защита от дурака" ( он есть в википедии) , но этот не слэнговый. Не оправдываю никого.
По поводу главных циклов. Тут надо просто понять не сложный принцип операционной системы программы. Если до этого дойдёт, то мы её рассмотрим подробнее.
dima080383
Предупреждений: 1
Предупреждений: 1 
Сообщения: 43




06-08-2017 16:47

Eex, Про защиту от дурака я еще со школы знаю, когда писал проги на бейсике. Просто что бы говорить подобное (о чужом коде) нужно как минимум что то из себя представлять, а как максимум самому уметь писать проги.
Список форумов » Программное обеспечение » Микроконтроллеры » Программный анализ сигналов На страницу Пред.  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!