Fernbedien RC5 Empfänger

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

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

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

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

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

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?family_id=607)

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.

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.

@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=17R2AJ1KwQARIAAFFVd9c21a427bea00e9bc5d79fd8cef9c46028;ACTION=7;LASTACTION=6;SORT=artikel.artnr;GRUPPE=A54;WG=0;SUCHE=TSOP;ARTIKEL=TSOP%25201736;START=0;END=16;STATIC=0;FC=669;PROVID=0;TITEL=0;DATASHEETSEARCH=TSOP%201736;FOLDER=A500;FILE=TSOP1730_TSOP1736_TSOP1738_TSOP1756%2523VIS.pdf;DOWNLOADTYP=1;DATASHEETAUTO=;OPEN=1

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?

1

#include <string.h>

2

#include <stdio.h>

3

#include <stdlib.h>

4

#include <avr/interrupt.h>

5

#include "dev/rc5.h"

6

7

8

int main( void )

9

{

10

  uint i;

11

  long myCount = 0;

12

//  char s[30];

13

14

  TCCR0 = 1<<CS02;      //divide by 256

15

  TIMSK = 1<<TOIE0;      //enable timer interrupt

16

17

  DDRB  = 0xff;

18

  DDRC  = 0xff;

19

  DDRD  = 0x00;   

20

  PORTB = 0xff;

21

  PORTC = 0xff;

22

23

  sei();

24

  for(;;){        // main loop

25

    cli();

26

    i = rc5_data;      // read two bytes from interrupt !

27

    rc5_data = 0;

28

    sei();

29

    if( i ){

30

      PORTB  = (i ^ 0xFF);        // LED output

31

      PORTC  = (((i >> 6) ^ 0xFF) & 0x1F);

32

//      itoa( i >> 6 & 0x1F, s, 10);  // Device address

33

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

34

      myCount = 0;

35

    } else {

36

      if (myCount < 80000)

37

      {

38

        myCount++;

39

      } else {

40

        PORTB  = 0xff;

41

        PORTC  = 0xff;

42

        myCount = 0;

43

      }

44

    }

45

  }

46

}

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.

1

void zett(void)

2

{

3

  int mytrash;

4

  mytrash++;

5

}

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-Decoder_f%C3%BCr_ATMega#Schaltplan

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

1

if(i)

2

{

3

4

.....

5

6

}

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

1

#define PULSE_MIN (uint8_t)(XTAL / 512 * RC5TIME * 0.4 +0.5)

2

#define PULSE_1_2 (uint8_t)(XTAL / 512 * RC5TIME * 0.8 +0.5)

3

#define PULSE_MAX (uint8_t)(XTAL / 512 * RC5TIME * 1.2 +0.5)

in

1

#define PULSE_MIN (uint8_t)(F_CPU / 2048 * RC5TIME * 0.4 +0.5)

2

#define PULSE_1_2 (uint8_t)(F_CPU / 2048 * RC5TIME * 0.8 +0.5)

3

#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

1

.. * 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?