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

Не понятго

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



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

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

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

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

ILYAUL, а не надо было расставлять точки, там все нормально было!=) Вместо сообщения, в котором "0" и "1" должно быть примерно пополам, мне приходит сообщение из одних только "1".
Меандр - прямоугольный сигнал со скважностью 2. Прямоугольный =НЕ пилообразный, НЕ синусоида и т.д.


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

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

Сообщение отредактировал micronano - Aug 2 2011, 11:59

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

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

Сообщение отредактировал micronano - Aug 2 2011, 12:17

Нарисуйте, как у вас выглядит лог. "1" и лог. "0", это для того чтобы представлять как они кодируются.
Если сигнал медленный, настройте внешнее прерывание на изменение уровня.
В прерывании запускаете таймер и сохраняете (в массив) длительность импульсов.
Если скорости хватает, походу и декодируете, если нет, декодированием занимаетесь уже приняв всю посылку.

Сообщение отредактировал Marian - Aug 2 2011, 17:24

Это лишнее


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

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

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

Сообщение отредактировал Marian - Aug 2 2011, 17:40

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

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

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






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

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


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

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

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

Сообщение отредактировал Marian - Aug 2 2011, 18:56

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

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

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

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

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

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

Сообщение отредактировал Marian - Aug 2 2011, 19:16