Hallo zusammen,
seit einigen Wochen versuche ich mit einem ATMega8 IR Signale (NEC
Codierung) zu senden.
Der AVR ist für mich (als Programmierer oh Schande) noch ziemliches
Neuland
nach jetzt so etlichen Fehlversuchen, bei denen ich aber viel gelernt
habe,
bin ich jetzt auf das Irsnd Projekt hier im Forum gestoßen.
Erstmal RESPEKT!!!
Hier steckt richtig viel Arbeit und Wissen drin!!!
Ich habe dann mal versucht den Code im AVR Studio (letzte Version) zu
compilieren. Dabei bekomme ich nachfolgende Errors, die ich nicht
aufgelöst bekomme.
Ich habe die im Zip enthaltenen Files mal auf die fehlenden
Deklarationen untersucht, es gibt sie nicht.
Was mache ich falsch?
Hoffe mir kann hier jemand auf die Sprünge helfen.
Was ich auch nicht verstanden habe, wo deklariere ich den von mir
verwendeten AVR? Oder ist das schon vom Studio erledigt, wenn ich dort
den
Mega8 konfiguriere?
1
Fehler 4 'COM2B0' undeclared (first use in this function)
2
Fehler 6 'COM2B0' undeclared (first use in this function)
3
Fehler 12 'DDRIRSND_PORT_LETTER' undeclared (first use in this function)
4
Fehler 8 'IRSND_BIT_NUMBER' undeclared (first use in this function)
5
Fehler 11 'IRSND_BIT_NUMBER' undeclared (first use in this function)
6
Fehler 9 'OCR2A' undeclared (first use in this function)
7
Fehler 7 'PORTIRSND_PORT_LETTER' undeclared (first use in this function)
8
Fehler 10 'PORTIRSND_PORT_LETTER' undeclared (first use in this function)
9
Fehler 2 'TCCR2A' undeclared (first use in this function)
10
Fehler 5 'TCCR2A' undeclared (first use in this function)
11
Fehler 13 'TCCR2A' undeclared (first use in this function)
12
Fehler 14 'TCCR2B' undeclared (first use in this function)
13
Fehler 1 #error Wrong value for IRSND_OCx, choose IRSND_OC2 in
14
irsndconfig.h
PS: Das Projekt das ich hiermit umsetzen möchte, ist die Lenkrad
Fernbedienung meines Fz. an ein Aftermarkt Radio zu koppeln.
Hans
Verwendest du das 6-er Studio?
Hab mir das auch mal geholt und zu meiner Schande muss ich sagen, dass
ich es in 10 Minuten auch nicht rausgekriegt habe was da los ist.
Hol dir ein 4-er Studio, dafür ist das Aps-File dafür im Zip-File.
Laden, auf Mega8 umstellen und dann sollte das problemlos compilieren.
(Hab ein 6.0.1843 aber benutze es nur ungern)
Ja ich nutze das 6er Studio!
Danke für den Tip, ich werde das mal versuchen.
Ich glaube ich hab noch irgendwo ein altes 4er Studio.
Hoffe nur das läuft noch unter W7 64Bit.
Wobei ich sagen muss, das 6er ist mir sehr sympatisch, liegt vieleicht
an der Ähnlichkeit zum Visual Studio 10
Gruss Hans
Kann das daher kommen, dass das 6-er Studio den Mega8 nicht mehr
unterstützt (fällt mir gerade ein).
Denn. Im Code ist das alles mit #ifdef geregelt und eigentlich sollten
die entsprechenden #define ja durch Auswahl des Prozessors ja schon
vorhanden sein.
Karl Heinz Buchegger schrieb:> Kann das daher kommen, dass das 6-er Studio den Mega8 nicht mehr> unterstützt (fällt mir gerade ein).
Kann gut sein, da hatte ich erst gestern hier im Forum etwas dazu
gelesen, zumindest was das Flashen eines ATmega8 betrifft. Das hat mich
schon sehr verwundert - auch wenn der ATmega8 wirklich ein uraltes Teil
ist.
Dann muss der TO halt das 4er oder 5er AVR-Studio nehmen oder den
ATmega8 gegen einen ATmega88 oder ATmega168 tauschen. Letzteres würde
ich auf jeden Fall machen, für mich zumindest ist der ATmega8 obsolet.
> Denn. Im Code ist das alles mit #ifdef geregelt und eigentlich sollten> die entsprechenden #define ja durch Auswahl des Prozessors ja schon> vorhanden sein.
Eben, diese ifdefs machen es eigentlich ziemlich einfach.
Trotzdem muss der TO noch den PWM-Pin in irsndconfig.h auswählen,
nämlich hier:
Ich habs gerade mal im 4er Studio getestet. Ich kann das Problem
reproduzieren, hier kommen dieselben Fehlermeldungen.
Der Grund ist die oben angegebene falsche Einstellung in irsndconfig.h.
Der TO muss hier bei einem ATmega8 IRSND_OC2 einstellen, dann gehts ohne
Warnungen/Fehler durch den Compiler.
Steht aber auch hier im IRMP-Artikel:
http://www.mikrocontroller.net/articles/IRMP#Einstellungen_in_irsndconfig.h
Als Autor des IRMP-Pakets frage ich dann mal in die Runde:
Kann ich das noch "idiotensicherer" machen? Ich meine, die ausgegebene
Meldung
1
#error Wrong value for IRSND_OCx, choose IRSND_OC2 in irsndconfig.h
Frank M. schrieb:> Kann ich das noch "idiotensicherer" machen?
Wenn du etwas idiotensicheres erfunden hast, erfindet irgendjemand einen
besseren Idioten.
;)
zum Beispiel einen, der die Fehlerliste alphabetisch sortiert, anstatt
nach Reihenfolge des Auftretens.
Frank M. schrieb:> Kann ich das noch "idiotensicherer" machen? Ich meine, die ausgegebene> Meldung>>
1
> #error Wrong value for IRSND_OCx, choose IRSND_OC2 in irsndconfig.h
2
>
>> ist doch eigentlich aussagekräftig genug?
Die ist ok.
Das erklärt aber nicht die anderen Fehler, die im 6-er kommen, wie zb
Fehler 4 'COM2B0' undeclared (first use in this function)
Fehler 9 'OCR2A' undeclared (first use in this function)
und die sind mir komplett unklar. Denn das stammt alles aus io.h
Karl Heinz Buchegger schrieb:> Das erklärt aber nicht die anderen Fehler, die im 6-er kommen, wie zb> Fehler 4 'COM2B0' undeclared (first use in this function)> Fehler 9 'OCR2A' undeclared (first use in this function)
Das werden Folgefehler des ersten sein, oder nicht
Vlad Tepesch schrieb:> Karl Heinz Buchegger schrieb:>> Das erklärt aber nicht die anderen Fehler, die im 6-er kommen, wie zb>> Fehler 4 'COM2B0' undeclared (first use in this function)>> Fehler 9 'OCR2A' undeclared (first use in this function)>> Das werden Folgefehler des ersten sein, oder nicht
Das sind die ersten. Das ist ja das interessante.
(Wobei ich sagen muss, das ich das 6-er Studio nicht leiden kann. Nach 5
Minuten hab ich immer noch nicht die Stelle gefunden, wo man die
Taktfrequenz eintragen kann. Ich habs dann mit einem Command Line
#define in den Compiler Options gemacht. Genauso wie _ATMega8_ (bitte
nicht auf die Schreibweise festnageln, aus dem Kopf), aber das hat alles
nichts gebracht.
Karl Heinz Buchegger schrieb:> wo man die> Taktfrequenz eintragen kann
Die kann amn in der 5. er Version einfach bei der Processor View
überschreiben. Dann merkt er sich die. Hat mich aber auch einige Zeit
gekostet.
Karl Heinz Buchegger schrieb:> Das sind die ersten. Das ist ja das interessante.
Die Liste oben ist sinnfreier Weise alphabetisch sortiert
(Standardeinstellung?). Fehler Nummer 1 ist "#error Wrong value for
IRSND_OCx, choose IRSND_OC2 in irsndconfig.h", die anderen kommen erst
danach.
Die Option zum Eintragen der Taktfrequenz gibt es afaik nicht mehr.
Könnte mir vorstellen, dass das rausgenommen wurde, weil man als
Anfänger leicht annehmen konnte, dass der Prozessor dann wirklich mit
der Taktfrequenz läuft, obwohl damit ja nur das Makro F_CPU definiert
wurde.
> #error Wrong value for IRSND_OCx, choose IRSND_OC2 in irsndconfig.h
2
>
>> Der TO hat die Fehler umsortiert und dafür die Fehlermeldungen> durchnummeriert.>> So siehts im AVR-Studio 4 aus:
Ah. Im 4-er
Ich hatte das 6-er gemeint.
(Kann allerdings wirklich sein, dass ich da eine Gedächtnislücke haben.)
xfr schrieb:> Karl Heinz Buchegger schrieb:>> Das sind die ersten. Das ist ja das interessante.>> Die Liste oben ist sinnfreier Weise alphabetisch sortiert> (Standardeinstellung?).
Das ist jetzt aber nicht dein Ernst. Oder?
Doch, doch. Jetzt wo du es sagst - da ist mir schon aufgefallen, das bei
den Fehlermeldungen eine Zahl dabei steht und das die durcheinander
sind. Aber das das die Reihenfolge der auftretenden Fehler ist, darauf
wär ich nicht gekommen. Wer macht denn sowas? Und warum ist die
Sortierung nach Nummern nicht Default? Und warum kann man die dauerhaft
umstellen?
Ich hab mich lieber darüber geärgert, dass ich da wahlfrei auf den
'Error' Tab bzw. 'Warning' Tab klicke und sich die Anzeige ändert - oder
auch nicht. Gleich darauf hab ich beschlossen, das so schnell wie
möglich wieder zuzumachen und aufzugeben. Weil mir das zu blöd ist, wenn
ich mich mit Werkzeug rumärgern muss :-)
Alles in allem sind in der Version des 6-er, die ich habe, so viele
Kleinigkeiten die mich nerven, dass ich wirklich keine Lust verspüre, da
drauf zu wechseln. Da leb ich lieber noch ein weilchen mit dem 4-er. Das
ist zwar auch nicht perfekt, aber gut genug, so dass mir das Studio
nicht dauernd in die Quere kommt.
> Könnte mir vorstellen, dass das rausgenommen wurde, weil man als> Anfänger leicht annehmen konnte, dass der Prozessor dann wirklich mit> der Taktfrequenz läuft, obwohl damit ja nur das Makro F_CPU definiert> wurde.
Spricht nicht gerade für die Produktentwickler. Wenn man in einer GUI
etwas missverstehen kann (was vorkommen kann), dann ist das eine Frage
der Präsentation. Oftmals reicht schon ein besserer Text im zugehörigen
Label.
Karl Heinz Buchegger schrieb:> Ah. Im 4-er> Ich hatte das 6-er gemeint.
Ja, 4er, aber mit gcc 4.7.2.
Ich kanns einfach nicht glauben, dass der 6er gcc-Meldungen neu sortiert
und dann
Fehler 2
Fehler 3
Fehler 1
vor die eigentlichen gcc-Meldungen schreibt. Echt wahr?
Es gibt eine Liste mit Fehlern und Warnungen, die hat mehrere Spalten:
- Symbol für Fehler/Warnung (wird bei Copy+Paste zu "Error" oder
"Warning")
- Die obige Nummer
- Beschreibung (nach der wurde sortiert)
- Datei
- Zeile
- Spalte
- Projekt
Man kann nach jeder dieser Spalten sortieren, indem man auf das
entsprechende Label klickt. Kann schon sein, dass es in der
Standardeinstellung nach Beschreibung sortiert wird, was natürlich
Blödsinn wäre. Oder der TO hat mal aus Versehen drauf geklickt.
Man kann nach Fehlern, Warnungen und Nachrichten filtern (Ein- und
Ausblenden dieses Typs durch Klicken auf das Label, funktioniert bei mir
absolut deterministisch ;-)). Wenn man möchte, kann man sogar die
Reihenfolge der Spalten ändern.
Die normale Textausgabe des Compilers gibt es natürlich auch noch, in
einem eigenen Fenster. Das sind vielleicht etwas mehr Möglichkeiten, als
man in AVR Studio 4 hat, aber schlecht gelöst kann man das imo nicht
nennen.
Nach der F_CPU-Einstellung habe ich allerdings auch lange gesucht und
hätte die lieber als eigene Option. Bin ebenfalls der Meinung, dass eine
klare Beschreibung reichen sollte, um Missverständnisse zu vermeiden.
ich liebe diese Fehlerübersicht im VS.
wenn man mehr details braucht doppelklickt man halt den Fehler an und
wechselt ins Buildoutput-Tab, wo er direkt zum angeklickten Fehler
gesprungen ist, ebenso wie er im Code zum entsprechenden Fehler springt
Ja das wars,
jetzt gehts schon mal durch den Compiler :)
Umsortiert hab ich da jedenfalls nichts, zumindest nicht bewußt.
Es scheint aber so als wenn das Studio sich die Sortierung merkt.
Vieleicht hab ich da wirklich mal in einer anderen Situation auf eine
der
Spalten geklickt.
Hätte aber nicht gedacht dass mein Problemchen zu so einer Diskussion
führt.
Man lernt halt nie aus....
Vielen Dank erstmal an alle die mich hier unterstützt haben.
Der Fehler sitzt halt wie immer vor dem PC.
Werd jetzt mal schauen ob ich mein Projekt damit umgesetzt bekomme.
Gruß Hans
Jaaaa...
einen Schritt weiter und wieder am Abgrund!!
Zuerst die gute Nachricht:
Der IRSDN Source läuft.
Auf dem Scope sieht das auch alles recht ordentlich aus.
Aber: Mein Radio (Kenwood BT42U)interessiert sich nicht dafür. (NEC
Code)
1. Versuch: Signal über Remote Digitaleingang eingespeist.
--> keine Reaktion
2. Versuch mit IR Diode.
Mein Multimedia PC macht seltsame Dinge wenn ich sende, also muss
der Sender funktionieren.
--> Radio: keine Reaktion
Dann hab ich mir gedacht, Im Header steht ja eine Adresse, die könnte ja
für mein Autoradio nicht passen. Es sind ja nur 255.
--> keine passt.
Und jetzt, da Tante Google auch nicht mehr hergibt gehen mir langsam die
Ideen aus.
Was mir noch aufgefallen ist.
Auf der folgenden Seite
http://www.sbprojects.com/knowledge/ir/nec.php
steht unter Modulation:
The recommended carrier duty-cycle is 1/4 or 1/3.
Mein Scope zeigt mir aber beim Träger ein carry duty-cycle von 1/2.
Könnte dies das Problem sein und wenn ja, läßt sich das im IRSND
einstellen?
Ansonsten fällt mir nur noch eine Lösung ein:
Original Fernbedienung bestellen und schauen was da so raus kommt.
Aber vieleicht hat ja hier jemand positive Erfahrungen mit so einer
Steuerung.
Den Source hab ich mal angehangen.
Nicht erschecken, da ist noch viel von meinen Tests drin was nicht
gebraucht wird
Schöne Grüße
Hans
Karl Heinz Buchegger schrieb:> Kann das daher kommen, dass das 6-er Studio den Mega8 nicht mehr> unterstützt (fällt mir gerade ein).
Nein, kann es nicht.
Die Version 6.0.1996 bietet den ATmega8 in der Device-Liste an.
Karl Heinz Buchegger schrieb:> Nach 5 Minuten hab ich immer noch nicht die Stelle gefunden, wo man die> Taktfrequenz eintragen kann.
Mit Google wärst du schnelle und zum Erfolg gekommen ;-)
xfr schrieb:> Die Option zum Eintragen der Taktfrequenz gibt es afaik nicht mehr.
Doch, eigentlich hat sich im AVR Studio 6 gegenüber Studio 4 wenig
geändert, nur neu sortiert.
Es nach wie vor die beiden Stellen zum Einstellen der Taktfrequenz,
einmal für den Compiler (Konstante F_CPU) und einmal für den Simulator.
Für den Compiler trägt man die F_CPU Konstante in den
Projekteigenschaften ein, also über Menü "Project" / "...Properties"
(Alt-F7) unter der Rubrik "AVR/GNU C Compiler" / "Symbols" einfach bei
"Defined symbols" mit dem Button "Add Item" einen Eintrag z.B.
"F_CPU=8000000UL" hinzufügen.
Für den Debugger kann man die Frequenz nach dem Starten auf der
Karteikarte/Fenster "Processor" unter "Frequency" direkt eingeben
Matthias schrieb:> Für den Debugger kann man die Frequenz nach dem Starten auf der> Karteikarte/Fenster "Processor" unter "Frequency" direkt eingeben
Eigentlich logisch, hätte ich da aber auch nie vermutet
Hans_F83 schrieb:> Eigentlich logisch, hätte ich da aber auch nie vermutet
Und wer rechnet schon damit, das F_CPU über einen "F_CPU="-Eintrag bei
den Defines eingegeben wird ... ;-)
Matthias schrieb:> Für den Compiler trägt man die F_CPU Konstante in den> Projekteigenschaften ein, also über Menü "Project" / "...Properties"> (Alt-F7) unter der Rubrik "AVR/GNU C Compiler" / "Symbols" einfach bei> "Defined symbols" mit dem Button "Add Item" einen Eintrag z.B.> "F_CPU=8000000UL" hinzufügen.
Das ist schon klar, dass das so geht. Aber das ist ja keine eigene
Option für die CPU-Frequenz im GUI, sondern einfach der Ort, wo man
allgemeine Preprocessor-Defines eintragen kann.
In AVR Studio 4 gab es in den Einstellungen ein eigenes Feld für die
CPU-Frequenz, aus der dann -DF_CPU wurde. Aus den anderen Optionen
(welcher uC, welche Optimierung, Include-Ordner usw.) werden ja am Ende
auch nur Parameter, die im Makefile an den Compiler gegeben werden.
Ich denke hier wollte man wohl was vereinfachen und hat es
unübersichtlicher gemacht.
Aber zurück zu meinem Problem (6 Post's vorher).
Hat hier noch jemand eine Idee?
Ich habe in der Zwischenzeit versucht meine Harmony auf das Gerät zu
programmieren. Leider unterstützt die Harmony das Gerät nicht.
Gruß Hans
Hans F. schrieb:> Der IRSDN Source läuft.
Gut.
> Auf dem Scope sieht das auch alles recht ordentlich aus.> Aber: Mein Radio (Kenwood BT42U)interessiert sich nicht dafür. (NEC> Code)
Woher weisst Du, dass Dein Radio NEC-Code verwendet?
> Dann hab ich mir gedacht, Im Header steht ja eine Adresse, die könnte ja> für mein Autoradio nicht passen. Es sind ja nur 255.
Nein, NEC extended verwendet 16-Bit-Adressen, damit bist Du bei 65536
Möglichkeiten, die Du durchprobieren müsstest.
> Auf der folgenden Seite> http://www.sbprojects.com/knowledge/ir/nec.php> steht unter Modulation:> The recommended carrier duty-cycle is 1/4 or 1/3.
Der Duty-Cycle spielt eigentlich keine Rolle.
> Ansonsten fällt mir nur noch eine Lösung ein:> Original Fernbedienung bestellen und schauen was da so raus kommt.
Du hast also keine Fernbedienung für Dein Kenwood-Radio? Woher weisst Du
dann, dass es NEC-Code ist?
Das beste Verfahren: Mit IRMP Fernbedienung auslesen und die Codes
speichern (entweder direkt im IRSND-Code oder im EEPROM).
Beschreibe doch erstmal konkret Dein Szenario.
Frank M. schrieb:
Danke erstmal für die Rückmeldung
> Hans F. schrieb:>>> Der IRSDN Source läuft.>> Gut.>>> Auf dem Scope sieht das auch alles recht ordentlich aus.>> Aber: Mein Radio (Kenwood BT42U)interessiert sich nicht dafür. (NEC>> Code)>> Woher weisst Du, dass Dein Radio NEC-Code verwendet?>
Diverse Quellen behaupten das Kenwood den NEC Code verwendet
z.B.
http://baggertech.com/forum/showthread.php?551-Road-Glide-Hacks&s=4214c4bf0f4c96f2548234f34b1a252f
oder
http://www.avr-praxis.de/forum/showthread.php?2581-BMW-MFL-Adapter-f%FCr-Kenwood
es gibt noch einige mehr, wobei nicht 100% klar ist um welches NEC
Protokoll es sich handelt.
Auch hier im Forum existieren einige Threads dazu.
>>> Dann hab ich mir gedacht, Im Header steht ja eine Adresse, die könnte ja>> für mein Autoradio nicht passen. Es sind ja nur 255.>> Nein, NEC extended verwendet 16-Bit-Adressen, damit bist Du bei 65536> Möglichkeiten, die Du durchprobieren müsstest.>
Ja das ist richtig, der Standart NEC Code hat aber nur 256 wobei man
0x00 und 0xFF warscheinlich weglassen kann.
Vieleicht gibt es ja eine Broadcast Adresse? Ich konnte dazu aber bisher
nichts finden.
>>> Auf der folgenden Seite>> http://www.sbprojects.com/knowledge/ir/nec.php>> steht unter Modulation:>> The recommended carrier duty-cycle is 1/4 or 1/3.>> Der Duty-Cycle spielt eigentlich keine Rolle.>
OK, damit eine Fehlerquelle weniger
>>> Ansonsten fällt mir nur noch eine Lösung ein:>> Original Fernbedienung bestellen und schauen was da so raus kommt.>> Du hast also keine Fernbedienung für Dein Kenwood-Radio? Woher weisst Du> dann, dass es NEC-Code ist?>
Nein bisher nicht, eine Fernbedinung im Auto macht (für mich) nicht
wirklich Sinn.
Ich habe aber jetzt die Originale bestellt, auch wenn ich die später nie
wieder brauchen werde.
>> Das beste Verfahren: Mit IRMP Fernbedienung auslesen und die Codes> speichern (entweder direkt im IRSND-Code oder im EEPROM).>
Das werde ich machen wenn ich die Fernbedienung bekomme
>> Beschreibe doch erstmal konkret Dein Szenario.
Eigentlich recht einfach:
Ich möchte über die Lenkrad Bedienung meines FZ ein Aftermarket Radio
(Kenwood) steuern. Die Lenkrad FB besteht aus einem Widerstandsnetzwerk.
Somit ist das eine relativ einfache Steuerung in der der Spannungswert
von der FB in einen IR Code, oder unmoduliert über den Remote Control
Eingang des Radios eingespeist wird.
Die Grenzen der Eingangs Spannungen leg ich mir ins EEprom.
Das ist auch schon soweit implementiert und funktioniert.
Die Werte können angelernt werden, aber das hast du warscheinlich im
Source schon gesehen.
Für die Einspeisung würde ich den Remote Eingang bevorzugen. IR ist nur
Plan B. Aus diversen Quellen ist zu entnehmen das der Remote Eingang
hinter dem IR Decoder gseschaltet ist, somit sollte hie das Signal ohne
Träger eingespeist werden können.
Allerdings muss ich dazu noch herausfinden ob es sich dabei um 5V oder
3,3V Logig handelt.
So ich hoffe ich hab' nichts vergessen
LG Hans
Hans F. schrieb:> Ja das ist richtig, der Standart NEC Code hat aber nur 256 wobei man> 0x00 und 0xFF warscheinlich weglassen kann.
Ich habe zu Hause zwei Media-Geräte (DVD-Player und
Multimedia-Festplatte), welche beide die NEC-Adresse 0xFF00 benutzen ;-)
Hast Du bei Deinen Versuchen denn daran gedacht, dass beim
Standard-NEC-Protokoll die Adresse auch aus 2 Byte besteht, wobei das 2.
Byte invertiert ist? Dann sind es zwar nur 256 Möglichkeiten, aber Du
musst das invertierte Byte auch setzen, also so:
00 FF 1. Adresse
01 FE 2. Adresse
02 FD 3. Adresse
...
FF 00 255. Adresse
Grund:
IRSND setzt das 2. Adressbyte nicht(!) automatisch auf den invertierten
Wert des 1. Adressbytes, denn sonst könnte IRSND kein
Extended-NEC-Protokoll "sprechen", wo die Invertierungsbedingung
aufgehoben ist.
Beispiel für Deinen "Probier-Code" wäre dann:
1
uint8_ta;
2
...
3
for(a=0;a<255;a++)
4
{
5
irmp_data.protocol=IRMP_NEC_PROTOCOL;
6
irmp_data.address=(a<<8)|~a;
7
irmp_data.command=IRGENDWAS;// kannst Glück haben oder auch nicht
8
irmp_data.flags=0;
9
10
irsnd_send(&irmp_data,TRUE);// senden und warten
11
}
...
Eigentlich müsste auch noch eine innere Schleife über command (0x00 bis
0xFF) laufen, damit Du sicher sein kannst. Aber dann sinds wieder 256 x
256 = 65536 Möglichkeiten.
> Ich habe aber jetzt die Originale bestellt, auch wenn ich die später nie> wieder brauchen werde.
Gut so. Du könntest dann die ermittelten Werte dafür im IRMP-Artikel
ablegen. Evtl. möchte jemand Deine Lenkrad-Lösung ja nachbauen ;-)
Gruß,
Frank
Frank M. schrieb:> Ich habe zu Hause zwei Media-Geräte (DVD-Player und> Multimedia-Festplatte), welche beide die NEC-Adresse 0xFF00 benutzen ;-)
Upps
>> Hast Du bei Deinen Versuchen denn daran gedacht, dass beim> Standard-NEC-Protokoll die Adresse auch aus 2 Byte besteht, wobei das 2.> Byte invertiert ist? Dann sind es zwar nur 256 Möglichkeiten, aber Du> musst das invertierte Byte auch setzen, also so:>> 00 FF 1. Adresse> 01 FE 2. Adresse> 02 FD 3. Adresse> ...> FF 00 255. Adresse
ja hatte ich auch so ähnlich gemacht
> Du könntest dann die ermittelten Werte dafür im IRMP-Artikel> ablegen. Evtl. möchte jemand Deine Lenkrad-Lösung ja nachbauen ;-)
Wenns mal läuft, so lange wie ich jetzt schon tüftel hatte ich im Traum
nicht einkalkuliert, kann ich die Lösung gerne hier ablegen.
Ist kein Geheimnis.
Ich werde mich jetzt mal mit dem Empfänger beschäftigen.
Wenn die FB und der TSOP kommen, kann ich dann gleich loslegen.
danke nochmal
Gruß Hans
Kleiner Zwischenstand
Die Adresse ist gefunden (0x45BA)
Durch das Probieren hat das Radio jetzt zwar einen generellen Reset
bekommen
(Display zeigt "DATA CLR OK"), aber das sollte nicht weiter stören.
Im Probiercode von Frank.M steckt aber ein kleiner Fehler
irmp_data.address = (a << 8) | ~a;
ergibt immer 0xFFxx
Die Invertierung muss gecasted werden!
irmp_data.address = (a << 8) | (uint8_t)~a;
oder
irmp_data.address = (a << 8) | (~a & 0xFF);
Hans F. schrieb:> Die Adresse ist gefunden (0x45BA)
Gratuliere. Jetzt hast Du noch 255 Kommando-Codes zum Durchprobieren.
Hier brauchst Du nur die Werte von 0x00 bis 0xff durchzutesten. Die
Invertierung des 4. Bytes macht IRSND selbst.
> Durch das Probieren hat das Radio jetzt zwar einen generellen Reset> bekommen> (Display zeigt "DATA CLR OK"), aber das sollte nicht weiter stören.
No risk no fun :-)
> Im Probiercode von Frank.M steckt aber ein kleiner Fehler
Stimmt, ich hatte den Cast vergessen. Sorry.
Frank M. schrieb:> Hans F. schrieb:>>> Die Adresse ist gefunden (0x45BA)>> Gratuliere. Jetzt hast Du noch 255 Kommando-Codes zum Durchprobieren.> Hier brauchst Du nur die Werte von 0x00 bis 0xff durchzutesten. Die> Invertierung des 4. Bytes macht IRSND selbst.
Ich hoffe das heute endlich der IR Empfänger kommt.
Dann kann ich die Codes auslesen, die FB hab ich ja jetzt.
>>> Durch das Probieren hat das Radio jetzt zwar einen generellen Reset>> bekommen>> (Display zeigt "DATA CLR OK"), aber das sollte nicht weiter stören.>> No risk no fun :-)>>> Im Probiercode von Frank.M steckt aber ein kleiner Fehler>> Stimmt, ich hatte den Cast vergessen. Sorry.
Bin auch erst drauf gestoßen nachdem ich die Adressen über den UART
ausgegeben hatte.
Eine Frage habe ich aber noch.
Ich steige durch die Senderoutine noch nicht ganz durch.
Ich würde mir gerne auf einen Output das Signal ohne Träger ausgeben.
Ich denke das ich damit das Radio direkt, ohne den Umweg über IR steuern
kann.
Gruß Hans
Hans F. schrieb:> Ich würde mir gerne auf einen Output das Signal ohne Träger ausgeben.
Hatte ich schon mal im IRMP-Thread der Codesammlung erklärt:
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
Wenn Du jedoch beide Signale (moduliert und unmoduliert) haben möchtest,
verwende den callback-Pointer, um einen weiteren Ausgang ein- und
auszuschalten. Den Callback-Mechanismus kannst Du über irsndconfig.h
einschalten. Der Rest ist im IRMP/IRSND-Artikel erklärt.
Jetzt bin ich doch etwas ratlos :((
Ich habe zur (Eigen) Kontrolle die von mir ermittelten IR Codes und
Adressen nochmal mit dem IRMP von der Fernbedienung ausgelesen.
Die ermittelten Codes/Adressen funktionieren,
die über IRMP ausgelesenen nicht.
von mir empirisch ermittelte Codes/Adressen
1
Adress 0x46
2
commands
3
0x1 LW1 /FM1
4
0x2 LW2 /FM2
5
0x3 LW2 /FM3
6
0x4 MW4 /FM4
7
0x5 MW5 /FM5
8
0x6 MW6 /FM6
9
0xa Suchlauf -
10
0xb Suchlauf +
11
0xc ? schaltet auf MW
12
0xd wechselt FM Bereiche 1-3
13
0xf numerische Eingabe
14
15
0x12 Funktions Anwahl (Direkt)
16
0x13 Funktions wechsel
17
0x14 Vol +
18
0x15 Vol -
19
0x16 ATT on / off
20
0x17 Audio Control
21
0x1C on/off
22
0x1E BT Umschaltung (Audio / USB)
23
0x92 BT Umschaltung (Audio / USB)
24
0xd8 Display Test? schaltet alle Digits im Display ein
25
0xd9 Reset
mit IRMP ausgelesene Codes
1
* Adresse 0x9D
2
* Taste 1 0x80
3
* Taste 2 0x40
4
* Taste 3 0xc0
5
* Taste 4 0x20
6
* Taste 5 0xa0
7
* Taste 6 0x60
8
* Taste 7 0xe0
9
* Taste 8 0x10
10
* Taste 9 0x90
11
* Taste 0 0x00
12
* tel 0x49
13
* direct 0xf0
14
* AM- 0x30
15
* FM+ 0xb0
16
* exit 0x71
17
* AUD 0xe8
18
* down 0x61
19
* up 0xe1
20
* left 0x50
21
* right 0xd0
22
* ENTER/Play/Pause 0x70
23
* ATT 0x68
24
* Return/Repeat 0xa1
25
* Vol- 0xa8
26
* Vol+ 0x28
27
* Src 0xC8
Die Bezeichnungen sind zum Teil etwas unterschiedlich, liegt daran das
ich mit den oberen begonnen habe.
Eines sollte ich noch anmerken:
Als IR Receiver habe ich statt eines 36MHz Receivers (Tsop 1836) einen
38Mhz Receiver verwendet (Tsop 1838). (falsch bestellt)
Ich weis nicht ob dies eine Rolle spielt, da der Receiver Baustein im
Grunde ja erstmal nur einen Tiefpass Filter darstellt, der den Träger
herausfiltert.
Das Signal was am Ausgang des Tsop herauskommt sollte von Timing
jedenfalls stimmen.
Das Nutzsignal selbst sollte sich ja nicht ändern.
Vieleicht ist mein Denkansatz hier aber auch völlig daneben, im Moment
ist das aber mein einziger Aufhänger.
Ein Muster ist hier ebenfalls nicht erkennbar.
Auffällig ist aber das zb. die Codes für die Lautstärke im oberen Fall
aufeinander folgen, im unteren Fall weit auseinander liegen, was
eigentlich darauf hindeutet, dass der Tsop die Ursache ist.
Das mittels Scope gegenzuprüfen ist fast nicht möglich, da die FB jeden
Code nur einmal sendet und als Folgecode den Repeat Code sendet.
Ohne Speicherscope... no way.
Gruß Hans
Hans F. schrieb:> Ein Muster ist hier ebenfalls nicht erkennbar.
Oh doch! Ich sehe zwar nicht viele übereinstimmende Tasten in Deiner
Liste (bis auf Vol+ und Vol-), aber bei diesen beiden ist es
offensichtlich: Die Bits sind von links nach rechts gespiegelt.
Auch das Muster der Tasten 0 bis 9 spricht dafür, denn wenn man diese
Werte spiegelt, dann erhält man:
Taste Code
0 0x00
1 0x01
2 0x02
3 0x03
.. ..
9 0x09
Das sieht dann für mich so aus, dass der IRMP die empfangenen Bits
spiegelt. Hast Du irgendwas an irmpprotocols.h geändert?
Da muss drinstehen:
1
#define NEC_LSB 1 // LSB...MSB
Das sorgt dafür, dass die Bits mit LSB first eingelesen werden.
Warum kommen die bei Dir "falschherum" an? Ob es da ein
Kompatibilitätsproblem mit der PIC-Portierung gibt?
Probiere doch mal, mit IRSND die Codes 0x00 bis 0x09 zu senden. Dein
Gerät müsste sich dann so verhalten, als ob die Tasten 0 bis 9 gedrückt
worden wären.
EDIT:
Die Zeilen
commands
0x1 LW1 /FM1
0x2 LW2 /FM2
0x3 LW2 /FM3
0x4 MW4 /FM4
0x5 MW5 /FM5
0x6 MW6 /FM6
sprechen jedoch dagegen. Oder Dein Gerät reagiert auf verschiedene
Adressen mit anderen Verhaltensweisen. Vielleicht ist die von Dir
empirisch ermittelte Adresse nur eine unter vielen? Oder kann man an der
Fernbedienung einen Modus umstellen? Meine Toshiba-Fernbedienung hat
sowas: einen Schiebschalter für drei verschiedene Modi. Jedesmal
wechseln die Adressen ... und auch manche Kommando-Codes.
Was ist mit der Adresse 0x46. Bekommst Du diese auch im IRMP angezeigt?
Frank M. schrieb:> Ob es da ein Kompatibilitätsproblem mit der PIC-Portierung gibt?
Das war Unsinn, Du hast ja einen AVR.
> commands> 0x1 LW1 /FM1> 0x2 LW2 /FM2> 0x3 LW2 /FM3> 0x4 MW4 /FM4> 0x5 MW5 /FM5> 0x6 MW6 /FM6
Wahrscheinlich sind das bei Dir die Tasten 0 bis 6, nur anders
bezeichnet? Dann passt ja meine obige Vermutung, dass sämtliche Bits von
IRMP gespiegelt sind. Oder der IRSND spiegelt nicht mehr, nämlich hier:
irsnd.c:
>> Oh doch! Ich sehe zwar nicht viele übereinstimmende Tasten in Deiner> Liste (bis auf Vol+ und Vol-), aber bei diesen beiden ist es> offensichtlich: Die Bits sind von links nach rechts gespiegelt.
Upps, du bist genial, manchmal ist man echt blind.
> Hast Du irgendwas an irmpprotocols.h geändert?>> Da muss drinstehen:>>
1
>#defineNEC_LSB1
2
>// LSB...MSB
3
>
kann es sein, das es unterschiedliche Projekte zum Auslesen der Codes
gibt?
Ich habe keine irmpprotocols.h
Hab ich vieleicht auf den falschen Code aufgesetzt?
Ich habe das Projekt nochmal angehangen.
> Probiere doch mal, mit IRSND die Codes 0x00 bis 0x09 zu senden. Dein> Gerät müsste sich dann so verhalten, als ob die Tasten 0 bis 9 gedrückt> worden wären.
Ja das funktioniert.
Je nach voreingestelltem Modus reagiert das Gerät anders, daher meine
unterschiedliche Interpretation.
Die Tasten 1-6 verhalten sich identisch, 7-0 warscheinlich nur für die
Direkteingabe von Werten.
> Was ist mit der Adresse 0x46. Bekommst Du diese auch im IRMP angezeigt?
nein, IRMP zeigt mir nur Adresse 0x9D
aber: 0x9d invertiert und dann gespiegelt ergibt 0x46.
Edit:
Im Sender gibt es die irmpprotocols.h, nur im Receiver nicht
#define NEC_LSB 1 // LSB...MSB
Vieleicht wäre ja der MSB Modus der passende.
Ich werde mal versuchen ob ich einen Code per Scope entschlüsselt
bekomme.
Gruss Hans
Hans F. schrieb:> Hab ich vieleicht auf den falschen Code aufgesetzt?
Whupps, hast Du. Der von Dir verwendete IRMP-Code ist von 2010, also
über 2 Jahre alt. Damals konnte der IRMP nur 6 Protokolle, heute sind es
30! LSB und MSB wurden damals noch nicht berücksichtigt.
Wo hast Du das uralte Teil her? Bitte lade Dir den IRMP und IRSND hier
herunter: IRMP
Dann sollte es reibungslos funktionieren.
EDIT:
Habe nochmal nachgeschaut: Das war Stand 01/2010, also ist das Teil
bereits knapp 3 Jahre alt!
Würde mich echt interessieren, wo Du das her hast.
Frank M. schrieb:> EDIT:> Habe nochmal nachgeschaut: Das war Stand 01/2010, also ist das Teil> bereits knapp 3 Jahre alt!>> Würde mich echt interessieren, wo Du das her hast.
Das würde es erklären.
Was alt ist, muss aber nicht schlecht sein :)
Der Code ist übrigens von
hier-"Beitrag "IRMP - Infrared Multi Protocol Decoder";
dann werde ich mal mit dem neuen testen
Gruß Hans
Hans F. schrieb:> Das würde es erklären.
Ja, der Steinzeit-IRMP betrachtete alle Protokolle im MSB-Format. Für
NEC ist das falsch.
> Was alt ist, muss aber nicht schlecht sein :)
Was neuer ist, kann aber besser sein ;-)
> Der Code ist übrigens von> hier-"Beitrag "IRMP - Infrared Multi Protocol Decoder";
Mist. Spätere Versionen landeten nur noch als Download im IRMP-Artikel.
Da hast Du zu früh aufgehört mit dem Lesen des Threads ;-)
> dann werde ich mal mit dem neuen testen
Ja. Dann wirds gehen. Sicher.
Frank M. schrieb:> Was neuer ist, kann aber besser sein ;-)
Guter Source muss reifen
> Ja. Dann wirds gehen. Sicher.
jetzt ist meine Welt wieder in Ordnung!
passt perfekt
vielen Dank!!!
Hans
Hans F. schrieb:> passt perfekt
Freut mich.
Noch als letztes ein Tipp: Stopfe vor dem Senden in irmp_data.address
exakt den 16-Bit-Wert, den IRMP ausgibt. Diese 16-Bit-Adresse enthält
auch den invertierten Teil. Dann brauchst Du diese Fummelei
irmp_data.address = (a << 8) | (uint8_t)~a;
nicht zu machen.
Frank M. schrieb:>> Noch als letztes ein Tipp: Stopfe vor dem Senden in irmp_data.address> exakt den 16-Bit-Wert, den IRMP ausgibt. Diese 16-Bit-Adresse enthält> auch den invertierten Teil. Dann brauchst Du diese Fummelei>> irmp_data.address = (a << 8) | (uint8_t)~a;>> nicht zu machen.
Ja ich weis, hatte ich auch in der ersten Version.
ich fand das aber so lesbarer, weil damit sofort erkennbar ist dass das
Low Byte das invertierte Adressbyte ist.
Jetzt muss ich nur mal schauen wie ich hierzu ne schöne Platine
hinbekomme.
Ist schon ein paar Jahre her, das ich die letzte gemacht habe.
Damals wurde das Layout noch auf Folie geklebt :)
Mal schauen ob ich das mit der Bügeltechnik hinbekomme.
Sollte für die kleine Schhaltung reichen.
nochmals Danke!
Gruss Hans
Hans F. schrieb:> ich fand das aber so lesbarer, weil damit sofort erkennbar ist dass das> Low Byte das invertierte Adressbyte ist.
Das stimmt aber nur bedingt, d.h. bei Deiner Anwendung. Im
Extended-NEC-Protokoll wurde diese Beschränkung aufgehoben. Damit ist es
dann eine echte 16-Bit-Adresse. Willst Du Deine Anwendung später auf ein
anderes Gerät übertragen, wird es evtl. so nicht mehr funktionieren.
> Jetzt muss ich nur mal schauen wie ich hierzu ne schöne Platine> hinbekomme.
Wie aufwändig ist denn die Schaltung? Was ist denn da außer dem µC, der
IR-Diode, dem Transistor und dem Widerstand noch notwendig?
Eventuell reicht da ja ein Stück Lochrasterplatine.
> Ist schon ein paar Jahre her, das ich die letzte gemacht habe.> Damals wurde das Layout noch auf Folie geklebt :)
Kenne ich, so habe ich damals auch angefangen. Ist aber schon über 25
Jahre her.
> Sollte für die kleine Schhaltung reichen.
Zeig doch mal. Bin neugierig :-)
Frank M. schrieb:> Eventuell reicht da ja ein Stück Lochrasterplatine.
Wird sicher reichen. Ich bin da aber etwas perfektionistisch.
Soll ja auch ein paar Jahre halten.
> Zeig doch mal. Bin neugierig :-)
Im Moment läufts erst noch auf den Testboard.
Kämpfe gerade noch damit mein Programm mit den aktuellen IRSND Sourcen
lauffähig zu bekommen.
Irgendwas hab ich verdaddelt, kriegs nicht durch den Compiler, es gibt
aber auch keine aussagekräftige Fehlermeldung.
Das gleiche hatte ich vorhin mit dem Receiver auch.
Da reichte es den Compiler neu zu starten.
Werds schon finden.
Danach werde ich die Schaltung in Target erstellen.
Im Moment gibts die nur in meinem Kopf.
Wenns soweit ist, stelle ich das hier mal vor.
Gruß Hans
Hans F. schrieb:> Irgendwas hab ich verdaddelt, kriegs nicht durch den Compiler, es gibt> aber auch keine aussagekräftige Fehlermeldung.
Naja, irgendeine Fehlermeldung muss doch da sein. F_CPU im Projekt
gesetzt? Target-µC im Projekt korrekt ausgewählt? IRSND_OC2 in
irsndconfig.h eingestellt?
> Das gleiche hatte ich vorhin mit dem Receiver auch.> Da reichte es den Compiler neu zu starten.
Merkwürdig.
> Danach werde ich die Schaltung in Target erstellen.> Im Moment gibts die nur in meinem Kopf.> Wenns soweit ist, stelle ich das hier mal vor.
Prima, bin gespannt.
Frank M. schrieb:> Naja, irgendeine Fehlermeldung muss doch da sein. F_CPU im Projekt> gesetzt? Target-µC im Projekt korrekt ausgewählt? IRSND_OC2 in> irsndconfig.h eingestellt?>
Ja gibt es
1
RunCompilerTask-Aufgabe
2
C:\Program Files (x86)\Atmel\Atmel Studio 6.0\make\make.exe all
3
make: *** No rule to make target `irsnd.o', needed by `out.elf'. Stop.
4
Die Ausführung der RunCompilerTask-Aufgabe ist abgeschlossen -- FEHLER.
5
Die Erstellung des Ziels "CoreBuild" im Projekt "GccRadio2.cproj" ist abgeschlossen -- FEHLER.
6
Die Erstellung des Projekts "GccRadio2.cproj" ist abgeschlossen -- FEHLER.
7
8
Fehler beim Erstellen
9
========== Build: 0 erfolgreich oder aktuell, Fehler bei 1, 0 übersprungen ==========
nur weis ich nicht wo's herkommt
Das gleiche hatte ich vorhin im Receiver Source auch.
Nach Neustart des Studio ging's, jetzt leider nicht.
Ich werd' jetzt mal ein neues Projekt mit den Sourcen erstellen.
Frank M. schrieb:> Hans F. schrieb:>> Ich würde mir gerne auf einen Output das Signal ohne Träger ausgeben.>> Hatte ich schon mal im IRMP-Thread der Codesammlung erklärt:>> Beitrag "Re: IRMP - Infrared Multi Protocol Decoder">> Wenn Du jedoch beide Signale (moduliert und unmoduliert) haben möchtest,> verwende den callback-Pointer, um einen weiteren Ausgang ein- und> auszuschalten. Den Callback-Mechanismus kannst Du über irsndconfig.h> einschalten. Der Rest ist im IRMP/IRSND-Artikel erklärt.
Hallo Frank,
das funktioniert so nicht.
Wenn ich beide Signale verwenden will und den Callback Pointer nutze
wird der Callback im Takt des 36KHz Clocks aufgerufen (moduliert).
Somit bringt der das gleiche Signal wie der Port IRSND_BIT_NUMBER
Gruß Hans
So es war fast geschafft.
Software ist fertig und funktioniert sehr gut.
Schaltbild und Layout waren (fast) fertig.
Bei den letzten Schönheitskorrekturen hat Target mir dann das Projekt
zerschossen und gelöscht.
Ausser einem Preview der Platine ist nichts mehr übrig.
Auf ein neues.....
Hans F. schrieb:> Wenn ich beide Signale verwenden will und den Callback Pointer nutze> wird der Callback im Takt des 36KHz Clocks aufgerufen (moduliert).> Somit bringt der das gleiche Signal wie der Port IRSND_BIT_NUMBER
Nein, das kann nicht sein. Die Modulation wird per Hardware-PWM erzeugt.
Mittels Software über Deinen Pin in der Callback-Funktion geht das schon
technisch nicht.
Bitte überprüfe das nochmal. Sonst zeige bitte irsndconfig.h und Deine
Callback-Funktion.
Auf Deinem Oszi-Bild sieht man die Modulation auch gar nicht. Da sehe
ich nur das nackte Signal. Da müsstest Du schon eine höhere
Zeitauflösung wählen.
Frank M. schrieb:> Nein, das kann nicht sein. Die Modulation wird per Hardware-PWM erzeugt.> Mittels Software über Deinen Pin in der Callback-Funktion geht das schon> technisch nicht.>> Bitte überprüfe das nochmal. Sonst zeige bitte irsndconfig.h und Deine> Callback-Funktion.
Ich werde das bei nächster Gelegenheit noch mal prüfen und das Ergebnis
hier posten. Zur Zeit komme ich leider nicht dazu.
Thread beobachten
Seitenaufteilung abschalten