Datum: 23.03.2004 11:42
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
Datum: 23.03.2004 14:33
Klingt gut, werde ich direkt bei mir einbauen ;)
Datum: 24.03.2004 01:48
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
Datum: 24.03.2004 02:54
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
Datum: 23.04.2004 23:05
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
Datum: 13.05.2004 21:59
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
Datum: 13.05.2004 22:25
Datum: 14.05.2004 09:48
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
Datum: 08.06.2004 19:18
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
Datum: 08.06.2004 19:58
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
Datum: 08.06.2004 20:04
Achso, vielen Dank für den Hinweis. Alex
Datum: 30.09.2004 22:10
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
Datum: 01.10.2004 09:10
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
Datum: 01.10.2004 09:24
Hi, ok dann hab ich es richtig erkannt. Ich bedanke mich für deine kurze Bestätigung. Mfg Dirk
Datum: 05.10.2004 05:11
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
Datum: 06.10.2004 08:36
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
Datum: 06.10.2004 08:52
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
Datum: 06.10.2004 08:59
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
Datum: 06.10.2004 09:03
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
Datum: 06.10.2004 09:12
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
Datum: 17.11.2004 15:37
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.
Datum: 17.11.2004 21:48
#-) Brett vorm Kopf. xRC5 ist natürlich nicht der Pin sondern nur die Port-Pinummer, so macht es einen Sinn... Grüße D.E.
Datum: 19.11.2004 21:53
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
Datum: 19.11.2004 22:39
Hallo Walter, probier mal www.reichelt.de Da hatte ich mir ne TSOP1738 bestellt. Gruss Dominik
Datum: 16.01.2005 21:23
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 ?
Datum: 17.01.2005 10:16
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
Datum: 17.01.2005 19:54
Hi, da hilft www.google.de. Bei Atmel gibt es ein Appnote mit Source fuer ASM. Mfg Dirk
Datum: 17.01.2005 21:01
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 !
Datum: 18.01.2005 01:09
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
Datum: 18.01.2005 09:23
"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
Datum: 18.01.2005 09:32
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....
Datum: 18.01.2005 10:35
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.
Datum: 18.01.2005 10:52
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
Datum: 18.01.2005 11:06
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
Datum: 19.01.2005 10:27
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.
Datum: 24.01.2005 21:04
Funktioniert der Code mit dem ATMega8 ohne Änderungen? Ginge er auch mit Attinys? ich kann leider kein C!
Datum: 26.01.2005 22:29
Ich weis, ich hab hier ne ziemlich doofe Frage gestellt, aber wäre jemand trotzdem so nett zu antworten?
Datum: 27.01.2005 01:00
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
Datum: 27.01.2005 07:24
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
Datum: 27.01.2005 15:46
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!
Datum: 28.01.2005 07:46
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
Datum: 28.01.2005 22:04
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
Datum: 29.01.2005 00:45
??? 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 :-)
Datum: 29.01.2005 12:56
Hi! Ich dachte, der Atmel würde die Befehle über das UART ausgeben! Felix
Datum: 30.01.2005 22:17
Hi, ja, der Atmel sendet dann über den Uart. Hex File ist im Anhang. Der RC5-Pin ist PD2. Baudrate ist 9600. Gruss Andreas
Datum: 30.01.2005 22:37
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
Datum: 30.01.2005 22:50
Danke, werds übermorgen mal ausprobieren!
Datum: 01.03.2005 11:37
hallo, dieses programm ist gut gelungen und funktioniert. klasse, mfg pebisoft
Datum: 11.03.2005 09:51
hallo, bei mir funktioniert es tadellos. mich würde noch einmal eine senderoutine interessieren. danke mfg pebisoft
Datum: 25.03.2005 13:34
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
Datum: 25.03.2005 17:44
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.
Datum: 25.03.2005 18:12
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
Datum: 25.03.2005 18:12
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
Datum: 24.05.2005 22:49
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
Datum: 25.05.2005 01:43
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
Datum: 25.05.2005 01:45
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
Datum: 25.05.2005 09:52
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.
Datum: 25.05.2005 09:59
10000000e6 = 1e13 = 10000000000000Hz, das ist glaube ich etwas viel :) 10MHz wären 10e6 = 1e7
Datum: 03.06.2005 10:53
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
Datum: 03.06.2005 12:22
@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.
Datum: 03.06.2005 13:51
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
Datum: 04.06.2005 00:01
hallo, diese rc5-routine ist fehlerfrei. ein klasse programm. weiter so peter d. mfg pebisoft
Datum: 06.06.2005 13:28
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 ?
Datum: 06.06.2005 16:59
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).
Datum: 01.10.2005 20:40
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
Datum: 02.10.2005 11:20
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.
Datum: 02.10.2005 19:26
"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
Datum: 03.10.2005 13:23
@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!
Datum: 05.10.2005 13:49
Analysiere doch den gesendeten Code einfach. Wenn du kein Speicherscope hast, gibs auf den Soundkarteneingang. Habe ich auch gemacht, hat recht gut funktioniert.
Datum: 10.10.2005 10:37
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
Datum: 10.10.2005 10:43
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
Datum: 11.10.2005 11:42
@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?