Anbei die Beschreibung und der komplette Code (AVR-GCC) meiner RC5
Empfangsroutine.

Sie hat folgende Vorteile:

- Der Timer ist durchlaufend und dadurch noch für weitere
Zeitbasis-Anwendungen verfügbar.
- Es wird nur ein Interrupt verwendet, dadurch ist der Code einfacher
und kleiner
- Es erfolgt eine Bitsynchronisation und damit sind selbst Abweichungen
von 10% ohne Einfluß
- Es erfolgt eine Pulsprüfung und dadurch werden Störungen bzw. Codes
anderer Fernbedienungen weitgehend unterdrückt


Peter

Klingt gut, werde ich direkt bei mir einbauen ;)

Hallo, Peter!

Vielen Dank für die gute Anregung. Ist doch immer sehr fruchtbar, wenn
man sich über seine Codes mal austauscht. Ich habe immer darauf
vertraut, dass bei einer (zu) grossen Abweichung sicherlich irgendwann
einmal ein Biphasenfehler auftritt, der die weitere Verarbeitung
abbricht. Aber mit Bitsynchronisation ist das Ganze natürlich noch viel
eleganter gelöst. Respekt!

Viele Grüße
Kai

Hallo Peter

Genau das habe ich gesucht. Läuft tadellos und war selbst für mich
problemlos zu integrieren obwohl ich erst seit ein paar Tagen in C
programmiere. VIELEN DANK !

Gruß

Eddi

Hi,
eine Anmerkung zu dem Code:
Man sollte die rc5_data Variable besser als volatile deklarieren, sonst
kann es vorkommen, dass der gcc einem die Variable nicht wie gewuenscht
weiterreicht.

Tobias

Habe soeben festgestellt, der Eingangspin muß immer Pin 7 eines Ports
sein, damit der Compiler funktionierenden Code erzeugt.

Woran das liegt, weiß ich nicht.

Mein AVR-GCC.EXE ist von 21.09.2003.


Peter

Hi!

Ich habe den Source gerade erfolgreich (nochmal danke dafür) auf einem
AVR 2323 eingesetzt. Der Eingang is Pin0. Geht problemlos (zum Glück,
das Ding hat ja gar keinen Pin 7, auf irgend einem Port :) )

 gcc version 3.3.1 aus WinAVR

MfG

Sebastian

Vergeßt mein letztes Posting, das ist totaler Quatsch.

Der Code ist einwandfrei und funktioniert mit jedem Bit !


Ich hab das Problem nur mit einer älteren Version, muß also bloß noch
rauskriegen, worin sich diese unterscheiden.

So ist das mit den großen GB-Festplatten.
Man hat viele Versionen eines Programms rumliegen und weiß dann nicht
mehr, welches nun die richtige ist.
Hab mir also meinen eigenen Code wieder vom Web runter laden müssen
:-)

Danke, Sebastian

Peter

Hallo,

ich habe gerade mal versucht Peters Code zu verstehen. Hierbei ist mir
aufgefallen, dass zweimal der folgende Vergleich gemacht wurde:
(temp & 0x4000)
Warum wird das 15. Bit des empfangenen Codes überprüft, wo dieses doch
eigentlich immer Null sein sollte. Der RC5-Code ist doch eigentlich auf
14 Bit beschränkt.
Vielleicht kann mir ja mal wer auf die Sprünge helfen ;-)

Gruss, Alex

Das dient nur dazu, um nicht-RC5-Codes zu unterdrücken.

Werden also zuviel Flankenwechsel erkannt, wird kein weiteres Bit mehr
eingelesen und am Ende das Paket verworfen.


Peter

Achso, vielen Dank für den Hinweis.

Alex

Hi,

ich hab mir heute dein Code angeschaut. Ich hab ein kleines Problem
deine folgende Aussage zuverstehen.

"Der Timer ist durchlaufend und dadurch noch für weitere
Zeitbasis-Anwendungen verfügbar. "

Ich habe dein Code wie folgt verstanden.

Der erste Timeroverflow0 kommt bei 16,xx ms ((Xtal 4Mhz / Presc. 256)*
timer0 (256)). Jetzt wird nach dem ersten Timeroverflow das
Timerregister auf 254 gestellt (TCNT0 = -2), somit kommt jetzt alle
128µs der Overflow von Timer0.

Wie soll man jetzt andere Zeitbasen erreichen? Über eine Variable die
in der ISR erhoeht wird? oder habe ich einfach nur ein Detail
übersehen?

Ich hoffe du kannst mir da ein bischen auf die Spruenge helfen.

Mfg

Dirk

Genau.

Der Interrupt kommt immer gleich, egal ob was empfangen wird oder
nicht.

Damit kann man darin bequem weitere Softwaretimer (Register
runterzählen) mit einfügen. Diese Softwaretimer können natürlich nur
ganzzahlige Vielache der Interruptzeit sein.


Andere RC5 Routinen stoppen den Timer aber, d.h. dort kann man den
Timer nicht noch anderweitig benutzen.


Peter

Hi,

ok dann hab ich es richtig erkannt. Ich bedanke mich für deine kurze
Bestätigung.

Mfg
Dirk

Hallo!

Danke für Deine Dekodierroutine, Peter!

Ich konstruiere gerade einen Drehstrom-Umrichter für meinen
Selbstbau-Stromgenerator, der per AVR angesteuert werden soll.
Fernbedienung soll sein, damit das Gerät vom Haus aus in der offenen
Garage gestartet werden kann.

In den nächsten Tagen weiß ich, ob die Software läuft. (ich sehe schon
die ersten Transistoren bei den kommenden Testläufen abrauchen ;-))

Deine Interruptroutine habe ich nur leicht angepasst übernommen; ich
hoffe, das ist OK. (Es stand nichts zur Softwarelizenz dabei)


Warum deklarierst Du rc5_bit, rc5_time und rc5_tmp nicht einfach in der
Interruptroutine als Speicherklasse static? (Ist vielleicht eine
Geschmacksfrage; ich finde das übersichtlicher)


Gruß,
Ulf

Hallo Peter, eine Frage:
TCNT0 auf -2 setzen, ist das ein kleiner Spaß, oder was verbirgt sich
dahinter? Mein IAR-Compiler läßt diese Anweisung gar nict zu. Bitte um
Erklärung.
Michael

Hi,

ich hab doch da schon eine Erklaerung und da es mit GCC programmiert
ist kennt maybe dein IAR das register unter der Bezeichnung nicht.

Mfg

Dirk

Doch doch, das Register kennt er schon. Eine Zuweisung mit dem Wert 254
funktioniert ja auch. Aber das Register ist per Deklaration ja
unsigned. Deshalb funktioniert es nicht. Ich wollte nur wissen, welcher
tiefere Sinn sich dahinter verbirgt. Mehr nicht.
Michael

Der Timer 0 kann doch nur aufwärts zählen.

Um nun die Schritte bis zum nächsten Interrupt anzugeben, stellt man
sie üblicher Weise als negative Zahl dar.
Ist ja viel besser lesbar.

Was paßt dem IAR daran nicht ?


Peter

Peinlich, peinlich, IAR macht das, ich habe mich vertippt.
Entschuldigung in die Runde. Und worauf ich hinaus wollte hat Peter mit
der Lesbarkeit erklärt. Vielen Dank.
Michael

Hallo,

die Flankenerkennung ist mir etwas unklar...

(rc5_bit ^ xRC5_IN) macht das EXOR vom kompletten Register (8 Bit)
mit dem Inhalt vom Zustand davor, das ist mir klar, aber wie "fischt"
die Routine jetzt raus ob sich auch der IR Eingangspin bewegt hat ?

Wenn ichs soweit verstanden habe ist xRC5_IN der komplette Port "D"
mit 8 Bit und xRC5 ist das Eingangsbit für den IR Sensor oder ?
Das & 1<<xRC5 macht mir Kopfzerbrechen ...

Grüße

D.E.

#-) Brett vorm Kopf.

xRC5 ist natürlich nicht der Pin sondern nur die Port-Pinummer,
so macht es einen Sinn...

Grüße

D.E.

Hallo guten Abend zusammen,

sorry für die blöde Frage aber wo bekomme
ich denn die passende IR Empfängerdiode her ??

M.f.G
Walter

Hallo Walter,

probier mal www.reichelt.de
Da hatte ich mir ne TSOP1738 bestellt.

Gruss
Dominik

Erstmal respekt für die Applikation...
da ich absoluter Newbie beim Controller-Programmieren bin, habe ich
mich für Assembler entschieden.
Hat schonmal jemand diese Applikation in Assembler umgesetzt ?
...by the way...
mit welcher Trägerfrequenz arbeiten die standard rc5-Fernbedienungen
eigentlich ?

Die Trägerfrequenz beträgt 36kHz.

Danke Thorsten,
jetzt muss ich "nur" noch versuchen als "dummer" VB-Programmierer
den C-Code in Assembler zu konvertieren.
...das wird witzig...
vielleicht hat ja doch schon jemand sowas fertig grins

Hi,

da hilft www.google.de. Bei Atmel gibt es ein Appnote mit Source fuer
ASM.

Mfg
Dirk

Hallo Dirk...
ich google bereits seit mehreren Tagen.
Ok, irgendwann werde ich wohl mal fündig.
War ja auch nur ne Frage, man muss das Rad ja nicht zweimal erfinden.
Werde bei Atmel mal weitersuchen.

Ach ja, Du solltest Deine Maustaste mal entprellen !

Hallo!

Nach nächtelangem Debuggen krieg ich meinen RC5 Empfänger einfach nicht
zum laufen, auch glaub ich tret' das Teil gleich in die Tonne,
grummel...

Beim debuggen fällt auf dass ständig die rc5_time kleiner MIN_BIT_TIME
ist (im Souce steht da als Kommentar "to short"). Was heißt das ?
Prellen auf der Leitung ? Fernbedienung funktioniert am Fernseher, das
Signal sieht am Oszi sauber aus.

@Peter
Warum hast du eigentlich nicht als Timer-Vorteiler 256 genommen und
setzt dann immer TCNT auf -2, so dass ein fclk / 512 erreicht wird ?
Hab mal versucht mit Timervorteiler auf 1 und ohne TCNT zu setzen,
dadurch wird dann das SIGNAL mit fclk / 256 angesprungen, also doppelt
so schnell (hab auch die defines entsprechend geändert), hat aber auch
alles nix gebracht.

Hat jemand ne Idee, bevor ich in die Gummizelle muss ?!?!

Stefan

"Hat jemand ne Idee, bevor ich in die Gummizelle muss ?!?!"


Was hast Du denn für einen Quarz ?
Ist etwa noch der interne RC aktiv ?
Kannst Du irgendwas über die UART ausgeben ?

Der häufigste Fehler ist, daß die FB keinen RC5-Code sendet.


Peter

Hi Peter,

