Начать с правильного выбора элементной базы. Отказаться от дорогого и неудобного RX5000 и уж, разумеется, не стоит полагаться на прозрачную передачу через него асинхронной посылки с UART. Программный-то полудуплексный UART на небольшой скорости сделать не просто, а очень просто. На любой ноге (хотя предпочтительно для этого использовать аппаратные средства, типа ICP). Но не стоит так делать, честное слово. Все ж надо делать модем. А еще лучше, по нынешним временам - взять радиотракт с встроенным модемом. Например, Chipcon/TI CC1100 (или CC2500). Он заодно (и в первую очередь, исходя из озвученных требований) решит и проблему обратного канала. Можно взять и микроконтроллер с встроенным трансивером (из того же выводка от TI), но это получится дороже и может оказаться менее удобным. Atmega8 (или 48 или 88) и CC1100 - очень удобная связка. Но в освоении CC11xx несколько сложнее, да. Зато потом, после освоения - полная свобода (говорю как автор десятка изделий на этой связке, с общим тиражом уже под 100K, если не больше).

Уже пробовал. Результат то же, что и в первом посту. Тем более мне намного проще согласовать приёмник и COM так как я в своей сжеме использую FT232 преобразователь COM too USB. А в ней как всем известно входной и выходной сигналы TTL уровня. Перед тем как создать тему я провёл множество различных эксперементов, но всё безуспешно. Поэтому и прошу помощи в виде работающего куска кода программы.

Сорри в схеме которую Вы привели не было это показано. Вопрос с инвертором снимается.

Только, что ознакомился сописанием CC2500, приглянулась. Но сейчас я не готов приобрести эту микросхему, но обязательно её на неделе опробую. Если Вы разрабатывали конструкции которые используют часть моей задумки, прошу поделиться опытом. У Вас наверное был опыт работы с моими исходными данными и Вы наверное так же стакивались с моими проблеммами. Я уже отключал от МК приёмник и напрямую аппаратный UART МК подключал к терминалу. В терминале я писал что либо и при отправке в МК я незамедлительно получал то же, что и отправил обратно в терминал. Поэтому осмелюсь сделать вывод:
МК программно правильно настроен на работу с COM потром.
А вот аппаратно не уверен. Так как с приёмника я получаю какую то постоянную последовательность кода, но на совершенно не похожа на то, чего ожидалось получить. Поэтому либо проблемма со скоростью, что мало вероятно, либо, но это вообще абсурд, сигнал с приёмника нужно сначало инвертировать, и только потом отправлять на UART МК. И тогда сразу же следующий вопрос: А как я спогу принятый сигнал на МК преджварительно обработать? В какую переменную или регистр он попадает?

Кусок программы что в вашем первом посте рабочий, раз уж вы что то получаете в терминале.
просто нужно знать с какой скоростью передает данные rx5000 и настоить контроллер и компьтер на эту скорость.

По даташиту на rx5000 у него три режима со скоростями 2.4 kbps, 19.2 kbps и 115.2 kbps.

При том что на скорости 115.2 kbps контроллер с кварцем 8МГц скорее всего работать не будет т.к. большой процент ошибки

Решение с двумя UART конечно же интересное но когда своими глазами видишь рабочую схему в которой сигнал с приёмника приходят не на UART то уже уверен, что такое возможно.... Но как?

Сушествует множество решений програмного UARTа

Я бы классифицировал такую реализацию как "через одно место". 50% ресурса процессора будет занято эмуляцией второго UART'a. В итоге ни шага влево ни шага вправо. Вам оно действительно нужно?

Из описания проекта на ~50 столиков будет только один приемник, неужели для него нельзя взять МК на доллар дороже, и без буквы L, поставить кварц с частотой делящейся на 115200 без остатка. Тем самым всего за $1 избавить себя от проблем?

Вы правильно сказали по поводу фиксированных скоростей в RX5000 я из-за своей невнимательности не посмотрел в верзнюю строку колонки где указаны номиналы для скорости 19200. Сейчас пересмотрю свои настройки и результаты проверки выложу на форум.
Меня ввёл в заблуждение рабочий проект этого устройства в котором используется такая же элементная база как в моём проекте. Я её просто скопировал но программу решил написать свою. Так вот в рабочем проекте с собранным приёмником для скорости 19200 я настраивал терминал на скорость 9600 и при прошивке рабочего проекта у меня выводился в терминал правильный код. А будучи уверенный в том, что скорости я установил правильные, то есть 9600 я и не пытался обратить внимание на эту существенную деталь. Спасибо.

Поскольку я пишу на asm, то вряд ли мои наработки пригодятся. И, естественно, know how никто не раскрывает

