mikrocontroller.net

Forum: Projekte & Code Fernbedien RC5 Empfänger


Autor: Peter Dannegger (peda)
Datum:
Angehängte Dateien:
  • rc5.zip (4,04 KB, 18437 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klingt gut, werde ich direkt bei mir einbauen ;)

Autor: Kai Markus Tegtmeier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Eddi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: schneidertobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian Schildt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, vielen Dank für den Hinweis.

Alex

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Shazter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

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

Mfg
Dirk

Autor: Ulf Timmerlade (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: D.E. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: D.E. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#-) Brett vorm Kopf.

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

Grüße

D.E.

Autor: Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dominik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Walter,

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

Gruss
Dominik

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Trägerfrequenz beträgt 36kHz.

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

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

Mfg
Dirk

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 !

Autor: Stefan Seegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: Stefan Seegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: D.E. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Seegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Hesse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: D.E. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: FeeJai (Gast)
Datum:

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

Autor: FeeJai (Gast)
Datum:

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

Autor: Stefan Seegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Hesse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: FeeJai (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Andreas Hesse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: FeeJai (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Seegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
???

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 :-)

Autor: FeeJai (Gast)
Datum:

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

Autor: Andrteas@andi-hesse.de (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

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

Gruss
Andreas

Autor: Stefan Seegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: FeeJai (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, werds übermorgen mal ausprobieren!

Autor: pebisoft (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo, dieses programm ist gut gelungen und funktioniert. klasse,
mfg pebisoft

Autor: pebisoft (Gast)
Datum:

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

Autor: max.p (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Malte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: max.p (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: DeltaEx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tobias Schneider (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tobias Schneider (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: DeltaEx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thorsten (Gast)
Datum:

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

10MHz wären 10e6 = 1e7

Autor: Daniel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Malte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: pebisoft (Gast)
Datum:

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

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Danilo Reinhardt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Danilo Reinhardt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: Danilo Reinhardt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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!

Autor: Jens (Gast)
Datum:

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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Danilo Reinhardt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :)

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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"?

Autor: Jens (Gast)
Datum:

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

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
kann ich auch einen TSOP 1738 (38kHz) benutzen ?
 Chris

Autor: Simon K. (simon) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hey.

Ich hab den Code eingebunden und ein wenig vom Einbau her verändert. Am
Code selbst habe ich nur in der Mainloop was verändert (mit
rc5_data_last).

Ich habe nun folgendes Problem:
Dürcke ich auf eine Taste, so erscheint das passende im
Terminalfenster. Drücke ich danach auf eine andere Taste, erscheint den
dazu passenden Code, jedoch mit dem Togglebit getoggelt. Ich weiß nicht
ob das richtig ist, aber mein nächstes Problem ist, halte ich eine
Taste gedrückt, kommt die Taste einmal an (mit getoggeltem Togglebit)
und dann garnichts mehr.

Der code ist im Anhang. Vielleicht will ja mal jemand kurz
drüberschauen.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Pete da Heat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ähm, ist das nicht so, dass bei langem drücken das Toggle Bit getoggelt
wird und bei einmal drücken das immer 0 oder 1 ist?

Autor: pebisoft (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Pete da Heat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ??

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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**

Autor: Hilel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hilel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat sich erledigt.
Danke.

Autor: André (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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é

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Frank,

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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Bärenmarke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Sebastian F.... (haseluenne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo! Da kein externer Interrupt benötigt wird, sollte der Pin egal
sein. Hab das jetzt aber nicht überprüft. Beschaltung steht bei den
Kollegen von
http://www.roboternetz.de/wissen/index.php/RC5-Dec...

Autor: Nik Bamert (Gast)
Datum:

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

Autor: karl-heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peppe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian Bäumler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Sebastian Bäumler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Clemens Schmiegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gehts noch ? (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein

Autor: Clemens Schmiegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Clemens Schmiegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hat sich erledigt... ich habs gepeilt...

Autor: Christina (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 =)

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Beschaltung ist ein TSOP17xy mit einem kleinem Kondensator zur 
Glättung in der Versorgungsspannung und der Ausgang direkt an den AVR 
geschaltet.

Autor: Christina (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke :)

Autor: Di Pi (drpepper) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich lese hier von TSOP1736 und TSOP1738...

Heißt das, dass es immer mit beiden Frequenzen (36 und 38kHz) 
funktioniert?

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"... 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

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg wrote:

> 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


Und was willst Du mit dem präzisen Zeitstempel anfangen, ihn ins Album 
kleben ?

Es reicht doch völlig, wenn man die Flanken eindeutig zuordnen kann.


Peter

Autor: Jörg (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg wrote:
> @Peter:
> Darin besteht doch die Decodierung, kurze und lange Pulse (=Differenz
> der Zeitstempel) zu unterscheiden.

Sach ich doch.
Eine übertriebene Genauigkeit ist also völlig unnötig.

Wenn ein Impuls 4..6 Zeitscheiben und der andere 8..12 breit ist, kannst 
Du schon klar erkennen, obs ein kurzer oder langer ist. Geeigneter gehts 
nicht.


Peter

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg wrote:

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

Der Schuß kann aber auch nach hinten losgehen.

Die Sensoren liefern auch gerne mal kurze Störimpulse, die würden dann 
sofort gecaptured.

Beim Sampeln ist die Warscheinlichkeit wesentlich geringer, daß so ein 
Störimpuls mit dem Sampletakt zusammen fällt.

Außerdem habe ich noch im Programm drin, daß zu kurze Impulse ignoriert 
werden und auf die nächste Flanke getriggert wird.

Nicht immer muß also ein zu schnelles Capture auch sinnvoll sein.


Du hast natürlich recht, daß andere Interrupts stören können, wenn sie 
zu lange dauern.


Peter

Autor: Jörg (Gast)
Datum:

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

Autor: Tobias Tezlaff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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


Autor: Tobias Tezlaff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Enrico Tabatzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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).

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin, ich hab mal eine kleine Frage zum Verständnis der 
Manchester-Codierung, die ja bei dem RC5 Protokoll benutzt wird.

Wenn ich das richtig sehe, ist die Kern-funktion diese:
#define  xRC5_IN    PIND
#define  xRC5    PD7      // IR input low active

uint8_t rc5_bit = 0;
uint8_t rc5_val = 0;

SIGNAL (SIG_OVERFLOW0)
{
  if( (rc5_bit ^ xRC5_IN) & 1<<xRC5 )
  {  
    rc5_bit = ~rc5_bit;

    rc5_val <<= 1;
    if( !(rc5_bit & 1<<xRC5) )  
      rc5_val |= 1;  
  }
}

Sprich: Jede Flanke wird gesampled und das Bit unten hereingeschoben.

Frage: Kann das so funktionieren? Ich glaube nämlich, dass die 
Zeiterkennung, die in deinem Code noch miteingebaut ein elementarer 
Bestandteil der Bit-erkennung ist und nicht nur Fehlerbehandlung.

In dem deutschen Wikipedia-Artikel zum Manchester-Code sieht man ein 
Beispielscode:
http://de.wikipedia.org/wiki/Manchester-Code

Hier sieht man nämlich eindeutig, dass nicht jede Flanke ein Bit 
darstellt. Sondern im Beispiel von zwei aufeinanderfolgenden nullen oder 
zwei einsen nur jede zweite flanke ein Bit darstellt.

Liege ich also richtig in der Annahme, dass man nicht einfach jede 
Flanke einlesen kann? Vielleicht habe ich ja noch irgendeinen Trick in 
deinem Code übersehen?

PS: Oder sollte ich lieber eine andere Decodierungsart wählen, wenn ich 
nur reinen Manchester decodieren will?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon Küppers wrote:

> Liege ich also richtig in der Annahme, dass man nicht einfach jede
> Flanke einlesen kann? Vielleicht habe ich ja noch irgendeinen Trick in
> deinem Code übersehen?

Stimmt, es wird nicht jede Flanke eingelesen:
if( rc5_time < PULSE_MIN )      // to short
      tmp = 0;


Peter

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:
> Simon Küppers wrote:
>
>> Liege ich also richtig in der Annahme, dass man nicht einfach jede
>> Flanke einlesen kann? Vielleicht habe ich ja noch irgendeinen Trick in
>> deinem Code übersehen?
>
> Stimmt, es wird nicht jede Flanke eingelesen:
>
>
> if( rc5_time < PULSE_MIN )      // to short
>       tmp = 0;
> 

Dank dir. Blöd ist nur, dass man im Vorhinein die Frequenz wissen muss, 
bzw. die Frequenz im Betrieb vom Manchester-Signal ableiten muss.
Du hast ja ersteres genommen.
Bei letzterem hätte man wieder das Problem, dass ein Timer für die 
Manchester-Geschichte draufgeht, da man ja immer unterschiedlich 
reloaden muss.

Autor: Lars Lochmann (Gast)
Datum:
Angehängte Dateien:

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

Autor: zett (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lars Lochmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: zett (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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;
      }
    }
  }
}

Autor: Lars Lochmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: zett (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lars Lochmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: zett (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: zett (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zett wrote:

> Also die itoa Zeilen habe ich auskommentiert. Dafür habe ich aber eine
> dummy Funktion gebaut die nichts sinnvolles oder Zeit intensives macht.
>
> Dann geht das ganze auch. Warum weis ich aber immer noch nicht.

Versuch mal:
volatile uint rc5_data;

Der GCC hat die unangenehme Eigenschaft, Zugriffe auf globale Variablen 
wegzuoptimieren.
Der Aufruf einer externen Funktion hindert ihn daran, da diese ja die 
Variable ändern könnte.

Ich falle da auch regelmäßig drauf rein.

In MC-Programmen ist es allerdings gang und gäbe, daß Interrupts globale 
Variablen ändern.
Der Keil C51 optimiert diese daher grundsätzlich nicht weg.
Die Optimierungen des GCC sind jedoch vorrangig auf größere CPUs 
ausgelegt, d.h. Mikrocontroller typische Programmabläufe fallen da etwas 
hinten runter.

Rein formal entspricht das aber dem C-Standard, daher wird sich daran 
auch nichts ändern.
Man würde daher am liebsten sämtliche Variablen als volatile definieren, 
allerdings wird dann die Optimierung ausgeschaltet.

Es hilft also nichts, man muß beim GCC immer ein wachsames Auge haben 
und bei derartigen Effekten darauf prüfen. Auch wenn ulkige Effekte nach 
einem Compilerupdate auftreten, liegt das oft an einer 
volatile-Fallgrube.

Wenn Du etwas Assembler kannst, hilft es auch, sich das Listing 
anzusehen. Dann sieht man schnell, wenn etwas unerwünscht wegoptimiert 
wurde.


Peter


P.S.:
Vielleicht erbarmt sich ja mal ein GCC-Guru und generiert wenigstens ne 
Warnung, wenn "Code possible without effect" auftritt, also ne Schleife 
ne Variable auswertet, die sich aus GCC-Sicht "nie" ändert.

Autor: zett (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Coder (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Meyer (dirkm)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

versuche seit mehreren Stunden den RC5 Code zum laufen zu bekommen..

Leider bisher ohne Erfolg :-(

Das "RC5-Dekoder:" beim Start wird normal gesendet aber es kommen keine 
Codes..

Verwende einen ATTiny2313@16Mhz Quarz und einen TSOP1136.

Musste für den ATTiny etwas bei dem Timer anpassen, denke mal da liegt 
auch irgendwo der fehler :-/

Ware super nett wenn jemand eine Idee hat bzw sich mal den Quellcode 
anschaut :-)

Gruß
Dirk

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sicher, dass deine Fernbedienung RC5 kodiert sendet?

Autor: EDAconsult Udo Kuhn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: sven s. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ein 100nf an alles dran so wie man das auch machen sollte bringts auch.

gruss sven

Autor: Rainer Milenski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Holger Krull (krulli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Rainer Milenski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke!!! :-)

Autor: Torny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Jens R. (jeronnimo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Torny,

send mir Deine Mail Adresse (jeronnimo39@hotmail.de), dann kann ich Dir 
meinen C Code für RC5 senden. Ich habe gerade was ähnliches 
programmiert, läuft super. Zwar mit MEGA8 aber die Anpassungen sind ja 
nur marginal.

Gruß Jens

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus Peter

Herzlichen Dank für Deinen Beitrag.
Nur als ich keine Befehl-Codes empfangen konnte, die grösser als 63 
waren, stiess ich auf die Zeile
itoa((i & 0x3F) | (~i >> 7 & 0x40), s, 10); // Key Code

Meiner Meinung nach müsste es aber
 .... (~i >> 6 & 0x40) .... 
lauten.

Soweit ich weiss, wird ja das 2. und nicht das 1. Startbit als 7. 
Command-Bit verwendet.

Autor: Neuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Kai G. (runtimeterror)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PIND ist der 8-Bit-Port selbst
PD7 ist die Nummer des Pins an dem besagten Port

Autor: Neuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

würde das dann bei einem 8051 so aussehen?

P0.7 Nummer des Pins
P0 8bit Port

Autor: Kai G. (runtimeterror)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich kenne den 8051 nicht, scheint aber dasselbe auszudrücken.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Neuling wrote:
> Hi,
>
> würde das dann bei einem 8051 so aussehen?
>
> P0.7 Nummer des Pins
> P0 8bit Port

Der AVR-GCC kennt keine SBITs, daher die Schreibweise mit Masken.

Schreib statt PIND, P0 und statt PD7 dann 7 für P0.7


Peter

P.S.:
Man kann dem AVR-GCC SBITs beibringen, aber das habe ich erst später 
gemerkt.

Autor: TobyTetzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TobyTetzi wrote:

> Ich brauche eigentlich nur 6 Bit zur Steuerung meines Projektes.

Erzähl doch einfach mal, was Du an dem Code nicht verstehst, um die 
Änderungen selber zu machen.


Peter

Autor: TobyTetzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernhard (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TobyTetzi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TobyTetzi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So,

hier nun der IR Sender.

Gruß Toby

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard wrote:
> Jedoch komme ich nie in die
>
> if(i)
> {
> 
> .....
> 
> }
> 
>
> Schleife.


Kein Wunder.
Erstens kannst Du nie 1µs Interruptrate erreichen, weil der Code schon 
länger dauert.
Zweitens ist das Quatsch mit Soße.
Lies Dir mal diese Zeile durch:

#define RC5TIME   1.778e-3    // 1.778msec

Du mußt also ne Interruptrate haben, die mindestens die Hälfte ist (zum 
abtasten) aber nur so groß, daß die Vergleichswerte in ein Byte passen.
Und dann mußt Du die darunter liegenden Vergleichswerte anpassen, da die 
Rate ja nicht 512 beträgt.
Z.B. ne Interruptrate von 0,18ms paßt gut.

Und nimm den Reloadmodus, sonst mußt Du ne 16Bit Addition zum Reload 
machen oder Du kriegst nen riesen Fehler.
Ein Reload am Ende des Interrupts ist besonders schlecht (maximaler 
Fehler).

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

Ja

Peter

Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernhard (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Entschuldigt,hab das Programm vergessen.


Bernhard

Autor: TobyTetzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard wrote:

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

Ja das RC5 ist warscheinlich tot, d.h. keine aktuellen Geräte benutzen 
es mehr.
Inzwischen wird ja alles in China hergestellt und die benutzen für 0 und 
1 kurze und lange Impulse (wie Morsecode) und erstmal nen extra langen 
als Startbit.

Eventuell mal ne Universal-FB probieren.

Mein Programm ist so ausgelegt, daß es alles, was nicht RC5 ist, 
verwirft.


Peter

Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lorenz .. (lorenz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir tut eine Universalfernbedienung (mit Philips-Gerät 
eingestellt)prima. Habe auch mehrere original Philips-Fernbedienungen 
getestst - tut prima. Egal ob Receiver, TV oder DVD-Codierung.

Autor: technikus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

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

technikus

Autor: Matthias (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso hab ich ganz vergessen!
interner Takt = 8MHz

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter:
for(;;)
{
   EA = 0; //entspricht cli(); 
   i = rc5_data;
   rc5_data = 0;
   EA = 1; //entspricht sei(); 
   if(i)
   {

rc5_data = 0 ist doch ein erlaubtes RC5-Kommando (addr=0 (TV), flip=0, 
cmd=0). Hier würde besser 0xffff als Leerwert dienen oder ein anderer 
Wert, dir kein gültiges RC5-Frame darstellt.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias: 0xffff wird Deinen Fehler nicht beheben.

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

Das ist gleichbedeutend mit
    Keycode = 10;

Autor: Frank Link (franklink)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard wrote:
> 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.

Ich habe die Routine von Peter schon sehr lange im Einsatz, ich verwende 
pauschal die Codierung 1112 von Phillips. Da ist die Steuerung für AMPs.
Als FB setzte ich eine 8 in 1 vom blauen C ein.

Gruß
Frank

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: roboter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
roboter wrote:
> wie weiss man eigentlich aus der rc5-routine, wann das ir-signal
> anfängt?
>
> ich sehe keinen interrupt, sondern nur eine timer-überlaufroutine.

Das Geheimnis liegt hier:

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

Damit wird erkannt, ob sich der Pegel seit dem letzten Interrupt 
geändert hat.
Und dann wird mitgezählt, wann er sich wieder ändert.
Ist diese Zeitdauer im gewünschten Bereich, wird angenommen, daß es ein 
RC5-Signal ist und die einzelnen Bits eingeschoben.


Peter

Autor: Felix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: roboter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
warum testest ud deinen code nicht?

ist doch einfacher wie das fragen.

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

Autor: Felix (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Felix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niemand? :-(

Bin für jeden Tipp dankbar

Autor: Hive (Gast)
Datum:

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

Autor: Hive (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hive (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es ist natürlich
.. * RC5TIME * ..

Autor: Hive (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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")

Autor: Baugatz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: steve (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: bottle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@steveläßtsichfurchtbarschlechtlesendeintext.

Autor: Steffen O. (derelektroniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe den Thread jetzt nicht ganz gelesen, daher weiß ich auch nicht, 
ob es irgendwo schon geschrieben wurde: Ich hab vor einiger Zeit bei 
Conrad mal einen TSOP gekauft, weiß aber nicht genau, welchen. Die 
unterscheiden sich ja nur in der Frequenz. Was beeeinflußt diese 
Frequenz, und muss ich die jeweilige Frequenz von meinem Empfänger 
wissen?
Ansonsten, die Beschaltung ist doch von GND des Empfängers zu VS einen 
100nF Kondensator, und in die VS- Leitung einen 100 Ohm Widerstand, 
oder?

Vielen Dank schon einmal im Voraus.
Gruß, Steffen

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Probiers es einfach mal mit der 38Khz Version. Ist die Frequenz höher 
oder niedriger wirst du auch einen Empfang haben, nur schlechter. Wenn 
ich das Datenblatt richtig lese läge die Empfindlichkeit bei 36kHz immer 
noch bei 70%  der genau passenden 38Khz.

Autor: Steffen O. (derelektroniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, was ich vergessen hatte: Benötige ich einen Baudratenquarz, oder 
kann ich den µC mit 4Mhz takten?
Und: Kann ich als Baudrateneinstellung auch 9600 Baud verwenden?

Vielen Dank schon einmal im Voraus.
Gruß, Steffen

Autor: Steffen O. (derelektroniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch was: Ist das Programm 100% kompatibel zum ATmega8? Oder muss ich da 
noch was an den UART- EInstellungen ändern?
Und, kann es zu komplikationen mit der UART- lib von Peter Fleury 
kommen?


Vielen Dank schon einmal im Voraus.
Gruß, Steffen

Autor: Steffen O. (derelektroniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe es nun auch geschafft, der Empfänger funktioniert einwandfrei - 
Danke Peter!!!
Ich verwende den Code mit TSOP 1736 an PC5, bei mit 4Mhz getaktetem 
Mega8, und mit 9600 Baud. Klappt ohne Probleme!
Jetzt muss ich nur noch den Code ein wenig umschreiben, dass eben am PC 
nur eine 1, oder 2, usw. ankommt, also nicht immer 101, oder so, da ich 
es am PC mit einem selbstgeschriebenem Programm auswerten will.

Gruß, Steffen

Autor: Valerian Stenske (val)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen!

Bei mir läuft die ISR von Peter einwandfrei!

Und die Decodierung reiner "1" Bitfolgen kann ich nachvollziehen. Doch 
wie wird eine "1" gefolgt von einer "0" decodiert, das es ja keinen 
Flankenwechsel zwischen den beiden Bits gibt!!! Folglich wird rc5_time 
nicht zurückgesetzt und es müsste tmp=0 weden, weil für

rc5_time>RCTIME_1_2

die

if((rc5_bit^xRC5_IN)&1<<xRC5) - Bedingung nicht erfüllt wird.

Es ist doch richtig, dass nach der Mittelflanke von "1"

rc5_bit=xRC5_IN=xRC5=1 sind bis dann die nächste Flanke (Mitte von "0") 
kommt oder?

Für eine Erklärung wäre ich sehr dankbar!

Gruss

Autor: Richard B. (rbrose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

der Code funktioniert bei mir wunderbar. Danke!
Habe aber eine Frage. Und zwar will ich NUR erneut gedrückte Tasten 
rausfiltern. Das heißt also wen ich eine Taste gedrückt halte ... soll 
es aber nur 1 mal empfangen. Und dann wieder bei nächsten drücken.

Das halten einer Taste soll unterdrückt werden.

Wie mach ich das? Wie prüfe ich das Togglebit?

Autor: Richard B. (rbrose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das so gemacht:
    toggle_tmp = i >>11 & 1;
    if(toggle_tmp == old_toggleBit) 
    {
      i = 200;
    }
    
    old_toggleBit= i >>11 & 1;

Aber so wird jede zweite gedrückte Taste unterdrückt :-(

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richard B. wrote:
> Hallo zusammen,
>
> der Code funktioniert bei mir wunderbar. Danke!
> Habe aber eine Frage. Und zwar will ich NUR erneut gedrückte Tasten
> rausfiltern. Das heißt also wen ich eine Taste gedrückt halte ... soll
> es aber nur 1 mal empfangen. Und dann wieder bei nächsten drücken.
>
> Das halten einer Taste soll unterdrückt werden.
>
> Wie mach ich das? Wie prüfe ich das Togglebit?

Toggle-Bit merken und Befehl nur weiter verarbeiten, wenn es sich 
geändert hat? Das änder sich ja auch, wenn eine andere Taste gedrückt 
wird, nicht nur beim Neu-Drücken der gleichen Taste. Hier kannst du in 
der main.c gucken wie ich das auf dem MSP430 gemacht hab: 
Beitrag "Fernbedien RC5 Empfänger mit MSP430" wollte das nämlich für 
DVBViewer Bedienung auch so haben.

Autor: Richard B. (rbrose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

vielen Dank für den Hinweis.
Habe das jetzt auch so wie bei dir gemacht ... aber leider wir ein 
weiter Tastendruck ausgegeben wenn ich die Taste halte. Und nicht nur 1 
mal :-(
Sieht jemand vielleicht den Fehler?
int main(void)
{  
  uint16_t i;
  uint8_t x;

  volatile uint8_t Command;
  volatile uint8_t Address;
  volatile uint8_t Toggle;


  uint8_t LastCommand;
   uint8_t LastAddress;
   uint8_t LastToggle;


    // uart_init(UART_BAUD_SELECT(19200, F_CPU));
  rf12_init();          // ein paar Register setzen (z.B. CLK auf 10MHz)
  rf12_setfreq(RF12FREQ(433.92));  // Sende/Empfangsfrequenz auf 433,92MHz einstellen
  rf12_setbandwidth(4, 0, 0);    // 200kHz Bandbreite, -6dB Verstärkung, DRSSI threshold: -79dBm 
  rf12_setbaud(19200);      // 19200 baud
  rf12_setpower(0, 5);      // 1mW Ausgangangsleistung, 120kHz Frequenzshift

  
  DDRD = 0xFF;   // Output 
  PORTD = 0xFF; //am Anfang alles aus

  DDRB |= ( 1 << DDB0) | ( 1 << DDB1 ) | ( 1 << DDB2 ); //Anzeige wählen Output

  PORTB |= (1 << PB0); 
  PORTB &= ~(1 << PB1);  
  PORTB &= ~(1 << PB2);   


    ///Timer for IRC5
   TCCR0B = (1<<CS02);      //divide by 256    
  TIMSK |= (1<<TOIE0);      //enable timer interrupt

  sei();

  while(1) 
  {    

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

    Command = (uint8_t)i & 0x3F;      //Dekodieren
    Address = (uint8_t)((i >> 6) & 0x1F);
    Toggle = (uint8_t)((i >> 11) & 0x01);

    if((LastCommand == Command) && (LastAddress == Address))
    {
      if(LastToggle == Toggle)  //Prüfung auf Änderung des Toggle-Bits
      {
        i=200;
      }
    }


    for(x=1;x<10;x++)
    {
      if( get_key_press(i, x) )
      {                      
        if(liednummerCount < 4)
        {
          liednummer =  liednummer*10+x;
          liednummerCount++;        
        }                
      }
    }  

    if( get_key_press(i, 0) )
    {      
      if(liednummerCount < 4 && liednummerCount > 1)
      {
        liednummer =  liednummer*10+0;
        liednummerCount++;
      }                  
    }

    if( get_key_press(i, 13) )
    {            
      liednummer =0;
      liednummerCount = 1;      
    }
    if( get_key_press(i, 46) )
    {      
      convertIntToSendString();            
    }

    

    if(liednummer == 0)
    {
      currentSeg1 = pgm_read_byte(&c_led[10]);   
      currentSeg2 = pgm_read_byte(&c_led[10]);
      currentSeg3 = pgm_read_byte(&c_led[10]);   
    }
    else if(liednummer > 0 && liednummer < 10)
    {
      currentSeg1 = pgm_read_byte(&c_led[liednummer]);   
      currentSeg2 = pgm_read_byte(&c_led[10]);
      currentSeg3 = pgm_read_byte(&c_led[10]);   
    }
    else if(liednummer > 9 && liednummer < 100)
    {
      uint16_t showDigits10[2];
      getDigits(liednummer,showDigits10,2);

      currentSeg1 = pgm_read_byte(&c_led[showDigits10[1]]);   
      currentSeg2 = pgm_read_byte(&c_led[showDigits10[0]]);
      currentSeg3 = pgm_read_byte(&c_led[10]);   
    }
    else if(liednummer > 99 && liednummer < 1000)
    {
      uint16_t showDigits100[3];
      getDigits(liednummer,showDigits100,3);

      currentSeg1 = pgm_read_byte(&c_led[showDigits100[2]]);   
      currentSeg2 = pgm_read_byte(&c_led[showDigits100[1]]);
      currentSeg3 = pgm_read_byte(&c_led[showDigits100[0]]);   
    }  
    
    //Letzten Tastendruck speichern

    LastCommand = Command;
    LastAddress = Address;
    LastToggle = Toggle;
              
  }
}

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum setzt du das i=200 bei gleichem Toggle Bit? Und deine main 
Schleife arbeitet doch trotzdem immer alles durch, egal, ob da eine neue 
Taste gedrückt wurde oder nicht?
Du musst halt gucken, ob LastToggle ungleich Toggle ist, und erst dann 
dein restlichen Zeugs abarbeiten.
Und wieso i=200 bei i=0? Gibts keine Fernbedienung mit GeräteCode 0 und 
Befehl 0? Was ist mit Taste "0" beim TV?

Autor: Richard B. (rbrose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. wrote:
> Warum setzt du das i=200 bei gleichem Toggle Bit? Und deine main
> Schleife arbeitet doch trotzdem immer alles durch, egal, ob da eine neue
> Taste gedrückt wurde oder nicht?

Richtig. In der Main-Schleife wird alles abgearbeitet. Ich setze i=200 
weil der Befehl 200 nicht kommt von der Fernbediegung.
Ich brauche NUR die Tasten 0 bis 9, Taste 13 und die Taste 46. Wenn ich 
i auf 200 setze wird keine Zahl hinzugefügt!

> Du musst halt gucken, ob LastToggle ungleich Toggle ist, und erst dann
> dein restlichen Zeugs abarbeiten.
> Und wieso i=200 bei i=0? Gibts keine Fernbedienung mit GeräteCode 0 und
> Befehl 0? Was ist mit Taste "0" beim TV?

Nein gibt es nicht.
Das Problem wieso ich es nicht so mache:
  if((LastCommand == Command) && (LastAddress == Address))
  {
    if(LastToggle != Toggle)  //Prüfung auf Änderung des Toggle-Bits
    {
      for(x=1;x<10;x++)
      {
        if( get_key_press(i, x) )
        {                      
          if(liednummerCount < 4)
          {
            liednummer =  liednummer*10+x;
            liednummerCount++;        
          }                
        }
      }  

      if( get_key_press(i, 0) )
      {      
        if(liednummerCount < 4 && liednummerCount > 1)
        {
          liednummer =  liednummer*10+0;
          liednummerCount++;
        }                  
      }

      if( get_key_press(i, 13) )
      {            
        liednummer =0;
        liednummerCount = 1;      
      }
      if( get_key_press(i, 46) )
      {      
        convertIntToSendString();            
      }  
    }
  }
  else    //Direkte Ausgabe, wenn neue Taste gedrückt
  {
    for(x=1;x<10;x++)
    {
      if( get_key_press(i, x) )
      {                      
        if(liednummerCount < 4)
        {
          liednummer =  liednummer*10+x;
          liednummerCount++;        
        }                
      }
    }  

    if( get_key_press(i, 0) )
    {      
      if(liednummerCount < 4 && liednummerCount > 1)
      {
        liednummer =  liednummer*10+0;
        liednummerCount++;
      }                  
    }

    if( get_key_press(i, 13) )
    {            
      liednummer =0;
      liednummerCount = 1;      
    }
    if( get_key_press(i, 46) )
    {      
      convertIntToSendString();            
    }
  }

ist weil es viel zu viel Speicher wegnimmt und mein AVR schon fast voll 
ist:
AVR Memory Usage
----------------
Device: attiny2313

Program:    2020 bytes (98.6% Full)
(.text + .data + .bootloader)

Data:         31 bytes (24.2% Full)
(.data + .bss + .noinit)


Deshalb muss ich es mit einem Flag machen. Und i=200 ist das Flag für 
die For-schleifen das die nicht true sind.

Die Frage ist ... wieso ich sowieso bei gehaltenen Taste die Tasten 
werte alle bekomme.

Autor: Benjamin A. (beni0664)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also jetzt gebe ich auch nochmal meinen Senf dazu ;-)!

@peter d.

Danke für den super Code!

Nur einen kleinen Verbesserungs vorschlag hätte ich noch:
 TCCR0 = 1<<CS02;      //divide by 256
  TIMSK = 1<<TOIE0;      //enable timer interrupt

  UBRRL = bauddivider;      //set baud rate

Ich würde hier nur das entsprechende Bit setzen, sonst überschreibt man 
alle event. schon vorhandenen Flags!

Also so:
 TCCR0 |= (1<<CS02);      //divide by 256
  TIMSK |= (1<<TOIE0);      //enable timer interrupt

  UBRRL = bauddivider;      //set baud rate


mfg beni

Autor: Juris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Code aus dem allerersten Post dieses Threads habe ich auf das Pollin 
Funk AVR Board angepasst. µC ist ein Attiny2313 bei 8 MHz:
http://www.mikrocontroller.net/articles/Pollin_Fun...

Autor: Jan -- (Firma: --) (bravo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute !
Sehr Interressant.
Hat auch einer eine RC5 Senderoutine fertig ?
So eine Art Lernbare Fernbedienung ?
Oder hat jeman ein Tipp wie ich da dran gehen soll?

Danke für jede Hilfe.
Jan

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Di Pi (drpepper) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Neue Frage, gleiches Thema:

Was tut die Zeile
  TCNT0 = -2;     // 2 * 256 = 512 cycle
?
Wieso wird ins TIMER-Count Register eingegriffen?

Ich möchte den Timer2 eines AtMega88 für rc5 und Sekundenerzeugung 
zusammen benutzen, und bin mir unsicher über den Prescaler, den ich 
wählen sollte.
Momentan verwende ich den Prescaler 256 auf 8MHz und erzeuge Sekunden so 
(Timer2 zählt nur bis 250):
ISR (TIMER2_OVF_vect) {
  if(t1 < 125) {
    t1++;
  }
  else {
    t1 = 0;
    newsecond = 1;
  }
}

Autor: David (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: C. D. (schnack)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
habe mich als AVR-Neuling ein paar Tage mit dem Code (und dem STK600) 
gequält. Nach ein paar ärgerlichen Anfängerfehlern, kam ich schließlich 
dahinter, daß der Tipp weiter oben, die Variable "rc5_data" als volatile 
zu deklarieren, der Schlüssel zum Erfolg war - ich verwende den avr-gcc 
in der Version 4.3.2. Ich kann mich für den Tipp nur bedanken, für den 
Code ohnehin ;-) Dies hat mir wirklich ein Erfolgserlebnis gegeben!

Grüße
schnack

Autor: Richard B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

beinhaltet rc5_data alle RC5 Bits?
Also

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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richard B. schrieb:
> Hallo Peter,
>
> beinhaltet rc5_data alle RC5 Bits?
> Also
>
> ein Toggelbit (abwechselnd "1" oder "0")
> 5 Adressbits
> 6 Kommandobits

Ja.

Peter

Autor: C. D. (schnack)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,
für das HCAN Hausautomatisierungsprojekt (http://www.iuse.org/) würde 
ich gerne den Empfänger-Code  - ein wenig modifiziert - einbringen.
Ich würde natürlich den Urhebervermerk belassen, ergänzt um einen 
Änderungsvermerk.
Die HCAN-Automatisierung steht unter GPL. Ich bin kein Anwalt, deshalb 
frage ich mich, ob ich die so entstandene SW dort "contributen" kann.

Das gleiche gilt auch für Deinen DCF77-Code in 
Beitrag "DCF77-Uhr mit ATTINY12".

Gibt es von Deiner Seite Bedenken?
Grüße
Christoph

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. D. schrieb:

> Gibt es von Deiner Seite Bedenken?

Nein.
GPL ist o.k.


Peter

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo hier eine kleine Verbesserung für alle, die den Code mit hoher 
Taktfrequenz verwenden:
#define PULSE_MIN  (uchar)(F_CPU / 2048 * RC5TIME * 0.4 + 0.5)
#define PULSE_1_2  (uchar)(F_CPU / 2048 * RC5TIME * 0.8 + 0.5)
#define PULSE_MAX  (uchar)(F_CPU / 2048 * RC5TIME * 1.2 + 0.5)

TCNT2 = -8;          // 8 * 256 = 2048 cycle

dies sorgt bei 16MHz dafür, dass nicht ganz so viele Takte nur für den 
RC5 Empfang verbraten werden. Mit einem Teiler von 4096 wollte der Code 
leider nur noch sporadisch laufen, somit sollte bei 8MHz maximal ein 
Teiler von 1024 funktionieren.

Der Grund für die Änderungen ist der:
Fügt man einen Funktionsaufruf ein, der die dekodierten Daten entgegen 
nimmt (statt der globalen Variable), sichert der Compiler jedes mal 
zusätzliche Register (auch wenn die Funktion nur selten wirklich 
aufgerufen wird). Somit wird dann der ursprüngliche Code alle ~556 Takte 
aufgerufen (512 Takte + Register sichern) und braucht zum Durchlauf ~100 
Takte. Somit ist der AVR 1/5 aller Takte nur damit beschäftigt auf rc5 
Starts zu achten. Bei mir kommt noch hinzu, dass der Stack im 
langsamerem externen RAM liegt und er somit alle ~588 Takte aufgerufen 
wird und ~164 Takte zum Durchlauf braucht = ~28%. Das war natürlich viel 
zu viel. Die obige Änderung reduziert den Anteil bei mir erstmal auf 
7,7%. Ich würde den Anteil gerne noch auf unter 1% drücken, mal sehnen 
ob sich da noch ein Weg findet.

Der sich durch das Register sichern aufsummierende Messfehler der Zeiten 
wird ebenfalls reduziert.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Malte __ schrieb:
> Fügt man einen Funktionsaufruf ein, der die dekodierten Daten entgegen
> nimmt (statt der globalen Variable), sichert der Compiler jedes mal
> zusätzliche Register (auch wenn die Funktion nur selten wirklich
> aufgerufen wird).

Ja, Funktionsaufrufe in Interrupts sollte man vermeiden.

Aber wenn es unbedingt sein muß, gib einfach den SPM-Interrupt frei und 
packe da dann Deine Funktion rein.
Der SPM-Befehl ist ja im Applikations-Flash wirkungslos und somit läßt 
sich dessen Interrupt prima als SW-Interrupt nutzen.


Peter

Autor: Christian T. (shuzz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wollte mich bei Peter gerne für den Code bedanken.

Funktioniert absolut problemlos zusammen mit einer RGB-PWM Routine.

Ursprünglich war der Plan, sowohl der PWM als auch der RC5-Erkennung 
jeweils nen eigenen Timer zu spendieren, aber das hat aus mir 
unerfindlichen Gründen nicht geklappt.

Nun habe ich beides in einem Timer laufen und es funktioniert wunderbar!
(PWM wird bei jedem Overflow abgearbeitet, RC5 nur bei jedem vierten, 
basierend auf dem Tipp von Malte.)

Momentan führt das Empfangen einer gültigen RC5-Sequenz lediglich zum 
ein- bzw. ausschalten der PWM, die Codes selbst werden (noch) nicht 
unterschieden.

Der Grund ist einfach: Ich habe keine Ahnung wie die Codes welche von 
der FB kommen aussehen... ^^

Deshalb noch eine Frage in die Runde: Hat jemand ne Idee wie ich die 
Werte nun am geschicktesten lesbar mache? Ich habe leider keinen Max232 
o.Ä. verfügbar, daher scheidet UART leider aus.
Ich tendiere zu zwei Schieberegistern und ner Latte von LEDs, somit 
könnte ich die entstehenden Bitmuster einfach per #define in meinen Code 
übernehmen.
Aber vllt. hat jemand von euch ja noch ne bessere Idee. UART wäre ja 
schon schick, aber ich fürchte das geht nicht nur mit ein paar 
Widerständen oder? ;)

Autor: Di Pi (drpepper) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.stefan-buchgeher.info/elektronik/rc5/rc5.html

hier steht zuminddest drin, was bei welchem knopf aus der FB rauskommt.

das hilft dir vllt. weiter :)

Autor: Christian T. (shuzz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dank an den Doktor, aber vermutlich wird mir das nicht weiterhelfen.

Die FB die ich verwenden möchte ist ein Fernost-All-in-one-teil mit 
Ein-Knopf-Programmierung... ^^

D.h. mein Plan ist, zunächst die FB so einstellen dass sie RC5 "spricht" 
und dann auszuknobeln welche Codes von welchen Tasten kommen.

Ich hoffe, das wird halb so wild. Auf dem Steckbrett daheim ist bereits 
alles aufgebaut, jetzt muss ich "nur" noch mitschreiben. ;)

Aber für alle (zukünftigen) Fälle hab ich mir mal ein paar MAX232 bei 
Maxim geordert, dann bin ich für die nächste FB gerüstet. ^^

Autor: Johannes T. (johnsn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe den Programmcode auch erfolgreich getestet. Allerdings habe ich 
mehrere Stunden gebraucht, bis ich kapiert hab, dass meine Samung RC 
keine RC5 Codes schickt, sondern auch was proprietäres.

Kennt jemand die genauen Codes von Samsung?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast schrieb:
> Fehlerquellen:
>  Sendeleistung reicht nicht
>  Sichtverbindung blockiert und keine Reflexion
>  Empfänger gestört (durch IR oder EMV z.B. Leuchtstofflampe, Sonne)
>
> Sonst noch was?
Interrupt wird möglicherweise zu lange durch einen andere Interrupt 
blockiert, so dass die Zeiten nicht mehr stimmen.
Abhilfe:
1. Statt Overflow, Compare Interrupt verwenden und 2. Clear Timer on 
Compare benutzen, damit sich Verzögerungen wenigstens nicht aufaddieren.

Autor: pille1990 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pille1990 schrieb:
> 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?

Ja.

Peter

Autor: dtm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Habe ich da etwas übersehen?
Nein.
Durchlaufen wohl eher in der Form, dass der Zähler durchgängig läuft, 
also nicht angehalten wird, wenn nichts zu empfangen ist.
Wenn du den Vorteiler kleiner setzt, kannst du den Timer aber problemlos 
über einen größeren Bereich laufen lassen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Malte __ schrieb:
> Wenn du den Vorteiler kleiner setzt, kannst du den Timer aber problemlos
> über einen größeren Bereich laufen lassen.

Neuere AVRs haben auch T0-Compare-Interrupts, damit kann man dann 
kleinere Intervalle erzeugen und weiterhin den Overflow erst nach 256 
Zyklen.


Peter

Autor: dtm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Neuere AVRs ...

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

Autor: dtm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dtm schrieb:
> Der Mega168 gehört nicht dazu, oder?

Doch: "Timer/Counter0 Compare Match A und B"


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dtm schrieb:
> OC-Match Interrupt aktivieren, und das OC-Register bei jedem Aufruf der
> Interruptroutine um 2 (natürlich vom Prescaler abhängig) zu erhöhen.

So war das gemeint.

Peter

Autor: Kai E. (kai20)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hätte eine Frage an Peter bzgl der Auswerteroutinean zu der Stelle,
wo eine 1 reingeschoben wird, die restlichen Anweisungen sind klar.

 if( !(rc5_bit & 1<<xRC5) ) tmp |= 1;  // inverted bit and insert new 
bit

Diese Abfrage wird doch nur ausgeführt, wenn eine lange Bitzeit erkannt 
wurde.
Wenn jetzt die fallende Flanke einer kommenden '1' erkannt wird und 
zuvor eine '0' kam, war es eine lange Bitzeit und eine '1' wird zu Recht
reingeschoben (rc5_bit hat doch dann den Wert 0x00).

Habe ich aber z.B. 3 aufeinanderfolgende Einsen, habe ich eine kurze 
Bitzeit vor der fallenden Flanke, also komme ich doch gar nicht zu 
dieser Abfrage,
aber wo schiebe ich dann für diesen Fall eine '1' rein ?

Ich sehe es einfach nicht,
Kai

Autor: Ratlos (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Kai E. (kai20)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ratlos,

bin zwar auch nur Anwender, aber setze halt XTAL auf 3.68MHz,
dann bekommst du ca. alle 139us einen Timer IRQ.
Dann ergibt sich PULSE_MIN zu 5, PULSE_1_2 zu 10 und PULSE_MAX zu 15.
5*139us ist kleiner als die halbe Bitzeit und 10*139us waere
entweder eine kurze oder lange Bitzeit.

Sollte so klappen,
Kai

Autor: Ratlos (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Di Pi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
code?

Autor: Ratlos (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Di Pi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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; 

Autor: Kai E. (kai20)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiss nicht, ob WINAVR alle Pins auf Eingang initialisiert,
sonst setze mal PD7 auf input und aktiviere den internen Pullup
deines uC (der TSOP1736 hat 100kOhm pullup).
RC Filter an der Versorgung des TSOP1736 ist vorhanden ?

Sonst prüfe doch mal, ob die Timer IRQ überhaupt ausgeführt wird, zähle 
z.B. eine variable in der timer irq hoch und lasse sie im terminal 
ausgeben, oder auf den LEDs.

Ich habe einige FBs gehabt, von denen ich dachte, sie würden RC5 senden, 
haben sie aber nicht.

Grüße,
Kai

Autor: Di Pi (drpepper) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bin nicht ganz sicher: aber vielleicht optimiert der compiler dein 
rc5_data auch weg, weil es nicht als volatile deklariert ist.

Autor: Christian S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/crt 
m8.o:(.init9+0x0):  undefined reference to `main'

Jemand ne Idee woran das liegen kann??

mfg Christian

Autor: John Doe (Gast)
Datum:
Angehängte Dateien:
  • preview image for fb.png
    fb.png
    14,8 KB, 1018 Downloads

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
John Doe schrieb:
> Garnicht so einfach heutzutage eine FB mit RC5 Code zu finden.

Das stimmt allerdings. RC5 ist ziemlich tot.

Alternative wäre IRMP: http://www.mikrocontroller.net/articles/IRMP

Das erkennt so ziemlich jedes IR-Protokoll, was heutzutage so 
rumschwirrt.

> Könnte mal jemand der sich damit auskennt überprüfen ob meine FB
> standardkonformes RC5 sendet?

Das sieht wirklich wie RC5 aus, bei den meisten anderen FB-Protokollen 
sind die Startbits wesentlich länger als die Datenbits. Das ist hier 
nicht gegeben. Allerdings fehlen bei Deinem Bild Angaben zu den Timings. 
Wie breit sind die Pulse?

Gruß,

Frank

Autor: John Doe (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Norman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joshua (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tom Eichw (hallo02)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich habe den original code von peter (erster beitrag) genommen. ich 
versuche ihn auf einem atmega32 mit 16Mhz zum laufen zu bringen. Leider 
bekomme ich keinen output :-(

ich habe die SIGNAL (SIG_OVERFLOW0) routine mit usart debug ausgaben 
bestueckt und herausgefunden, dass folgende if bedingung nicht erfuellt 
wird (siehe kommentar unten) - in allen anderen if bedingungen bekomme 
ich eine debug ausgabe

kann mir vielleicht jemand weiterhelfen?

SIGNAL (SIG_OVERFLOW0)
{
  uint tmp = rc5_tmp;

  TCNT0 = -2;
  if( ++rc5_time > PULSE_MAX ){
    if( !(tmp & 0x4000) && tmp & 0x2000 ) // <--- HIER KOMM ICH NICHT 
REIN
      rc5_data = tmp;                    // <--- HIER KOMM ICH NICHT 
REIN
    tmp = 0;
  }

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

    if( rc5_time < PULSE_MIN )
      tmp = 0;

    if( !tmp || rc5_time > PULSE_1_2 ){
      if( !(tmp & 0x4000) )
        tmp <<= 1;
      if( !(rc5_bit & 1<<xRC5) )
        tmp |= 1;
      rc5_time = 0;
    }
  }

  rc5_tmp = tmp;
}

Autor: Tom Eichw (hallo02)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das problem hat sich geloest, ich habe einen fehler im code gehabt auf 
grund meiner vielen debug ausgaben - der oben gezeigte code funktioniert

das einzige was ich geandert habe, ist uint in uint16_t umzubenennen, 
bzw uchar nach uint8_t

Autor: Christian Swoboda (swoc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

wieso wird bei

if( (rc5_bit ^ xRC5_IN) & 1<<xRC5 )

mit xRC5_IN der gesamte Port eingelesen und verknüpft?

Autor: moo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hendrik Xyz (wolf77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend.
Ich versuche auch den RC5 Code von oben zu verwenden, doch ich weiß 
leider nicht wie ich das char_feld auslesen kann, wo code und adresse 
stehen, um die ausgänge meines ATMEGA8 mit 3 verschiedenen 
Fernbediehnungstasten zu steuern.

Ich hab das programm im atmelstudio kompiliert und übertragen, aber das 
einzige was ich erreiche sind komische 500mV flanken auf PB0 beim 
drücken einer taste.

Nun meine frage wie kann zb. beim drücken der PWR taste ( code 12) 
meiner Loewe fernbediehnung ( RC5) eine aktion auslösen?

Autor: Malte __ (malte) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe mal die Version für einen XMEGA angepasst (getestet mit 
ATxmega64A1). Außerdem wird der Timer abgeschaltet, solange nichts 
empfangen wird. Der Pin ISR weckt den Timer dann wieder auf. Das erlaubt 
einen Betrieb auch während die CPU im Power Save Mode ist. Viel Spaß.

Autor: Kim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle zusammen,
ich soll, von meinem Ausbilder, ein RC5-signal mit einem PIC16F84A 
auswerten und das Ergebnis von einem LCD anzeigen lassen
ich finde leider rein gar nichts dazu.
Kann mir da jemand helfen??

LG Kim

Autor: Di Pi (drpepper) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
IRMP hilft. Lesen bildet :)

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Di Pi schrieb:
> IRMP hilft. Lesen bildet :)

Nunja, das Lesen des Artikels hilft bestimmt. Aber das IRMP-Paket als 
Software für diese Aufgabe anzuwenden dürfte wohl den gewünschten 
Lerneffekt unterlaufen ;-)

@Kim:

  http://www.mikrocontroller.net/articles/IRMP#RC5_.2B_RC5X

Hier findest Du weitere 4 Links als "Literatur-Hinweis":

  http://www.mikrocontroller.net/articles/IRMP#RC5-_...

Autor: Kim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke =)
damit bin ich aber leider nicht viel weiter gekommen =/

LG Kim

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kim schrieb:
> damit bin ich aber leider nicht viel weiter gekommen =/

Warum? Du weisst jetzt, wie das Signal aussieht. Jetzt musst Du das nur 
noch programmieren. Oder hapert es genau daran?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.