danke für die rasche Antwort.
System Clock war zunächst 4.0 MHz intern, hab dann, weil ich dachte die
interne Clock ist zu langsam/ungenau, einen externen 7,3728 MHz
drangehängt. Uart steht zur Verfügung und wird fleißig zum debuggen
benutzt (somit stimmt auch die Clock).

"Der häufigste Fehler ist, daß die FB keinen RC5-Code sendet."
ACH, da schau an, dachte dass sogut wie alle Fernbedienungen RC5 sind
?!?! Es handelt sich um so eine 6in1 Fernbedienung, die mit meinem
Fernseher, CD Player etc funzt. Sollte das ganze etwa kein RC5 Signal
sein !? Welche Fernbedienungen senden denn RC5 aus ?

...Das würde auch erklären warum ich mir immer noch nicht den
zusammenhang zwischen meinem OSZI Schirmbild und einem richtigen
RC5-Signal (z.B. Spettel.de) erklären kann...

Stefan

P.S. Was gibts denn sonst noch für Fernbedienungsprotokolle ?! Würde
gern diese Fernbedienung hernehmen....

Hi !

RC5 stammt ursprünglich von Philips. Deine FB ist doch vermutlich mit
Codes auf versch. Geräte einsellbar.

Meine Empfehlung ist erstmal die Codes für die Philips Geräte
ausprobieren, da ist eigentlich immer etwas in RC5 dabei, wenn auch
nicht alle Philips Geräte RC5 verwenden #-)

Mit dem Oszilloskop ist ja schnell gemessen ob es ein RC5 oder etwas
anderes ist....

Grüße

D.E.

Tach D.E.,

ja, hab grad im Web noch n bissl recherchiert, den Code den ich da
unglücklicherweiße erwischt habe scheint der "sircs" code von Sony zu
sein. Grrrr, da kann ich mich lange dumm und dusselig debuggen!
Mal sehen, entweder ich implementier mir eben ne sircs routine oder ich
such in der fernbedienung nach nem rc5-code...

Danke soweit,

Stefan

Hallo,

ich habe mal verschiedene Universalfernbedienungen verglichen und dabei
festgestellt, dass die vielfach gleiche Codenummern haben. Vielleicht
könnten wir die mal vergleichen, dann brauchst du nicht zu suchen.

Der RC5-Empfänger von Peter hat im übrigen bei mir direkt (nach
Anpassung der defines) funktioniert. Danke noch mal an Peter.

Gruss
Andreas

Diese Seiten enthalten viele Informationen, auch zu versch.
Protokollen.

http://www.ustr.net/infrared/index.shtml

http://www.xs4all.nl/~sbp/knowledge/ir/ir.htm


Grüße

D.E.

Funktioniert der Code mit dem ATMega8 ohne Änderungen? Ginge er auch mit
Attinys? ich kann leider kein C!

Ich weis, ich hab hier ne ziemlich doofe Frage gestellt, aber wäre
jemand trotzdem so nett zu antworten?

Ne, ist keine doofe Frage,

ohne das mal getestet zu haben würde ich sagen dass der Code auf nem
Mega8 mit Sicherheit läuft, und auf nem ATTiny auch, alles was man
braucht ist 1 Input Pin (der sollte wohl bei allen atmels vorhanden
sein) und einen Timer, der zyklisch den Zustand des Pins abfragt.
Wenn du aber kein C kannst wird das mit dem C-Code nicht so ganz
einfach...

Stefan

Hallo,

prinzipiell sollte der Code auch auf einem Tiny laufen, sofern der
internen RAM hat. Dazu müssten die UART Routinen aber entfernt werden.
Für die Bausteine ohne RAM bin ich nicht sicher, ob man da C verwenden
kann. Da könnte man aber den RC5 empfänger in Assembler schreiben. Ich
glaube da gab es mal ein App Note von Atmel.

Gruss
Andreas

Jetzt hätte ich nochmal ne blöde Frage.

Könnte mir das jemand assemblieren (assembler) unhd als code für den
AT90S2313 hier posten? Damit müsste es doch auch laufen!

Hm,
ich verstehe nicht ganz, was Du genau vor hast.
Willst Du den C-Code von Peter als HEX-File haben, oder den
Assembler-Output des Compilers?
Wenn Du den HEX-Code benötigst, um eine Schaltung zu testen, müssten Du
noch die verwendete Taktfrequenz mitteilen (und eventuell die
Baudrate?).

Bei Atmel gibt es die Application Note 410 mit Beschreibung und
Assemblerquellen.
(http://www.atmel.com/dyn/products/app_notes.asp?fa...)

Gruss
A.Hesse

Hi!

Erst einmal vielen Dank. Ich hätte gerne beides für den AT90S2313 mit
einem 2,4576 Mhz Oszillator! Ich finde es wirklich super von euch, dass
ihr euch extra für mich diese Mühe macht.

Felix

???

Ja was soll den der Code machen ?! Nutz ja eher nix wenn einfach die
RC5 Befehle dekodiert werden, irgendwas muß ja damit passieren ?!
Ansonsten gehts genausogut wenn man eine Fernbedienung auf eine
Schachtel Streichhölzer richtet, die macht das gleiche wie ein
AT90S2313 der RC5 Daten einfach nur dekodiert :-)

Hi!
Ich dachte, der Atmel würde die Befehle über das UART ausgeben!
Felix

Hi,

ja, der Atmel sendet dann über den Uart.
Hex File ist im Anhang. Der RC5-Pin ist PD2.
Baudrate ist 9600.

Gruss
Andreas

Ja, wenn man dem Atmel sagt er solls über die UART ausgeben macht er das
auch ;-)
Aber die RC5 Routine alleine macht wohl nicht so viel Sinn...

Viel Spaß beim RC5 dekodieren

Stefan

Danke, werds übermorgen mal ausprobieren!

hallo, dieses programm ist gut gelungen und funktioniert. klasse,
mfg pebisoft

hallo, bei mir funktioniert es tadellos.
mich würde noch einmal eine senderoutine interessieren. danke
mfg pebisoft

hallo, was muss ich ändern damit das ganze mit 16 mhz fungtionier? ich
komm erlich gesagt mit den timern nicht ganz zurecht. was mir
aufgefallen ist, dass im code "TCCR0 = 1<<CS02; //divide by 256"
steht. im datenblatt sthet aber das das es dann ein 128er teiler ist.
was ist jetzt richtig? hab leioder noch keien empfänger zum
ausprobieren, wolte aber zumindest die SW schon mal verstehen.

mfg
Max

Hallo,
dein Code funktioniert wunderbar, danke :-). Ich musste allerdings in
der MAIN.H bei den #include Einträgen entsprechend ein avr/ vor den
Dateinamen einfügen damit es funktioniert. Müssen die Variablen die in
der Interrupt Routine verwendet werden nich eigentlich alle als
volatile definiert werden? Als letztes wüsste ich wie weit ich den Code
verwenden darf, da ich gerne den Quellcode für die Steuerung eines
Roboters, der eine leicht veränderte Form deines Codes verwendet, auf
meine Homepage stellen würde.

@all
Wenn in der MAIN.C die Zuweisung für UBRRH und UCSRC auskommentiert
werden, läuft das ganze auch auf den älteren AT90S. Ich habs mit einem
AT90S4433 und einem AT90S2313 getestet.

@max.p
Also im Datenblatt des ATMEGA16 bedeutet TCCR0 = 1<<CS02 einen Teiler
durch 256, ein Teiler 128 ist überhauptnicht vorhanden.

Alternativ kannst Du alles, was unter \avr steht, eine Etage nach oben
kopieren, dann sparst Du Dir die extra Schreibarbiet.

Verwenden kannst Du alles uneingeschränkt, ein Urhebervermerk wäre
nicht schlecht.

Peter

hallo malte
ok, du hast recht, hab jetzt in ein paar anderen datenblätern
nachgesehen. Ich hab nur in dem vom mega128 geschaut. Danke

mfg
Max

Kann mir einer sagen was in denn Zeilen gemacht wird?

#define RC5TIME   1.778e-3    // 1.778msec
#define PULSE_MIN  (uchar)(F_CPU / 512  RC5TIME  0.4 + 0.5)
#define PULSE_1_2  (uchar)(F_CPU / 512  RC5TIME  0.8 + 0.5)
#define PULSE_MAX  (uchar)(F_CPU / 512  RC5TIME  1.2 + 0.5)

und was dei 1.778e-3  das e-3 machen sowie
bei
#ifndef F_CPU
#define F_CPU 10000000e6     /* Quarz mit 10.0000 Mhz  */
#endif

das e6 ??

vielen dank

Das ist expotential schreibweise. 1.778e-3 wird einfach zu 0.001778. So
kann man die Zahlen besser lesen und vertippt sich auch nicht so
schnell.
Wie Peter aber auf F_CPU=10000000e6 kommt weis ich auch nicht.
Ist F_CPU vll. schon im Makefile definiert worden und der Fehler ist
sonst niemandem aufgefallen?

Gruß Tobias

Hm,
wo hast du den das
#ifndef F_CPU
#define F_CPU 10000000e6     /* Quarz mit 10.0000 Mhz  */
#endif

gefunden? Im zip finde ich nichts was so aussieht

Das ist nicht von Peter. Das habe ich so definiert.
Wollte 10 Mhz angeben. Ist das Falsch? wie gebe ich 10 Mhz ein?

#ifndef F_CPU
#define F_CPU 10000000e6     /* Quarz mit 10.0000 Mhz  */
#endif

Nach deiner erklärung müsste es nach der Schreibweise
0.000001
sein.

10000000e6 = 1e13 = 10000000000000Hz, das ist glaube ich etwas viel :)

10MHz wären 10e6 = 1e7

Hallo zusammen,

ich hab ein echtes Problem, ich versuche hier seit einiger Zeit den
Code zum Laufen zu bekommen. Leider klappt es einfach nicht.
Ich bekomme andauernd die unten genannte Fehlermeldung.
Das Makefile ist eigentlich aus einem alten Projekt übernommen und
müste theoretisch funktionieren.
Den Code von Peter habe ich auch übernommen (danke dafür), ich habe nur
die Datei main.h in fernbedienung.h umbenannt.
Mir ist aufgefallen, dass wenn ich Make clean mache die Datei rc5.c
gelöscht wird... das kann doch nicht gut sein, oder?

Viele Grüße,

Daniel

ps: meine Dateien hängen an!

avr-gcc (GCC) 3.4.3
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.


