Добрый день!

Кто-нибудь может подсказать как прочитать передачу некоего интерфейса?
Известна его его скорость и структура.

Пытаюсь по первому биту запускать таймер, и с частотой раз в бит увожу контроллер в прерывание, где считываю значение порта.
Но огромное количество ошибок самого разного плана: сдвиг, чтение 1 вместо 0, чтение 0 вместо 1... Не знаю что делать.

Сигнал прямоугольный, так что дело к коде.

Есть программные алгоритмы приема?

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

А так ничего особо сложного вроде бы нету...

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

Формат посылки известен ? Если совершенно точно известно, как устроены посылки, известна скорость, на которой работает интерфейс, и проч., то выберите подходящий аппаратный интерфейс, входящий в состав вашего МК, и на нем все сделайте. Если такого итерфейса у вашего МК нет, то поищите МК с необходимым вам интерфейсом. Если такого МК нет, то придется имитировать этот интерфейс программно (если интерфейс медленный) или используя ПЛИС (если он быстрый). А если формат посылки точно не известен, то придется захватывать посылки, например, хорошим осциллографом или лог. анализатором, а затем изучать их вручную.

P.S. Из вашего сообщения ничего нельзя понять. Неужели так трудно изложить свои мысли яснее ?

Непомнящий Евгений
Да, спасибо, как вариант.

AHTOXA, это не влияет. и фо фронту пробовал, и в середине бита.

kovigor, если бы такой интерфейс бы был, я бы не пытался прочитать его столь извращенно.
И если бы был такой МК с таким интерфейсом, то я бы взял его.
Формат известен!

- я пришел к тому же выводу, что и вы, и сразу задал такой вопрос! =) Минуя очевидные вещи.

Тогда и говорить не о чем - делайте программно, если скорость позволяет. А алгоритм зависи от того, что это за интерфейс. Одно дело - UART, и совсем другое - I2C или SPI ...

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

Вот я и прошу подсказать существующие алгоритмы!! Т.к. мне нужно сделать это программно! И это не UART, не I2С, не SPI!!!
kovigor, вы не чувствуете, что ничем не помогли, а просто проконстатировали то, что я и так уже написал? Не можете помочь алгоритмом - не отвечайте, можете - я буду вам очень благодарен!

Непомнящий Евгений

выдайте на ножку момент выборки - не понял)
на другую - её результат - тоже не понял =)
И что такое реальных вход?

что есть что?=)

Ммм сложно представить, как прерывание по сравнению может считывать не в тот момент...=)
Или я что- то не понимаю..

В момент, когда читаете вход, инвертируйте некоторый выход МК.
Потом берете осциллограф и сравниваете реальный входной сигнал и моменты его считывания вашей программой.

Теперь понял.

А что мне это даст? ошибки от этого никуда не денутся и их причину я не пойму... Я увижу тоже самое, что и видел до этого! =)
Просто например бывает что вместо сообщения (порядка 60 бит выборки), мне приходят 60 "1"... (состояние на линии без передачи - "1")

Логика окончания приема сообщения - пауза в 50 бит перед следующим сообщением, состоящая из "1"

Ну как что даст - отсечете какие-то виды ошибок...

Потом еще что-нить попробуете, еще какие-то ошибки отсечете. И так до победного

Возможно у вас не в те моменты срабатывает прерывание - например другие прерывания слишком тяжелые. Или просто в программе ошибка. Да мало-ли что может быть...

Даже если битовая скорость известна, то никто не обещал что тактовая частота приёмника точно совпадает с тактовой частотой передатчика.
Со временем неизбежно накапливается ошибка.
Нужно подстраивать свою скорость приёма под скорость следования битов в принимаемом сигнале.
В зависимости от способа кодирования это можно делать по-разному, обычно это некая разновидность цифровой ФАПЧ, которая синхронизируется по фронтам сигнала.

Других прерываний нет =)
В программе кроме считывания передачи и отправки пакетов на компорт, ничего нет...

Ошибки конечно есть, но какого плана...



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

Сделайте без прерываний ради интереса.

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

Приведите здесь код, если его немного. Может кто-нить сразу увидит в чем дело

#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdio.h>
#include <util/delay.h>
#include "uart_i2c.h"

volatile int i = 0, pause = 0, uart = 0; // i - length of telegramm, pause - length of pause after telegramm
char s[64];

#define F_CPU 1843200L

// I/O ports init
void init_io_ports()
{ DDRA =(1<< DDA0)|(1<< DDA1)|(1<< DDA2)|(1<< DDA3)|(1<< DDA4)|(1<< DDA5)|(1<< DDA6)|(1<< DDA7);
DDRB =(1<< DDB0)|(1<< DDB1)|(1<< DDB2)|(1<< DDB3)|(1<< DDB4)|(1<< DDB5)|(1<< DDB6)|(1<< DDB7);
DDRC =(0<< DDC0)|(0<< DDC1)|(1<< DDC2)|(1<< DDC3)|(1<< DDC4)|(1<< DDC5)|(1<< DDC6)|(1<< DDC7);
DDRD =(1<< DDD0)|(1<< DDD1)|(1<< DDD2)|(1<< DDD3)|(1<< DDD4)|(1<< DDD5)|(1<< DDD6)|(1<< DDD7);

PORTA =(0<< PA0)|(0<< PA1)|(0<< PA2)|(0<< PA3)|(0<< PA4)|(0<< PA5)|(0<< PA6)|(0<< PA7);
PORTB =(0<< PB0)|(0<< PB1)|(0<< PB2)|(0<< PB3)|(0<< PB4)|(0<< PB5)|(0<< PB6)|(0<< PB7);
PORTC =(1<< PC0)|(1<< PC1)|(0<< PC2)|(0<< PC3)|(0<< PC4)|(0<< PC5)|(0<< PC6)|(0<< PC7);
PORTD =(0<< PD0)|(0<< PD1)|(0<< PD2)|(0<< PD3)|(0<< PD4)|(0<< PD5)|(0<< PD6)|(0<< PD7);
}


