RC5+atmega 8

[miwutka]

пульт от тюнера компа. Откуда ж я знаю его протокол ))

[miwutka]

почитаю статью, спасибо

[Flopix]

omercury, частота таймера выставилась навскидку. Понятно что для измерения длительности импульса модулированного ИК сигнала 1000 итераций таймера на 1 замер это лишнее, но согласитесь все равно если использовать 1 байтный таймер получится слишком грубо.

Прерывание в котором много кода вызывается раз в иногда. Да конечно если устройство будет заниматься еще какими то RealTime задачами, то это прерывание может навредить будучи вызванным в критичный момент, но как я написал выше это сделано ради экономии озу. Массивы с задержками в моем примере введены только для отладки и не используются в алгоритме приема. Да и кода там думаю не больше чем на 100 ассемблерных команд, там больше сравнений чем полезной нагрузки, при частоте ядра даже 10 Мгц этот код будет выполнен за 10мкс.

[omercury]

Откуда ж я знаю его протокол ))

На такой скорости в качестве осциллографа достаточно звуковой карты компа и звукового редактора. ВременнАя шкала там обычно присутствует, всё можно глазами посмотреть. Только не напрямую с выхода TSOP, делитель нужен.

[Flopix]

В моем коде есть все для анализа протокола. Нужно просто вывести значения массивов после замера. Там этот кусок кода в main закомментирован. Но советую для удобной отладки подключить МК к ПК через USART. Ну или через звуковую как советуют выше.

[omercury]

если использовать 1 байтный таймер получится слишком грубо.

Точности более чем достаточно для ИК.

если устройство будет заниматься еще какими то RealTime задачами

Насколько понял, там вообще HID USB, а это процесс периодический.

это сделано ради экономии озу

Ну не знаю, у меня это в 32х регистрах всё крутится, без RAM вообще, включая двойную буферизацию, АЦП с усреднением, перекодировку в hex и вывод на индикатор...

UPD
Упс... Без USB, ессно - таня15...

[Flopix]

Точности вполне было бы достаточно для ИК если бы я еще этим таймером не измерял
длительность около 100мс. У меня ДУ с протоколом NEС, там есть задержка 0,5 мс и почти 100 мс.
Если растянуть 100 мс на байт (значение 255), да еще и с некоторым запасом, то на этот импульс будет приходиться 1 итерация таймера. А чуть поплывет фронт сигнала может быть и 0 итераций. Есть сигнал длительностью 1мс. На него будет приходится 2 итерации, а может быть и 1.




10 мкс задержки для USB там роли не сыграет. То что этот код можно оптимизировать я и не возражаю.

[miwutka]

Код заработал. принимает сигнал. Подскажите как правильно расшифровывать числа в pult_a1, pult_a2, pult_c1, pult_c2?? Я там числа вижу, но при нажатии на одну и туже кнопку там числа а1 и а2 повторяються часто. Из 5 раз 1-2 раза не то. А с1 и с2 както 50 на 50 повторяются. Может чтото еще не так. Записал все временные интервалы. в основном 110-140 и 390-415. Записал длительности первого полупериода и второго.

[miwutka]

взял другой пульт. У него все сигналы стабильные, кроме адреса. а1 и а2 редко сбиваются... Подскажите как их лучше декодировать?

[Flopix]

miwutka, при правильном подключении ИК сенсора и ошибок быть не должно. У меня сбоев при прямой видимости пульт-ИК сенсор не бывает вообще. Возможно необходимо несколько расширить диапазон допустимых задержек или наоборот сузить.
Так же возможен вариант неправильного подключения ИК сенсора. Приведите схему подключения. И заодно киньте весь текст того что у вас получилось.

а1 и а2 это как правило код производителя устройства.
pult_c1 содержит в себе код нажатой кнопки и должен быть равен инвертированному значению pult_c2, то есть должно выполнятся условие
(pult_c1 == ~pult_c2)

Конечно если у вас протокол NEC