Linking: fernbedienung.elf
avr-gcc -mmcu=attiny26 -I. -gdwarf-2 -DF_CPU=8000000UL  -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=fernbedienung.o  -std=gnu99 -MD -MP -MF
.dep/fernbedienung.elf.d fernbedienung.o RC5/RC5.C
C:/Programme/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/include/avr/signal.h
--output fernbedienung.elf -Wl,-Map=fernbedienung.map,--cref    -lm
cc1plus.exe: warning: command line option "-Wstrict-prototypes" is
valid for C/ObjC but not for C++
cc1plus.exe: warning: command line option "-std=gnu99" is valid for
C/ObjC but not for C++
RC5/RC5.C: In function `void __vector_6()':
RC5/RC5.C:27: warning: converting of negative value `-0x000000002' to
`unsigned char'
C:\Programme\WinAVR\bin\..\lib\gcc\avr\3.4.3\..\..\..\..\avr\bin\ld.exe:fernbedienung.o:
file format not recognized; treating as linker script
C:\Programme\WinAVR\bin\..\lib\gcc\avr\3.4.3\..\..\..\..\avr\bin\ld.exe:fernbedienung.o:1:
parse error
make.exe: *** [fernbedienung.elf] Error 1

> Process Exit Code: 2

@Daniel:
Also ich bekomme bei deinem Quelltext den gleichen Fehler, wenn ich im
Quelltext:
1: include "../dd1draht.h" auskommentiere
2: die Groß-kleinschribung der Dateinamen korrigiere
3: Die Pfandangaben zu RC5.C anpasse
4: im Makefile DEBUG = dwarf-2 auskommentiere
Ich wüsste jetzt auch nicht weiter. Aber du scheinst das irgendwie als
c++ und nicht als c zu compilieren, vielleicht liegt es ja daran.

Hallo,

danke für die Hilfe, ich habe es ausprobiert... und aufgegeben, wenn
ich den code direkt in die hauptdatei stecke funktioniert es prima!

Andere Frage: Wie könnte man denn eigentlich auch "nicht RC5" Signale
empfangen? Gibt es dazu Projekte?

Viele Grüße,

Daniel

hallo, diese rc5-routine ist fehlerfrei. ein klasse programm.
weiter so peter d.
mfg pebisoft

habe die Routine jetzt auch mal ausprobiert es hat auf Anhieb
funktioniert, aber mit folgendem Problem:
ok: Gerät 0, Ziffern 0..9 z.B. werden korrekt auf Terminal ausgegeben
nicht ok: Gerät 0, andere Funktionen wie z.B Codes 24 und andere
'höhere'. Auch Gerät 5 (VCR) das gleiche: Ziffern ok, aber z.B. Stop
oder Play machen eine Ausgabe ('0 5 53') und dann passiert nix mehr,
µC braucht Reset.
Die FB ist original Philips (RT202) und auch mit einer anderen von
einem Philips CD Player zeigt das gleiche Verhalten.
Das Projekt läuft auf einem STK500 mit ATMega32 Proz, Takt ist 3,686
Mhz, serielle auf 9600 bit/s eingestellt, Zeichen und Startmeldung
kommen auch korrekt auf dem Terminal an. Empfangsdiode ist eine
SFH5110-36. Die RC5 Routine ist die aus dem ersten Posting hier.
Hat jemand eine Idee was da faul sein kann ?

habe den Fehler gefunden, meine IR-Diode war an PortB angeschlossen. In
der Beispielroutine in main.c wird aber PortB modifiziert:
    if( i ){
      DDRB = i;        // LED output
und damit wird meine IR-Diode totgeschaltet wenn das richtige Bit
getroffen wird...
Damit wäre aber doch noch ein kleiner Fehler in dem Beispiel: Wenn die
Led's gesetzt werden sollen dann müsste es doch
   PORTx=i;    // oder PORTx=~i; wenn LED's invertiert sind
heissen. Und in der initialisierung muss noch
   DDRx=0xff;
   PORTx=0xff;   // wenn LED's invertiert sind
gesetzt werden.

Damit wäre die erste Hälte meines Projektes fertig. Jetzt möchte ich IR
Code noch umsetzen und auf einem Funkmodul (FS20 von ELV) ausgeben.
Damit habe ich dann ein IR->Funk Gateway und ich kann mit meiner
Universal FB auch Licht und andere Geräte schalten (die eben per FS20
Funksystem angebunden sind).

Hallo,

ich bekomme leider den Code auf einem Mega8 mit 4MHz Takt (external
Crystal) nicht zum laufen.

Ich habe inzwischen verschiedene Fernbedienungen (2x Sony, 1x Pioneer,
1xNoname) getestet, ohne auch nur das geringste zu empfangen.

In der ISR geht er nie in die Abfrage die mit "change detect"
kommentiert ist. Woran könnte das liegen?

Danke und schönes WE!
Ciao Danilo

Nun, nach ner Nacht schlaf hat die kosmische Strahlung dazu geführt das
es schonmal besser funktioniert. Das heißt er empfängt, verwirft aber
das empfange in der Zeile mit dem Kommentar "only if 14 bits
received". Deutet dies auf ein Timing Problem hin, oder liegts daran
das alle FB hier nicht RC5 senden?

Ciao

PS: habe inzwischen noch 2 FB getestet, gleiches Ergebnis. Ich glaube
also eher an ein Timing Problem.

"oder liegts daran das alle FB hier nicht RC5 senden?"

Bei Sony und Pioneer bin ich mir zu 99.9% sicher, daß die einen eigenen
Code nehmen.

Versuchs dochmal mit einer Kombi-FB und stelle die auf Philips bzw.
probiere alle Codes durch.


Peter

@Peter, danke für die Antwort.

Hab  mal der Pioneer nen Phillips Code beigebracht, leider ohne Erfolg.
Vielleicht find ich eines Tages raus warum es nicht ging, bis dahin muss
ich halt zum uC laufen LOL

Ciao und Danke!

Analysiere doch den gesendeten Code einfach. Wenn du kein Speicherscope
hast, gibs auf den Soundkarteneingang. Habe ich auch gemacht, hat recht
gut funktioniert.

Ich bekomme das auch nicht zum laufen. :(

Ich habe einen AT90S4433 und benutze PD3 als Eingangspin (weil der
Empfänger da physisch prima dranpaßt) und als Empfänger habe ich einen
TSOP1736. Der TSOP1736 bekommt eine VCC von 3 V.

Ich habe eine FB, die eigenlich Philips-RC5 senden sollte (von einem
Grundig-Sat-Receiver).  Die kann man auch Fernseher von Philips
umstellen.

Nun weiss ich nicht, wo das Problem liegt: Ist die Fernbedienung doch
nicht RC5 oder der TSOP defekt oder der Pin nicht richtig initialisiert
...?

Über die serielle Schnittstelle kann ich zwar was empfangen. Ich habe
auch schon ein paar puts() in die Interrupt-Routine eingefügt. Aber ich
habe nicht das Gefühl, dass sich da irgendwas ändert, wenn ich auf der
FB irgendwelche Tasten betätige.

@Jens:
Blöde Frage, aber wie sollte man den Eingang der Soundkarte benutzen?
Wird dort der Out vom TSOP angeschlossen? Wenn ja, müßte man ja
ausschliessen können, das der dann defekt ist, wenn was ankommt. Und
was sagt mir dann das empfangene Signal? Woran erkennt man, dass das
RC5 ist?

Frank

Du legst das Out vom TSOP auf den Eingang der Soundkarte (Masse nicht
vergessen) und zeichnest z. B. mittels Cooledit das empfangene Signal
auf. Das Programm zeigt dir dieses dann als Wave-File auf dem
Bildschirm an. Da du die Abtastrate und somit die Zeit zwischen zwei
Samples kennst, kannst du mit den Cursorfunktionen des Programms
messen, wie lange die einzelnen Impulse bzw. Impulsfolgen dauern.
Daraus wiederrum kannst du ableiten, ob es sich um RC5 handelt oder
nicht.

Die Soundkarte in Verbindung mit Cooledit funktioniert quasi als
Digitalspeicheroszilloskop.

Jens

@Jens

War ein guter Tip.

Wenn ich den TSOP in der Schaltung lasse, bekommt er eine VCC von 3 V.
Da kann ich mit der Soundkarte auch nichts messen (Kein Wunder, dass
der Controller keine Reaktion zeigt.). Wenn ich ihn aber mit 6 V
versorge, kommt ein Signal an. Komisch, im Datenblatt stand doch (wenn
ich mich recht entsinne) VCC 0,x .. 6,0 V. Da liegen die 3 V doch
mitten drin!? Oder arbeitet der TSOP nur mit TTL-Pegeln?

> VCC 0,x .. 6,0 V.

Das sind die "absolut maximum ratings", die nur aussagen, dass der
Baustein innerhalb dieses Bereichs nicht sofort kaputt geht.

Es gibt allerdings auch 3V-Varianten des TSOPs, nur leider sind die
schwer erhältlich.

Ich benutze zwar den TSOP18xx aber im Datenblatt Seite 2 "Application
Circuit" steht "tolerated supply voltage range : 4.5V<VS<5.5V". In
der Datentabelle angegeben ist "Supply Voltage -0.3 to 6.0V".

Von daher sollten 3V wohl nicht reichen, was leider auch in meiner
Schaltung gleich mal zum Problem wird. :)

"Supply Voltage -0.3 to 6.0V".

Und was heißt das? Ich dachte erst, in diesem Bereich arbeitet das
Ding. Aber das kann ja nicht sein... Ist das wirklich nur die Angabe,
dass das Teil da nicht kaputt geht? Wieso heißt das dann "Supply
Voltage"?

Naja, wie willst du es sonst nennen? Die Supply Voltage darf halt nicht
außerhalb dieses Bereichs liegen, sonst machts (vielleicht) peng!

hallo,
kann ich auch einen TSOP 1738 (38kHz) benutzen ?
 Chris

>>Kann es sein, dass es richtig ist, dass das Togglebit getogglet wird
>>wenn 2 Tasten unmittelbar hintereinenader gedrückt werden

>>ABEr das Togglebit bleibt gleich, wenn man die Taste gedrückt hält?

Ja, das ist ja genau der Sinn des Toggle-Bit. Zu Erkennen, ob eine
Taste dauerhaft gedrückt wird oder mehrmals hintereinander.

Pete

hallo, gute sache(routine).

habe diese umgesetzt in fastavr-basic 1:1.
läuft klasse. hatte nicht gesacht, das dieses fatsavr-basic es so gut
kann. progge damit schon 5 monate.

mfg pebisoft

Hallo Simon

quote: "Das Toggelbit ändert seinen Wert bei jedem Tastendruck.
Dadurch kann man das lange Drücken einer Taste (und damit das
wiederholte Senden eines Befehls) vom wiederholten Drücken der selben
Taste unterscheiden. "

zu lesen auf: http://www.sprut.de/electronic/ir/rc5.htm

Pete

hallo zusammen,

ich habe bisher vergebens versucht einen TSOP1738 an meinem ATmega8 zum
laufen zu bekommen. In sämtlichen Schaltplänen wird immer wieder der
TSOP1736 oder SFH5110-36 erwähnt. Unter Linux (LIRC) läuft mein
TSOP1738 tadellos, nur halt an meinem Board nicht. Wenn ich ein Piezo
Schallwandler an die Data Leitung anschließe hört man ganz deutlich das
er funktioniert. Nur mein Atmel kann mit dem Signal nichts anfangen. Hat
jemand eine Idee ??  Läuft denn der 1738 überhaupt an dem Atmels oder
bin ich gezwungen mit einen 1736er zu bestellen ??

das sind alles die gleichen nur die demodulationsfrequenz ist anders.

ich würde vermuten es liegt eher an deinem programm. hast du den 1738
an nen interrupt pin? alles richtig eingestellt? Haben AVR und 1738 die
gleiche masse? :P

Hi Lupin,

danke erstmal für deine schnelle Antwort.!.
Da ich noch Newbie bin bitte ich um Entschuldigung... ;-)

Denn du hattest völlig recht, es lag tatsächlich an meinem Programm.
Nach wirklich langen suchen im Netz bin ich dann auf mein Problem
aufmerksam geworden. Und zwar hatte ich im Bascom "If Address = 0
Then" stehen und somit funktionieren natürlich auch nur RC5
Fernbedienungen von Fernseh-Herstellern die die "Adresse 0" senden
:-)

Nachdem ich die Fernbedienung meines Fernseher ausprobierte,
funktionierte gleich alles auf Anhieb ;-)
Der TSOP1738 läuft jetzt tadellos mit meiner Schaltung zusammen,
und ich kann damit z.B. Relais schalten...

** Ich wünsche allen noch eine schöne Weihnachtszeit und einen gesunden
Rutsch ins neue Jahr**

Hallo zusammen.
Hat jemand von Euch den Code von Peter für ATMega128 und 16 MHz
Taktfrequenz angepasst? Ich verwende den TSOP1736 an PINE.5 und bekomme
das Programm (noch) nicht zum laufen. Muss der Eingangspin
Interrupt-fähig sein? Ich sehe nur das Timer0-Interrupt.
Danke im voraus

Hat sich erledigt.
Danke.

Hallo zusammen,

ich weiß nicht, ob es noch jemanden interessiert, aber Daniel hat am
03.06.2005 gepostet, dass er immer Fehlermeldungen und Warnungen des
Compilers bekommt. Unter anderem auch:
"cc1plus.exe: warning: command line option "-Wstrict-prototypes" is
valid for C/ObjC but not for C++"
Das kommt daher, dass der Compiler sich die Endung des Sourcefiles
(hier: .C) anschaut und ein großes .C als C++-Datei und ein kleines .c
als C-Datei unterscheidet und entsprechend kompiliert.
Wenn man gem GCC-Compiler als Option -xc mitgibt, werden auch
.C-Dateien als C-Dateien behandelt.
Das ganze kommt aus der UNIX-Welt, wo zwischen Groß- und
Kleinschreibung unterschieden wird.

Gruß André

Hi, super Code !
Ich versuche grade ihn zu verstehen, weil ich so ändern möchte, daß er
mit nicht-invertiertem Eingang funktioniert. Ich brauche das für eine
Kabelgebundene Steuerung ( d.H. ich habe keine Empfängerdiode, sondern
den Eingang über ein langes Kabel mit dem "Sender" verbunden, den
Träger filtere ich mit einem Kondensator (1.8nF)+Widerstand (10K)
heraus (es geht um eine Hifi-Steuerungsgeschichte)). Klar könnte ich
mit einem Transistor invertieren, aber warum ein zusätzliches
Bauteil..:-)

1.
"if( (rc5_bit ^ xRC5_IN) & 1<<xRC5 ){ rc5_bit = ~rc5_bit; ..."

erkennt wohl die Flanke, und "if( !(rc5_bit & 1<<xRC5) ) tmp |= 1;"
setzt das Bit in TMP. Was ich nun nicht verstehe:
Nirgendwo gibt es eine initiale Zuweisung für rc_bit. Oder habe ich die
einfach nicht gesehen ? Wenn das Programm das erste Mal läuft ist der
Wert von rc_Bit doch zufällig. Verstehe ich da etwas falsch ? Oder ist
das egal ?

grübel....

2.
Ist es korrekt, dass ich für meine nichtinvertierten Signale einfach
nur die Zeile auf if( (rc5_bit & 1<<xRC5) ) tmp |= 1;" ändern muss ?


Danke im Voraus !
Frank

@Frank,

invertiere doch einfach das gelesene Bit VOR der Auswertung. So musst
Du am getesteten Code nichts ändern!

@Werner:

LOL, manchmal denkt man einfach zu kompliziert. Natürlich hast Du
Recht. Warum um alles in der Welt bin ich nicht selbst darauf
gekommen...

Naja, den Code muss ich natürlich trotzdem ändern (halt die Stellen wo
der eingangspin gelesen wird). Aber das macht die Sache einfacher :-)

Danke !
Frank.

@Werner:

Funktioniert prächtig!

Wen eine Kabelsteuerung interessiert:
Man braucht einen Tiefpass um den Träger loszuwerden. Also Kondensator
1,8nF und Widerstand 10K parallel an GND, das andere Ende an den
Eingangspin. Jetzt noch im Source die Zeile "if( (rc5_bit ^ xRC5_IN) &
1<<xRC5 ){ rc5_bit = ~rc5_bit; ..." auf "if( (rc5_bit ^ (~xRC5_IN)) &
1<<xRC5 ){ rc5_bit = ~rc5_bit; ..." ändern und fertich.


Frank.

Hallo! Die Beschaltung nehme ich so vor wie im Datenblatt vorgeschlagen?
Muss ich irgend einen speziellen PIN nehmen?


http://www.reichelt.de/inhalt.html?SID=17R2AJ1KwQA...

So ich habs nun heute auch mal ausprobiert, einfach genial,
funktioniert perfekt :-)

ich habe ihn sogar so geändert, das ich jetzt auf einmal 12bit empfangen
kann. benutze ich für eine steuerung, 1 datenbyte 8bit und ein
steuer-nibble 4bit. klappt wunderbar. 12bit kann ich auch mit einem
schwung senden, habe ich selber geschrieben.

Hallo,
ich bin gerade auf dieses Projekt aufmerksam geworden, da ich noch ein
Tsop rumliegen hatte habe ich ihn direkt mal an mein Atmega 8
angeschlossen. Hat auf anhieb funktioniert, echt prima.
Ich habe eine 8 in 1 fernbedienung aber ich bekomme es einfach nciht
hin das ich ausser Device 0 etwas anderes empfangen bzw decodieren
kann. kann das an der Source liegen?? ich habe irgendwo gelesen man
müsste ein pullup Widerstand mit anschliesen, das habe ich nicht
gemacht. könnte es daran liegen??
Gruß Peppe

Hallo,

ich habe mal eine Frage zur Pause zwischen zwei frames?
Vielleicht wurde es schon beantwortet, und ich habe es nur überlesen.

Wie lang ist die minimale Pausenlänge zwischen zwei frames, damit diese
als richtig interpretiert werden kann. Oder reicht es, wenn nach dem
14Bits des ersten Frames die startbits des zweiten frames kommen?

Ansonsten freue ich mich schon darauf den Code vom Peter
auszuprobieren!

Hallo,

meine Frage hat sich erledigt!

Zwischen zwei Frames muss min. 114ms Pause sein.
Diese Information habe ich auf
http://mikrocontroller.cco-ev.de/de/IR-Protokolle.php gefunden.

Falls das falsch ist, sagt mir doch bitte Bescheid!
Gruss Sebastian

Hallo,
Könnte mir jemand weiterhelfen indem er mir sagt wie ich den code
anpassen muss, damit er auf einem Atmega8 mit dem internen Timer läuft?
das wär spitze.

Nein

Aha, und warum nicht? es ist ja bestimmt ganz einfach, oder? ich habs
nur noch nicht hinbekommen.
Es gibt einige Sachen die mich verwirren.
1. "Der Timerinerrupt wurde so eingestellt, daß er alle 512 Zyklen
aufgerufen wird. Damit ergeben sich bei 4MHz je Bitzeit
4e6/512*1.778e-3=14 Aufrufe des Timerinterrupts. Das ist ausreichend
fein gestaffelt, um die verschiedenen Zeitbedingungen testen zu können.
Bei höheren Quarzfrequenzen kann man die Zyklenzahl entsprechend
erhöhen."
Welche Zyklenzahl brauch ich denn?
2. "#define  XTAL    11.0592e6"
Das bedeutet das ein externer Quarz mit 11MHz angeschlossen ist, oder?
Und kann ich jetzt einfach sagen: #define FCPU  16e6 , und XTAL überall
durch FCPU ersetzen?
3. Wie müsste ich den Vorteiler einstellen?

hat sich erledigt... ich habs gepeilt...

Wird als Hardware nur ein Fototransistor genutzt, der bei Infrarotlicht
einen Pin auf Masse zieht?

Könnte jemand die Beaschaltung ganz kurz nochmal beschreiben? Danke =)

danke :)

Hallo,

auch ich habe das Rad nochmal erfunden, aber etwas anders. So wie oben
konnte ich das in meinem bestehenden "System" nicht einbauen, u.A. kein
Timer mehr frei, zu lange Interrupt-Responsezeiten.

Ich verwende nun den Capture-Interrupt, was verschiedene Vorteile hat:
- Interrupt-Antwortzeit ist weitgehend egal
- nur soviele Interrupts wie Flanken im Signal
- Synchronisation kommt gratis dazu
- er war noch frei   ;-)

Die Capture-Hardware liest bei einer entsprechenden Flake den Timer aus,
merkt sich den Wert und wirft einen Interrupt. In der ISR kann ich mir
nun "in Ruhe" die Differenzen der Zeitmarken ansehen, auf Gültigkeit
checken und die Dekodierung darauf aufbauen. Ich invertiere dabei die
aktive Flanke, um beide Richtungen mitzukriegen. Der Code dieser ISR ist
eigentlich recht kompakt. War aber trotzdem trickreich, den zum Laufen
zu kriegen.

Außer dieser ISR gibt es noch etwas Code an einer Stelle meiner
bestehenden "Infrastruktur":
In einem "Heartbeat"-Interrupt checke ich auf hängende (unvollständige)
Dekodierung und setze ggf. den Dekoder zurück.
Dort ist auch ein weiteres Timeout implementiert, was das Loslassen der
Fernbedienungstaste erkennt. Also wenn keine Code-Wiederholungen mehr
empfangen werden.

Bei ernsthaftem Interesse kann ich das mal posten. Erfordert aber noch
etwas Arbeit, es auf ohne "Nebenwissen" lesbar zu vereinfachen. Ich
mache z.B. keine direkten Registerzugriffe, sondern verwende eine
selbstgestrickte, dünne Abstraktionsschicht. Die ISRs senden ihre
Ergebnisse durch eine Queue zum Hauptprogramm, statt nur gemeinsam
genutzte Variablen zu verändern.

Das Prinzip mit dem Capture-Interrupt sollte auch für andere
Fernbedienungscodes taugen. Ich bin immer noch auf der Suche nach einem
lernfähigen Universalempfänger...

Gruß
Jörg

"... u.A. kein Timer mehr frei"

????

Der Trick bei allen Programmen von P.D. besteht doch darin, eben nicht
exklusiv einen Timer zu belegen, sondern nur einen frei laufenden
Timerinterrupt mitzunutzen. Und das so einer "nicht mehr frei ist", gibt
es nicht.

Aber trotzdem schön, daß dein Implementierung auch läuft :-)

Oliver

@Oliver:
Ich korrigiere mich auf "kein externer Interrupt mehr frei". Der
Capture-Pin hingegen war verwendbar.
Dessen unbenommen halte ich ich den Capture-Interrupt allgemein für
geeigneter. Damit kriegt man einen präzisen Zeitstempel der Flanke,
unabhängig von Interrupt-Latenzen, welche nur kleiner als die Pulsbreite
sein brauchen.

@Peter:
Darin besteht doch die Decodierung, kurze und lange Pulse (=Differenz
der Zeitstempel) zu unterscheiden.
Habe ich das so unklar beschrieben?

Da erwartest due einen Puls der Länge 1000, und die blöde, völlig
ungeeichte FB sendet alles mögliche zwischen 980 und 1020, nur niemals
genau 1000. Und nu? Was machst du jetzt mit den Zeitstempeln?

Oliver

Ihr macht's mir ja nicht leicht...  ;-)

Natürlich erlaube ich für die Flanken eine gewisse Toleranz. Aber ich
will sie auch nicht unnötig vergrößern, nur weil ich meine
Interruptlatenzen auch noch draufrechnen muss. Sonst interpretiert das
Programm wohlmöglich auch nicht-RC5 Pulsfolgen fälschlicherweise, aus
meinem Fernbedienungszoo. (Eine Flanke außerhalb der Toleranzbandes
bricht das Dekodieren ab.)

Ich versuche zu erklären, dass ich im "System" noch andere
Interruptquellen habe, deren Latenz schon bald in die Nähe der
Pulsdauern kommt. Nested Interrupts kann ich nicht, dann müßte ich in
der Software einige Klimmzüge machen um alles reentrant zu kriegen. Der
Atmel kann keine Priorisierung der Interrupts, sonst könnte man dem
IR-Interrupt eine Sonderstellung einräumen.

Lange Rede, kurzer Sinn: Wenn eine Capture-Hardware existiert und
verfügbar ist, dann sollte man die doch gegenüber "einfachen" externen
Interrupts bevorzugen.

Jörg

Guter Input mit den Stör-Spikes, da werde ich nochmal drauf schauen.

Hallo,

ich habe mich nun nochmal mit deiner (Peter) RC5 Routine befasst.

Dein Testcode um per UART die RC5 Daten angezeigt zu bekommen
funktionierte auf Anhieb!

Nun habe ich noch eine Frage.
Ich möchte je ein Char für den Gerätecode und den Tastencode haben.
Warum klappt das hier nicht?

//Variablen allgemein
volatile unsigned char Bild = 0;
//und für RC5
uint i;
char s[30];
char DeviceAdress = 0;
char KeyCode = 0;

im Main:

//RC5
cli();
i = rc5_data;      // read two bytes from interrupt !
rc5_data = 0;
sei();
if( i ){

  DeviceAdress = itoa( i >> 6 & 0x1F, s, 10);  // Device address
  //  puts( DeviceAdress );
  //  putchar(' ');
  KeyCode = itoa((i & 0x3F) | (~i >> 7 & 0x40), s, 10); // Key Code
  //  puts( KeyCode );
  //  puts( "\n\r" );

  //NullPosition
  if ( DeviceAdress == 1 ){
   bInt0 = 1;
  }
  switch ( KeyCode ){
   case 0 : Bild = 0;break;
   case 1 : Bild = 1;break;
   case 2 : Bild = 2;break;
   case 3 : Bild = 3;break;
  }
}

wenn ich die beiden Zeilen:
  //  puts( DeviceAdress );
  //  putchar(' ');

und
  //  puts( KeyCode );
  //  puts( "\n\r" );

reinnehme, sehe ich im Hyperterminal die beiden Zahlen, GeräteCode und
KeyCode.

Danke im voraus...

Gruß Toby

Hallo,

habs schon gefunden.

die beiden Zeilen um aus dem RC5 Code die beiden Byte zu machen müssen
so lauten:

DeviceAdress = i >> 6 & 0x1F;  // Device address
KeyCode = (i & 0x3F) | (~i >> 7 & 0x40); // Key Code

Ich muß die bytes ja nicht in ASCII umwandeln, da ich diese ja nicht per
UART senden will.

Gruß Toby

Ich habe das Program gerade auf ein atmega 8 mit internen 4Mhz Taktgeber
getestet, aber leider funktioniert es hier nicht. Kann es sein das der
interne Oszilator nicht genau genug arbeitet?

Und gibt es eine Möglicht diese Taktgeben irgendwie zu kalibrieren?

Gruss,
Enrico

> Kann es sein das der interne Oszilator nicht genau genug arbeitet?

Nein. Der Takt ist prinzipiell Egal (solange er nicht bei 100kHz oder
darunter liegt).

Upps, sorry. War in Gedanken bei den "Enprell" - Problemen.
Der Takt muss WESENTLICH höher als die 36kHz des IR Signals sein.
Das elegante an diesem Code ist eben gerade dass er recht unempfindlich
gegen Frequenz/Taktabweichunge ist. 4MHz ist aber OK. Bist du dir sicher
dass die Fuses auf 4MHz stehen?

Hallo Peter,

Ich vermute mal das es in der Anweisung statt

 itoa((i & 0x3F) | (~i >> 7 & 0x40), s, 10); // Key Code

 itoa((i & 0x3F) | (~i >> 6 & 0x40), s, 10);

sein soll da (~i >> 7 & 0x40) immer Null ist.

Gruß Wolfgang

Ich hab mal versucht einen PAP für die Empfangsroutine zu erstellen. (Im
Anhang)
Ich denke es funktioniert so ungefähr. Was meint ihr?

Ich nutze seit gestern auch die RC5-Auswertung von Peter.

Da ich die Adresse und den Befehl jeweils auf einen PORT schreibe habe
ich alle Codezeilen die das UART betreffen auskommentiert.

Zu meiner Überraschung lief der Code bei mir nicht mehr bzw. nicht mehr
wie zuvor.

Ich habe es auf folgende zwei Code Zeilen eingrenzen können:

>      itoa( i >> 6 & 0x1F, s, 10);  // Device address
>      itoa((i & 0x3F) | (~i >> 7 & 0x40), s, 10); // Key Code

wenn ich die raus schmeiße geht nichts mehr.

Dieses Verhalten kann ich mir nicht erklären.

mit den beiden Code Zeilen + die Deklaration von s läuft der Code
einwandfrei.

Ich hoffe du hast die puts() Funktionsaufrufe auch heraus genommen.
Sonst könnte es sein dass er sich in der Funktion aufhängt, weil er über
Pointer auf Null prüft. Also nach den itoa() da stehen die puts() die
musst du dann auch heraus nehmen.

@Lars: Danke für die Reaktion.

Wenn ich die drei auskommentierten Zeilen auskommentiert habe geht
nichts mehr.

PS: Ich weis da da zu viel includiert ist. Kann es daran liegen?

#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <avr/interrupt.h>
#include "dev/rc5.h"


int main( void )
{
  uint i;
  long myCount = 0;
//  char s[30];

  TCCR0 = 1<<CS02;      //divide by 256
  TIMSK = 1<<TOIE0;      //enable timer interrupt

  DDRB  = 0xff;
  DDRC  = 0xff;
  DDRD  = 0x00;   
  PORTB = 0xff;
  PORTC = 0xff;
  
  sei();
  for(;;){        // main loop
    cli();
    i = rc5_data;      // read two bytes from interrupt !
    rc5_data = 0;
    sei();
    if( i ){
      PORTB  = (i ^ 0xFF);        // LED output
      PORTC  = (((i >> 6) ^ 0xFF) & 0x1F);
//      itoa( i >> 6 & 0x1F, s, 10);  // Device address
//      itoa((i & 0x3F) | (~i >> 7 & 0x40), s, 10); // Key Code
      myCount = 0;
    } else {
      if (myCount < 80000)
      {
        myCount++;
      } else {
        PORTB  = 0xff;
        PORTC  = 0xff;
        myCount = 0;
      }
    }
  }
}

Die itao() Funktion braucht bissl Zeit. Ich vermute du möchtest, dass
die LED's bei einem empfangenen Signal nur kurz leuchten? Deshalb die
mycount Geschichte am Ende? Wenn die itoa()s faheln hast du natürlich
viel Zeit übrig. Darum könnte das für dich zu einer "fehlerhaften"
Anzeige kommen.
Ich würde
        PORTB  = 0xff;
        PORTC  = 0xff;
einfach mal auskommentieren und dann kucken was passiert.

Nö, dann geht immer noch nichts ;o(
Ich habe auch mal eine kleine Warte Zeit eingefügt (eine Dumme schleife)
was auch nichts brachte. Also wenn es kein Timing Problem ist was dann?

Das Programm geht ja mit dem itoa. Aber ich kann mir Verhalten einfach
nicht erklären.

Ich sehe es einfach nicht.

Es müsste eigentlich funktionieren. Ich habe gerade mal probiert. Wobei
ich die DDR Regsiter zum ein und ausschalten der LEDs verwendet habe.
Hast du auch dioe richtige File kompalliert bzw. funktioniert da alles
auch mit der my Count sache.

Also das ich den richtige File kompiliere ist sicher. Da ich die
Funktion ja jeder Zeit einschalten in dem ich einen der beiden "itoa"
befehlen aktiviere.
Ich verstehe es einfach nicht. Aber ich werde weiter testen. Was kann
ich in dem Zusammenhang noch falsch gemacht haben? Die Geschichte mit
dem myCount funktioniert auch so wie ich es mir wünsche.

Ich bin mir recht sicher das mein Programm nicht mal in die true
Bedingung der if Abfrage kommt. was aber eine Abfrage innerhalb der if
== true Abfrage nicht beeinflussen kann.

Danke nochmals für Deine Tipps.

So ich habe neue Erkenntnisse dich ich aber nicht verstehe.

Also die itoa Zeilen habe ich auskommentiert. Dafür habe ich aber eine
dummy Funktion gebaut die nichts sinnvolles oder Zeit intensives macht.

void zett(void)
{
  int mytrash;
  mytrash++;
}

diese Funktion rufe ich an der Stelle wo vorher die itoa standen auf.

Dann geht das ganze auch. Warum weis ich aber immer noch nicht.

Das war es. Vielen Dank!

Vor allem aber für die Erklärung warum man da ein volatile einfügen
sollte. Die Funktion war ja gegeben. Ich konnte mir aber keinen Reim
darauf machen.

Mit einer Warnung wäre ich vielleicht selbst darauf gekommen.

Schönes Wochenende noch.

Hallo,

passend zum Thema habe ich gerade für den RC5 Code einen Beitrag im
Fernbedienungsportal veröffentlicht:
http://fb-vz.de/rc5-code/
Evt. hilft er euch bei euren Problemen weiter

Hallo Peter Dannegger,

super GCC-Code von Dir, opimieren durch weglassen, sowas kommt gut an.
Kein C++ Code war so klein wie dieser, von allen die ich bisher
gesichtet. Habe diesen schon länger in Betrieb aber wusste nichts von
diesen Forum und Beitrag.

Zu dem Problemen mit den Empfängern, wenn auf den Schaltungen
Spanungswandler sind, z.B. -5V für Display's oder ähnliches, dann
braucht der Empfänger eine Entkopplung mit einem Wiedersand in der
Stromversorgung.

+5v----.--|100ohm|---.-----+5V IRempfänger SFH50X oder andere
       |             |
      ===           ===
      --- 1- 10uF   --- 1-10uF
       |             |
      _|_           _|_

Udo

ein 100nf an alles dran so wie man das auch machen sollte bringts auch.

gruss sven

Kann jemand bitte mal ein Schaltbild reinsetzen? Ich checke noch nicht
so 100%ig wie der TSOP1736 angeschlossen wird.
Bin in Elektronik (noch) ein blutiger Anfänger. Vergönnts mir :-)

Gruß, Rainer

Danke!!! :-)

Hallo,

kann bitte jemand die .hex Datei für ( ATMega16 @ 4MHz-Intern ) zur
Verfügung stellen, ich versuche schon seit Stunden, nichts läuft, ich
bekomme zwar die Meldung
"RC5-Dekoder", aber weiter tut sich gar nichts, ich habe probiert
einfach die  Signale von TSOP1736 zu empfangen und im Terminal
auszugeben, das funktioniert, aber wenn ich die gepostete Sourcecode
kompiliere, dann passiert außer Textausgabe nichts mehr. Als
Fernbedienung benutze ich Imex IM-1313, die habe ich damals mit "lirc",
benutz und lirc geht doch nur mit RC5, oder? OK, dann hab ich probiert
die ganzen Philips Geräte-Codes einzugeben (es ist eine universal
Fernbedienung), funktioniert auch nicht. Nun bin ich langsam verzweifelt
und weiß nicht weiter, deswegen bitte ich euch um ein Tipp oder die .hex
datei damit ich zumindest sehen kann dass es wirklich funktioniert und
ich was falsch gemacht habe.

Vielen Dank für die Hilfe!

Hi,

ich versuche gerade den Code auf einen 8051 abzuändern.

Was mir jedoch Schwierigkeiten bereitet:

In der Main.h Datei steht ja folgendes:

#define  xRC5_IN    PIND
#define  xRC5    PD7

Der Pin PD7 ist mir klar,das ist halt einfach ein Portpin,aber was ist
der PIND - ist das auch ein Portpin?

Wenn ja,für was benötige ich einen zweiten Portpin,oder sieht die
Schaltung nicht so aus wie auf dieser Seite?

http://www.roboternetz.de/wissen/index.php/RC5-Dec...

Hi,

würde das dann bei einem 8051 so aussehen?

P0.7 Nummer des Pins
P0 8bit Port

Hallo Peter,

Ich nutze deinen RC5 Code erfolgreich, danke dafür.

Nun habe ich aber mal eine Frage:
Da ich einen eigenen IR Sender habe, also keine handelsübliche
Fernbedienung, würde ich den Code gerne kürzen.
Ich brauche eigentlich nur 6 Bit zur Steuerung meines Projektes.

Kannst Du mir evtl. weiterhelfen, wenn ich den Gerätecode nicht
übertragen will, und auch nicht auswerten will.
Klar weiß ich, das es dann nicht mehr mit einer "normalen" FB geht.

Mein Problem besteht darin, das ich Daten per IR übertragen will,
diese 6 Bit aber schneller als alle 24 ms kommen müssen.
Da das RC5 Protokol aber 24ms Zeit braucht, ist es zu langsam.

Vielleicht könnte man ja ein Protokoll "bauen", das ein Byte übertragt?!
2 Bit als Startbit
8 Bit Daten Byte
= 10*1,778ms = 17,78ms für ein Byte.
Evtl. kann man die länge der Bits noch kürzen, da eine SFH5110 bei
6*36kHz
schon für ein eindeutiges Signal reicht, lt.Datenblatt.
So könnte man z.B. statt 32*36kHz nur 16*36kHz für ein Halbbit nehmen.
Spart nochmal die Hälfte an Zeit.

Danke schon mal, für die Hilfe.

Gruß Toby

PS: Interessant wäre dann sogar einen Sender und Empfänger zu bauen.

Hallo Peter,

grundsätzlich muss ich mich, glaube ich, erst mal mit der
RC5 Systemathik auseinandersetzen. Dann verstehe ich auch deinen Code.

Ich möchte, auch wenn es jetzt etwas Off Topic ist, mal anders beginnen,
um mein Problem zu schildern.

Ich habe ein Rotordisplay in meinem RC-Heli gebaut.
Die Steuerungen der Leds, die in den Blättern verbaut sind, drehen sich
mit. Ich erfasse die Drehzahl per Hallsensor, und übertrage RC5 Code vom
nichtdrehenden Teil des Helis zum Rotor, um zwischen verschidenen
Bildern
umschalten zu können.
Nun möchte ich gerne den Hallsensor im drehenden Teil einsparen, da es
zu viel Bauaufwand ist.
Getestet habe ich es folgendermaßen:
Hallsensor am festen, nicht drehenden Teil des Helis.
Bei jedem Hallsignal sendet nun eine Steuerung einen IR Puls zu dem
Rotor.
Die Pulslänge wird im Rotor ausgewertet, und dementsprechend die Bilder
angezeigt.
Der Beginn des Pulses ist gleichzeitig das Startsignal, also der
Referenzpunkt der Anzeige. Ersetzt also den Hallsensor am drehenden
Teil.

Nun ist mir die Sache mit der Pulslänge aber zu störanfällig, so das ich
dachte, ich könnte den RC5 Code so ändern, das ich damit die Übertragung
bewältigen kann.
Da der RC5 Code im Original etwa 24ms für eine Übertragung braucht, bei
2000 U/min eine Umdrehung ca. 30ms benötigt, bekomme ich da schon
Probleme.

Also muss ich 2 Dinge mit der IR Routine erledigen:
Beim beginn der Übertragung fesstellen, das es das Startsignal ist.
Die Übertragungsgeschwindigkeit erhöhen, bzw. die Datenlänge kürzen.

Vielleicht habe ich ja einen enormen Denkfehler, vielleicht weiß jemand
eine Intelligentere Lösung des Problems.


So, werde mich nun erstmal mit der RC5 Systemathik beschäftigen.

Gruß Toby

Hi,

@Peter: die Vorschläge von Dir hab ich übernommen.

Hab den Code jetzt mal auf den 8051 angepasst.
Ich habe versucht möglichst den ganzen Code möglichst 1:1 zu übernehmen
um Fehler zu vermeiden.
Jedoch komme ich nie in die

if(i)
{

.....

}

Schleife.

Bei den Funktionen cli(); und sei(); war ich mir nicht sicher was die
eigentlich machen. Ich hab im Forum nach den beiden Funktionen gesucht
und hab die folgendermaßen ersetzt:

cli();  --> EA = 0;
sei(); --> EA = 1;

Das Prorgamm hab ich angehängt.

Bernhard

Hallo Peter,

ich denke, ich habs nun verstanden. ;-)

Ich habe deine Code mal so geändert, das ich 2 Startbits und 8 Datenbits
empfangen kann.
Siehe Anhang.

Ebenso habe ich meinen IR Sender umgebaut, damit er dieses Protokoll
sendet.
Anhang kommt sofort.

Ich bitte allerdings, den ganzen Code Müll zu entschuldigen.

Nun muss ich nur noch sehen, wie und wo ich ein Bit setze, damit ich
auswerten kann, ob es das Startsignal für meine Anwendung ist.
Ich denke, ich sollte es nach den beiden Startbits machen.

Gruß Toby

So,

hier nun der IR Sender.

Gruß Toby

Danke,ich hab die Änderungen in mein Programm übernommen.

Aber irgendwo scheint noch der Wurm drinnen zu sein,denn wie auch vorhin
geht er mir nicht in die Schleife.
Zuerst hatte ich den TSOP 1838 ohne Zusatzbeschaltung direkt an den µC
geschalten,dann hab ich den Schaltungsvorschlag aus dem Datenblatt
übernommen.
(den 100Ohm Widerstand + den 4,7µF Elko(statt dem 4,7µF Elko hab ich
einen 10µF Elko genommen,ich hoffe das macht das Kraut auch nicht
Fett?!))


p.s: Ich hab zwei verschiedene Fernbedienungen ausprobiert,die eine
Fernbedienung funktioniert sicher(ist jeden Tag in Verwendung). Aber ich
bin mir bei beiden nicht sicher welches Protokoll sie verwenden...
Angenommen ich hätte hier Fernbedienungen die nicht das RC5 Protokoll
verwenden,würde dann ein Blödsinn im Terminal aufscheinen oder gar
nichts?

Bernhard

Entschuldigt,hab das Programm vergessen.


Bernhard

Hallo,

ich habe festgestellt, das bei falschen FB's nicht angezeigt wird.

Das soll wohl daran liegen, das die anderen Codes längere/kürzere Pulse
und mehr/weniger bits haben.

Es sind dann halt völlig andere Protokolle.

Gruß Toby

Ich hab mir jetzt mal eine Univeralfernbedienung geschnappt und ein
bisschen mit der herumgespielt.
Ich hab die Fernbedienung auf die verschiedenen Philips Gerätecodes
programmiert und jeweils dazwischen die Funktion ausprobiert - kein
einziger Gerätecode funktionierte.
Auch ein automatischer Suchlauf der Fernbedienung selber brachte kein
Ergebnis..

War Philips vielleicht der falsche Ansatz?! Doch laut Google setzten
einige TV Geräte von Philips das RC5 Protokoll ein.

Habt ihr einen Vorschlag?

Bernhard

Hi,

teste mal Grundig oder Marantz Codes. Viele von denen funktionieren bei
mir prima.

technikus

Hallo Zusammen,

ich versuche nun schon seit 2 Tagen meine RC5 Routine zum laufen zu
bekommen.
Ich verwende einen Tiny44 mit dem internen Takt.
Ich will mir, nur damit ich weiß dass er die RC5 Routine richtig
durchführt, auf Port PA3 eine LED an- bzw. ausschalten!
PA2 soll der Eingang meines IR- Empfänger sein!

Wäre super wenn mir da jemand weiterhelfen könnte!

Grüße
Matthias

Achso hab ich ganz vergessen!
interner Takt = 8MHz

wo soll ich da den wert 0xffff reinschreiben?
also auf einem Atmega8 hat das Programm schonmal funktioniert!
nur auf dem Tiny läuft es nicht!

@Georg:

Keycode = ((i & 0x3F) | (~i >> 7 & 0x40), s, 10); // Key Code

bedeutet einfach dass ich mir dn Code der hinter einer Ziffer auf der
Fernbedienung in der Variable abspeichere.
Aber du hast recht, in dem ......,s,10) könnte der Fehler liegen!

Ich werds am Montag gleich mal testen!
Falls sonst noch jemand Fehler in dem Quelltext findet, bitte melden!

Danke
Gruß
Matthias

wie weiss man eigentlich aus der rc5-routine, wann das ir-signal
anfängt?

ich sehe keinen interrupt, sondern nur eine timer-überlaufroutine.

normal müsste doch über einen interupt das signal gegeben werden "die
rc5-signale kommen jetzt an" und dann die auswertung.

mfg

Hallo,

erstmal Danke für den Code.

Will ihn anpassen damit er mit 16 Mhz funktioniert.

Hab da aber ein paar fragen.

In deiner Erklärung schreibst du von 4 Mhz als Frequenz.

XTAL ist aber auf 11.0592e6 gesetzt.

Ansonsten würde ich

#define PULSE_MIN (uint8_t)(XTAL / 512 * RC5TIME * 0.4 +0.5)
#define PULSE_1_2 (uint8_t)(XTAL / 512 * RC5TIME * 0.8 +0.5)
#define PULSE_MAX (uint8_t)(XTAL / 512 * RC5TIME * 1.2 +0.5)

in

#define PULSE_MIN (uint8_t)(F_CPU / 2048 * RC5TIME * 0.4 +0.5)
#define PULSE_1_2 (uint8_t)(F_CPU / 2048 * RC5TIME * 0.8 +0.5)
#define PULSE_MAX (uint8_t)(F_CPU / 2048 * RC5TIME * 1.2 +0.5)

ändern. F_CPU ist 16e6.

Beim Timer hab ich den Prescaler auf 1024 gestellt, des müsste passen.

Wäre super wenn du mir kurz ne Rückmeldung geben kannst ob des so passt.

Danke!

warum testest ud deinen code nicht?

ist doch einfacher wie das fragen.

bei mir läuft er mit 16mhz und auch mit 8mhz.

Ja, hab ich inzwischen auch.

Und es hat leider nicht funktioniert.
Nach allem was ich bis jetzt herausgefunden habe, denke ich, das es an
der Funktion zur erkennung des RC5-Codes liegt.

Mein Program hat einen LernModus wo es RC5-Codes erkennen und
abspeichern soll.

Wenn ich statt der normalen rc5 Funktion einfach eine leere Aufrufe
bleibt das Programm in der Endlosschleife. Sonst springt es nach ca 0,5
sec. raus. Es muss also etwas "erkannt" haben. Habe auch schon den PIN
mal gewechselt um irgendwelche störeinflüsse auszuschließen.

Im Debugger läuft das Programm auch einwandfrei durch. Allerdings läuft
der Debugger auch mit 4Mhz, mein Atmega8 aber mit 16.

Habe den Code angehängt. F_CPU wird vom Compiler auf 16000000 gesetzt.


Wäre echt super wenn sich das jemand anschauen und mir helfen könnte.

Danke.

Niemand? :-(

Bin für jeden Tipp dankbar

Hat es schonmal jemand mit 1MHz Takt bzw. 128 Zyklen probiert oder
könnte das zu knapp werden?

geht auch auf einem tiny25 mit 1MHz, allerdings wohl schon knapp.
der interrupt besteht aus 76 befehlen, ohne signal braucht er aber nur
40 zyklen.
man muss den timerinterrupt auf irgendwas im bereich 100µs einstellen,
und dann RC5CYCLES zurückrechnen.

#define RC5CYCLES  162 // tatsächlicher wert ist langsamer, messen.
#define PULSE_MIN  (uint8_t)(XTAL / RC5CYCLES  RC5TIME  0.4 + 0.5)
#define PULSE_1_2  (uint8_t)(XTAL / RC5CYCLES  RC5TIME  0.8 + 0.5)
#define PULSE_MAX  (uint8_t)(XTAL / RC5CYCLES  RC5TIME  1.2 + 0.5)

TCCR0B=1<<CS01; // 1mhz durch 8 = 125khz bzw. 8µs
TIMSK=1<<OCIE0A;

ISR(TIM0_COMPA_vect)
OCR0A=TCNT0+16; // 16 * 8 takte = 128 takte

sicherheitshalber das volatile einbauen.

danke für das programm.

es ist natürlich

.. * RC5TIME * ..

Hier noch Hinweise:

Das Programm muss zunächst das Toggle-Bit prüfen, da die Codes meistens
mehrmals gesendet werden (will man meistens nicht, manchmal ja
(Lautstärke)).

Die Bits stehen in der Variable i, und werden durch schieben und
maskieren zu einem echten Byte gemacht.
Der Befehlscode steht schon an der richtigen Stelle und wird nur
maskiert, bekommt aber noch das zweite Startbit als 7. Bit dazu (RC5X):

(i & 0x3F) | ((~i >> 6) & 0x40)

(Fehler im Original, siehe
Beitrag "Re: Fernbedien RC5 Empfänger")

Hallo Peter,

eine kurze Frage zu Deinem Code:

die Zeilen:

 if( rc5_time < PULSE_MIN )      // to short
      tmp = 0;

sollen zu kurze Impulse abfangen, müsste dann aber nicht auch noch
rc5_time auf null gesetzt werden?

Danke im Voraus?

hallo liebe IR freunde :)

ich habe den Code ebenfalls benutzt, erstmal ein großes lob an peter
dafür!
leider habe ich ein kleines problem, ich muss schon wirklich massiv
lange auf die bedienung drücken bis er dann doch endlich mal im terminal
was ausspuckt (ich lasse mir alles über einen virtuellen comport
rausschicken. ich benutze einen usb pic von microchip dafür und hab die
routinen also etwas umgeschrieben aber das wesentliche ist das von
peter).
leider hatte ich den kondensator, den sie im datenblatt für störungen
empfehlen nicht da. kann es sein dass es daran liegt??? das was im
terminal ankommt ist nämlich an sich schon richtig, nur leider kommt es
wirklich viel zu selten dafür dass ich so lange auf der taste bin.
mehrmaliges drücken bringt auch keinen erfolg. den 100ohm widerstand vor
vcc hab ich mal reingebaut...
vielen dank!

@steveläßtsichfurchtbarschlechtlesendeintext.

Hello all,
i am sorry that i dont speak german and understand just a little of it.
I would like to ask popular nice RC5 code author Peter Dannegger: is
there maybe a more recent version of RC5 code that would also accept
RC5X signals?
Thank You very much in advance!

>Oder hat jeman ein Tipp wie ich da dran gehen soll?

Senden ist doch straightforward. Man weiß, wann es losgeht, es gibt
keine Störungen und Abbruchbedingungen. Einfach RC5-Codebeschreibung
lesen, Timer entsprechend initialisieren, damit die Pulse und die
Grundfrequenz erzeugen und über LED raustickern, fertig.

>So eine Art Lernbare Fernbedienung ?

Was willste denn lernen? RC5 ist RC5. Andere Protokolle sind ganz anders
aufgebaut, haben andere Grundfrequenzen, etc. Eine lernbare Universal-FB
nachzubauen wird da ernsthaft aufwendig.

Oliver

Nachtrag:

Hier
http://www.sbprojects.com/knowledge/ir/ir.htm
gibt es eine schöne Zusammenfassung, mit (Assembler-)Software. Deren
Prinzip lässt sich aber serh schön und einfach auch in C umsetzen.

Oliver

Hallo,
ich wollte euch kurz darum bitten meinen Source anzuschauen. Irgendwo
ist der Wurm drin.
Ich verwende einen Attiny2313, gcc version 4.3.2 (WinAVR 20090313). Ich
drehe bald durch. Mit der version habe ich es geflasht und ging und
jetzt nicht mehr warum?????
- Warum meckert der bei AVRStudio4 wenn ich mit volatile rc5_data habe
und
- Warum meckert der bei AVR-GCC wenn ich mit extern rc5_data habe

ICH krieg echt die kriese ich schmeiße alles aus dem Fenster, seit einer
Woche mache ich da rum.

TSOP ist bei PD2 angeschlossen
Quarz: 3,6864 Mhz

Ich bedanke mich jetzt schon f+r euere muehe

Hallo Peter,

beinhaltet rc5_data alle RC5 Bits?
Also

ein Toggelbit (abwechselnd "1" oder "0")
5 Adressbits
6 Kommandobits

Nochmal 'laut' gedacht zum Toggle Bit und der weiteren Auswertung der
RC-5 Pakete:

Eingabemethoden
 1 Einfacher Tastendruck gilt für alle Befehle
 2 Dauerfeuer, gilt nur für z.B. Lautstärke (nicht für An/Aus :-)

Fehlerquellen:
 Sendeleistung reicht nicht
 Sichtverbindung blockiert und keine Reflexion
 Empfänger gestört (durch IR oder EMV z.B. Leuchtstofflampe, Sonne)

Bei einem Tastendruck wird das Toggle-Bit umgeschaltet.
Wird die Taste gedrückt gehalten, ändert sich das Toggle Bit (TB) nicht,
und das Paket wird alle 114 ms wiederholt (also ca 90 ms später).

Der Empfänger guckt erstmal, ob die Adresse stimmt.
Das letzte Paket hat er sich gemerkt (TB, ggf. Befehl).

Ist das TB gleich, kann das bedeuten:
 der letzte Befehl ist nicht angekommen (out of synch)
 die Taste wird gedrückt gehalten
 der Befehl wird zur Sicherheit mehrfach gesendet (?)

Ist es verschieden
 der letzte Befehl ist nicht angekommen (out of synch)
 eine neue Taste wurde/wird gedrückt


Was müsste der Empfänger also machen?
  das TB ignorieren, falls seit 114 ms nichts empfangen
Dann sind Sender/Empfänger wieder synchron.

Beim nächsten mal
  TB gleich -> prüfen, ob der Befehl Dauerfeuer akzeptiert, wenn ja,
ausführen.


Sonst noch was? Wie ist das mit der Mehrfachsendung?


--
http://www.sbprojects.com/knowledge/ir/rc5.htm
http://en.wikipedia.org/wiki/RC-5

ich habe eine software eintwickelt die 3 leds per pwm dimmen kann (alle
einzeln). die timer im atmega32 laufen alle 3 im fast pwm mode.

kann ich hier die rc5 routine auch verwenden?

gruß pille

Hallo zusammen!

Im ersten Post steht, dass der Timer durchlaufend sei, aber es wird doch
nach jedem overflow das zählregister so gesetzt, dass nach zwei
zählererhöhungen wieder ein overflow auftritt!?
Habe ich da etwas übersehen?
Bei einem "durchlaufenden" 8Bit timer hätte ich jetzt erwartet, dass der
zähler auch die vollen 8 bit zählt.

gruß dtm

Peter Dannegger schrieb:
> Neuere AVRs ...

Der Mega168 gehört nicht dazu, oder? Zumindest kann ich im Datenblatt
nichts dazu finden.

Da kommt mir folgende Idee:

OC-Match Interrupt aktivieren, und das OC-Register bei jedem Aufruf der
Interruptroutine um 2 (natürlich vom Prescaler abhängig) zu erhöhen.
Dann dort einfach die Flankenerkennung ablaufen lassen.

Hallo,

erstmal Danke für den Code.

Will ihn anpassen damit er mit 3,686411 Mhz funktioniert. (myAvr)


Was ich nicht verstehe ist;
In deiner Erklärung schreibst du von 4 Mhz als Frequenz.
XTAL ist aber auf 11.0592e6 gesetzt.

Warum das?


Gruß

Guten Morgen,

danke erstmal für die rasche Antwort! ;)

XTAL habe ich soweit angepasst, leider funktioniert noch nichts. Dachte
das ich die 512(Zyklen) bzw einen Vorteiler dementsprechend anpassen
muss. Der Aufbau ist auch klar, leider bekomme ich an PortB, welcher die
letzten 8 Bits ausgibt keinerlei Signal.


Lg Ratlos

code?

Guten Morgen nochmals :)

Danke vorab für die Mühe!


Zitat:
"Der Timerinerrupt wurde so eingestellt, daß er alle 512 Zyklen
aufgerufen wird. Damit ergeben sich bei 4MHz je Bitzeit
4e6/512*1.778e-3=14 Aufrufe des Timerinterrupts."

Die Mhz des Quarzes wie auch die 1.778ms sind fixe Werte, also kann man
theoretisch nur noch die "512" ampassen, um auf ~14 Aufrufe zu kommen.
Eine Idee wäre die besagten "512" variabel zu gestalten, sodass man eine
Schleife generiert, welche den Wert in 10er Schritten von 300-700
wandern lässt.

Denke ein großer Fehler kann es ja nicht sein, da am Orginalcode kaum
etwas verändert wurde, dieser funktioniert und am PD7 ein sauberes
Rc5-Signal anliegt.


Hier die Interrupt Routine:
(Muss man die 512 dementsprechend anpassen, sodass man auf ~14 kommt?)

#include "main.h"

#define RC5TIME   1.778e-3    // 1.778msec
#define PULSE_MIN  (uchar)(XTAL / 512 * RC5TIME * 0.4 + 0.5)
#define PULSE_1_2  (uchar)(XTAL / 512 * RC5TIME * 0.8 + 0.5)
#define PULSE_MAX  (uchar)(XTAL / 512 * RC5TIME * 1.2 + 0.5)


uchar  rc5_bit;        // bit value
uchar  rc5_time;        // count bit time
uint  rc5_tmp;        // shift bits in
uint  rc5_data;        // store result


SIGNAL (SIG_OVERFLOW0)
{
  uint tmp = rc5_tmp;        // for faster access

  TCNT0 = -2;          // 2 * 256 = 512 cycle

  if( ++rc5_time > PULSE_MAX ){      // count pulse time
    if( !(tmp & 0x4000) && tmp & 0x2000 )  // only if 14 bits received
      rc5_data = tmp;
    tmp = 0;
  }

  if( (rc5_bit ^ xRC5_IN) & 1<<xRC5 ){    // change detect
    rc5_bit = ~rc5_bit;        // 0x00 -> 0xFF -> 0x00

    if( rc5_time < PULSE_MIN )      // to short
      tmp = 0;

    if( !tmp || rc5_time > PULSE_1_2 ){    // start or long pulse time
      if( !(tmp & 0x4000) )      // not to many bits
        tmp <<= 1;        // shift
      if( !(rc5_bit & 1<<xRC5) )    // inverted bit
        tmp |= 1;        // insert new bit
      rc5_time = 0;        // count next pulse time
    }
  }

  rc5_tmp = tmp;
}

Und auch die Main:
(Unverändert)

#include "main.h"


void putchar( char c )
{
  while( (UCSRA & 1<<UDRE) == 0 );
  UDR = c;
}


void puts( char *s )
{
  while( *s )
    putchar( *s++ );
}


int main( void )
{
  uint i;
  char s[30];

  TCCR0 = 1<<CS02;      //divide by 256
  TIMSK = 1<<TOIE0;      //enable timer interrupt

  UBRRL = bauddivider;      //set baud rate
  UBRRH = bauddivider >> 8;
  UCSRA = 0;        //no U2X, MPCM
  UCSRC = 1<<URSEL^1<<UCSZ1^1<<UCSZ0;  //8 Bit
  UCSRB = 1<<RXEN^1<<TXEN;    //enable RX, TX

  sei();
  puts( "RC5-Dekoder:\n\r" );
  for(;;){        // main loop
    cli();
    i = rc5_data;      // read two bytes from interrupt !
    rc5_data = 0;
    sei();
    if( i ){
      DDRB = i;        // LED output
      putchar(( i >> 11 & 1) + '0');  // Toggle Bit
      putchar(' ');
      itoa( i >> 6 & 0x1F, s, 10);  // Device address
      puts( s );
      putchar(' ');
      itoa((i & 0x3F) | (~i >> 7 & 0x40), s, 10); // Key Code
      puts( s );
      puts( "\n\r" );
    }
  }
}

XTAL wurde der Quarzfrequenz (3.686Mhz) angepasst

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/signal.h>
#include <stdlib.h>


#define uchar unsigned char
#define uint unsigned int

#define  xRC5_IN    PIND
#define  xRC5    PD7      // IR input low active

#define  XTAL    3.686e6

#define  BAUD  19200
#define bauddivider (uint)(XTAL / BAUD / 16 - 0.5)


extern uint  rc5_data;        // store result

Lg Ratlos

Ratlos schrieb:
> DDRB = i;

Hier setzt du den Prot nicht, sondern definierst die Pins am PortB (in
deinem fall vom rc5-signal gesteuert) als Ausgang.

Versuchs mal an gleicher Stelle mit

 PORTB = i; 

und vor der main-loop mit:

 DDRB = 0xff; 

hey
finde den Code auch sehr gut und würde ihn gern verwenden.
Danke hier nochmal an Peter!

Ich verwende AVR Studio VER. 4.18 ich habe alle 3 Dateien in einem
Projekt geöffnet allerdings nach drücken auf "build" kommt folgende
Fehlermeldung:

c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr4/crtm8.o:(.init9+0x0):
undefined reference to `main'

