Hallo, habe zur Anwendung des Programms Fragen. Zunächst habe ich die
AVR-Version (irmp-main-avr.c) ausgesucht und Änderungen zur Anpassung an
den ATMEGA168P (Hardware Pin an PORTD2) in irmpconfig.h gemacht.
Nirgendwo konnte ich allerdings die F_CPU Anpassung finden, doch das
Programm wurde fehlerlos compiliert. Da ich annahm, dass irgendwo F_CPU
auf 8MHz definiert ist, habe ich in irmp-main-avr.c statt #error ... in
#define F_CPU 16000000UL; geändert. Damit ich überhaupt was sehe, habe
ich weiter im Demo-Programm die Endlos-Schleife mit einer blinkenden LED
an PORTB5 angepasst
for (;;)
{
if (irmp_get_data (&irmp_data))
{
// got an IR message, do something
if(PINB & (1<<5)) {PORTB &= !(1<<5);} // LED an
else {PORTB |= (1<<5);} // LED aus
}
}
Danach im Studio7 compiliert und per usbasp in den ATMEGA geladen. Mit
der MEDION Fernbedienung für MD84627 ging nichts. Dann habe ich meine
PANASONIC FB genommen aber auch damit blinkt die LED nicht. Dann
PANASONIC =1 und Kaseikyo =0 auch kein Erfolg.
Welchen Fehler mache ich?
mfG Frewer
Nur weil Du F_CPU auf einen bestimmten Wert setzt, tickt die CPU noch
lange nicht mit dieser Frequenz - das kannst Du einzig über das korrekte
Setzen der AVR Fuses bewirken. Also, schreibe Dir mal ein
Minimalprogramm mit LED an - 500 ms warten - LED aus - 500 ms warten,
und schaue, ob die LED tatsächlich im 1s-Rhythmus blinkt. Erst dann
weitermachen mit IRMP, wenn das erfolgreich war!
Ja Thilo, das ist mir bekannt. In meinen Programmen wird zuerst mal
F_CPU definiert, da zBsp sonst die util/delay.h einen Fehler meldet.
Mich machte nur stutzig, dass bei meiner F_CPU Definition der Compiler
ein "redefine..." als Warnung meldet. Habe nunmehr festgestellt, dass in
der Toolchain F_CPU auf 8MHz voreingestellt ist. Das habe ich m.E. jetzt
mit der Neudefinition auf 16MHz geändert. Die LED sollte im
irmp-Hauptprogramm nur melden, dass die irq-Routine mit einer Erkenntnis
zurück ins Hauptprogramm gekommen ist (in der for-Schleife unter "// got
a message" etwas angezeigt wird). Das aber tut es nicht.
mfG Frewer
Werner F. schrieb:> Welchen Fehler mache ich?
- das Signal kommt nicht an
- dein Empfänger ist kaputt
- ...
- das Signal kommt an, wird aber nicht dekodiert
- IRMP kann es nicht
- ...
- das Signal kommt an, wird dekodiert, aber dein Programm hat einen
Fehler
- ...
Werner F. schrieb:> if(PINB & (1<<5)) {PORTB &= !(1<<5);} // LED an> else {PORTB |= (1<<5);} // LED aus
warum nicht einfach ein
PORTB &= ~(1<<PB5) // toggle LED
hui schrieb:> falsches Forum übrigens
Und wie komme ich ins richtige? Habe im wiki die Anweisung ausgfüllt,
that's it.
2. habe mit dem Oszillographen verifiziert, dass das Signal einwandfrei
an PIND2 ansteht (TSOP gemäß Bild im Artikel). Mein Test war mit der
PANASONIC FStg ebenfalls nicht erfolgreich. Es sollte daher am Programm
liegen. Doch fehlt mir irgendwie eine Beschreibung, wie man mit dem
Programm umgeht. Die Analyse des Programms ist für mich schwierig, da
die C-Programmierung aus meiner Sicht ganz schön den Compiler ausreizt.
3. Das MEDION-Protokoll: (nach dem TSOP Impulse L)
Sync: 9,2ms L + 4,5ms H
Daten: 0,76ms L + 0,45ms H bzw 0,76ms L + 1,6ms H
insgesamt Sync + 32 Daten + Endbit(0,76ms L)
4. Horst: na klar geht einfacher, macht aber den "Bock nicht fett" und
löst mein Problem nicht!
mfG Frewer
Werner F. schrieb:> macht aber den "Bock nicht fett"
doch, du benutzt das falsche NOT, das logische und nicht das bitweise.
wobei ein &= auch nicht umschaltet, dafür bräuchte man ein EXOR, also
^=.
Johannes S. schrieb:> wobei ein &= auch nicht umschaltet, dafür bräuchte man ein EXOR, also> ^=.
Ich hab ja auch Unsinn geschrieben, das währe LED aus.
Ich wollte schreiben:
PORTB ^= (1<<PB5) // toggle LED
1. hui: Das Original steht im Forum "Projekte&Code" und meine Frage
dito. Demnach bin ich vollkommen richtig hier.
2. irmp scheint zu laufen. Jedenfalls leuchtet meine LED, wenn ich die
FStg gedrückt habe. Es war ein Anfängerfehler, hatte vergessen den
LED-PORT auf Ausgang zu setzen.
3. mein nächster Schritt ist jetzt die Anzeige des Codes über eine
LCD-Anzeige oder über den UART auf den PC. Mal sehen.
mfG Frewer
Frewer schrieb:> Es war ein Anfängerfehler, hatte vergessen den> LED-PORT auf Ausgang zu setzen.
was den Fehler mit dem falschen Operator immer noch einen Fehler sein
lässt.
> Welchen Fehler mache ich?
keine Fragen, Projektvorstellung mit HW und SW.
Mich stört es nicht weil ich sowieso immer über
https://www.mikrocontroller.net/forum/all hier einsteige.
Werner F. schrieb:> Da ich annahm, dass irgendwo F_CPU auf 8MHz definiert ist, habe ich in> irmp-main-avr.c statt #error ... in #define F_CPU 16000000UL; geändert.
Das ist schlecht, mache das bitte rückgängig! Der #error ist bewusst
gewählt!
F_CPU sollte genau einmal definiert sein, und zwar nicht in den
C-Sources oder Headers, sondern in den IDE-Einstellungen. Sonst gibt es
Kuddelmuddel bei der Übersetzung jedes C-Files, welches F_CPU benötigt.
Wie willst Du einen einheitlichen Wert garantieren, wenn nicht in den
Projekteinstellungen oder im Makefile?
Du bekommst beim Compilieren eine Fehlermeldung, wenn F_CPU nicht in den
Projekteinstellungen definiert ist. Wenn Du keine bekommst, dann scheint
F_CPU im Projekt bereits definiert zu sein. Suche danach und stelle den
Wert korrekt ein!
Wenn Du im IRMP Artikel unter
https://www.mikrocontroller.net/articles/IRMP#Source-Code nachschaust,
wirst Du auch ein dickes rotes Kästchen sehen, welches die richtige
Anwendung von F_CPU erläutert, siehe auch Bild.
Offenbar hast Du das rote Kästchen übersehen.
Danke Frank für die Info. Ich habe das rote Kästchen sehr wohl gelesen,
den unteren Teil aber nicht wirklich verstanden. Bin halt weit entfernt
vom Programmier-Profi. Da ich Studio7 benutze, habe ich mit dem Makefile
nichts zu tun und wohl auch keinen Einfluss darauf. Ein sog. Projektfile
ist mir bisher unbekannt, obwohl ich schon viele Projekte mit AVR's in
Ass und C hinter mir habe. Bei der Suche nach einer ersten Definition
von F_CPU meldet Studio7 eine Datei "irmp". Die sieht nach einem
Projektfile aus. Wie ich den allerdings erzeuge, ist mir unklar. Ich
habe nach Recherche im Internet (Wolles Elektronikkiste) gelernt, dass
ich mit dem "Hammer" Symbol einen File öffne, in dem der µC unter
"Device" und unter "toolchain-Symbol" die Frequenz eingegeben werden
kann. Allerdings ist mir diese Datei immer nur dann aufgefallen, wenn
ich in einem Projekt den Simulator benutzen will und dieser in dieser
Datei unter "tools" noch nicht angewählt ist. Mein Schluss aus diesem
Vorgehen war, dass diese Angaben nur für die Simulatornutzung relevant
sind. Neue Erkenntnis: Ist wohl nicht so! Habe jetzt in dieser Datei die
Frequenz auf 16MHz geändert und damit erscheint auch kein Fehler mehr.
mfG Frewer
Frewer schrieb:> Da ich Studio7 benutze, habe ich mit dem Makefile> nichts zu tun und wohl auch keinen Einfluss darauf.
Doch. In den Project Settings findest du auch optionale Ergänzungen des
make Files und da schreibst du rein
1
-D F_CPU 16000000
Es ist auch egal dabei, ob du Atmel Studio 7 oder Microchip Studio 7
benutzt, das ist die gleiche IDE, nur, das Microchip den Namen geändert
hat und ein paar Links auf Microchip umgebogen hat.
IRMP ist recht gutmütig, du solltest aber nach erfolgreichem Empfang
auch aufs Protokoll und die richtige Subadresse prüfen, bevor du mit den
Daten was anfängst:
Vielen Dank für die Info. Ich habe mittlerweile das Thema
Projektfile-Makefile kapiert und angepasst. Und in Zukunft werde ich
darauf achten, da ich immer mal wieder Probleme mit der
Frequenzeinstellung im Simulator hatte. Das ist jetzt klar soweit. Bin
gerade dabei, meinem "alten" PC mit WIN10 ein Terminalprogramm zu
verpassen, damit ich mit dem UART den Code meiner FStg mal sehen kann.
Bin gespannt.
mfG Frewer
Frewer schrieb:> Bin> gerade dabei, meinem "alten" PC mit WIN10 ein Terminalprogramm zu> verpassen, damit ich mit dem UART den Code meiner FStg mal sehen kann.
Das klingt doch gut. Ich habe dazu einen Mega328 mit LC-Display und so
gut wie allen Protokollen programmiert, der mir auf dem Display
Protokoll, Subadresse und Kommandocode anzeigt. Damit schnüffele ich
nach Bedarf unbekannte Fernbedienungen aus.
kannst Du Deine Lösung mit dem LCD nicht hier mal vorstellen? Würde mich
sehr interessieren, bevor ich loslege und meinen PC aktiviere. Die Idee
gefällt mir sehr gut.
habe mit der RS232 Schnittstelle und irmp-main-avr-uart.c die MEDION
FStg getestet mit folgendem Ergebnis:
protocol: 0x02 -> NEC
address : 0xFF00
command : 0x0045 -> Ein/Aus
flag : 0x00 manchmal 0x01 oder 0x02
Das scheint mit dem Oszillogramm übereinzustimmen (Sync + 33Bit).
Der Test mit der Panasonic FStg bringt das Ergebnis:
protocol: 0x05 -> Panasonic
address : 0x2002
command : 0x8100 -> Taste "1"
flag : 0x00 immer
Auch das scheint mir logisch. Die Überprüfung mit dem Oszi folgt.
Ansonsten vielen Dank für die positiven Kommentare, die mich ein Stück
weiter brachten. Mein nächster Schritt ist das Ganze auf einem LCD
Display anzuzeigen und dann einen entsprechenden IR-Sender zu bauen.
mfG Frewer
Werner F. schrieb:> Ansonsten vielen Dank für die positiven Kommentare, die mich ein Stück> weiter brachten. Mein nächster Schritt ist das Ganze auf einem LCD> Display anzuzeigen und dann einen entsprechenden IR-Sender zu bauen.> mfG Frewer
Hallo,
das Projekt hier kannst Du ja mal als Anregung nehmen:
https://www.mikrocontroller.net/articles/IR-LCD#Software
...und Deines dann in Projekte vorstellen...
Grüße!
Frewer schrieb:> kannst Du Deine Lösung mit dem LCD nicht hier mal vorstellen?
Ich hänge dir mal die main.c aus dem Projekt an. Das ist aber die
gleiche wie die IRMP demo, nur das ich per define auf LCD_OUTPUT
umschalten kann. Als LCD Treiber wird die Bibliothek von Peter Fleury
benutzt, die mit den HD44780 kompatiblen Modellen gut spielt.
Die Bibliothek findest hier:
http://www.peterfleury.ep?zy.com/?i=1
Weil hier irgendein Spamschutz des Forums zuschlägt, bitte ep?zy durch
epizy ersetzen.
merci Matthias für die "main.c". Die Fleury Lib benutze ich auch,
allerdings an meine Bedürfnisse angepasst.
Eine offene Frage habe ich doch noch:
Beim Testen von FStgen wird neben Adresse und Command stets noch der
Begriff flag angezeigt. Abhängig von der Dauer der Übertragung
beinhaltet flag unterschiedliche Werte (mal 00,01,02,etc). Was bedeutet
flag??
mfG Frewer
Werner F. schrieb:> Die Fleury Lib benutze ich auch,> allerdings an meine Bedürfnisse angepasst.
Das muss man ja immer machen, deswegen habe ich das weggelassen.
> Was bedeutet> flag??
Das sind Repeatcodes. M.W. gibt IRMP diese aus, wenn es von der FB diese
Codes als 'wiederholter Code' bekommt - z.B. für Tasten wie Lautstärke
oder Programmzappen.
Wenn Frank hier mal vorbeikommt, kann er da sicher was zu sagen.
Jedenfalls kann das sinnvoll sein, wenn du ein Kommando nur dann
akzeptieren willst, wenn es wiederholt wird, oder es nur beim ersten Mal
auswerten möchtest.
Werner F. schrieb:> Abhängig von der Dauer der Übertragung beinhaltet flag unterschiedliche> Werte (mal 00,01,02,etc). Was bedeutet flag??
Ist im IRMP-Artikel hier beschrieben:
https://www.mikrocontroller.net/articles/IRMP#%22Entprellen%22_von_Tasten
Das Flag IRMP_FLAG_REPETITION wird dann gesetzt, wenn der Frame aufgrund
eines langen Tastendrucks wiederholt wurde.
Willst Du nur den ersten Frame berücksichtigen und alle folgenden
identischen Frames ignorieren, dann unterscheide dies anhand des Flags,
siehe auch den Beispielcode im oben angegebenen Link - Kapitel
"Entprellen von Tasten". Dieser ist ausführlich kommentiert.
Das kann sinnvoll sein, damit eine mit der Taste verbundene Aktion nicht
versehentlich mehrfach ausgeführt wird. Willst Du aber eine
Lautstärke-Regelung bauen, wo ein langes Drücken durchaus sinnvoll ist,
dann ignoriere das Flag - zumindest für diese Taste.
Entschuldige Frank! Mit dem Lesen das ist so eine Sache. Habe viel
früher abgebrochen, da das Entprellen für meine ersten Tests gar keine
Rolle spielt und ich eigentlich ja nur mal den Code einer anderen Fstg
MEDION sehen wollte.
Beim Testen mit meinen Panasonic Fstgen (TV und DVD Recorder) fiel mir
ein auf, dass das Ergebnis mit der Beschreibung des Panasonic Codenicht
übereinstimmt. Der Code wird wie folgt beschrieben und sieht auf dem
Oszi auch so aus
Werner F. schrieb:> dass das Ergebnis mit der Beschreibung des Panasonic Codenicht> übereinstimmt.
Panasonic benutzt diverse Protokolle, nicht nur sein hauseigenes.
> Ergebnisse, die ich mit dem Oszi ermittelt habe:> Player : SyncSignal + 40 04 0D 00 88 85 = StandBy-Taste> Recorder: SyncSignal + 40 04 0D 08 88 8D = StandBy-Taste> Der gleiche Versuch mit IRMP ergibt aber> TV : Sync + 20 02 83 D0 = StandBy-Taste> Recorder: Sync + 20 02 B3 D0 = StandBy-Taste
Was heisst das? IRMP gibt keine RAW-Codes aus, sondern berechnet eine
Adresse und ein Kommando. Wie kommst Du auf die Zahlenfolge "20 02 83
D0"?
Hast Du dabei beachtet, dass IRMP sowohl PANASONIC als auch KASEIKYO als
LSB-codiert betrachtet? also wortweise von rechts nach links?
Wenn ich mir die Beschreibung von PANASONIC unter
https://www.mikrocontroller.net/articles/IRMP#PANASONIC anschaue, dann
steht da:
Das heisst:
Die Panasonic schickt 56 Datenbits, wobei die ersten 24 Bits fix sind.
Diese werden von IRMP zwar geprüft, aber nicht in der Adresse und im
Kommando hinterlegt. Dann bleiben 16 + 16 Bits im LSB-Format übrig, die
IRMP dann noch "von rechts nach links umdreht", damit sie den korrekten
Code ergeben.
Wenn das keine Erklärung für Dich ist, dann aktivierst Du am besten mal
in irmpconfig.h die Konstante IRMP_LOGGING und erstellst ein paar Scans
über UART mit einem Terminal-Programm, z.B. Putty.
Nachdem Du sie hier eingestellt hast (als Anhang - unter Angabe von
F_INTERRUPTS), kann ich mir diese dann anschauen und auch mit dem
IRMP-Analyzer (irmp-xxx -a unter Linux) prüfen. Dann bekomme ich
ziemlich schnell raus, welches Protokoll das ist.
(P.S. Ich habe Dein Posting mit [ code ] ... [ /code ] (ohne
Leerzeichen) neu formatiert, damit das auch auf Mobilgeräten mit
Proportionalschrift lesbar ist.)
Werner F. schrieb:> Frequenz 32 (33) kHz.> Frequenz 56 kHz
Beide Fernbedienungen, vor allem die KASEIKYO, sind mit einem normalen
IR Empfänger wie dem TSOP 31238 nur grenzwertig zu empfangen. für die
KASEIKYO wird auf jeden Fall ein Receiver für 56kHz nötig, wie der
TSOP31256.
Hallo Frank, hallo Matthias,
zuerst mal vielen Dank für die Erklärungen, die ich beim Lesen
verstanden habe und bei genauerer Bewertung werde zuordnen können. Denn
klar, ich habe die fest codierten Bits auch ausgelesen, da sie in meiner
Beschreibung einen Herstellercode sind. Wenn ich die weglasse, dann
komme ich der Sache ja schon näher.
1. Meine Panasonic Fernsteuerung für den DVD-Recorder ist schon einige
Jahre alt (>10) und so alt ist auch meine Code-Beschreibung. Deshalb
vielleicht die Unterschiede.
2. Ich lese den Code mit Deinem Programm IRMP-MAIN-AVR-UART.C aus, das
mir das Protokoll, die Adresse, den Command und das Flag ausgibt. Das
ganze Protokoll heißt original mit dem Terminal "hterm" empfangen:
protocol: 0x05, address: 0x2002, command: 0x83D0, flags: 0x00.
Ich habe das nur umgeschrieben zum Vergleich mit meinen alten Werten,
die ich früher mal (2009) neben dem Oszi mit einem Programm auf einem
AT89S51 ermittelt hatte.
3. meine Beschreibung des KASEIKYO Code (auch >10Jahre) diente nur der
Aussage im IRMP Artikel, dass dieser und Panasonic so gleich seien, dass
das Protokoll 5 für beide angegeben wird. Ich habe weder eine solche
FStg noch einen solchen 56kHz Empfänger.
Soweit so gut, ich muss jetzt erst einmal die restlichen Erklärungen
verdauen, mal den Oszi "anschmeissen", um die ganzen Details zu
verstehen und Deine Änderung (irmpconfig.h) mit Ausdruck machen. Ich
melde mich wieder im neuen Jahr.
mfG Frewer
Hallo Frank,
habe die Änderung mal ausprobiert und hänge die Ergebnisse für die alte
PA Recorder FStg und die neue PA TV FStg an. Bin gespannt über die
Ergebnisse.
mfG Frewer
Matthias S. schrieb:> für die> KASEIKYO wird auf jeden Fall ein Receiver für 56kHz nötig,
ich hatte gestern noch eine Panasonic mit TSOP31238 ausgelesen,
zumindest auf kurze Entfernung hat es geklappt. Haben die Kaseiykos
alles 56 kHz?
Und einige Tasten haben andere Flags, die zumindest in meiner alten IRMP
von 2016 nicht dokumentiert sind:
1
proto 5 addr 8194 cmd 34928 flags 90 name KASEIKYO : guide 8870
2
proto 5 addr 8194 cmd 33536 flags 20 name KASEIKYO : input TV 8300
3
proto 5 addr 8194 cmd 32848 flags 0 name KASEIKYO : input AV 8050
Hallo Johannes,
also ich kenne KASEIKYO erst seit ich IRMP durchgearbeitet habe. Ich
kann es auch nicht ausprobieren, keine FStg. Dagegen besitze ich wie
gesagt PANASONIC alt und neu, sowie eine Medion FStg für einen KüRadio.
Mit Panasonic habe ich kein Entfernungsproblem außer man geht aus der
Reichweite heraus. Mit dem TSOP, den ich nutze, gibt es da keine
Schwierigkeiten.
Es ist interessant, dass bei Dir die Codes ähnlich sind wie bei mir
(address: 0x2002, cmd: 0x8870). Warum die flags so große Zahlen haben
ist mir unklar (es sei denn, Du hast lange die Taste gedrückt).
Ich bin sehr gespannt, was Frank zu den Ausdrucken sagt.
mfG Frewer
die Adresse ist gleich, 0x2002 = 8194 dezimal. Das Flag für lange
Tastendrücke ist 1, ich hänge mal die ganze Liste an, da sieht man das
die Flägs wohl Gruppen wie AV oder andere Sonderfunktionen bedeuten.
Die 56 kHz stehen auch in einer im IRMP Artikel verlinkten Diplomarbeit,
wird also so sein. Habe die FB auch nicht mehr hier und kann es jetzt
nicht nachmessen. Die Filter in den TSOP sind aber sehr breitbandig und
es wird dann nur die Reichweite beeinflussen. War aber ein guter Hinweis
von Matthias.
Werner F. schrieb:> Warum die flags so große Zahlen haben ist mir unklar (es sei denn, Du> hast lange die Taste gedrückt).> Ich bin sehr gespannt, was Frank zu den Ausdrucken sagt.
Um die Flags mit den "großen Zahlen" speziell bei Kaseikyo zu erklären,
muss ich etwas weiter ausholen. Ich hatte das zwar schon mal vor einigen
Jahren im IRMP-Thread erklärt, versuche es aber jetzt nochmal.
IRMP hat den Anspruch, das verwendete IR-Protokoll zu "verstehen". Das
heisst, es extrahiert aus den Daten lediglich die tatsächlichen
Nutzinformationen. Ein IR-Frame besteht aber aus noch viel mehr, nämlich
auch aus Redundanzen durch (optional invertierte) Wiederholungen oder
Parity-Bits oder CRCs. Diese redundanten Infos gehören aber nicht zu den
Nutzdaten, sondern dienen lediglich als Hilfe, um die Gültigkeit eines
IR-Frames zu überprüfen.
IRMP extrahiert also aus den Rohdaten ("raw") die Nutzinformationen
("cooked") und prüft diese gegen die redundanten Daten. Ist die Prüfung
erfolgreich, liefert irmp_get_data() TRUE zurück - sonst nicht. In
diesem Fall liegen in irmp_data.address die Geräteadresse und in
data.command das Kommando vor.
So schafft es IRMP, auch Frames, die wesentlich länger als 16+16=32
Bits sind, redundanzfrei in lediglich 32 Bit zu speichern. Aus diesen
beiden Angaben kann IRSND (das Gegenstück zu IRMP) den IR-Frame
verlustfrei wieder reproduzieren - also aus den Cooked-Daten den
Raw-Frame generieren und auf einer IR-Diode wieder ausgeben.
Das einzige Protokoll, wo es IRMP nicht schafft, die Nutzdaten auf
16+16=32 Bits einzustampfen, ist KASEIKYO. Ein Kaseikyo-Frame besteht
aus 48 Bits Daten, von denen 36 Bits tatsächlich Nutzdaten und
zusätzlich 12 Bits Parity-Bits sind, siehe auch
https://www.mikrocontroller.net/articles/IRMP#KASEIKYO .
Von daher gibt es das Problem, dass 36 Bits in die 32 Bit-Datenstruktur
von IRMP "gepresst" werden müssen. Ich habe das so gelöst, dass ich die
Bedeutung von irmp_data.flags erweitert habe, nämlich so:
1
Das Kommando setzt sich zusammen aus:
2
1. irmp_data.command
3
2. irmp_data.flags im oberen Nibble (obere 4 Bits)
So bleibt die Kompatibilität zu Non-Kaseikyo-Protokollen bestehen, da
nämlich bei allen anderen Protokollen die 4 oberen Bits von flags immer
0 sind. Und auch nur in Ausnahmefällen ist das obere Nibble beim
Kaseikyo-Protokoll ungleich 0, denn hier speichert IRMP die 4
Genre2-Bits von Kaseikyo, die oft unspezifiert und damit 0 sind.
Das heißt:
Um einen mit IRMP empfangenen Frame mittels IRSND wieder
auszusenden, muss man folgendes tun:
1
1. irmp_data.address mit der empfangenen Adresse füllen
2
2. irmp_data.command mit dem empfangenen Kommando füllen
3
3. Im oberen Nibble von irmp_data.flags das empfangene obere Nibble füllen.
4
4. Im unteren Nibble von irmp_data.flags die Anzahl der Wiederholungen setzen (Wert von 0..15)
Das "Schöne" an dieser Erweiterung ist: Der Schritt 3 kann kann bei
allen Protokollen außer Kaseikyo entfallen, bietet also höchstmögliche
Rückwärtskompatibilität. Und selbst bei Kaseikyo ist das obere Nibble
von flags oft 0.
Als Alternative könnte ich auch IRMP auf 32 Bit Adresse und 32 Bit
Kommando aufbohren. Auf 32-Bittern wie STM32 wäre das auch kein Problem,
auf AVRs könnte das bei einigen Anwendungen jedoch zu Problemen führen,
da hier die ISR ziemlich zeitintensiv 32-Bit-Variablen bearbeiten (im
wesentlichen shiften) müsste - was nicht gerade zur Stärke eines AVR-µCs
gehört. Von daher wurden mir von einigen Usern Probleme gemeldet, die
eine spezielle IRMP-Version mit der Möglichkeit, IRMP auf 32 Bit
umzustellen, getestet hatten.
Ich hoffe, dass ich damit alle Klarheiten beseitigt habe. Ja, ich müsste
das spezielle KASEIKYO-Verhalten mal im Artikel dokumentieren. Bisher
bin ich aber aus Faulheit nicht dazu gekommen ;-)
P.S.
In IRMP testet man das Wiederholungs-Bit natürlich immer mit:
1
if(irmp_data.flags&IRMP_FLAG_REPETITION)
bzw. das Loslassen einer Taste (optional) mit:
1
if(irmp_data.flags&IRMP_FLAG_RELEASE)
so dass ein etwaiger Wert im oberen Nibble in irmp_data.flags überhaupt
nicht stört.
Keinesfalls sollte man Frame-Wiederholungen mit
1
if(irmp_data.flags>0)
testen, denn das hat mit irgendwie gesetzten Bits in Flags überhaupt
nichts zu tun!
Johannes S. schrieb:> Haben die Kaseiykos alles 56 kHz?
Das weiß ich auch nicht, aber ich hatte damals im IRMP-Artikel zu
Kaseikyo (hier auch "Japan-Code" genannt) zwei Literatur-Hinweise
hinterlegt:
https://www.mikrocontroller.net/articles/IRMP#KASEIKYO-Protokoll_(auch_%22Japan-Protokoll%22)
Der erste Link dokumentiert Kaseikyo mit 56 kHz, der zweite mit 38 kHz.
Den usprünglichen Link auf die offizielle Kaseikyo-Dokumentation, nach
der ich damals das Protokoll implementiert hatte, finde ich nicht mehr.
die FB habe ich ja mit einem 38 kHz Empfänger ausgelesen bekommen, die
Sendeseite kann ich ja umschaltbar machen um sicher zu gehen, da ist die
Trägerfrequenz ja eine SW Sache.
Werner F. schrieb:> Hallo Frank,> habe die Änderung mal ausprobiert und hänge die Ergebnisse für die alte> PA Recorder FStg und die neue PA TV FStg an. Bin gespannt über die> Ergebnisse.
Danke für die Scans. Dein Recorder bzw. Dein TV benutzt ein etwas
abgeändertes Protokoll zu dem, was ich unter PANASONIC implementiert
habe. Damals lagen mir nur Daten für einen speziellen Panasonic-Beamer
vor. Deine FBs senden lediglich 48 statt 56 Bits, sind aber vom Timing
her sehr ähnlich und innerhalb der Toleranzen.
Um diese FBs zu unterstützen, müsste ich ein weiteres Protokoll
PANASONIC2 einführen. Wenn dies für Dich wichtig ist, kann ich das
implementieren. Dauert aber ein paar Tage, da ich momentan wenig Zeit
dafür habe.
vielen Dank Frank für das Angebot, Dich um die Ergänzung zu bemühen. Mir
ging es um meine Medion FStg. Die Panasonic habe ich nur benutzt, um
IRMP bedienen zu lernen (MEDION wird im Artikel nicht angesprochen) und
meinen TSOP-> UART Adapter auszutesten. Und dafür hat es ja prima
gereicht. Mein Ziel ist es für den Medion FStg Sender eine Alternative
zu bauen, mit dem ich Tastenfunktionen kreieren kann. Ich habe nämlich
mehrere Geräte, die auf Tasten der MEDION FStg ansprechen, aber wohl
andere Tastencodes zusätzlich benötigen (was mir beim Auslesen der FStg
auch deutlich geworden ist). Dazu will ich Deine Software IRSND
benutzen. Mal sehen, ob ich das hinkriege im neuen Jahr.
Gruß Frewer
Werner F. schrieb:> Mein Ziel ist es für den Medion FStg Sender eine Alternative zu bauen
Offenbar hast Du ja schon herausgefunden, welches Protokoll die Medion
benutzt, nämlich NEC. Das wird auch mit IRSND out-of-the box gehen, ich
selber habe schon mehrere FBs mit IRSND und NEC-Protokoll realisiert.
Frank M. schrieb:> Das wird auch mit IRSND out-of-the box gehen
Überhaupt keine Frage. Falls der TE Interesse hat, poste ich gerne den
Code meiner Spitzenfernbedienung :-P:
Beitrag "Re: Quick&dirty - schnelle Problemlösungen selbst gebaut"
Allerdings gabs dazu nie einen Schaltplan. Sollte aber aus dem Code
hervorgehen.
Werner F. schrieb:> MEDION wird im Artikel nicht angesprochen
Aus gutem Grund, Medion benutzt jedes Protokoll, was nicht bei 3 aufm
Baum ist :-) Ich hatte hier auch schon einen Medion TV mit RC5.
Hallo Matthias,
bin sehr interessiert an Deinem Code. Habe mir Deine Lösung angesehen
und finde die super einfach für die Anwendung, die ich mir vorstelle.
Schaltplan ist kein Problem. Thanks im Voraus.
mfG Frewer
Werner F. schrieb:> Thanks im Voraus.
Da nich' für :-) Frank ist der Held - anbei das Archiv, sollte ohne
Probleme auf Atmel Studio 7 aka Microchip Studio 7 kompilieren.
Die Matrix sind 2 Zeilen an PortD und 2*8 Tasten, die an Port A
abgefragt werden.
Beim Tastendruck wacht der MC auf und scannt die Tasten. Die beiden
anderen PORTD sind auch verwendbar, im Moment aber für Debug Zwecke
missbraucht. Mittlerweile habe ich die Rundzelle durch einen flachen
Telefonakku ersetzt, dann ist das Ding etwas handlicher. Hält nach wie
vor seit Monaten ohne Nachladen.
Am IR Ausgang hängt ein BC547 mit 1k Vorwiderstand an der Basis. Der
Kollektor treibt die IR-LED (oder auch 2 parallel) über jeweils einen 27
Ohm Widerstand.
Vielen Dank Matthias, werde das Ganze jetzt mal verdauen (bin schon
etwas älter und langsamer) und die Elektronik konkret aufbauen. ZZt bin
ich noch auf einem Brettboard. Da sieht alles etwas unübersichtlich aus.
Der Empfänger läuft aber einwandfrei mit einem TSOP ?? und ATmega168p
(Nano Arduino Verschnitt von Pollin auf 5V getrimmt).
Melde mich hier wieder, wenn es soweit ist. Habe doch noch einige
gedankliche Probleme mit Franks Programmen, die ich noch gerne abklären
möchte. Muss aber meine Verständnisfragen zuerst mal noch
konkretisieren. ZBsp ist mir noch unklar, wie ich die beiden
selbstständigen Programme IRMP.c und IRSND.c zusammenpacke. In den
config.h Dateien sind ja viele gleiche Pakete. Vielleicht habe ich aber
beim mehrfachen durchlesen der vielen Artikel zum Thema wieder etwas
übersehen, nicht kapiert oder..
mfG
Frewer
Einfach gesagt, für einen IR Sender brauchst du nur IRSND und für einen
Empfänger nur IRMP. Der kleine ATTiny2313 könnte gar nicht beides
schlucken, da er nur 2kByte Flash besitzt. Man bekommt zwar sicher 2-3
Protokolle da rein, aber nicht Sender und Empfängersoftware
gleichzeitig.
Das Problem gibts beim Mega328 natürlich nicht. Für mich war wichtig,
das die Fernbedienung mit einer LiIon Zelle (3,5 - 4,2 Volt) läuft.
Deswegen auch nur 8MHz Takt. Willst du einen MC schneller takten, musst
du ihm nämlich auch die vollen 5V geben.
Der o.a. IRMP Schnüffler mit LCD läuft auch mit einem Mega328, damit die
ganzen Protokolle reinpassen.
Werner F. schrieb:> (bin schon> etwas älter und langsamer)
Lass dir Zeit, man wird ja nie zu alt, um etwas zu lernen, das hält
frisch. Bin auch nicht mehr der Jüngste, habe aber Spass am Basteln und
Werkeln. Und solange es Winter bleibt, ist es im Haus gemütlicher als
draussen, also wird gelötet und programmiert :-)
Thread beobachten
Seitenaufteilung abschalten