Hallo,
ich habe hier zwei Fernbedienungen, die nur teilweise mit einem
IRMP-STM32-USB-IR-Empfänger an zwei VDRs funktionieren. Grundsätzlich
bekomme ich per irw eine Funktion mit allen Tasten aber der VDR reagiert
nicht auf alle. Interessant finde ich auch, dass wenn ich einen Kanal
hochschalte zwar hochgeschaltet wird aber ca. 2 Sekunden später wieder
zurück.
Die eine Fernbedienung ist eine Terratec Cinergy XS. Diese gab es als
Set incl. USB Bulk und als FB für den USB DVB-T Stick. Die zweite
Fernbedienung ist von einem COMAG Receiver SL40HD.
1.
https://www.amazon.de/Terratec-Cinergy-Hybrid-TV-Karte-Analog/dp/B000B48T62/ref=sr_1_11?ie=UTF8&qid=1518027315&sr=8-11&keywords=terratec+fernbedienung
2.
https://www.amazon.de/COMAG-Fernbedienung-f%C3%BCr-SL-HD25-schwarz/dp/B006KC6MT0
Ich hatte beide Fernbedienungen erfolgreich mit dem Atric Einschalter
Rev. 5 (Seriell) an zwei VDRs betreiben.
Im VDR Portal hat User seahawk1986 herausgefunden, dass es sich bei
beiden um Fernbedienungen mit dem NEC Protokoll handelt.
mode2 Ausgabe der Terratec Cinergy Fernbedienung:
1
space 16777215
2
pulse 9050
3
space 4456
4
pulse 610
5
space 524
6
pulse 589
7
space 518
8
pulse 616
9
space 1653
10
pulse 582
11
space 526
12
pulse 606
13
space 1663
14
pulse 582
15
space 526
16
pulse 608
17
space 526
18
pulse 607
19
space 525
20
pulse 591
21
space 1654
22
pulse 609
23
space 1633
24
pulse 614
25
space 519
26
pulse 613
27
space 1631
28
pulse 615
29
space 517
30
pulse 604
31
space 1638
32
pulse 609
33
space 1661
34
pulse 584
35
space 1657
36
pulse 610
37
space 525
38
pulse 586
39
space 522
40
pulse 610
41
space 524
42
pulse 612
43
space 522
44
pulse 590
45
space 1652
46
pulse 614
47
space 521
48
pulse 592
49
space 517
50
pulse 615
51
space 518
52
pulse 605
53
space 1638
54
pulse 606
55
space 1663
56
pulse 584
57
space 1659
58
pulse 608
59
space 1633
60
pulse 612
61
space 523
Die andere Fernbedienung lasse ich erstmal weg.
Die Frage ist, gibt es eine Tuning Möglichkeit von IRMP, um
Fernbedienungen mit problematischem NEC Protokoll zu konfigurieren?
Danke und Gruß
Obelix
"T." ". schrieb:> Die Frage ist, gibt es eine Tuning Möglichkeit von IRMP, um> Fernbedienungen mit problematischem NEC Protokoll zu konfigurieren?
Was ist denn hier "problematisch"? Das Timing?
Die NEC-Timings findest Du hier:
https://www.mikrocontroller.net/articles/IRMP#NEC_.2B_extended_NEC
Abgesehen vom Start-Bit haben wir 560µs-Pulse und Pausen von 560µs oder
1690µs (Space).
Deine FB benutzt jedoch Pulse von ca. 610 µs. Das ist eine Abweichung
von ca. 10%. Um das in IRMP anzupassen, könntest Du die Werte in
irmpprotocols.h annähern:
Aber eigentlich sollten die Standard-Werte von IRMP völlig ausreichen,
um alle Tasten Deiner FB zu erkennen, denn IRMP ist das ziemlich
tolerant, was das NEC-Protokoll betrifft, siehe irmp.c:
Das heisst, dass IRMP Abweichungen von bis zu 30% nach unten bzw. oben
akzeptiert. Bei Deinen 10% sollte es daher kein Problem geben.
Für weitergehende Hilfe brauche ich mehr Infos. Werden bestimmte Tasten
konsequent nicht erkannt oder nur sporadisch welche nicht erkannt?
Weicht bei den nicht-erkannten Tasten vielleicht das Timing komplett ab?
Was läuft sonst noch auf Deinem µC? Gibt es z.B. höher priorisierte
Interrups? Wie ist bei Dir F_INTERRUPTS eingestellt?
Stelle F_INTERRUPTS mal auf 10000, das reicht für NEC aus.
Die Terratec der Cinergy funktionieren bei mir problemlos mit IRMP. Das
ist NEC Standard Protokoll. Vielleicht hat der MC Timing-Probleme?
Andere NEC gehen?
Ich konnte den Fehler eingrenzen. Ein Test mit yaVDR zeigte, dass beide
NEC Fernbedienungen ohne murren funktionieren. Ich werde das mal im
easyVDR Forum ansprechen.
Hi,
zusammen mit Usern aus dem vdr-portal und easyVDR Forum konnten wir dem
Problem auf den Grund gehen. Herausgekommen ist, dass der Repeat nach
einer Pause nicht mit Null weiter geht.
Hier die irw Ausgabe. Die beiden Leerzeilen dienen der besseren
Übersicht. Dort war die Pause.
1
1518798560.124436: 106545 02eb14001200 f KEY_OK IRMP
"T." ". schrieb:> Herausgekommen ist, dass der Repeat nach einer Pause nicht mit Null> weiter geht.
Ehrlich gesagt, habe ich das nicht verstanden. Vielleicht kannst Du das
näher erläutern.
Läufts jetzt mit IRMP? Wenn ja, was musstest Du ändern?
Nein, geht leider nicht.
In der dritten Spalte von rechts werden die Repeats hochgezählt.
Es wird also ein neuer Tastendruck nach einer Pause fälschlich als
Wiederholung erkannt.
0belix poste mal mode2 von Tastendruck-Pause-derselbe Tastendruck.
Jörg R. schrieb:> Nein, geht leider nicht.> In der dritten Spalte von rechts werden die Repeats hochgezählt.> Es wird also ein neuer Tastendruck nach einer Pause fälschlich als> Wiederholung erkannt.>> 0belix poste mal mode2 von Tastendruck-Pause-derselbe Tastendruck.
Hier die mode2 Ausgabe der Terratec Fernbedienung:
Mir geht gerade auf: Es werden bei den problematischen Tasten ja sogar
alle Tastendrücke als Wiederholung erkannt, auch wenn sie neu sind.
0belix poste bitte auch den mode2 von Tastendruck-Pause-derselbe
Tastendruck bei einer "guten" Taste. Dann sollte man den Unterschied
sehen können.
Jörg R. schrieb:> Mir geht gerade auf: Es werden bei den problematischen Tasten ja sogar> alle Tastendrücke als Wiederholung erkannt, auch wenn sie neu sind.
Was heisst neu? Unterschiedlich zum Tastendruck davor? Oder ein- und
dieselbe Taste zweimal hintereinander kurz gedrückt?
Sehr merkwürdig. Wie groß ist denn der Abstand zwischen zwei
Tastendrücken? IRMP benutzt bei NEC zwei Methoden, um lange Tastendrücke
zu erkennen:
1. Es wird ein spezieller NEC-Repetition-Frame gesendet -> Wiederholung
2. Die beiden identischen(!) Frames kommen hintereinander mit
einem Abstand von weniger als x msec rein.
Methode 2 wird nur deshalb zusätzlich angewandt, weil einige
NEC-kompatible Fernbedienungen keinen NEC-Repetition-Frame beherrschen.
Jörg R. schrieb:> Mir geht gerade auf: Es werden bei den problematischen Tasten ja sogar> alle Tastendrücke als Wiederholung erkannt, auch wenn sie neu sind.>> 0belix poste bitte auch den mode2 von Tastendruck-Pause-derselbe> Tastendruck bei einer "guten" Taste. Dann sollte man den Unterschied> sehen können.
Das ist die Up Taste:
Ich habe gerade ein kleines Programm geschrieben, um Euer Space/Pulse
Log-Format in das IRMP-Log-Format zu konvertieren.
Darauf habe ich den IRMP losgelassen.
Mode2:
00101000110101110110000010011111 p= 2 (NEC), a=0xeb14, c=0x0006, f=0x00
00101000110101110110000010011111 p= 2 (NEC), a=0xeb14, c=0x0006, f=0x00
address: 0xeb14
command: 0x0006
Es wird kein Repetition-Flag gesetzt, denn f = flag ist 0x00.
Up-Taste:
00101000110101110000100011110111 p= 2 (NEC), a=0xeb14, c=0x0010, f=0x00
00101000110101110000100011110111 p= 2 (NEC), a=0xeb14, c=0x0010, f=0x00
address: 0xeb14
command: 0x0010
Auch hier wird kein Repetition-Flag gesetzt, denn f = flag ist 0x00.
Irgendwas macht Ihr falsch bzw. anders.
Bitte die obige Frage beantworten:
Was heisst neu? Unterschiedlich zum Tastendruck davor? Oder ein- und
dieselbe Taste zweimal hintereinander kurz gedrückt?
Frank M. schrieb:> Was heisst neu? Unterschiedlich zum Tastendruck davor? Oder ein- und> dieselbe Taste zweimal hintereinander kurz gedrückt?
Beides. Sowohl unterschiedlicher Tastendruck als auch dieselbe Taste
mehrfach gedrückt werden fälschlich als Wiederholung erkannt.
0belix poste bitte die Ausgabe von stm32IRconfig im Monitor-Modus von
Tastendrücken unterschiedlicher "schlechter" Tasten (also z.B. 0, 1, 2
...).
Frank, in der Firmware ist ein unverändertes IRMP und andere Protokolle
funktionieren tadellos, z.B. RC5.
https://github.com/j1rie/IRMP_STM32/blob/master/STM32F103/patches/irmp.patch
Es werden nur Protokolle aktiviert, und der Port angepasst.
Frank M. schrieb:> Bitte die obige Frage beantworten:>> Was heisst neu? Unterschiedlich zum Tastendruck davor? Oder ein- und> dieselbe Taste zweimal hintereinander kurz gedrückt?
Ich habe immer dieselbe Taste hintereinander kurz gedrückt. Beim ersten
Mal war es die Taste 5.
Auf einen Tastendruck hin wird eventuell
* der PC aufgeweckt
* der PC rebootet
* mehrere IR Befehle gesendet
* der uC rebootet
Das ist hier aber Alles nicht der Fall.
Hier wird nur über USB der IRMP Code übertragen.
Jörg R. schrieb:> https://github.com/j1rie/IRMP_STM32/blob/master/ST...
Okay, was ich da sehe:
Es wird irmp_get_data() aufgerufen. Wenn myIRData.flags gesetzt ist,
wird RepeatCounter hochgezählt.
Frage 1: Was ist jetzt konkret Dein Problem? Ist bei Deiner Anwendung
RepeatCounter immer größer als 0?
Weiter unten sehe ich:
memcpy(buf, &myIRData, sizeof(myIRData));
USB_HID_SendData(REPORT_ID_IR, buf, sizeof(myIRData));
Die Datenstruktur wird also in einen buffer "buf" kopiert und
anschließend die Funktion USB_HID_SendData() aufgerufen, bei der man
beten muss, dass sie das STM32-typische Alignment der
IRMP_DATA-Datenstruktur genauestens kennt.
Frage 2: Was hat das alles mit IRSND zu tun? Sendet die Anwendung auch
etwas über IR? Oder warum sehe ich da dieses:
1
int8_tset_handler(uint8_t*buf)
2
{
3
/* number of valid bytes in buf, -1 signifies error */
4
int8_tret=3;
5
uint8_tidx;
6
uint8_ttmp[SIZEOF_IR];
7
switch((enumcommand)buf[2]){
8
caseCMD_EMIT:
9
yellow_short_on();
10
---->>>irsnd_send_data((IRMP_DATA*)&buf[3],1);
Frage 3: Kann es sein, dass der IR-Frame, der da reinkommt, von IRSND
direkt wieder rausgeblasen wird und IRMP den da als Tastenwiederholung
erkennt? Also: Ist der Sender optisch isoliert vom Empfänger? Oder
"sieht" der Empfänger vielleicht die selbst rausgeschickten Frames des
Senders?
Du solltest die IR-LED des Senders mal zukleben, um das zu testen.
Jörg R. schrieb:> Das ist hier aber Alles nicht der Fall.> Hier wird nur über USB der IRMP Code übertragen.
Gerade erst gelesen. Okay, dann kannst du Frage 2 & 3 ignorieren ;-)
Jörg R. schrieb:> 0belix poste bitte die Ausgabe von stm32IRconfig im Monitor-Modus von> Tastendrücken unterschiedlicher "schlechter" Tasten (also z.B. 0, 1, 2> ...).
Dann sieht man was über USB vom uC herein kommt. Insbesondere die flags.
Es wird also flags auf == 0 geprüft. Das ist so nicht ganz korrekt.
Richtig wäre:
1
if(myIRData.flags&IRMP_FLAG_REPETITION)){
2
RepeatCounter++;
3
}else{
4
RepeatCounter=0;
5
}
IRMP nutzt die anderen Bits von flags durchaus für weitere
Daten-Informationen, z.B. beim KASEIKYO-Protokoll. Sollte bei NEC aber
zufälligerweise funktionieren.
Jörg R. schrieb:> Dann sieht man was über USB vom uC herein kommt. Insbesondere die flags.
Ja, das wäre sehr interessant. Hoffentlich ist das Alignment der
IRMP-Datenstruktur bei jeder Compiler-Variante und -Version immer
gleich.
Sauberer wäre es, statt einem memcpy()-Aufruf die Struktur-Elemente
einzeln an die richtigen Stellen von buf[] zu kopieren.
Jörg R. schrieb:> Jörg R. schrieb:>> 0belix poste bitte die Ausgabe von stm32IRconfig im Monitor-Modus von>> Tastendrücken unterschiedlicher "schlechter" Tasten (also z.B. 0, 1, 2>> ...).>> Dann sieht man was über USB vom uC herein kommt. Insbesondere die flags.
Hier die Ausgabe. Gedrückt habe ich die Menü Taste und die Tasten 1,2,3
bis 0
Danke für den Hinweis mit der myIRData.flags Auswertung. Das werde ich
dann so einbauen.
Frank M. schrieb:> Hoffentlich ist das Alignment der> IRMP-Datenstruktur bei jeder Compiler-Variante und -Version immer> gleich.>> Sauberer wäre es, statt einem memcpy()-Aufruf die Struktur-Elemente> einzeln an die richtigen Stellen von buf[] zu kopieren.
Das hatte ich anfangs mal so. Wie es jetzt ist, finde ich aber
eleganter. Das funktioniert, weil IRMP_DATA ja das _attribute_
((_packed_)) hat.
Jörg R. schrieb:> Da wird uint8_t + uint16_t + uint16_t + uint8_t in ein uint8_t-Array> kopiert und in uint8_t-Häppchen übertragen, das ist schon OK so.
Das glaube ich erstmal so nicht. ;-)
Wenn ich es richtig in Erinnerung habe, werden auf einem STM32 i.d.R.
die Struktur-Elemente auf 32 Bit ausgerichtet.
Dann sieht auf einem STM32 die Struktur physikalisch so aus:
1
1 Byte protocol
2
3 Byte Füllbytes
3
2 Byte address
4
2 Byte Füllbytes
5
2 Byte command
6
2 Byte Füllbytes
7
1 Byte flags
8
3 Byte Füllbytes
Wenn man die Struktur allerdings packt (per Pragma oder über
Compiler-Flag), sieht diese ganz anders aus.
Wird das bei der späteren Auswertung vom uint8_t-Array so
berücksichtigt?
Beachte bitte auch meine obige Anmerkung zu IRMP_FLAG_REPETITION, was in
der Auswertung von flags fehlt. Ich empfehle bei dieser Gelegenheit,
auch nur (flags & IRMP_FLAG_REPETITION) in das uint8_t-Array zu kopieren
oder bei der späteren Auswertung von flags im uint8_t-Array die
entsprechende Stelle im Array ausschließlich auf dieses eine Bit zu
prüfen - falls flags da überhaupt irgendwie inhaltlich ausgewertet wird.
0belix, bitte poste dasselbe mit RC5, nur um Frank zu überzeugen.
Frank, ich bin mir ziemlich sicher, dass das so richtig ist.
Zumindest funktioniert das seit Jahren, und ich habe das damals genau
untersucht und war mir der Problematik bewußt.
Das IRMP_FLAG_REPETITION werde ich einbauen, aber du meintest doch bei
dem Problem hier spielt es keine Rolle?
Hier ist der buffer 'buf' ein Byte kürzer, aber ausreichend, denn der
memcpy kopiert nur 16 Bytes. Okay, ich sehe, Du brauchst später ein Byte
mehr in USB_HID_SendData(), das habe ich verstanden. Scheint also auf
den 2. Blick doch kein Problem zu sein.
Ich hatte nämlich erst befürchtet, dass durch einen Buffer-Overflow
genau die dahinter definierte Variable RepeatCounter evtl. überschrieben
wird. Aber das scheint doch wasserdicht zu sein.
Gepackt sieht die Struktur physikalisch so aus:
1 Byte protocol
2 Byte address
2 Byte command
1 Byte flags
und das passt perfekt zum uint8_t-Array:
1 Byte
1 Byte
1 Byte
1 Byte
1 Byte
1 Byte
Endian habe ich auch berücksichtigt.
Ich mache dann mal eine neue Firmware mit korrektem
IRMP_FLAG_REPETITION.
Jörg R. schrieb:> 0belix, bitte poste dasselbe mit RC5, nur um Frank zu überzeugen.
Erstmal würde ich gerne den das uint8_t-Array sehen mit einer
funktionierenden NEC-Taste und mit einer nicht-funktionierenden
NEC-Taste sehen, idealerweise genau mit den beiden Tasten oben, nämlich
MODE2 und UP-Taste. Dann kann ich die von IRMP ermittelten Werte mit
denen im Array befindlichen abgleichen.
Oder ist es so, dass jetzt bei allen NEC-Tasten flags != 0 ist??? Ich
steige hier langsam nicht mehr durch ;-)
RC5 ist in dem Zusammenhang eher uninteressant.
Jörg R. schrieb:> Das IRMP_FLAG_REPETITION werde ich einbauen, aber du meintest doch bei> dem Problem hier spielt es keine Rolle?
Bei NEC spielt es keine Rolle, bei anderen Protokollen wie KASEIKYO
schon. Daher war das eher eine allgemeine Anmerkung meinerseits.
Jörg R. schrieb:> Gepackt sieht die Struktur physikalisch so aus:> 1 Byte protocol> 2 Byte address> 2 Byte command> 1 Byte flags> und das passt perfekt zum uint8_t-Array:> 1 Byte> 1 Byte> 1 Byte> 1 Byte> 1 Byte> 1 Byte> Endian habe ich auch berücksichtigt.
Upps, das war mir doch glatt entfallen, dass ich vor 3 Jahren die
Struktur ab Revision 151 (Jan 19 11:04:00 2015 UTC) gepackt hatte.
irmpsystem.h:
0belix, dann also bitte die Ausgabe von stm32IRconfig im Monitor-Modus
mit "guten" Tasten (Leiser / Lauter, Kanal + / Kanal - und vom
Steuerkreutz die Pfeiltasten).
Dann können wir das uint8_t-Array mit guten und schlechten Tasten
vergleichen.
Jörg R. schrieb:> Ich habe es jetzt so verbessert:
Gut.
Noch zwei Empfehlungen:
1. Der Buffer 'uint8_t buf[HID_OUT_BUFFER_SIZE-1]' in main.c liegt auf
dem Stack. Daher ist es nicht garantiert, dass alle 16 Bytes darin = 0
sind. Da Du später die gepackte Struct (6 Bytes) per memcpy kopierst,
bleiben die letzten 10 Stellen im Buffer undefiniert. In der späteren
Funktion USB_HID_SendData() kopierst Du dann aber alle 16 Stellen und
damit 10 Bytes Schrott. Wenn das nicht stört - auch gut.
Aber ich empfehle Dir, am Anfang von main() das Array einmal(!) zu
nullen, z.B. per
1
memset(buf,0,HID_OUT_BUFFER_SIZE-1);
2. Es kann sein, dass ich irgendwann in Zukunft das Packing der Struct
wieder rauswerfe. Denn glücklich bin ich darüber eigentlich nicht, z.B.
wegen Performance-Einbußen - gerade in einer ISR. Ich empfehle Dir
daher, um kompatibel zu bleiben, den memcpy() zu ersetzen durch:
Jörg R. schrieb:> Hat aber bisher nie gestört.
Kann gut sein. Es ist auch unwahrscheinlich, dass eine Stack-Variable in
main() irgendeinen Unsinn enthält. Das passiert eher in einer
Unterfunktion. Aber darauf würde ich mich nicht verlassen.
Beispiel:
Jörg R. schrieb:> 0belix, dann also bitte die Ausgabe von stm32IRconfig im Monitor-Modus> mit "guten" Tasten (Leiser / Lauter, Kanal + / Kanal - und vom> Steuerkreutz die Pfeiltasten).> Dann können wir das uint8_t-Array mit guten und schlechten Tasten> vergleichen.
Guten Morgen, war gestern ab Nachmittag unterwegs.... Hier die Ausgabe
in der genannten Reihenfolge:
Ist das normal, dass da ein- und derselbe Code ein paar dutzend Mal
wiederholt wird?
Jörg R. schrieb:> Rätselhaft, die "Guten" haben auch trotz neuem Key das> Wiederholungsflag.> Wie können die dann "gut" sein?!
Wann ist denn ein Code "gut"? Was ist denn das Kriterium?
Ich habe bereits im IRMP-Source gesucht, ob bei irgendwelchen
Eventualitäten das Repetition-Flag in flags vom vorhergehenden Lauf
versehentlich nicht gelöscht wird. Ich kann so einen Fall aber leider
nicht konstruieren.
Man könnte natürlich mal vor Aufruf von irmp_get_data() das
myIRData.flags versuchsweise explizit löschen.
Frank M. schrieb:> Ist das normal, dass da ein- und derselbe Code ein paar dutzend Mal> wiederholt wird?
Wenn er etwas länger drückt, ja.
Frank M. schrieb:> Wann ist denn ein Code "gut"?
Mit "gut" waren die Tasten gemeint, die seiner Beschreibung nach gehen.
Sind eigentlich die Protokolle
https://github.com/j1rie/IRMP_STM32/blob/master/STM32F103/patches/irmp.patch
alle miteinander kompatibel?
0belix, bitte poste die Ausgabe von stm32IRconfig - g - c (get
capabilities), und zur Sicherheit auch von ein paar RC5 Tasten
(stm32IRconfig - m).
Jörg R. schrieb:> Wenn er etwas länger drückt, ja.
Da hat er aber verdammt lang gedrückt. Kann da was bei einer derartigen
Befeuerung verloren gehen?
> Mit "gut" waren die Tasten gemeint, die seiner Beschreibung nach gehen.
Ich sehe nur, dass die Codes, die oben stehen, alle vom IRMP erkannt
werden. Leider hat Obelix nicht näher beschrieben, was er da gemacht hat
und ob da Ausgaben bei bestimmten Tastendrücken fehlen.
> Sind eigentlich die Protokolle> https://github.com/j1rie/IRMP_STM32/blob/master/STM32F103/patches/irmp.patch> alle miteinander kompatibel?
Ich habe eben mal alle Protokolle eingeschaltet, die Du auch
eingeschaltet hast und dann nochmal den konvertierten Pulse/Pause-Log
von oben in den IRMP geschoben: Beide Tasten (bezeichnet mit Mode2 und
Up) wurden erkannt - mit flag = 0x00.
Das wäre noch interessant:
Frank M. schrieb:> Man könnte natürlich mal vor Aufruf von irmp_get_data() das> myIRData.flags versuchsweise explizit löschen.
Eine andere Idee habe ich im Moment auch nicht. Sehr merkwürdig, das
Ganze.
Jörg R. schrieb:> 0belix, bitte poste die Ausgabe von stm32IRconfig - g - c (get> capabilities), und zur Sicherheit auch von ein paar RC5 Tasten> (stm32IRconfig - m).
Soll ich vorher die neue Firmware flashen oder nicht?
"T." ". schrieb:> Jetzt weiß ich was du gemeint hast. Hier die Ausgabe:
Die Ausgabe wovon? Was hast Du da gedrückt?
> written 17> bytes:> 03 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
An Jörg: Was ist das? Wahrscheinlich darf ich alles, was nicht mit 01
beginnt, ignorieren, weil es nichts mit IRMP zu tun hat?
> [...]
Auch mit dem Rest kann ich persönlich nichts anfangen. Da muss Jörg was
zu sagen.
"T." ". schrieb:> Und hier die Ausgabe einer RC5 FB:read 17 bytes:> 01 07 0b 00 48 00 00 00 00 00 00 00 00 00 00 00 00> converted to protocoladdresscommandflag:> 07000b004800>> read 17 bytes:> 01 07 0b 00 48 00 01 00 00 00 00 00 00 00 00 00 00> converted to protocoladdresscommandflag:> 07000b004801
Damit kann ich was anfangen: Protokoll RC5, beim ersten mal mit flags =
0x00, also keine Wiederholung, beim zweiten Mal dieselbe Taste mit flags
= 0x01, also Wiederholung.
@Obelix: Bitte zukünftig die Tasten nicht soooo lange drücken, dann wird
die Liste nicht so lang und damit übersichtlicher.
Frank M. schrieb:> Da hat er aber verdammt lang gedrückt. Kann da was bei einer derartigen> Befeuerung verloren gehen?
Nein, erst ab 255 mal.
"T." ". schrieb:> protocols: 1 2 3 5 20 27 28 4 8 7 9 21 24> protocols: 15 17 16
Das sind die Nummern der eingebauten Protokolle.
"T." ". schrieb:> converted to protocoladdresscommandflag:> 07000b004800
RC5 geht tadellos.
Frank M. schrieb:> Man könnte natürlich mal vor Aufruf von irmp_get_data() das> myIRData.flags versuchsweise explizit löschen.
0belix, drücke bitte ganz kurz eine RC5 Taste und dann eine NEC Taste
und poste stm32IRconfig - m. Wichtig ist dabei die RC5 Taste so kurz zu
drücken, dass nur eine Ausgabe kommt. Also mit spitzem Finger ganz
kurz hacken. Es darf nur die Ausgabe mit 00 am Ende sein.
Mal sehen ob das dem NEC hilft.
Jörg R. schrieb:> 0belix, drücke bitte ganz kurz eine RC5 Taste und dann eine NEC Taste> und poste stm32IRconfig - m. Wichtig ist dabei die RC5 Taste so kurz zu> drücken, dass nur eine Ausgabe kommt. Also mit spitzem Finger ganz> kurz hacken. Es darf nur die Ausgabe mit 00 am Ende sein.> Mal sehen ob das dem NEC hilft.
Taste 5 von NEC:
Krass. Jetzt hat das NEC plötzlich flags 0. Auch vor dem RC5.
Spiel mal ein bischen rum und erkunde, wovon es abhängt, ob du bei neuer
Taste NEC flags 0 oder 1 bekommst.
Jörg R. schrieb:> Krass. Jetzt hat das NEC plötzlich flags 0. Auch vor dem RC5.>> Spiel mal ein bischen rum und erkunde, wovon es abhängt, ob du bei neuer> Taste NEC flags 0 oder 1 bekommst.
Bitte:
"T." ". schrieb:> Frank M. schrieb:> @Obelix: Du hast aus dieser Liste nichts rausgelöscht, oder?>> Nein.
Da bin ich jetzt ratlos. Aber eine Idee habe ich noch:
@Jörg:
Ich habe mir mal Deine Funktionen check_macros() usw. angeschaut. Ist
das richtig, dass Du die IRMP-Daten inkl. flags mit EEPROM-Inhalten
abgleichst?
Ich vermute mal, dass im EEPROM angelernte IRMP-Daten stecken. Aber
warum inkl. flags? Dann matchen sie ja nur, wenn auch das flag identisch
ist!
Angenommen, es werden IRMP-Daten mit flags = 1 im EEPROM gespeichert.
Dann muss ich danach die Taste immer lange drücken, damit sie überhaupt
eine Funktion erfüllt?
Andersherum: es werden IRMP-Daten mit flags = 0 im EEPROM gespeichert.
Dann wirken Wiederholungen (zum Beispiel Lautstärke-Taste) gar nicht und
ich muss die Lautstärke-Taste 30x hintereinander drücken (statt 1x
lange), um 30 Stufen runterzudrehen?
Frage: Wann erscheinen die Daten im obigen Log vom Obelix? Wenn sie
matchen? Oder immer? Wenn sie nur geloggt werden, wenn sie matchen, dann
erkläre ich das Verhalten so: Im EEPROM sind Daten mit flags = 0x01
gespeichert und der vorher empfangene Frame mit 0x00 wird im Log
unterdrückt.
Das Speichern/Vergleichen der Daten inkl. Flags halte ich erstmal für
unsinnig. Aber vielleicht hast Du da noch eine andere Erklärung, die
mich umstimmt ;-)
"T." ". schrieb:> Ist das eigentlich normal, dass stm32IRconfig und irw unterschiedliche> Ausgaben haben?>> Taste 5 stm32IRconfig (monitor):> read 17 bytes:> 01 02 14 eb 06 00 01 00 00 00 00 00 00 00 00 00 00> converted to protocoladdresscommandflag:> 02eb14000601> Taste 5 irw (nicht gepatcht):> 02eb14000600 3 KEY_5 IRMP
irw zeigt an, was irmplircd ausgibt. irmplircd läßt die flags weg, und
benutzt statt dessen einen Zähler. Der ist 0 beim ersten Tastendruck,
und zählt mit jeder Wiederholung +1 hoch.
flags sieht man also hier: 02eb140006*01* oder indirekt am Hochzählen in
irw: 02eb14000600 3 KEY_5 IRMP
Frank M. schrieb:> Ist> das richtig, dass Du die IRMP-Daten inkl. flags mit EEPROM-Inhalten> abgleichst?
Für das PC aufwecken z.B.
https://github.com/j1rie/IRMP_STM32/blob/master/STM32F103/src/main.c#L437
wird flags genullt. Das sollte überall so sein, müßte ich mal prüfen
bzw. ins README schreiben (wenn man von Hand eingibt).
Frank M. schrieb:> Dann wirken Wiederholungen (zum Beispiel Lautstärke-Taste) gar nicht und> ich muss die Lautstärke-Taste 30x hintereinander drücken (statt 1x> lange), um 30 Stufen runterzudrehen?
Nein, denn dafür wird ja nichts mit dem Eeprom verglichen, sondern
erster Tastendruck plus 29 Repeats werden an die Anwendung weiter
gegeben.
Frank M. schrieb:> Frage: Wann erscheinen die Daten im obigen Log vom Obelix?https://github.com/j1rie/IRMP_STM32/blob/master/STM32F103/src/main.c#L749https://github.com/j1rie/IRMP_STM32/blob/master/STM32F103/src/main.c#L775
werden ja in jeder Schleife abgearbeitet, also erscheinen sie praktisch
sofort (außer wenn IR gesendet wird, denn dann ist ja der Empfang lahm
gelegt).
Frank M. schrieb:> Das Speichern/Vergleichen der Daten inkl. Flags halte ich erstmal für> unsinnig. Aber vielleicht hast Du da noch eine andere Erklärung, die> mich umstimmt ;-)
Weil jede Eeprom Einheit 2 Bytes aufnimmt, paßte ein IRMP_DATA in 3
Eeprom Einheiten:
https://github.com/j1rie/IRMP_STM32/blob/master/STM32F103/src/main.c#L326
. Ob mit oder ohne flags. Beim Vergleichen ist der Code
eleganter/einfacher, wenn die flags mit verglichen werden, aber
aufbauend auf der Voraussetzung das sie vorher genullt wurden. Das
könnte ich aber tatsächlich mal überarbeiten.
Unterm Strich haben wir immer noch keine Erklärung dafür, warum bei
0belix's NEC Fernbedienung die flags beim ersten Tastendruck ohne
erkennbares System mal richtig und mal falsch kommen.
Was mir noch auffällt ist, dass bei allen NEC Tests vor dem RC5 Test
immer flags 1 war, und dass es seitdem mal 0 und mal 1 ist.
Ich weiß aber nicht, was ich da noch machen könnte.
Wenn ich die Fernbedienung hätte, könnte ich theoretisch mal einen
Debugger anschmeissen, oder printf's einbauen oder IRMP loggen lassen.
So fällt mit erst mal nichts mehr ein.
Eine Idee doch noch: 0belix, was passiert, wenn du deine Harmony
Universal-FB mal auf NEC stellst? Geht es dann?
Jörg R. schrieb:> Eine Idee doch noch: 0belix, was passiert, wenn du deine Harmony> Universal-FB mal auf NEC stellst? Geht es dann?
Du meinst ich soll den Code mit der Harmony anlernen?
Jörg R. schrieb:> Jörg R. schrieb:>> Was mir noch auffällt ist, dass bei allen NEC Tests vor dem RC5 Test>> immer flags 1 war, und dass es seitdem mal 0 und mal 1 ist.>> Das könnte daran liegen, dass er zwischendurch die Firmware upgedatet> hat, was wiederum bedeutet, dass> https://github.com/j1rie/IRMP_STM32/blob/master/STM32F103/src/main.c#L756> ein bißchen geholfen hat.
Nein, ich habe noch kein Update installiert. Es ist weiterhin Version
2018-01-05_14-37_Red_BL_SC_jrie.bin installiert.
/* store received wakeup IRData in first wakeup slot */
12
eeprom_store(idx,(uint8_t*)&wakeup_IRData);
13
toggle_LED();
14
}
15
}
Es kann unter Umständen passieren, dass im IRMP-Buffer immer noch Daten
vom zuletzt empfangenen Frame "lauern", weil sie noch nicht per
irmp_get_data() abgeholt wurden. Dein Aufruf von irmp_get_data() liest
dann eventuell einen alten Frame aus.
Genau das Problem hatte ich mal beim Anlernen in
DIY Lernfähige Fernbedienung mit IRMP.
Die Lösung ist simpel:
Vor dem Aufruf von delay_ms(5000) einbauen:
1
irmp_get_data(&wakeup_IRData);// flush input of irmp data
Dabei den Rückgabewert ignorieren. Danach hat der User 5 Sekunden Zeit,
seine Taste zu drücken.
> Was mir noch auffällt ist, dass bei allen NEC Tests vor dem RC5 Test> immer flags 1 war, und dass es seitdem mal 0 und mal 1 ist.
Ich habe nochmal im irmp-Source gesucht, ob es da eine Lücke bzgl. flags
gibt.
Und ich bin fündig geworden. Es gibt nur eine Stelle im IRMP-Source, wo
irmp_flags genullt wird:
1
caseIRMP_NEC_PROTOCOL:
2
if((irmp_command>>8)==(~irmp_command&0x00FF))
3
{
4
irmp_command&=0xff;
5
rtc=TRUE;
6
}
7
....
8
if(rtc)
9
{
10
irmp_data_p->protocol=irmp_protocol;
11
irmp_data_p->address=irmp_address;
12
irmp_data_p->command=irmp_command;
13
irmp_data_p->flags=irmp_flags;
14
irmp_command=0;
15
irmp_address=0;
16
irmp_flags=0;
17
}
Das heisst:
Falls ein NEC-Frame empfangen wurde, wo das Upper-Byte vom command NICHT
dem invertierten Lower-Byte entspricht, wird rtc nicht gesetzt, d.h. der
Frame wird verworfen. Aber die evtl. gesetzte interne Variable
irmp_flags wird dann leider NICHT auf 0 zurückgesetzt.
Es kommt offenbar bei der FB von Obelix bei bestimmten Tasten zu
Übertragungsfehlern und dabei kann ein evtl. vormals gesetztes
Repetition-Bit stehenbleiben.
@Obelix: Kannst Du den obigen if-Block mal testweise ändern?
Alt:
1
if(rtc)
2
{
3
irmp_data_p->protocol=irmp_protocol;
4
irmp_data_p->address=irmp_address;
5
irmp_data_p->command=irmp_command;
6
irmp_data_p->flags=irmp_flags;
7
irmp_command=0;
8
irmp_address=0;
9
irmp_flags=0;
10
}
Neu:
1
if(rtc)
2
{
3
irmp_data_p->protocol=irmp_protocol;
4
irmp_data_p->address=irmp_address;
5
irmp_data_p->command=irmp_command;
6
irmp_data_p->flags=irmp_flags;
7
}
8
9
irmp_command=0;
10
irmp_address=0;
11
irmp_flags=0;
Das if-Statement solltest Du in Zeile 2461 finden.
EDIT:
Es kann aber auch sein, dass diese FB bei bestimmten Tasten die Regel
generell nicht einhält, dass das Kommando aus nicht-invertierten und
invertierten Kommando-Bits besteht. Dann verhält sie sich nicht
NEC-standardkonform. Die obige Korrektur ist aber auf jeden Fall
sinnvoll. Kommt ins nächste Release.
Ich habe die oben beschriebene Änderung im SVN von IRMP eingecheckt
und auch die Download-Dateien aktualisiert auf Version 3.0.9.
Ich hoffe, das hilft.
Frank M. schrieb:> Und ich bin fündig geworden.
Danke Frank, ich bin froh, dass du was gefunden hast.
Heute spät oder morgen gibt es dann eine neue Firmware zum Testen.
Ich werde mal meine eigene Universal-FB auf NEC stellen, und damit
testen.
Frank M. schrieb:> Es kann unter Umständen passieren, dass im IRMP-Buffer immer noch Daten> vom zuletzt empfangenen Frame "lauern", weil sie noch nicht per> irmp_get_data() abgeholt wurden. Dein Aufruf von irmp_get_data() liest> dann eventuell einen alten Frame aus.
Ein alter Frame kann aber nur ausgelesen werden, wenn keine Taste in den
5 Sekunden gedrückt wurde. Wenn eine Taste gedrückt wird, wird der alte
Frame ja komplett überschrieben.
Oder?
Ich werde das so einbauen, um zu vermeiden, dass das
Bestätigungs-Blinken der LED kommen könnte, obwohl der Tastendruck gar
nicht in den 5 Sekunden statt fand.
Das Initialisieren des Buffers werde ich aber wieder raus nehmen, weil
nach nochmaligem Überdenken ich sicher bin, dass da nichts schief gehen
kann.
Da werden sowieso ständig verschieden lange Sachen rein geschrieben, und
hinterher wird nie aufgeräumt, was aber auch gar nicht nötig ist, da
beim Senden immer nur genau das Benötigte raus geht, und der Rest
genullt wird.
Noch eine kurze offtopic Frage:
Frank M. schrieb:> Danke. Mittlerweile bin ich mit der imon.txt durch. Es handelt sich um> kein Fernbedienungsprotokoll im klassischen Sinne. Es ist weder> Manchester-codiert noch ist ein Pulse-Distance Protokoll. Es ist viel> einfacher, nämlich einfach bitseriell mit 38 Bits, wenn ich mich nicht> verzählt habe.>> Das kann IRMP nicht. Einfacher wäre es, einen Software-Uart (i.d.R. 8> Bit) auf 38 Bit umzuschreiben. ;-)>> Naja, ich schaue mir nochmal imon2.txt an. Dann entscheide ich, ob ich> das in IRMP einbaue oder nicht.
Da wurde nie geschrieben, was dabei heraus gekommen ist. Ist das immer
noch gültig, dass IRMP kein IMON kann? Neulich kam diese Frage mal im
VDR-Portal auf.
"T." ". schrieb:> Hier die stm32config Monitor Ausgabe der anderen NEC FB:
Im Prinzip dasselbe, mal flags 0, mal 1.
Ich sage Bescheid, wenn es die neue Firmware gibt.
Jörg R. schrieb:> "T." ". schrieb:>> Hier die stm32config Monitor Ausgabe der anderen NEC FB:>> Im Prinzip dasselbe, mal flags 0, mal 1.>> Ich sage Bescheid, wenn es die neue Firmware gibt.
OK, danke. Bevor ich nun meine Harmony umprogrammiere, habe ich mal
geschaut, was die anderen Fernbedienungen die ich hier noch habe für
Protokolle sprechen. Ich habe noch zwei Stück mit NEC gefunden.
Jörg R. schrieb:> Ein alter Frame kann aber nur ausgelesen werden, wenn keine Taste in den> 5 Sekunden gedrückt wurde. Wenn eine Taste gedrückt wird, wird der alte> Frame ja komplett überschrieben.
Nein, der wird nicht überschrieben. Solange Du ihn nicht per
irmp_get_data() abholst, nimmt IRMP keine weiteren Frames mehr an. Du
bekommst dann den alten ausgeliefert.
> Ich werde das so einbauen, um zu vermeiden, dass das> Bestätigungs-Blinken der LED kommen könnte, obwohl der Tastendruck gar> nicht in den 5 Sekunden statt fand.
Gut.
> Das Initialisieren des Buffers werde ich aber wieder raus nehmen, weil> nach nochmaligem Überdenken ich sicher bin, dass da nichts schief gehen> kann.> Da werden sowieso ständig verschieden lange Sachen rein geschrieben, und> hinterher wird nie aufgeräumt, was aber auch gar nicht nötig ist, da> beim Senden immer nur genau das Benötigte raus geht, und der Rest> genullt wird.
Okay, deshalb schrieb ich ja gestern: Wenn es nicht stört, auch gut.
> Da wurde nie geschrieben, was dabei heraus gekommen ist. Ist das immer> noch gültig, dass IRMP kein IMON kann? Neulich kam diese Frage mal im> VDR-Portal auf.
Hm, das muss schon was länger her sein. Upps, 2011... Weiß ich jetzt aus
dem Stehgreif gar nicht mehr. Schaue ich mir nochmal an.
Frank M. schrieb:> Nein, der wird nicht überschrieben. Solange Du ihn nicht per> irmp_get_data() abholst, nimmt IRMP keine weiteren Frames mehr an. Du> bekommst dann den alten ausgeliefert.
Da hatte ich was ganz Falsches erwartet. Gut zu wissen!
Ich weiß jetzt ungefähr, woran es liegt. Nur das tiefere Verständnis
fehlt mir noch. Aber der Reihe nach.
Schlußendlich habe ich es geschafft, meine OFA URC 7541 per SAT-0137
auf NEC einzustellen.
Auch mit IRMP 3.0.9 kamen dann wie bei 0belix alle flags 1, bei anderen
Versuchen mal 0 , mal 1. Bei einem Versuch sogar alles richtig.
Also habe ich bei meinem Code alles verzichtbare abgestellt, und langsam
wieder dazu genommen, und dabei getestet, ab wann der Fehler wieder
auftaucht. Es lag am toggle_LED(); in main():
https://github.com/j1rie/IRMP_STM32/blob/master/STM32F103/src/main.c#L766
Durch das kürzlich hinzu gekommene "SHORTFLASH" gibt es da eine
Verzögerung. Abstellen von SHORTFLASH oder Herabsetzen des delay von
50ms auf 30ms hilft.
https://github.com/j1rie/IRMP_STM32/blob/master/STM32F103/src/main.c#L317
Nur verstehe ich nicht, wie diese Verzögerung die Fehler in IRMP hervor
ruft.
Noch eine interessante Beobachtung: Wenn ich die Tasten ganz kurz
drücke, geht es bei 35ms delay immer, es kommt eine Ausgabe mit flags 0,
drücke ich die Taste etwas länger, kommt wieder flags 1 für beide
frames. Was passiert da??
Ist das nun ein Fehler in meinem Code, oder exponiert die Verzögerung
ein Problem in IRMP?
irmp_get_data(&wakeup_IRData); // flush input of irmp data
ist jetzt übrigens auch drin:
https://github.com/j1rie/IRMP_STM32/blob/master/STM32F103/src/main.c#L433Jörg R. schrieb:> Für das PC aufwecken z.B.> https://github.com/j1rie/IRMP_STM32/blob/master/STM32F103/src/main.c#L437> wird flags genullt. Das sollte überall so sein, müßte ich mal prüfen> bzw. ins README schreiben (wenn man von Hand eingibt).
Getan:
https://github.com/j1rie/IRMP_STM32/blob/master/STM32F103/src/main.c#L753
Bei den Konfigurationsprogrammen muß ich noch gucken.
Es gibt neue Firmware im git.
Jörg R. schrieb:> Es lag am toggle_LED(); in main():
Es liegt definitiv am delay().
Ich kann das vielleicht auch - zumindest teilweise - erklären:
1. User drückt Taste (hält den Finger drauf)
2. Anwendung holt Frame ab.
3. Anwendung macht Delay
4. Da der Finger noch drauf ist, kommt während des Delays ein weiterer
Frame mit flags = 1 rein
5. IRMP sperrt den Empfang, da Anwendung den letzten Frame noch nicht
abgeholt hat.
6. Anwendung holt Frame mit flags = 1 ab.
7. IRMP gibt den Empfang wieder frei.
Solange Dein Delay länger ist als die Zeit, in welcher ein weiterer
Frame reinkommen kann, hinkst Du in der Anwendung immer 1 Frame
hinterher.
Ist eigentlich dasselbe Problem wie das (vor)gestern erläuterte mit dem
delay von 5 Sekunden.
Entweder machst Du das delay kürzer (sehe gerade: hast Du schon auf
25msec runtergestellt)
oder
Du baust den Flush auch hinter(!) dem Delay in main() ein
oder
Du lässt Deine LED im Hintergrund über eine Timer-Routine aufblitzen und
lässt die main-Routine ungehindert, d.h. ohne Verzögerung, durchlaufen.
Die dritte Variante ist zweifellos die eleganteste.
P.S.
Du könntest die LED auch über die IRMP-Callback-Funktion aufleuchten
lassen. Dann flimmert die immer dann, solange IRMP einen Frame empfängt.
Genau für so etwas hatte ich damals die Callback-Funktion in IRMP
implementiert:
IRMP: IRMP USE CALLBACK
Frank M. schrieb:> Die dritte Variante ist zweifellos die eleganteste.
Ja, das im Hintergrund zu machen erscheint mir auch das Beste.
Deine Erklärung erklärt aber nicht, wieso schon der erste frame flags 1
hat. Oder?
Jörg R. schrieb:> Ja, das im Hintergrund zu machen erscheint mir auch das Beste.
Oder über IRMP: IRMP USE CALLBACK, siehe P.S., was ich oben eben noch
nachträglich angehangen habe.
> Deine Erklärung erklärt aber nicht, wieso schon der erste frame> flags 1 hat. Oder?
Nein, ganz habe ich es noch nicht verstanden. Aber ich weiß, dass bei
delays der IRMP dicht macht, sobald er einen weiteren Frame im
Hintergrund empfängt und der nicht (rechtzeitig) abgeholt wird.
Lösung wäre ein FiFo (Queue), hatte ich aber damals, als es nur die
AVR-Variante gab, wegen höherem Speicherbedarf verworfen.
Frank M. schrieb:> 1. User drückt Taste (hält den Finger drauf)> 2. Anwendung holt Frame ab.> 3. Anwendung macht Delay> 4. Da der Finger noch drauf ist, kommt während des Delays ein weiterer> Frame mit flags = 1 rein> 5. IRMP sperrt den Empfang, da Anwendung den letzten Frame noch nicht> abgeholt hat.> 6. Anwendung holt Frame mit flags = 1 ab.> 7. IRMP gibt den Empfang wieder frei.
Der Frame von 2. wird vor dem Delay abgeholt, hat aber bereits flags 1.
Da muss noch etwas Anderes dazwischen funken.
Jörg R. schrieb:> Der Frame von 2. wird vor dem Delay abgeholt, hat aber bereits flags 1.> Da muss noch etwas Anderes dazwischen funken.
Ja, schon klar. Leider habe ich es auch noch nicht zu 100% verstanden.
Frage:
Der WAKEUP_RESET_PIN ist in der Regel high, korrekt? Nicht, dass der in
jedem Schleifendurchgang in store_new_wakeup() reinspringt...
Du könntest natürlich auch mal einen Breakpoint auf delay_ms() setzen.
Vielleicht gibts da noch weitere Delays. Ein Breakpoint auf
irmp_get_data() wäre auch nicht so verkehrt.
Jörg R. schrieb:> Einen Breakpoint setzen kriege ich hin. Aber auf was soll ich dann> achten?
Wo der Sprung in die Funktion herkam. Am besten zu Anfang der jeweiligen
Funktion einen Breakpoint und dann nochmal am Ende, also entweder beim
return oder beim letzten Statement der Funktion.
Wenn die Funktion dann aufgerufen wird (z.B. Delay), mit "Continue" zum
Breakpoint am Ende der Funktion springen, und dann mit "Step over"
weitersteppen. Dann sieht man direkt, wo der Call herkam. Anschließend
kann man dann mit "Continue" das Programm weiterlaufen lassen.
Ich würde erstmal auf delay_ms() einen Breakpoint setzen und dann mal
schauen, wann und woher Calls auf delay_ms() gemacht werden. Wenn das
alles logisch erscheint, dann Breakpoint auf get_irmp_data(). Das dürfte
ja im Normalfall lediglich direkt aus main() aufgerufen werden, richtig?
Nicht, dass da noch ein irmp_get_data() dazwischenkommt, der
ausggerechnet den Frame mit flags = 0x00 wegfrisst - was übrigens
passieren kann, wenn WAKEUP_RESET_PIN low gemessen wird.
Frank M. schrieb:> Der WAKEUP_RESET_PIN ist in der Regel high, korrekt?
Ja, da muss man schon das Gehäuse öffnen und eine Drahtbrücke ansetzen
...
Bei den ganzen Tests wurde ja nur IR empfangen und über USB ausgegeben,
von den ganzen anderen Sachen wird dabei nichts benutzt, außer dem
offensichtlichem.
Wir sind nur in diesem Block
1
/* poll IR-data */
2
if(irmp_get_data(&myIRData)){
3
if(learn_wakeup){
4
/* store received wakeup IRData in first wakeup slot */
Dabei ist learn_wakeup irrelevant, da schon vorhanden, macros sind nicht
vorhanden, resets auch nicht, wakeups nur einer, reboot auch nur einer.
Da gibt es keine Verzögerung.
Außer dem toggle_LED(), dem man nicht gleich die Verzögerung ansieht,
ist da nichts.
Ich werde aber sowieso auf die IRMP-Callback-Funktion umsatteln, optisch
sehe ich da keinen großen Unterschied zu wie es vorher war, und ich
finde es eleganter. Und weiter Energie in Debuggen stecken, habe ich
eher nicht vor, da ich mir nichts davon verspreche. Wenn ich es doch
tue, würde ich timestamps über printf's ausgeben, um mal zu sehen, wo
wie viel Zeit verbraten wird. Das könnte interessant sein.
Ich habe die Version 2018-02-20_13-52_Red_BL_SC_jrie.bin gerade getestet
und die NEC Fernbedienungen funktionierten nun tadellos.
Vielen, vielen Dank :-)
"T." ". schrieb:> Ich habe die Version 2018-02-20_13-52_Red_BL_SC_jrie.bin gerade getestet> und die NEC Fernbedienungen funktionierten nun tadellos.
Prima! Viel Spaß!
Ja, habe ich. Es ist ein 38-Bit bitserielles Protokoll. IRMP kann zwar
seit ein paar Jährchen auch dieses Protokoll (das ist nichts anderes als
das, was ein UART ausspuckt, nur halt ein paar Bits mehr), nur weiß ich
im Moment noch nicht, wie ich die 38 Bit in die IRMP-Struct quetschen
soll.
Da sich sämtliche 38 Bit je nach Taste ändern, gibt es auch keine
Geräteadresse. Damit bleiben in der IRMP-Struct nur noch 16 Bit übrig,
die ich verwenden kann. Es könnte durchaus sein, dass der IMON-Frame
noch Redundanzen enthält, die man dann beim Decodieren noch eindampfen
könnte (mache ich bei fast allen Protokollen so, z.B. NEC oder auch beim
42-Bit-Kaseikyo-Protokoll), aber bisher konnte ich keine entdecken.
Alles in allem gestaltet sich die Dekodierung allein mit der bisherigen
IRMP-Struct als schwierig bis unmöglich. Ich müsste sie daher aufbohren
und damit eine Inkompatibilität in Kauf nehmen.
Ich habe aber noch nicht aufgegeben. Vielleicht fällt mir ja noch was
auf.
Jörg R. schrieb:> Und noch was (da muss mal der pointer type angepaßt werden):
Nein, das Argument von Deiner Funktion led_callback().
Alt:
1
voidled_callback(uint8_ton)
Neu:
1
voidled_callback(uint_fast8_ton)
Dann passt das und die Warnung verschwindet.
Ich hatte das Argument im Zuge der Portierung auf 32-Bit-µCs auf
uint_fast8_t geändert und vergessen, das Beispiel im IRMP-Artikel unter
IRMP: IRMP USE CALLBACK anzupassen. Habe ich jetzt nachgeholt. Danke
für den Hinweis.