Jemand ne Idee woran das liegen kann??

mfg Christian

Garnicht so einfach heutzutage eine FB mit RC5 Code zu finden.
Könnte mal jemand der sich damit auskennt überprüfen ob meine FB
standardkonformes RC5 sendet?

Ich hoffe dass es RC5 ist, hab mal nacheinander die Tasten 1..9,0
gedrückt und mit Audacity den Ausgang vom Empfänger IC (TSOP...)
aufgezeichnet. Übrigens danke schonmal ans Forum für den genialen Tipp
mit der Soundkarte.

Danke für den Tipp mit dem IRMP, habe ich irgendwie über die
Suchfunktion noch nicht entdeckt.

Scheint bei meiner FB aber tatsächlich RC5 zu sein, Start- und Toggle
Bits sind vorhanden, der komplette Frame besteht aus 14 Bits und dauert
etwa 24 ms (siehe Anhang.)
Leider hat sich auf der FB keinerlei Hersteller verewigt, einfach
unbeschriftet. Ist aber ein interessantes Teil, da sie über ein
Steuerkreuz und "Maustasten" mit deutlich höherer Updaterate als die
anderen Tasten verfügt. Ich kann nachher mal Bilder davon machen.

Hallo,

habe im Mediamarkt von Vivanco eine Fernbedienung für 3,99E gekauft.
Siehe Link:
http://www.vivanco.de/cgi-bin/vivanco/de_DE/produc...

