Измерение длительности импульса

[fawkes]

Правда название темы не совсем соответствует реальности. В общем проблема в следующем:
Есть контроллер ATmega48, хотя тип контроллера не суть важен, на его лапу приходит некоторая посылка в последовательном коде, начинающаяся на 0xAA (10101010) По длительности единиц в этой посылке, теоретически, можно определить длительность одного бита в последующих данных. Вопрос в том, каким образом можно определить длительность этого импульса, чтобы правильно отсекать данные?
Пробовал написать на задержках (с помощью осциллографа посчитал длительность)это примитивно, но работает.
Для избавления от конкретных величин пробовал написать с автоматически определяемыми задержками (что то не очень получилось), пробовал написать на прерываниях по лапе, которая является входом.
На прерываниях делал так:
ПРиходит импульс, который вызывает прерывание, это прерывание запускает 16ти разрядный таймер в 1мкс, ожидаем окончания импульса, останавливаем таймер. Значения из регистров таймера переписываем в регистр А этого же таймера, потом переключаем таймер на прерывание по совпадению с А, выжидаем несколько мкс, чтобы сдвинуть синхронизацию, читаем лапу, и стартуем таймер.
Соответственно ранее отключили прерывание по лапе, разрешение прерываний тоже сделал.
Но в общем не работает.

Буду благодарен за разъяснения, или же за пример программы, читающей с лапы последовательный код по синхропосылке.

[picavr]

Есть контроллер ATmega48, хотя тип контроллера не суть важен, на его лапу приходит некоторая посылка в последовательном коде, начинающаяся на 0xAA (10101010) По длительности единиц в этой посылке, теоретически, можно определить длительность одного бита в последующих данных. Вопрос в том, каким образом можно определить длительность этого импульса, чтобы правильно отсекать данные?
Пробовал написать на задержках (с помощью осциллографа посчитал длительность)это примитивно, но работает.
Для избавления от конкретных величин пробовал написать с автоматически определяемыми задержками (что то не очень получилось), пробовал написать на прерываниях по лапе, которая является входом.
На прерываниях делал так:
ПРиходит импульс, который вызывает прерывание, это прерывание запускает 16ти разрядный таймер в 1мкс, ожидаем окончания импульса, останавливаем таймер. Значения из регистров таймера переписываем в регистр А этого же таймера, потом переключаем таймер на прерывание по совпадению с А, выжидаем несколько мкс, чтобы сдвинуть синхронизацию, читаем лапу, и стартуем таймер.
Соответственно ранее отключили прерывание по лапе, разрешение прерываний тоже сделал.
Но в общем не работает.

Буду благодарен за разъяснения, или же за пример программы, читающей с лапы последовательный код по синхропосылке.

Делал приём POCSAG.
Прерывание таймера с периодом в 4(8,16) раза меьншим чем время бита.
Анализ принимаемых уровней.
При повторе 4 нулевых записываеш бит=0
При повторе 4 единычных записываеш бит=1
дальше анализ битов.

Прерывания по фронтам или спадам могут ловить помехи.

[fawkes]

Спасибо, будем пробовать.

[fawkes]

Только вот прошу ответа правильным ли я способом считаю через прерывания?
Сегодня доделал, вроде даже читает, и вроде даже правильно.(судя по морганиям светодиода) У микрухи нет JTAG приходится отлаживаться в эмуляторе. Ну ладно, отвлекся.
Значит вопрос, если время делить на 4(8,16) сильно ли повлияет погрешность при делении, если время следования импульса нечетное?
И второй вопрос, велика ли ошибка при подобном способе чтения с порта при длинных(›32байт) посылках?
сейчас правда мне надо читать с порта 5 байт, но в дальнейшем возможно придется передавать длинные посылки.
(на второй вопрос можно не отвечать, проверю как только напишу нормальный алгоритм, просто хотел бы знать реально возможную длинну пакета)

Способ, которым у меня читается сейчас - прерывание по лапе запускает таймер 1000KHz, ждем окончания импульса, останавливаем таймер, пишем в регистр А таймера полученные значения, устанавливаем тип прерывания таймера по совпадению (кстати из показаний таймера приходится вычитать 3, чтобы быть более точным, смотрел в дебагере - пока происходят переходы на прерывания - теряется 3мкс),пауза для сдвига синхронизации(чтобы избавиться от попаданий в состояние перехода между уровнями), запускаем таймер (при запуске сразу происходит прерывание, хотя таймер в нуле, но мне пофиг, из-за этого предыдущий алгоритм не работал) и читаем с лапы уровень во время прерывания. Если получилось 0xAA то проходим дальше, если нет, иттить в начало.

[picavr]

И второй вопрос, велика ли ошибка при подобном способе чтения с порта при длинных(›32байт) посылках?
сейчас правда мне надо читать с порта 5 байт, но в дальнейшем возможно придется передавать длинные посылки.

POCSAG посылки это тон сигнал + заголовок + собщение закодированое, бывало и до килобайта, и более...

период таймера = 1/speed/4
1/1200/4=208 мксек
1/9600/4=26 мксек

[liza171]

А стандартные протоколы почему не устраивают? Типа 1-wire?

[liza171]

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

[ra9mig]

как только напишу нормальный алгоритм...

Мысль верная! Если не знаешь конечного результата, то как прогу то писать!

Как минимум должен быть стартовый байт...

Вероятно 0xAA оно и есть!?
Посмори AVR410: RC5 IR Remote Control Receiver, там тебе и таймауты, и стартовые биты, и пакеты. Переиграть можно "полюбому", главное идея!

[fawkes]

Да, про IrDa читал, правда там отсекается это дело по спаду/подъему. Пока не ясно как определить длительность импульса.
0xAA посылает сам передатчик. Его делал не я, не могу я изменить ни тайминги ни синхронизацию. Хоть тресни будет либо 1 раз 0xAA либо 2 раза 0xAA чтобы более точно определить время синхронизации.

[ra9mig]

а формат представления данных то какой?
что, собственно, есть 1, и что - 0.
я имею в виду как передается 1 и как передается 0?
формат пакета какой (скока данных и тд...)