Лениво вникать в предисторию, поэтому спрошу, как я понял - так что, Вы ожидаете, что принятый приемником RX5000 сигнал брелка можно передать в компьютер через UART непосредственно ? Просто забудьте это как страшный сон, и больше не вспоминайте. Начинать надо с принципов работы кодера в брелке, с формата его выходных данных. Просто в данном случае это не нужно и неинтересно, поскольку для решения поставленной задачи неприменимо (по причине абсолютной необходимости обратного канала. Которая, кстати, проистекает в первую очередь вовсе не из-за гипотетической возможности одномоментного нажатия кнопок на двух брелках)...

Это про обработку выхода RX5000 ? Превратить входной сигнал в последовательность "0" и "1", декодировать, превратить в осмысленную посылку для компьютера и передать по UART. А как декодировать - зависит от формата посылки, определяемой кодером. И уж, конечно, это не 115200,8,n,1, и штатный UART тут не в помощь (впрочем, могу представить себе вариант, когда можно было бы применить, в конце концов, UART успешно используют при общении, скажем, с 1-wire).

И так, из всего написанного делаю следующие выводы:
Для данного проекта необходимо использовать МК с двумя UART. Один на приём с выхода приёмника, другой на передачу в COM компьютера. Следовательно принятый сигнал с первого UATR я смогу редактировать непосредственно в МК и передавать его на второй UART.
Теперь о только что проведённых мной эксперементах с моим железом и настройкой скоростей.
Эксперемент 1.
Подключил выход приёмника на вход FT232. В терминале на разных скоростях принимал сигнал с кнопок. Ближе всего к положительному результату была скорость 2400.
Эксперемент 2.
Подключил выход приёмника на вход МК UART. Выход UART водключил на вход FT232. В терминале на на скорости 2400 были похожие сигналы на реальный сигнал с кнопки.
Завтра я разберу прошивку любой из кнопок и посмотрю с какими настройками передаётся сигнал. Хотя я в asm ничего не понимаю, но с дизасемблером и самоучителем попробую разобраться. Если кто знает настройки таких брелков или правельнее сказать, по какому протоколу они передают свои коды, буду признателен за предоставленную информацию.

Да нет у RX5000 никаких "режимов". Он примитивен как грабли. Все, что относится к скорости передачи - это выбор обвязки фильтра. Ничего больше. Предположение, что сигнал с OOK/ASK приемника можно подать на вход UART и получить осмысленный отклик от брелка автосигналки - у меня лично цензурных выражений для комментариев не находится, честное слово. Ну учите же матчасть или скопом гляньте... Поглядите, в конце концов, даташит на микрочиповские HCSxxx (даташиты на прародителей, продукцию Nanoteq, пожалуй, найти будет трудновато) - на выходе у них типично PWM. Вот его и надо декодировать. Да, можно, конечно, согласовав полярность и выбрав правильную скорость, заставить UART принимать посылку побитно (только скорость надо тогда выбрать порядка 1200 bps), но лучше фигней не страдать. Тем более что описанную задачу так вообще не решить...

Пардон, скорость должна быть где-то 9600...

Сообщение отредактировал rx3apf - Nov 6 2009, 16:28

Проанализировав datasheet HCSxxx стало понятно, что она шифрутет данные как я понял по какому то протоколу. И теперь становится понятно почему я постоянно получаю не то, что хотелось бы. Если я не ошибаюсь надо просто на уровне МК расшифровать полученный сигнал и тогда я ы терминале получу то, что мне нужно. Я проавильно думаю?

Ну наконец-то ! С этого (ознакомления с даташитом и просмотр выходного сигнала брелка скопом) и надо было начинать. Да, надо декодировать этот сигнал, превратив PWM в "0" и "1", разобраться с форматом посылок (а кодеров вообще-то много разных, с разными форматами), надо проверять контрольную сумму посылки (если она есть), найти и выделить серийный номер (иначе как различать кнопки ?) Но, главное, это не решает поставленной задачи - надежную передачу запроса с подтверждением можно реализовать только при наличии обратного канала. Так что с брелками стоит играть разве что для общего развития или под какую-то другую задачу...

Меня непосредственно интересует HCS301 KEELOQ Code так как есть возможность приобрести таких кнопок от гаражных ворот сотни по 10$ за штуку. А если учесть, что они используют один и тот же протокол шифрования, то осталось только разобраться в этом протоколе, написать свою программу дешифрования и результат налицо. Теперь понятно почему у меня в рабочем проекте и прошивке все брелки с этой HCS301 прекрасно отображают свой код в терминале. Где бы только найти протокол этого KEELOQ