Diese produziert mit der Codeeinstellung: 035 einen RC-5 Code.
TV1 hat die Geräteadresse  0
Sat1 hat die Geräteadresse 8

MfG Norman

Hallo erst mal,
habe den gesamten Thread jetzt mal. Es taucht immer wieder die Frage
bzw. das Problem mit der Nutzung des internen Oszillators auf...
Ist das in irgendeiner Form ein Problem oder nicht bzw. kann jemand
bestätigen die Routinen mit internem Oszillator lauffähig bekommen zu
haben.
Ich selber kämpfe noch, arbeite allerdings mit ext. Quarz (9.8304Mhz),
um glatte Baudraten einstellen zu können.
Plane aber später ne Version mit int. Oszillator, wo dann aber auch
keine UART benötigt wird.

Gruß Josh

Hi Leute.

Sorry wenn ich den alten Threat wieder raus krame, aber ich bin jetzt
auch dabei den RC5-Code von Peter auszuprobieren...
Leider klappt es nicht und ich such mich seit Wochen nach dem Fehler
tot...bin total verzweifelt...hab alle Posts doppelt und dreifach
gelesen...aber nix hilft.

Ich versuche den Code an einen ATMega128 mit 16MHz anzupassen. Das ganze
ist ein AVRStudio4-Projekt.