//************************************* Timer ****************************************************
// Timer0 8bit init, no prescaler, CTC mode
void init_timer()
{ TCCR0 = (0<< FOC0)|(0<< WGM00)|(0<< COM01)|(0<< COM00)|(1<< WGM01)|(0<< CS02)|(0<< CS01)|(1<< CS00);
TIMSK = (1<< OCIE0); // enable interrupts
sei(); // enable interrupts
SREG = (1<< 7); // enable interrupts
OCR0 = 192; // 1.8432Mhz of Xtal / 9600Hz = 192
}

//******************************** Interrupt Vector ************************************************
ISR(TIMER0_COMP_vect) // interrupt vector
{
if (i <= 64) // while telegramm is ON 64
{

if((PINC & (1 << PC0)) == 1)
{s[i] = '0';} // write "0" in s[i]
else
{s[i] = '1';} // write "1" in s[i]
i++;
}

else
{
if ((PINC & (1 << PC0)) == 0) //waiting the end of pause
{pause++;}
else
{pause = 0;}
}

}

//**************************************** MAIN ****************************************************
int main(void)
{
init_io_ports();
init_uart();

while (1)
{
i = 0;
pause = 0;
uart = 0;
if((PINC & (1 << PC0)) == 1) // waiting first "0" in Transmition on PC0

{
_delay_ms(0.010);
init_timer();
TCCR2 = 254;
while (pause <= 50) // pause after telegramm = 50 bit
{}
TCCR2 = 0; // stop timer TCNT2
putstr(s);
}

}


return 0;
}


без прерываний как?

Глупы ошибки это да... =)

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

Не понятго

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



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

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

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

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

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


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

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

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

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

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

Это лишнее


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

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

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

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

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

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






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

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


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

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

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

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

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

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

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

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

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

Конечно, конечно

Что тут не понятного, пауза после посылки.

Там слово телеграмма - а это накладывает определённые параметры на протокол передачи и и обычно это USART

Посмотрите Отрисовка сигнала.
Создавалась для отрисовки сигнала пультов, отрисует и цифровой сигнал, если подойдет по скорости,
Есть проект для протеуса, если интересует могу выложить.

На всякий случай вспомнил бы о картинках из описания к микросхеме типа AVR *. Которые в разделе про уарт. В смысле асинхронный. Которые переопубликовывать вручную уже от своего имени представляется нецелесообразным.
Или много букв про не понял что здесь пишут.

* особенно когда даже название раздела выбрано...

А почему бы и нет , положите вот сюда:
http://electronix.ru/forum/index.php?showtopic=10934
Вдруг и в правду кому-то понадобится , а по поводу этого топика , при таком "количестве "полезной" информации от топикстартера, мы можем только гадать

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

Есть простой способ - используете прерывание capture и складываете отсчеты таймера в буфер. Индекс буфера обнуляется при отсутствии фронтов в течение определенного времени.
Потом, пройдясь по буферу с начала до конца, можно спокойно проанализировать, что же там передавалось.

Marian, ILYAUL, спасибо.
Попробую сделать на прерываниях по фронту/спаду и записью длительности...

Dog Pawlowa, нет, это не интерфейс какой-нить микросхемы радио управления. =)

Наверное тем, что когда речь о "0" и "1" или о протоколе, они все прямоугольные... Это не информативно.
Надо знать как передается эти "0" и "1". Это может быть просто уровень, это может быть скважность, это может быть период(частота), это может быть что-то еще. Вариантов там воз и маленькая тележка.
И вообще, что Вы знаете о сигнале кроме того, что он прямоугольный?
ЗЫ. А вообще, самый разумный был совет - используйте запоминающий осциллограф или логический анализатор и внимательно рассмотрите сам сигнал. Пока половина советов тут сводилась к попытке сделать простейший лог. анализатор подручными средствами...

Вроде capture работает по фронту импульса.
Измерить длительность лог."0" так не получится.

Работает по обоим фронтам (какой укажешь и можно менять по ходу дела) и по результату компаратора. Измерить длительность нуля - очень просто. Ловишь падающий, меняешь в прерывании каптура на нарастающий и запоминаешь текущее. В следующем прерывании вычитаешь текущее от запомненного = измерили.
Плюс можно компарами ставить ограничения на допустимые пределы длительности нуля/импульса.

А надо ли ? По условию задания ему нужно только

К тому же

Насчёт длительности импульсов ничего не сказано. И даже если , что-то считать , то только не в прерывании. К тому же по каждому прерыванию , можно просто перезапускать счётчик, предворительно считав предыдущие данные, которые можно потом сохранить выйдя из прерывания. И считать полученные данные до следующего прерывания.
Но неизвестны ни скорость передачи ни структура сигнала- не озвучены. А так можно было прикинуть программу обработки. Но и проц не известен.

Такие вещи и на СИ! прям садомазо какоето
сорри за офтоп

В документации на любой микроконтроллер AVR (раз уж эта ветка в МК AVR), содержащий UART, очень детально расписан принцип детектирования последовательного сигнала.
ИМХО, к этому добавить нечего.