Hallo. Ich hätte da gerne mal ein Problem. Nämlich das folgende: Ich habe gerade versucht mit der Software von Peter Danegger (in einem anderen post hier irgendwo ^^) wenn ein Mega8 irgendein Signal empfängt eine LED zu toggeln. Blöd nur, dass er anscheinend mit den Signalen, die er bekommt nichts anfangen kann. (Definitiv sind hier RC5 Fernbedienungen unter denen, die ich hier grad probiere). Der uC läuft mit 4MHz internem Takt. Ich würde gerne einen 4MHz Quarz anschließen, hab aber keine Ahnung, auf welchen von den geschätzen 20 Werten der Fusebits ich selbige setzen muss (Slow, Middle, Fast, ...) Im Anhang der für die aktuelle GCC version angepasste code. Danke Schonmal! Gruß M.
Kannst ja mal zum Test die LED Toggeln, wenn der Empfangspin was empfängt, also ein Test, ob die Schaltung ok ist. Hast du einen richtigen Fernbedienungsempfänger am Pin (z.B. TSOP1736), richtig geschaltet?
Hey Tobi, Also die Beschaltung sieht folgendermaßen aus: GND an GND V+ an +5V die Datenleitung an PD2 und über 10kOhm an +5V Ich hab jetzt mal ne LED mit der kathode an die Datenleitung vom TSOP geschaltet und man sieht wie das teil flackert, wenn ich ne Taste auf einer Fernbedienung drücke. Oder meinst du den Port-Toggle befehl an einer anderen Stelle einfügen, wenn ja an welcher?
Ich hab jetzt auch mal testweise
1 | if(!(PIND & (1<<PD3))) |
2 | {
|
3 | PORTC ^= (1<<PC5); |
4 | }
|
in der Hauptschleife eingefügt und die LED an PC5 flackert dann entsprechend, wenn auf den Fernbedieungen rumdrücke.
Aja, dann funktioniert die hardware ja schonmal. Die RC5 software von P-Dannegger sollte ja auch funktionieren, vllt hat er einen anderen Takt benutzt, nicht 4 MHz, oder von deinen Fernbedienungen ist keine RC5. Ich hab 3 zuhause, und keine davon ist RC5. Ich geh jetzt schlafen. Gute Nacht
Morgen allerseits, was mir grad auffällt ist, dass ich einen TSOP1738 und nich den 36 drin habe, könnt's daran liegen? Gruß
am tsop liegts nicht. wenn du einen 1738 anstatt einen 1736 nimmst klappt das trotzdem - nur mit geringerer reichweite. hast du schon die timer pulsezeiten angepasst auf deine taktfrequenz??
da du ja "TCNT0 = -2", "PULSE_MIN (uchar)(XTAL / 512 RC5TIME 0.4 + 0.5)" etc. nicht an deine taktfrequenz von 4mhz angepasst hast. scheinst du den code nur kopiert zu haben. versuch ihn doch einfach mal zu vertsehen. dann wirst du feststellen, dass peter die ganze sache für eine anderen taktfrequenz geschrieben hat. ich glaube er hatte 16mhz. das heisst, dass du den timer/prescaler neu berechnen und die "512" anpassen musst.
Hallo! Das mit der 512 kann schon bleiben; lediglich der XTAL sollte an den Quartz angepaßt werden. Ich habe diese Routine schon mit diversen Quartz-Frequenzen ausprobiert und es klappte immer. Es gibt lediglich Probleme, wenn die Fernbedienung nicht die passenden Sequenzen sendet; das ist bei Universalfernbedienungen halt auszuprobieren, bei welchen Einstellungen das funktioniert. Der TSOP selbst ist da relativ entspannt, was die Frequenz angeht; 36 - 40 khz decken die Teile schon ab (mit leichten Einbußen in der Empfindlichkeit). Probier mal ein bißchen rum
>Das mit der 512 kann schon bleiben; lediglich der XTAL sollte an den >Quartz angepaßt werden. Ich habe diese Routine schon mit diversen >Quartz-Frequenzen ausprobiert und es klappte immer. Es gibt lediglich >Probleme, wenn die Fernbedienung nicht die passenden Sequenzen sendet; >das ist bei Universalfernbedienungen halt auszuprobieren, bei welchen >Einstellungen das funktioniert. Der TSOP selbst ist da relativ >entspannt, was die Frequenz angeht; 36 - 40 khz decken die Teile schon >ab (mit leichten Einbußen in der Empfindlichkeit). Probier mal ein >bißchen rum Dann hast du immer Glück gehabt das sich der Wert nicht groß geändert hat. Er muss auf jeden Fall neu berechnet werden. Schon alleine weil TCNT0 bei 4MHz und 256 Prescaler auf -5 angepasst werden muss um die 32µs einzuhalten. Versucht doch bitter erst einmal den Kode zu verstehen.
Hallo ihr, also ich werde mir demnächst mal ein oszi beschaffen und mir angucken, was der TSOP da so produziert, so langsam fange ich an an den Fernbedienungen zu zweifeln. Ja gast, so ganz verstanden hab ich den Code noch nicht, hier allerdings mal ein zitat aus der beiligenden index.htm: "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." Gruß
Naja; bei Frequenzen von 3,8xxx bis 8 Mhz funktioniert die Routine; alle Werte der Fernbedienung werden bei mirsauber erkannt. Poste doch mal Deine main.c und Deine Schaltung
Den Code findest du im 1. Post im Anhang, die Schaltung habe ich im 3. Post beschrieben Habe jetzt einen externen Quarz mit 4MHz angeschlossen mit folgenden FUSE settings: CKSEL=1111 und SUT=11, falls das irgendwie weiterhilft
So, Oszi ist da, sogar gleich ein Rolls Royce unter den Oszis, hab ich von dem Vater meiner Freundin ausgeliehen bekommen. Nach ein bisschen rumtüfteln an der Signalerfassung klappt das sogar ganz prima ... Ich brauch auch so ein Teil :D Also hier mal ein paar Bilder die ich von dem Signal gemacht hab: Das gesamte Signal: http://marcelk.info/ir/tek0006.png Der Afnang des SIgnals: http://marcelk.info/ir/tek0005.png Wenn eine Taste gedrückt ist, wird dieses SIgnal wiederhohlt: http://marcelk.info/ir/tek0004.png Das mit den Bildern vom Oszi hat leider nicht so geklappt, falls ihr euch die anderen in dem Verzeichnis noch anguckt. Ich hab da mit den Cursorn noch die Länge der Pulse vermessen, aber da wo diese Informationen normalerweise stehen, ist leider der "Datei Speichern" Dialog vom Oszi ^^ Naja, ich hoffe ihr schlachtet mich jetzt nicht, aber das ganze sieht nach dem JVC Protokoll aus, doch kein RC5 ... argh Sorry, ich habe wirklich fest daran geglaubt, das wäre RC5, weil ich mal einen IR-Empfänger für den PC gebaut habe (Serieller Port) und ich dachte die Software dafür kann nur RC5, die ist nämlich mit allen FBs die ich hatte klar gekommen. Die Software konnte aber anscheinend noch ein paar mehr Protokolle! Aber vielen Dank und ein dickes Sorry für alle die versucht haben mir zu helfen, super Community hier ;) Gruß Masl
Hallo Masl, der aufgezeichnete Code ist sicher kein JVC, da der nur 16-bit lang ist. Ich würde auf extended-NEC tippen. Also 16-bit Adresse, 8-bit Befehl und 8-bit negierter Befehl. Demnach wäre das deine Sequenz: 00001000 10110111 11010010 00101101 Schau mal hier für die Beschreibung: http://www.sbprojects.com/knowledge/ir/nec.htm Gruß Rolf
Oh stimmt, auf die gesamt länge hab ich garnich geachtet, dämlich von mir ^^ Danke dir, mal schauen ob ich demnächst mal zeit finde dafür nen Code zu schreiben. Danke dir
Masl schrieb: > Oh stimmt, auf die gesamt länge hab ich garnich geachtet, dämlich von > mir ^^ > > Danke dir, mal schauen ob ich demnächst mal zeit finde dafür nen Code zu > schreiben. > Ich habe den Code von Peter umgeschrieben (d.h. das Prinzip beibehalten), so daß der NEC code dekodiert wird. Allerdings nicht der extended (mit 16 bit Adresse), sondern nur der Standard mit 8 bit Adresse (d.h. das 2. Adressbyte ist das negierte 1. Adressbyte); das kann man aber leicht ändern. Ich kann ja den Code heute abend mal posten, wenn Interesse besteht.... Gruß, Boregard
Hi Bernhard, ja, das wäre super. Ich hab zwar gestern auch schon bisschen rumgetüftelt und einen halbwegs funktionierenden code gebaut aber deiner ist bestimmt eleganter Gruß
Halli hallo, hier mal der Code den ich gebastelt hab. Ich komme aber partout nicht drauf, warum mit das ding auf dem LCD (is ein 40x4 Zeichen LCD) nur 16 bit anzeigt. Auf dem oszi sehe ich schön wie bei jeder 1, also bei nem langen low puls PD6 toggelt, aber irgendwie scheint da noch der wurm bzw käfer drin zu sein ;) Vielleicht sieht von euch einer spontan, woran es liegt. Gruß
Ok, hab jetzt einen Code der funktioniert. Vielleicht kann mir trotzdem einer erklären warum der im vorigen Post nicht funktioniert hat, hab den Fehler nämlich nicht gefunden, sondern schreibe jetzt die 16 Bit Adresse und die jeweils 8 Bit Commands in einzelne Register. Der Code ist noch nicht wirklich fertig, will alles noch mit Präprozessor-Intelligenz versehen um den code leicht auf die aktuelle Umgebung anpassbar zu machen. Wer verbesserungsvorschläge hat - immer her damit ;) Gruß Marcel
So, nach Problemen mit Rechner und USB-Stick... Jetzt der versprochene NEC Decoder von mir. Aufgerufen wir sie im 125usec interrupt, dies findet sich im IRQS_PER_SECOND wieder. Der empfangene 32 bit code besteht: nec_data & 0xff000000 : invertiertes Datenbyte nec_data & 0x00ff0000 : Datenbyte nec_data & 0x0000ff00 : invertiertes (oder erweitertes) Adressbyte nec_data & 0x000000ff : Adressbyte Man kann noch eine erweiterte Konsistenzprüfung machen, über Datenbyte oder auch über Adressbyte (wenn man keine erweiterten Adressen zulässt). (Der repeat ist auskommentiert, man sollte da nicht tmp nehmen, sondern einen gespeicherten gültigen Wert...). Gruß, Boregard
1 | /*************************************************************************
|
2 | * (C) Bernhard Michler 2009
|
3 | * Based on ideas and code of Peter Danneggers rc5 decoder
|
4 | *
|
5 | * File : ir_nec.c
|
6 | * Created : August 2009
|
7 | * Author(s) : Bernhard Michler
|
8 | *
|
9 | *
|
10 | * DESCRIPTION:
|
11 | * Routines for IR receivers, decoding the ancient the widely spread
|
12 | * Japanese NEC code.
|
13 | *
|
14 | ************************************************************************/
|
15 | #include <avr/io.h> |
16 | #include <avr/interrupt.h> |
17 | #include "config.h" |
18 | #include "ir-nec.h" |
19 | |
20 | volatile uint32_t nec_data; // store result |
21 | |
22 | |
23 | void irnec_init (void) |
24 | {
|
25 | nec_data = 0; |
26 | }
|
27 | |
28 | |
29 | uint32_t get_nec_data (void) |
30 | {
|
31 | uint32_t tmp; |
32 | uint8_t intStat = SREG; |
33 | cli(); |
34 | tmp = nec_data; |
35 | nec_data = 0; |
36 | SREG = intStat; |
37 | return (tmp); |
38 | }
|
39 | |
40 | |
41 | /************************************************************************/
|
42 | /* */
|
43 | /* NEC Remote Receiver */
|
44 | /* */
|
45 | /* Author: Bernhard Michler */
|
46 | /* */
|
47 | /************************************************************************/
|
48 | // NEC / Japanese...
|
49 | // 13.500ms - start
|
50 | // 2.250ms - "1"
|
51 | // 1.125ms - "0"
|
52 | // 90.000ms - key repeat
|
53 | #define NECP_MIN (uint8_t)(IRQS_PER_SECOND * 0.875e-3)
|
54 | #define NECP_ZERO (uint8_t)(IRQS_PER_SECOND * 1.750e-3)
|
55 | #define NECP_ONE (uint8_t)(IRQS_PER_SECOND * 3.000e-3)
|
56 | #define NECP_REPEAT (uint8_t)(IRQS_PER_SECOND * 12.00e-3)
|
57 | #define NECP_MAX (uint8_t)(IRQS_PER_SECOND * 15.00e-3)
|
58 | |
59 | |
60 | void irnec_int (void) |
61 | {
|
62 | static uint8_t irrc_bit; // bit value |
63 | static uint8_t irrc_time; // count bit time |
64 | static uint32_t irrc_tmp; // shift bits in |
65 | static int8_t bit_cnt; // count bits |
66 | uint32_t tmp = irrc_tmp; // for faster access |
67 | int8_t tmp_cnt = bit_cnt; |
68 | |
69 | if (++irrc_time > NECP_MAX) |
70 | {
|
71 | irrc_time = 0; |
72 | tmp_cnt = 0; |
73 | }
|
74 | |
75 | // signal change ??
|
76 | if ((irrc_bit ^ xIRRC_IN) & 1<<xIRRC ) |
77 | {
|
78 | irrc_bit = ~irrc_bit; // 0x00 -> 0xFF -> 0x00 |
79 | |
80 | if ((irrc_bit & 1<<xIRRC) == 0) |
81 | {
|
82 | // it was a change 0 -> 1, so check
|
83 | // pulse length now:
|
84 | if ((irrc_time < NECP_MIN ) || // too short, error |
85 | (irrc_time > NECP_REPEAT)) // start pulse |
86 | {
|
87 | tmp_cnt = 0; |
88 | }
|
89 | else if (irrc_time > NECP_ONE) |
90 | {
|
91 | // repeat pulse
|
92 | // nec_data = tmp;
|
93 | }
|
94 | else
|
95 | {
|
96 | // bit received
|
97 | tmp_cnt++; |
98 | |
99 | tmp >>= 1; |
100 | |
101 | if (irrc_time > NECP_ZERO) |
102 | tmp |= 0x80000000; |
103 | |
104 | if (tmp_cnt == 32) |
105 | {
|
106 | nec_data = tmp; |
107 | tmp_cnt = 0; |
108 | }
|
109 | }
|
110 | irrc_time = 0; |
111 | }
|
112 | }
|
113 | bit_cnt = tmp_cnt; |
114 | irrc_tmp = tmp; |
115 | }
|
Bevor die ersten Beschwerden kommen, daß etwas fehlt... Hier mein Testprogramm für Mega 8 mit 2*16 Display, auf dieses Display wird der empfangene Code ausgegeben, und zwar in die obere Zeile NEC, in die untere RC5 (mit Peter Code decodiert). Gruß, Boregard
Hallo Bernhard! Vorweg: vielen Dank für deine "Erweiterung" um den NEC-Code. Allerdings krieg ichs nicht hin, das Teil mit einer bestimmten Fernbedienung zum Laufen zu bringen :-( Mit meiner Yamaha-FB klappt alles bestens. Mit der hier allerdings nicht: http://www.ltt-versand.de/product_info.php/info/p36217.html Ich dann mit dem LA von einem Kumpel mal die Zeiten gemessen:
1 | A B C D E |
2 | ¯¯\_______/¯¯¯¯\_/¯\_/¯¯\ |
3 | | start | 0 | 1 | |
4 | |
5 | smarites: (µs) |
6 | A: 9075 .. 9130 |
7 | B: 4420 .. 4490 |
8 | C: 485 .. 550 |
9 | D: 480 .. 550 |
10 | E: 1615 .. 1645 |
11 | |
12 | yamaha: (µs) |
13 | A: 9040 |
14 | B: 4370 |
15 | C: 655 |
16 | D: 460 |
17 | E: 1580 |
Ich verstehe allerdings anhand dieser Zeiten nicht mal, warum die yamaha-FB funktioniert. Die haben irgendwie nichts mit den Zeiten in den defines zu tun. An deinem Code hab ich nur die Ausgabe angepasst und als printf über die UART geschrieben. Hier kommt bei der "smaries"-FB meisten nur Fehler oder sinnlose Sequenzen an. Hilfe :-) Grüße, Max
Max schrieb: > Mit meiner Yamaha-FB klappt alles bestens. Mit der hier allerdings > nicht: http://www.ltt-versand.de/product_info.php/info/p36217.html Das Ding macht auch das NEC-Protokoll. > smarites: (µs) > A: 9075 .. 9130 > B: 4420 .. 4490 > C: 485 .. 550 > D: 480 .. 550 > E: 1615 .. 1645 > > yamaha: (µs) > A: 9040 > B: 4370 > C: 655 > D: 460 > E: 1580 > [/pre] Das korrekte Timing beim NEC-Protokoll ist: A = 9000µs B = 4500µs C = 560µs D = 560µs E = 1690µs Da ist die Smarties-Fernbedienung sogar näher dran als die Yamaha. IR-Fernbedienungen haben vom Timing her oft bis zu 40% Abweichungen vom Idealwert, siehe auch http://www.mikrocontroller.net/articles/IRMP Dort findest Du auch einen IR-Decoder, der beide Fernbedienungen (Yamaha als auch die Smarties-FB) durch Berücksichtigung gewisser Toleranzen (40% beim NEC-Protokoll) ohne Probleme "versteht". Gruß, Frank
Frank M. schrieb: Hallo Frank, danke für deine Antwort! Um Missverständnissen vorzubeugen: ich weiß, dass das NEC-Code ist und dass es im Thread eigentlich um RC5 geht, aber ich hab mich an der NEV-Variante von Bernhard Michler versucht. > Dort findest Du auch einen IR-Decoder, der beide Fernbedienungen (Yamaha > als auch die Smarties-FB) durch Berücksichtigung gewisser Toleranzen > (40% beim NEC-Protokoll) ohne Probleme "versteht". Ich hab mir deinen IRMP auch schon angesehen, bin aber nicht richtig warm damit geworden, weil dieses riesige Stück Software für mich Overkill ist. Ich will auch nicht verschiedene Codes oder Timing-Varianten eines Codes erkennen, sondern nur diese eine bunte FB :-) Darum hab ichs zuerst mit diesem Dekoder versucht und ihn ja eigentlich auch zum Funktionieren gebracht. Nur nicht mit der richtigen FB :-( Wenn ich hier wirklich nicht zum Ziel komme, kommt der IRMP zum Einsatz. Gut zu wissen, dass die Smarties-FB damit funktioniert! Nochmal danke, Grüße, Max
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.