Die relevanten Code-Stellen sehen folgender Maßen aus:

#define F_CPU 16000000UL

/* Zuweisungen PORT D */
#define PORT_D_CONFIGBYTE  0x48 //
  #define PD0x           PORTD0  // Input    -> 0  
  #define PD1x           PORTD1  // Input    -> 0 
  #define PD2x           PORTD2  // Input    -> 0  RX1
  #define PD3x           PORTD3  // Output   -> 1  TX1  
  #define PD4x           PORTD4  // Input    -> 0  switch
  #define PD5x           PORTD5  // Input    -> 0  switch
  #define PD6x           PORTD6  // Output   -> 1  led
  #define xRC5           PORTD7  // Input    -> 0  RC5-Signal
  

//RC5
#define  xRC5_IN    PIND

#define uchar unsigned char
#define uint unsigned int
#define  XTAL    16000000  

#define RC5TIME   1.778e-3    // 1.778msec
#define PULSE_MIN  (uint)(F_CPU / 2048 * RC5TIME * 0.4 + 0.5)
#define PULSE_1_2  (uint)(F_CPU / 2048 * RC5TIME * 0.8 + 0.5)
#define PULSE_MAX  (uint)(F_CPU / 2048 * RC5TIME * 1.2 + 0.5)

Ich benutze Timer2 (8-Bit).

TCCR2 |= (1<<CS22)| (1<<CS20);      //divide by 1024
TIMSK = (1<<TOIE2);      //enable timer interrupt

In der ISR(TIMER2_OVF_vect) habe ich

TCNT2 = -8; 

 angepasst.

Der Rest ist eigentlich Original...

Kann mir jemand sagen warum das ganze nicht funktioniert?
In die ISR(TIMER2_OVF_vect) wird gesprungen, aber rc5_data wird nie
gültig.
D.h.

if( !(tmp & 0x4000) && (tmp & 0x2000) ){  // only if 14 bits received
      rc5_data = tmp;

 wird nie erreicht.

Hat jemand eine Idee?

LG.
moo