[kovigor 6]

kovigor, вы не чувствуете, что ничем не помогли, а просто проконстатировали то, что я и так уже написал? Не можете помочь алгоритмом - не отвечайте, можете - я буду вам очень благодарен!

 

Я чувствую, что вы не желаете описать вашу проблему человеческим языком. Что вам нужно ? Принимать биты ? Принимайте по прерыванию (если они следуют один за другим не очень быстро. Только учтите, что компилятор при вхождении в обработчик складывает регистры в стек, а это съедает львиную долю быстродействия. Или вам надо сложить биты в слова ? Тогда поможет обычный цифровой автомат. конкретный ответ дается на конкретный вопрос. Или вы думаете, что я могу читать мысли ?

[ILYAUL 0]

Не понятго

 

Сигнал прямоугольный,

меандр , что ли?

 

Просто например бывает ,что вместо сообщения (порядка 60 бит выборки), мне приходят 60 . "1"... (состояние на линии без передачи - "1")

 

Точки и запятые в фразе расставил я. Но , что такое вместо 60 приходят 60 , я не расшифровал

 

Зато понятно, что можно спокойно использовать прерывание INTX для принятия посылки

[_Pasha 0]

Пишут Вам пишут, что надо дождаться фронта, сдвинуть моменты чтения на полпериода и смело принимать, а Вы так и не хотите... Ну-ну :laughing:

 

[micronano 0]

kovigor, да, мне нужно принимать биты..

 

ILYAUL, а не надо было расставлять точки, там все нормально было!=) Вместо сообщения, в котором "0" и "1" должно быть примерно пополам, мне приходит сообщение из одних только "1".

Меандр - прямоугольный сигнал со скважностью 2. Прямоугольный =НЕ пилообразный, НЕ синусоида и т.д.

 

Зато понятно, что можно спокойно использовать прерывание INTX для принятия посылки

Это что за прерывание? Можно поподробнее, пожалуйста?

 

_Pasha, я на это уже ответил, что я так уже пробовал! ничего не меняется, абсолютно! К сожалению. Я экспериментировал с задержками как только можно! =(

Изменено 2 августа, 2011 пользователем micronano

[ILYAUL 0]

ILYAUL, а не надо было расставлять точки, там все нормально было!=) Вместо сообщения, в котором "0" и "1" должно быть примерно пополам, мне приходит сообщение из одних только "1".

Меандр - прямоугольный сигнал со скважностью 2. Прямоугольный =НЕ пилообразный, НЕ синусоида и т.д

Т.е слово импульсный Вам не знакомо, будем знать

[micronano 0]

ILYAUL, считайте что хотите.

Чем вам не понравилось слово прямоугольный, не понимаю.

Изменено 2 августа, 2011 пользователем micronano

[codenamehawk 0]

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

Если сигнал медленный, настройте внешнее прерывание на изменение уровня.

В прерывании запускаете таймер и сохраняете (в массив) длительность импульсов.

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

Изменено 2 августа, 2011 пользователем Marian

[ILYAUL 0]

В прерывании запускаете таймер и сохраняете (в массив) длительность импульсов.

Это лишнее

 

Чем вам не понравилось слово прямоугольный, не понимаю.

В электронике есть чёткое определение таких сигналов - импульсный сигнал

[codenamehawk 0]

Это лишнее

 

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

 

"Слово из песни не выкинешь"

Изменено 2 августа, 2011 пользователем Marian

[ILYAUL 0]

А вы что, знаете какая скорость и какая форма сигнала ?

На скорость - вобщем-то наплевать , лишь бы несовпадала с частотой процессора , а форма - прямоугольная. См. начало топика.

Но Вы на верном пути- осталось написать обработчик прерывания, но надо ещё чуть-чуть и поймёте почему это лишнее

В прерывании запускаете таймер и сохраняете (в массив) длительность импульсов.

[codenamehawk 0]

На скорость - вобщем-то наплевать , лишь бы несовпадала с частотой процессора , а форма - прямоугольная. См. начало топика.

Но Вы на верном пути- осталось написать обработчик прерывания, но надо ещё чуть-чуть и поймёте почему это лишнее

Как раз вся загвоздка в скорости.

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

 

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

 

 

 

 

а форма - прямоугольная.

 

Такое название мне тоже не нравиться.

Любой цифровой сигнал будет иметь импульсы прямоугольной формы.

 

Сигнал прямоугольной формы мне представляется(похоже и другим участникам форума) меандр определенной частоты с заполнением столько та процентов.

Все остальное импульсный сигнал.

 

каждое сообщение (порядка 60 бит), таймер запускаю заново по фронту первого бита, т.ч. врятли за 60 бит накапливается ошибка... Тем более что иногда (очень редко) приходит то, что надо!

Вам, в 12 посте подсказали, что необходима синхронизация.

 

Посмотрите http://ru.wikipedia.org/wiki/%D0%9C%D0%B5%...%BB%D0%BE%D0%B2

 

Обратите внимание на Манчестерское кодирование.

Изменено 2 августа, 2011 пользователем Marian

[ILYAUL 0]

Как раз вся загвоздка в скорости.

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

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

 

Но всё это при условии практически идеальной линии - или откуда там этот сигнал поступает

[codenamehawk 0]

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

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

[ILYAUL 0]

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

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

 

И ещё настораживает вот эта фраза из кода

pause after telegramm

[codenamehawk 0]

Скорость == количеству команд используемых в обработке прерывания

Это не соответствует действительности.

Скорее так :

"Скорость ==" частота проца делить на "количеству команд используемых в обработке прерывания "

Чем меньше команд в прерывании тем выше скорость.

Изменено 2 августа, 2011 пользователем Marian