Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dominique Görsch schrieb:
> Super, dass du es gleich implementieren willst. Reichen dir die Infos
> aus dem Paper oder kann ich dir noch anderweitig (zB mit Scans) helfen?

Es wäre natürlich nett, wenn Du auch ein paar Scans machen könntest. 
Graue Theorie ist die eine Geschichte, Praxis oft eine andere :-)

Gruß,

Frank

von Dominique G. (dgoersch)


Bewertung
0 lesenswert
nicht lesenswert
Kein Problem, werde ich machen. Muss deinen Code dafür nur etwas 
umstricken weil ich in meiner Firmware sowieso UART mit 250kBaud (USB) 
drin hab. Wird heute aber wohl eher nixmehr...

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dominique Görsch schrieb:
> Sowohl als auch wäre genial. Ich plane zum einen eigene Receiver die
> dann mit der LEGO Fernbedienung steuerbar sind, zum anderen aber auch
> das automatische Steuern zB von Zügen.

Im SVN ist nun ein IRMP/IRSND mit dem LEGO-Protokoll zu finden. 
Maßgeblich sind in irmp_data.command die unteren 12 Bits, die je nach 
Inhalt von der Anwendung zu prüfen sind - anlehnend an die 
LEGO-Dokumentation. irmp_data.address ist immer 0.

IRMP liest die 16 Bits des LEGO-Telegramm ein und checkt das letzte 
Nibble im XOR-Verfahren gegen die anderen 3 Nibbles. Kommt der richtige 
Wert raus, gibt IRMP die 12 Bit an Nutzdaten zurück.

Umgekehrt kann man die 12 Bits an IRSND in irmp_data.command übergeben. 
IRSND "konstruiert" daraus das fehlende letzte Nibble und schickt 
anschließend den kompletten Frame mit 16 Bit raus.

Als letzte Info: Man braucht eine Interrupt-Frequenz von 20kHz, da die 
Pulse ziemlich kurz sind. Wenn Du noch Scans machen möchtest, dann bitte 
mit 20kHz.

Ich hoffe, ich habe keinen Fehler gemacht, bitte testen.

Gruß,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Hy Frank,

wie ist es denn mit der Unterstützung für die kleine Pollin Tasttatur 
"Merlin" ?
Hast Du da schon was erreichen können ?

Gruß
Torsten

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten K. schrieb:
> wie ist es denn mit der Unterstützung für die kleine Pollin Tasttatur
> "Merlin" ?
> Hast Du da schon was erreichen können ?

Nein, noch nicht. Da werde ich wohl vor dem nächsten Wochenende nicht zu 
kommen. Wenn Du mir helfen willst, kannst Du gern vorabe schon mal ein 
paar Scans mit IRMP machen. Das würde mir eine Menge Arbeit abnehmen.

Gruß,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

ja, werde mal sehen, wie ich die Tage dazu komme, sollte aber möglich 
sein.

Bis dann
Torsten

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Sollte gehen. Wenns läuft, schick mir bitte Deine Code-Änderungen. Dann
> baue ich das als Alternative zum 16-Bit-Timer ein.
>
> Gruß,
>
> Frank

läuft prima, erstzt nun den dani code und mein Timer kann immer mehr, 
nicht nur timen, sondern auch FB testen :-)
/* ======================================================================

C Source File -- Created with SAPIEN Technologies Primalscript(TM)

NAME: <filename>

AUTHOR: jar , test
DATE  : 12.04.2011

COMMENT: <comment>

====================================================================== */
#define F_INTERRUPTS F_CPU/512   // Timer0 RC5 dannegger 64µs bei 8 MHz oder anders gesprochen F_CPU/512 = 15625
//#define F_INTERRUPTS F_CPU/448   // Timer0 F_CPU/448 = 17857

void timer0_init(void)
{  TCCR0B = 1<<CS02;      //divide by 256
  //TCCR0B = (CS01 | CS00);    //divide by 64 
  TIMSK0 |= (1<<TOIE0);    //enable timer interrupt
}

SIGNAL (SIG_OVERFLOW0)
{  
  uint tmp = rc5_tmp;      // for faster access

  TCNT0 = -2;          // gibt mit divide by 256 genau 512 Takte zum Interrrupt
  //TCNT0 = -7;          // gibt mit divide by 64 genau 448 Takte zum Interrrupt
  irmp_ISR();
}

// die würden sich auch bei 8 MHz anbieten
//            TCCR0B
//            CS02  CS01  CS00  Description
//            0     0     0     No clock source (Timer/Counter stopped)
//            0     0     1     clkI/O/(No prescaling)
//            0     1     0     clkI/O/8 (From prescaler)
//            0     1     1     clkI/O/64 (From prescaler)
//            1     0     0     clkI/O/256 (From prescaler)
//            1     0     1     clkI/O/1024 (From prescaler)
//            F_CPU / MHz   Interrupts    TCCR0B        TCNT0
//             8             20833         64           -6 ->   #define F_INTERRUPTS  20833   ;TCCR0B = (CS01 | CS00);  TCNT0 = -6 ;
//             8             17857         64           -7 ->   #define F_INTERRUPTS  17857   ;TCCR0B = (CS01 | CS00);  TCNT0 = -7 ;
//             8             13888         64           -9 ->   #define F_INTERRUPTS  13888   ;TCCR0B = (CS01 | CS00);  TCNT0 = -9 ;
//             8             12500         64           -10 ->   #define F_INTERRUPTS  12500   ;TCCR0B = (CS01 | CS00);  TCNT0 = -10 ;
//             8             15625         256          -2 ->   #define F_INTERRUPTS  15625   ;TCCR0B = (CS02);      TCNT0 = -2 ;
//             8             11363         64           -11 ->   #define F_INTERRUPTS  11363   ;TCCR0B = (CS01 | CS00);  TCNT0 = -11 ;
//             8             10416         256          -3 ->   #define F_INTERRUPTS  10416   ;TCCR0B = (CS02);      TCNT0 = -3 ;

von Dominique G. (dgoersch)


Bewertung
0 lesenswert
nicht lesenswert
Sorry, ich komme im Moment leider nicht zum Testen, trotzdem schonmal 
ein Danke für die schnelle Implementation.

von Joachim B. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
an Frank (ukw)

habe eine FB die IRMP nicht erkennt

daewoo Videorecorder V-737

die FB ist defekt, nur noch 3/4 ? Tasten funktionieren IR Led leuchtet
output_2011-04-15_09-02-22.log

Tasten PROG, <- , -INDEX

habe eine Nachbau FB bestellt
1 90 11 54 22 daewoo 97p1r2taa0 DAEWOO 97P1RA1AA0

die sendet auf den Tasten (PROG Taste nicht gefunden)
Tasten <- , -INDEX
output_2011-04-15_09-05-56.log

kannst du den Code erkennen ?

kannst du die "gleichen" Codes ? vergleichen ?

und evt. sagen um was für einen Code es sich handelt ?

#define F_INTERRUPTS                            17857
#define F_CPU                            8000000


wenn nötig, mehr Codes aus der Ersatz FB

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> an Frank (ukw)
>
> habe eine FB die IRMP nicht erkennt

kann die Nachbau FB nicht vorher testen weil der VCR im Ausland steht

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi Joachim,

Joachim B. schrieb:
> an Frank (ukw)
>
> habe eine FB die IRMP nicht erkennt

Doch, wird erkannt. Das ist das NEC16-Protokoll (eine verkürzte Variante 
des 32-Bit-NEC-Protokolls, dafür aber mit Sync-Bit nach den 8 
Adressbits).

Protokoll: 27
Adresse: 0x0015

Habe ich erst vor ein paar Wochen eingebaut, findest Du im Download des 
SVN.

Gruß,

Frank

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Habe ich erst vor ein paar Wochen eingebaut, findest Du im Download des
> SVN.
>
> Gruß,
>
> Frank

hast du ne Idee warum ich bei F_INTERRUPTS 17857 -> 25 warnings bekomme 
?

manche Codes brauchen doch sogar 20000 ! OK mit 15500 gehts aber wenn 
20000 geht sollte 17857 nicht meckern

../irmp.c:1106: warning: integer overflow in expression
../irmp.c:1107: warning: integer overflow in expression
../irmp.c:1108: warning: integer overflow in expression
../irmp.c:1109: warning: integer overflow in expression
../irmp.c:1157: warning: integer overflow in expression
../irmp.c:1158: warning: integer overflow in expression
../irmp.c:1159: warning: integer overflow in expression
../irmp.c:1160: warning: integer overflow in expression
../irmp.c:1260: warning: integer overflow in expression
../irmp.c:1261: warning: integer overflow in expression
../irmp.c:1262: warning: integer overflow in expression
../irmp.c:1263: warning: integer overflow in expression
../irmp.c: In function 'irmp_ISR':
../irmp.c:2033: warning: integer overflow in expression
../irmp.c:2033: warning: integer overflow in expression
../irmp.c:2035: warning: integer overflow in expression
../irmp.c:2035: warning: integer overflow in expression
../irmp.c:2079: warning: integer overflow in expression
../irmp.c:2080: warning: integer overflow in expression
../irmp.c:2184: warning: integer overflow in expression
../irmp.c:2184: warning: integer overflow in expression
../irmp.c:2186: warning: integer overflow in expression
../irmp.c:2186: warning: integer overflow in expression

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> hast du ne Idee warum ich bei F_INTERRUPTS 17857 -> 25 warnings bekomme
> ?

Habs mir gerade angeschaut, das hat was mit einer kürzlich von mir 
geänderten Behandlung der 2-fachen Längen von Pulsen/Pausen im 
Manchester-Decoder zu tun. Ich wollte da Code einsparen, hab aber nicht 
bedacht, dass da Variablen "platzen" könnten. Ich repariere das am 
Wochenende. Entweder Du gehst auf 15kHz runter oder Du verzichtest 
erstmal auf RC5 und Co.

Gruß,

Frank

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich repariere das am
> Wochenende.

fein, gib dann mal Bescheid, dann lade ich die reparierte

hast du schon die 8-bit Timer0 Variante eingebaut ?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> hast du schon die 8-bit Timer0 Variante eingebaut ?

Nein, habe ich noch nicht. Bei der 16-Bit-Timer-Variante werden die 
Werte für die Timer-Register über eine Formel, die lediglich von F_CPU 
und F_INTERRUPTS abhängig sind, automatisch initialisiert. Da muss man 
nichts anpassen.

Bei Deiner Timer0-Variante muss man eine Tabelle heranziehen und dann 
die Werte abtippen und damit den eigentlichen Code ändern. Das ist nicht 
so schön, geht aber wohl nicht anders. Deshalb überlege ich noch hin und 
her, wie ich das am besten allgemeingültig in den Code einbaue.

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Bei Deiner Timer0-Variante muss man eine Tabelle heranziehen und dann
> die Werte abtippen und damit den eigentlichen Code ändern. Das ist nicht
> so schön, geht aber wohl nicht anders. Deshalb überlege ich noch hin und
> her, wie ich das am besten allgemeingültig in den Code einbaue.

ich weiss

lauter #if F_CPU == && F_INTRRUPTS ==

ist auch keine Lösung

schade das der Precompiler nicht rechnen kann

die Teilerstufen sind auch nicht linear 2^n

wegen 0 8 64 256 1024 gibt 2^0 2^3 2^6 2^8 2^10

kleiner 6 step 3
else step 2

eine Tabelle einfügen ?

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

in ethersex verwendet IRMP wahlweise Timer 0 oder 2. Der Vorteiler wird
in abhängigkeit von F_CPU und Abtastrate zur Compilezeit berechnet, ganz 
ohne Tabelle.

https://github.com/ethersex/ethersex/blob/12710c72d560ec0e60382bd1778912702a63c3d7/hardware/ir/irmp/irmp.c

von Cajus H. (cajush)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

erst mal ein großes Lob, Dein IRMP ist große Klasse!

Ich spiele mit dem Gedanken mir eine programmierbare Fernbedienung zu 
basteln, die mit einem 5" Touch etwa so viel kann wie die Philips 
Pronto.
Leider hat Philips die Herstellung dieser genialen Fernbedienungen 
eingestellt und es gibt keinen Hersteller, der etwas vergleichbares 
anbieten kann, zumindest nicht unter 1400€.

Ich habe also alle 20 Originalfernbedienungen aus dem Keller geholt und 
IRMP mit allen Protokollen (ausser Lego) auf meinem ATmega32 zum Laufen 
gebracht.

Dabei bin ich auf eine Fernbedienung gestossen, die scheinbar von IRMP 
nicht erkannt wird. Es handelt sich um eine Fernbedienung für einen 
älteren Thomson TV, die Fernbedienung nennt sich "mb100". Die 
Modulationsfrequenz ist ca. 33kHz (mit dem Oszi nachgemessen), der 
Empfänger ist ein TSOP1738 (38kHz), also passt nicht ganz zur 
Modulationsfrequenz, sollte aber trotzdem noch gehen.

Könntest Du mal schauen, ob Du mit den Scans etwas anfangen kannst?
Es wäre schön, wenn man das Protokoll noch implementieren könnte.

Gruß
Cajus

Hoppla, irgendwie ist mein Dateianhang doppelt vorhanden!?
Weis jemand wie man Dateianhänge wieder löschen kann?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Cajus H. schrieb:

> erst mal ein großes Lob, Dein IRMP ist große Klasse!

Danke :-)

> Ich spiele mit dem Gedanken mir eine programmierbare Fernbedienung zu
> basteln, die mit einem 5" Touch etwa so viel kann wie die Philips
> Pronto.

Das sagt mir jetzt nichts, aber ich vermute, dass es sich um eine 
programmierbare FB handelt, bei dem das Tastenlayout auf dem Display 
frei wählbar ist?

Vielleicht schaust Du Dir dazu mal

  http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP

an. Diese kann die Codes lernen und im EEPROM abespeichern. Ich weiß, 
hier gibt es zwar nur 5 Tasten, aber vielleicht kannst Du da was von 
übernehmen oder zumindest die eine oder andere Anregung erhalten :-)

> Ich habe also alle 20 Originalfernbedienungen aus dem Keller geholt und
> IRMP mit allen Protokollen (ausser Lego) auf meinem ATmega32 zum Laufen
> gebracht.

Super!

> Dabei bin ich auf eine Fernbedienung gestossen, die scheinbar von IRMP
> nicht erkannt wird. Es handelt sich um eine Fernbedienung für einen
> älteren Thomson TV, die Fernbedienung nennt sich "mb100". Die
> Modulationsfrequenz ist ca. 33kHz (mit dem Oszi nachgemessen), der
> Empfänger ist ein TSOP1738 (38kHz), also passt nicht ganz zur
> Modulationsfrequenz, sollte aber trotzdem noch gehen.
>
> Könntest Du mal schauen, ob Du mit den Scans etwas anfangen kannst?
> Es wäre schön, wenn man das Protokoll noch implementieren könnte.

Habs mir gerade mal kurz mit "irmp-15kHz -a" unter Linux angeschaut. Das 
Protokoll ist sehr einfach gehalten:

- Jeder Frame wird 2 mal wiederholt (also insgesamt 3 Frames)
- Kein Startbit
- Framelänge 12 Bit
- Pulslänge: 550 µs
- Pausen: 1990 µs oder 4523µs

Ich schaue mal, ob ich das morgen früh mal einbaue, sollte nicht 
schwierig sein. Dank der Fülle Deiner Scans sollte ich auch noch 
herausbekommen, wieviele Bits zur Adresse und wieviele zum Kommando 
gehören.

Eine Frage hätte ich noch: Hast Du die Tasten kurz gedrückt oder länger? 
Die 2 Wiederholungen eines jeden Frames sind etwas untypisch. Eventuell 
müsstest Du das nochmal testen, sobald IRMP das Thomson-Protokoll 
"versteht". Nicht dass zumindest der 3. Frame eine Wiederholung ist, die 
durch langes Drücken einer Taste zustandekam...

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mich hat es doch in den Fingern gejuckt und ich habe gerade mal das 
Thomson-Protokoll in den IRMP eingebaut. Da es so einfach ist, hat es 
gerade mal 20 Minuten gebraucht :-)

Neue Erkenntnisse:

- Der Frame setzt sich aus einer 4-Bit-Adresse und 8-Bit Daten zusammen
- MSB oder LSB first ist noch unbekannt, lässt sich leider nicht aus den
  Tasten 0 bis 9 erkennen
- Frame-Wiederholungen werden im Moment noch als Tasten-Wiederholungen
  (flag = 0x01) erkannt. Das muss noch angepasst werden, sobald klar
  ist, wieviele Frames bei kurzem! Tastendruck erzeugt werden

@Cajus H. (cajush):

Teste das bitte mal. Gemeinsam sollten wir das dann hinbekommen.

Im Anhang findest Du die gegenüber dem SVN geänderten Sources.

Achja: Da kommt im Moment noch eine Compiler-Warnung, die Du ignorieren 
kannst... ist halt noch ein Prototyp.

Gruß,

Frank

von Cajus H. (cajush)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

>> Philips Pronto...
> Das sagt mir jetzt nichts, aber ich vermute, dass es sich um eine
> programmierbare FB handelt, bei dem das Tastenlayout auf dem Display
> frei wählbar ist?

Ja genau und zwar WIRKLICH frei wählbar mit Tastenform, Tastengröße, 
Anordnung der Tasten, beliebige Macros und vielem mehr. Es gab eine 
Variante mit Graustufen-Touch und eine Variante mit Farb-Touch, ich habe 
eine ältere Graustufen-Variante mit relativ kleinem Touch. Im Anhang 
sind ein paar Seiten meiner Pronto.
Als Basis für eine Touch-FB habe ich dieses Modul im Auge 
http://shop.embedded-projects.net/index.php?module=artikel&action=artikel&id=459 
, erweitert um einen ATmega mit IRSND.

> Thomson Protokoll...
Ich habe eine Scan-Datei in den Anhang gepackt, bei der ich kurze und 
lange Tastendrücke dokumentiert habe. Der kurze Tastendruck ist SEHR 
kurz, normalerweise kommen zwei Ausgaben mit Code,Address und Command.
Man kann ausserdem erkennen, dass das letzte Bit ein Toggle-Bit (analog 
zum RC5 von Philips) ist. Das Bit togglet bei jedem Tastendruck, egal ob 
kurz oder lang. Es togglet auch beim Drücken von unterschiedlichen 
Tasten.

Ich habe Dir außerdem mal meine Source-Dateien angehängt.
Darin sind ein paar kleine Änderungen:
- Versionsnummer aktualisiert (sollte man eigentlich besser in einer 
Header-Datei festlegen als in der printf-Ausgabe, ich war aber zu faul 
;-)
- printf-Unterstützung auch für gcc (war nur für CODEVISION drin)
- Namen der Protokolle erweitert

Gibt es eigentlich irgendwo eine Sammlung mit Scancodes?
Ich habe mal angefangen die Codes meiner FBs in eine Tabelle zu packen, 
aber vielleicht gibt es schon eine vergleichbare Sammlung. Ich habe den 
aktuellen Stand der Liste auch mal angehängt, es fehlen noch einige FBs. 
Eigentlich eine Anwendung für eine Datenbank...

Gruß
Cajus

von Cajus H. (cajush)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

hier noch einmal meine modifizierten IRMP Sourcen, bei den obigen hatte 
sich ein Fehler eingeschlichen, der das Übersetzen mit IRMP_LOGGING = 0 
verhinderte. Das resultierte daher, weil ich Deine Uart-Initialisierung 
nach main() kopiert hatte, die Definition der Register aber nur bei 
IRMP_LOGGING = 1 gemacht wird. Daher habe ich diese Definitionen nach 
irmp.h verlegt.

Ich habe die Version nach irmp.h verschoben und gebe bei printf nur noch 
%s aus.


In Deinem Code war auch noch ein kleiner Fehler, den ich allerdings auch 
schon in der letzten Version meiner Sourcen behoben hatte: irmp.c

vor
static PROGMEM IRMP_PARAMETER thomson_param =
steht
#if IRMP_SUPPORT_DENON_PROTOCOL == 1
das sollte vermutlich
#if IRMP_SUPPORT_THOMSON_PROTOCOL == 1
heissen, oder?

Gruß
Cajus

von Torsten K. (nobby)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

hier sind ein paar Scans der Pollin Merlin Tastatur, hat etwas länger 
gedauert.
Gemacht mit  F_INTERRUPTS 20000.
Wenn Du noch mehr brauchst, oder bei Fragen, sag bescheid.

Gruß
Torsten

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Cajus H. schrieb:
>> Thomson Protokoll...
> Ich habe eine Scan-Datei in den Anhang gepackt, bei der ich kurze und
> lange Tastendrücke dokumentiert habe. Der kurze Tastendruck ist SEHR
> kurz, normalerweise kommen zwei Ausgaben mit Code,Address und Command.
> Man kann ausserdem erkennen, dass das letzte Bit ein Toggle-Bit (analog
> zum RC5 von Philips) ist. Das Bit togglet bei jedem Tastendruck, egal ob
> kurz oder lang. Es togglet auch beim Drücken von unterschiedlichen
> Tasten.

Sehr gut. Bei kurzen Tastendrücken gibt es nur einen einzigen Frame. Das 
macht die Sache leichter. Danke für den Tipp mit dem Toggle-Bit. IRMP 
blendet das nun aus. Damit konnte ich dann sehen, dass die 
Bit-Reihenfolge MSB-First ist, denn die untereinander liegenden Tasten 
0,4,7 / 2,5,8 / 3,6,9 haben damit eine aufsteigende Reihenfolge. Das 
ergibt folgende Codeänderungen:
#define THOMSON_COMMAND_OFFSET                  5                               // skip 4 address bits + 1 toggle bit
#define THOMSON_COMMAND_LEN                     7                               // read 7 command bits
#define THOMSON_LSB                             0                               // MSB...LSB

> Ich habe Dir außerdem mal meine Source-Dateien angehängt.
> Darin sind ein paar kleine Änderungen:
> - Versionsnummer aktualisiert (sollte man eigentlich besser in einer
> Header-Datei festlegen als in der printf-Ausgabe, ich war aber zu faul
> ;-)

Die Versionsnummer, die im Codevision-Teil steht, habe ich nie gepflegt. 
Ich überlege mittlerweile auch, die Codevision-Unterstützung komplett 
rauszuwerfen, da ich diese mangels Codevision-Compiler sowieso nicht 
unterstützen kann. Das würde den Code etwas übersichtlicher machen - 
zumindest in main.c.

> - printf-Unterstützung auch für gcc (war nur für CODEVISION drin)

Schaue ich mir mal an. Eigentlich hat das aber nichts im IRMP zu suchen. 
Die main.c ist eigentlich nur ein Beispiel-Code und nicht wirklich 
Bestandteil des IRMP.

> - Namen der Protokolle erweitert

Ja, eben, das wurde nicht gepflegt. Eigentlich will ich das auch gar 
nicht ;-)

> Gibt es eigentlich irgendwo eine Sammlung mit Scancodes?

Es gibt das LIRC-Projekt. Ob es sinnvoll ist, für IRMP auch so etwas zu 
machen, weiß ich nicht.

Cajus H. schrieb:

> In Deinem Code war auch noch ein kleiner Fehler, den ich allerdings auch
> schon in der letzten Version meiner Sourcen behoben hatte: irmp.c
>
> vor
> static PROGMEM IRMP_PARAMETER thomson_param =
> steht
> #if IRMP_SUPPORT_DENON_PROTOCOL == 1
> das sollte vermutlich
> #if IRMP_SUPPORT_THOMSON_PROTOCOL == 1
> heissen, oder?

Ja, danke, das war ein Copy&Paste-Fehler.

Ich werde meine Änderungen bzgl. Thomson-Protkoll morgen mal ins SVN 
einchecken.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten K. schrieb:
> hier sind ein paar Scans der Pollin Merlin Tastatur, hat etwas länger
> gedauert.

Vielen Dank. Auf den ersten Blick ist das ein Bitserielles Protokoll - 
analog zur Netbox. Also weder Manchester noch Pulse-Distance, wie es bei 
Fernbedienungen üblich ist. Ich schaue mal, dass ich da einen ersten 
Prototyp im Laufe der kommenden Woche baue.

> Wenn Du noch mehr brauchst, oder bei Fragen, sag bescheid.

Danke, ich melde mich dann :-)

Gruß,

Frank

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
>> Gibt es eigentlich irgendwo eine Sammlung mit Scancodes?
>
> Es gibt das LIRC-Projekt. Ob es sinnvoll ist, für IRMP auch so etwas zu
> machen, weiß ich nicht.

fände ich sinnvoll, wenn z.B. eine FB kaputt geht kann man nix machen, 
würde man die Codes finden könnte man eine FB nachprogrammieren und sei 
es wenn man IRSND nur dazu benutzt eine lernfähige anzulernen, ich 
musste für Vaters VCR FB die teure Nachbau FB bestellen, hätte ich die 
Codes gefunden, genügte IRSND + eine billige Lern FB

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@frank (ukw)

gibt es die Möglichkeit das RC5 toogle Bit wieder einzufügen ?

ich hatte ja vorher den dani RC5 Code drin und nun auf IRMP umgestellt, 
Address und Data konnte ich kompatibel erstellen, aber mir fehlt zu 
einfachen Auswertung das toogle Bit für gleiche Taste oder neue Taste

irgendwie schaffe ich es nicht nur 1 Tastendruck auszuwerten, egal wie 
ich drücke entweder wird nix erkannt, zu kurz, oder zu lang und ich 
bekomme 2 steps zum einstellen, mit toogle bit wärs leichter

danke

gruss
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> gibt es die Möglichkeit das RC5 toogle Bit wieder einzufügen ?

Ich sehe dafür eigentlich keine Notwendigkeit. IRMP ignoriert das 
Toggle-Bit, weil es meines Erachtens überflüssig ist. Zum "Entprellen" 
der Tastatur stellt IRMP andere (kompatible) Methoden zur Verfügung, 
s.u.

> ich hatte ja vorher den dani RC5 Code drin und nun auf IRMP umgestellt,
> Address und Data konnte ich kompatibel erstellen, aber mir fehlt zu
> einfachen Auswertung das toogle Bit für gleiche Taste oder neue Taste

Das ist einfach: IRMP setzt in flags das BIT IRMP_FLAG_REPETITION, wenn 
eine Wiederholung durch langen Tastendruck entsteht, siehe auch 
IRMP-Artikel.

Einfache Abfrage:
    if (irmp_data.flags & IRMP_FLAG_REPETITION)
    {
      // Benutzer hält die Taste länger runter
      // entweder:
      //   ich ignoriere die (Wiederholungs-)Taste
      // oder:
      //   ich benutze diese Info, um einen Repeat-Effekt zu nutzen
    }
    else
    {
      // Es handelt sich um eine neue Taste
    }

So ist das für alle von IRMP unterstützten Protokolle kompatibel gelöst 
- egal, ob das Protokoll ein Toggle-Bit bereitstellt oder nicht.

> irgendwie schaffe ich es nicht nur 1 Tastendruck auszuwerten, egal wie
> ich drücke entweder wird nix erkannt, zu kurz, oder zu lang und ich
> bekomme 2 steps zum einstellen, mit toogle bit wärs leichter

Ignoriere einfach alle Frames, wo das Bit IRMP_FLAG_REPETITION gesetzt 
ist.

Also in Deinem Fall:
    if (! (irmp_data.flags & IRMP_FLAG_REPETITION))
    {
      // Es handelt sich um eine neue Taste
      // ACTION!
    }

Und schon hast Du Deine FB-Tasten "entprellt" ;-)

Gruß,

Frank

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Also in Deinem Fall:
>     if (! (irmp_data.flags & IRMP_FLAG_REPETITION))
>     {
>       // Es handelt sich um eine neue Taste
>       // ACTION!
>     }
>
> Und schon hast Du Deine FB-Tasten "entprellt" ;-)
>
> Gruß,
>
> Frank

funzt, nur natürlich kein repeat mehr.....

ich muss mal sehen evt. muss ich aus diesen Infos das toogle Bit 
nachbauen

oder ich blicke noch nicht durch wie ich kurz und lang auswerten kann 
ohne delay !

ich weiss die Lösung hast du schon beschrieben, nur muss ich das in 
meinen Code pressen, oder meinen code neu schreiben, mal sehen

danke
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> funzt, nur natürlich kein repeat mehr.....

Wie hast Du denn mit dem Toggle-Bit das Repeat gemacht? Wenn das 
Toggle-Bit sich nicht(!) ändert, dann Repeat wegen langem Tastendruck? 
Das entspricht doch dem Fall, dass das IRMP-Flag gesetzt ist.

Brauchst Du für jede Taste ein Repeat? Oder nur für bestimmte?

> ich weiss die Lösung hast du schon beschrieben, nur muss ich das in
> meinen Code pressen, oder meinen code neu schreiben, mal sehen

Vielleicht zeigst Du mal einen Auszug aus Deinem Code?

Gruß,

Frank

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
so ungefähr, muss mich nach 3 Jahren selber wieder einfummeln, bin halt 
kein begnadeter progger, nur für den Hausgebrauch :-)

// Auszug
L_Com=(irmp_data.address*100)+irmp_data.command;

switch( L_Com&0x7fff )
// kein repeat
case PINN_PLAY:  // programm ausführen pinnacle taste "||>"
case 3053:  // programm ausführen hauppauge taste ">"
 if(Old_L_Com != L_Com)
  res_key=(1<<KEY6);
break;

// repeat möglich
case PINN_PLUS:  // kon up pinnacle taste "VOL up"
case 3016:  // kon up hauppauge taste "VOL up"
k_plus();
break;

aus dani code
void fb(void)
{  if( i_ )
  {  //_toggelbit = ( i_ >> 11 & 1);
    L_Com  =  (i_ >> 6 & 0x1F)*100;
      L_Com  +=  (i_ & 0x3F) | (~i_ >> 7 & 0x40);


von Cajus H. (cajush)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

>> Thomson Protokoll...
> Ich werde meine Änderungen bzgl. Thomson-Protkoll morgen mal ins SVN
> einchecken.
Kann es sein, dass Du noch nicht dazu gekommen bist? ;-)

Nachdem ich die Fernbedienungen aller z.Zt. in Gebrauch befindlichen 
Geräte mit IRMP einlesen konnte stehe ich nun vor der Aufgabe IRSND in 
Betrieb zu nehmen. Der aktuelle Code aus dem SVN funktionierte auf 
Anhieb, zumindest kam ein IR-Signal im 1 sec. Rythmus. Wie ich oben 
schon erwähnt habe, möchte ich eine Programmierbare FB mit Touch-Screen 
bauen. Die Touch-Software erkennt einen Tastendruck und sendet einen 
"Taste Gedrückt" Event an IRSND, zusammen mit dem Wert für Protokoll, 
Adresse und Komando. Wird der Finger vom Touch genommen kommt der "Taste 
Losgelassen" Event. In der Zwischenzeit sollte IRSND das entsprechende 
Kommando senden.

Frage: Wie lässt sich das mit IRSND realisieren?

Ein einfaches Wiederholen des Komandos bis zum Taste Losgelassen Event 
dürfte nicht funktionieren. Ich habe Funktionen, die unterschiedlich auf 
lange und kurze Tastendrücke reagieren. Beispiel Licht Schalten/Dimmen: 
Ein kurzer Tastendruck schaltet das Licht ein/aus, ein langer 
Tastendruck dimmt heller/dunkler. Hier wird RC5 Code verwendet, d.h. 
neben der "gedrückt-Zeit" das Togglebit wird mit ausgewertet. Wird der 
gleiche Code mit anderem Toggle-Bit empfangen, so wertet das der Dimmer 
als neuen Tastendruck. Würde ich also den Befehl "Licht ein/heller" so 
lange wiederholen, bis der Taste Losgelassen Event eintrifft, dann würde 
jede Wiederholung mit invertiertem Toggle Bit ausgesendet. Dies würde 
vom Dimmer aber als neuer Tastendruck gewertet, wodurch bei einem langem 
Tastendruck nicht die Funktion Dimmen, sondern nur 
ein-aus-ein-aus-ein-aus erkannt wird.

Berücksichtigt IRSND eigentlich das Toggle-Bit bei Codes, die das 
unterstützen?

Ich habe gesehen, IRSND hat den Parameter flags, mit dem man die Anzahl 
der Wiederholungen vorgeben kann. Das Problem dabei ist, in dem Moment, 
in dem die Taste gedrückt wird, weis ich noch nicht wie lange sie unten 
bleibt! Man bräuchte daher ein flag "sende bis auf Widerruf".

Und noch eine Bitte: Könntest Du das neue Thomson Protokoll in IRSND 
einbauen?

Gruß
Cajus

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Cajus,

Cajus H. schrieb:

>> Ich werde meine Änderungen bzgl. Thomson-Protkoll morgen mal ins SVN
>> einchecken.
> Kann es sein, dass Du noch nicht dazu gekommen bist? ;-)

Upps, habe ich das tatäschlich vergessen? Naja, bis auf die 3 defines 
habe ich da nichts großartiges geändert. Okay, werde ich nachholen.

> [...] Wird der Finger vom Touch genommen kommt der "Taste
> Losgelassen" Event. In der Zwischenzeit sollte IRSND das entsprechende
> Kommando senden.
>
> Frage: Wie lässt sich das mit IRSND realisieren?

Gute Frage. Ich würde auf den ersten Blick sagen, dass Du, bis das 
Loslassen-Event kommt, immer wieder irsnd_send_data() aufrufst.

> Ein einfaches Wiederholen des Komandos bis zum Taste Losgelassen Event
> dürfte nicht funktionieren.

Warum nicht? Wenn das Problem lediglich das Toggle-Bit ist, werden wir 
das auch lösen können. Ich habe da auch schon eine Idee, siehe weiter 
unten.

> Ich habe Funktionen, die unterschiedlich auf
> lange und kurze Tastendrücke reagieren. Beispiel Licht Schalten/Dimmen:
> Ein kurzer Tastendruck schaltet das Licht ein/aus, ein langer
> Tastendruck dimmt heller/dunkler. Hier wird RC5 Code verwendet, d.h.
> neben der "gedrückt-Zeit" das Togglebit wird mit ausgewertet. Wird der
> gleiche Code mit anderem Toggle-Bit empfangen, so wertet das der Dimmer
> als neuen Tastendruck.

Wenn ich es recht in Erinnerung habe, toggelt IRSND das Toggle-Bit nicht 
in Wiederholungen, die durch den flags-Wert angegeben ist, sondern nur 
bei erneutem Aufruf von irsnd_send_data(). So sollte es jedenfalls 
sein... und so brauchst Du das ja prinzipiell auch.

> Würde ich also den Befehl "Licht ein/heller" so
> lange wiederholen, bis der Taste Losgelassen Event eintrifft, dann würde
> jede Wiederholung mit invertiertem Toggle Bit ausgesendet.

Korrekt.

> Dies würde
> vom Dimmer aber als neuer Tastendruck gewertet, wodurch bei einem langem
> Tastendruck nicht die Funktion Dimmen, sondern nur
> ein-aus-ein-aus-ein-aus erkannt wird.

Okay, habe ich verstanden. Ist das Dein eigens entwickelter Dimmer? 
Sowas am Toggle-Bit festzumachen, ist eine höchst inkompatible 
Geschichte, wenn man an andere IR-Protokolle denkt ;-)

> Berücksichtigt IRSND eigentlich das Toggle-Bit bei Codes, die das
> unterstützen?

Ja, sollte IRSND berücksichtigen. Bei jedem erneuten Aufruf von 
irsnd_send_data() wird getogglet, innerhalb der flags-Wiederholungen 
nicht.

> Ich habe gesehen, IRSND hat den Parameter flags, mit dem man die Anzahl
> der Wiederholungen vorgeben kann. Das Problem dabei ist, in dem Moment,
> in dem die Taste gedrückt wird, weis ich noch nicht wie lange sie unten
> bleibt! Man bräuchte daher ein flag "sende bis auf Widerruf".

Ja, genau DAS ist das Problem, was ich bei meiner lernfähigen FB, die 
mein Sohn und ich im gesonderten Artikel vorgestellt hatten, auch hatte.

Deshalb rufe ich irsnd_send_data() in einer Schleife mit flags = 0 auf, 
wenn ich Wiederholungen senden möchte (Code dazu s. ganz unten). Da wird 
aber das Toggle-Bit immer wieder geändert... nicht schön.

Ich hätte folgenden Vorschlag zur Änderung der Software:

1. Die Anzahl der Wiederholungen werden im unteren Nibble von
   flags abgelegt, es sind dann nur noch Werte von 0 bis 15 möglich.
   Mehr als 15 Wiederholungen (in einem Satz) braucht keiner, außer...
   siehe Punkt 2.

   Damit gewinne ich 4 Bit, die ich zukünftig als flags gebrauchen kann.

2. Der Wert flags = 15 führt dazu, dass IRSND die Frames endlos
   wiederholt, also bis in alle Ewigkeit sendet. Hier würde dann
   natürlich ein Toggle-Bit nicht geändert werden - wie jetzt auch.

3. Es gibt eine neue Funktion irsnd_stop(), welche das weitere Senden
   von Wiederholungen nach Abschluss des aktuell gesendeten Frames
   unterbindet. Damit kann man dann das endlose Senden dann wieder
   stoppen.

Fürs API würde ich folgende 4 Konstanten vorsehen:

#define IRSND_NO_REPETITIONS       0    // no repetitions
#define IRSND_MAX_REPETITIONS     14    // max # of repetitions
#define IRSND_ENDLESS_REPETITION  15    // endless repetions
#define IRSND_REPETITION_MASK     0x0F  // lower nibble of flags

Du könntest dann beim "Taste Gedrückt" Event die Funktion 
irsnd_send_data() mit flags = IRSND_ENDLESS_REPETITION aufrufen. Sobald 
Deine Software das "Taste Losgelassen" Event schickt, rufst Du 
irsnd_stop() auf.

Wäre Dir damit geholfen?

> Und noch eine Bitte: Könntest Du das neue Thomson Protokoll in IRSND
> einbauen?

Ja, kann ich machen. Ich komme zu all diesen Änderungen aber frühestens 
am Sontagabend (spät!).

Gruß,

Frank

P.S.
IRSND hat im Moment auch noch einen unschönen Bug, den ich dabei auch 
noch loswerden möchte: Nach Aussenden des gewünschten Frames wird die 
Pause-Zeit zum nächsten Frame nicht eingehalten, wenn man 
irsnd_send_data() direkt wieder aufruft. Innerhalb von flags > 0 wird 
das korrekt eingehalten, aber nach dem letzten gesendeten Frame kann man 
direkt wieder mittels irsnd_send_data() "feuern". Das ist unschön.

Ich habe das in der DIY-FB erstmal als Hack folgendermaßen gelöst:
        while (cnt > 0)                                             // send cnt frames
        {
            irsnd_send_data (&(irmp_data[k]), TRUE);                // send IR code now

            while (irsnd_is_busy ())                                // HACK: wait until IRSND is ready
            {
                ;
            }

            _delay_ms (50);                                         // wait 50 msec to force a pause between frames
            cnt--;
        };

Ich weiß, das ist unschön. Deshalb werde ich den Bug in IRSND 
schnellstmöglich fixen.

von Cajus H. (cajush)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

> Ist das Dein eigens entwickelter Dimmer?
Ja
> Sowas am Toggle-Bit festzumachen, ist eine höchst inkompatible
> Geschichte, wenn man an andere IR-Protokolle denkt ;-)
Dem will ich nicht widersprechen, aber die Abhängigkeit vom Toggle-Bit 
ist nicht auf meinem Mist gewachsen. Ich habe bei diversen alten Philips 
TV Geräten und anderen mit RC5 arbeitenden FBs eine ähnliches Verhalten 
festgestellt: Lautstärke + gedrückt halten hat nur funktioniert, wenn 
sich das Toggle Bit NICHT geändert hat.

> 1. Die Anzahl der Wiederholungen werden im unteren Nibble von
>   flags abgelegt, es sind dann nur noch Werte von 0 bis 15 möglich.
>   Mehr als 15 Wiederholungen (in einem Satz) braucht keiner, außer...
>   siehe Punkt 2.
>
>   Damit gewinne ich 4 Bit, die ich zukünftig als flags gebrauchen kann.

OK. Ich hoffe es schreit dann keiner "Ich brauche aber 20 
Wiederholungen!"

> 2. Der Wert flags = 15 führt dazu, dass IRSND die Frames endlos
>   wiederholt, also bis in alle Ewigkeit sendet. Hier würde dann
>   natürlich ein Toggle-Bit nicht geändert werden - wie jetzt auch.

Gut. Vielleicht sollte man eine "Notabschaltung" nach einigen Sekunden 
vorsehen (per #define sollte reichen), sonst ist bei batteriebetriebenen 
Geräten und einem verloren gegangenen Loslass-Event jedes mal die 
Batterie alle ;-). So etwas kann man auch in main() realisieren, dann 
bläht das nicht die Interrupt Routine auf.

> 3. Es gibt eine neue Funktion irsnd_stop(), welche das weitere Senden
>   von Wiederholungen nach Abschluss des aktuell gesendeten Frames
>   unterbindet. Damit kann man dann das endlose Senden dann wieder
>   stoppen.

Perfekt!

> Wäre Dir damit geholfen?

Sehr!

>> Und noch eine Bitte: Könntest Du das neue Thomson Protokoll in IRSND
>> einbauen?
> Ja, kann ich machen.

Danke!
Bitte im Thomson Protokoll auch das Toggle-Bit berücksichtigen!

> IRSND hat im Moment auch noch einen unschönen Bug...
> Nach Aussenden des gewünschten Frames wird die Pause-Zeit zum
> nächsten Frame nicht eingehalten...

Danke für den Hinweis. Ich sehe das aber nicht als so schlimm an, das 
kann ruhig in main() erledigt werden. Schreib doch einfach den Hinweis 
und den Code in irsndmain.c. Ich halte das für völlig ausreichend.

Gruß
Cajus

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

> Ich hätte folgenden Vorschlag zur Änderung der Software:
>
> 1. Die Anzahl der Wiederholungen werden im unteren Nibble von
>    flags abgelegt, es sind dann nur noch Werte von 0 bis 15 möglich.
>    Mehr als 15 Wiederholungen (in einem Satz) braucht keiner, außer...
>    siehe Punkt 2.
>
>    Damit gewinne ich 4 Bit, die ich zukünftig als flags gebrauchen kann.

Die Änderung ist nun im SVN.

> 2. Der Wert flags = 15 führt dazu, dass IRSND die Frames endlos
>    wiederholt, also bis in alle Ewigkeit sendet. Hier würde dann
>    natürlich ein Toggle-Bit nicht geändert werden - wie jetzt auch.

Bei flags == IRSND_ENDLESS_REPETITION wird der erzeugte Frame endlos 
geschickt. Nein, stimmt nicht ganz: Nach max. 256 Frames wird aufgehört, 
um die Batterie nicht komplett leerzulutschen :-)

Auch diese Änderung ist im SVN.

> 3. Es gibt eine neue Funktion irsnd_stop(), welche das weitere Senden
>    von Wiederholungen nach Abschluss des aktuell gesendeten Frames
>    unterbindet. Damit kann man dann das endlose Senden dann wieder
>    stoppen.

Ist nun auch im SVN.

> Fürs API würde ich folgende 4 Konstanten vorsehen:
>
> #define IRSND_NO_REPETITIONS       0    // no repetitions
> #define IRSND_MAX_REPETITIONS     14    // max # of repetitions
> #define IRSND_ENDLESS_REPETITION  15    // endless repetions
> #define IRSND_REPETITION_MASK     0x0F  // lower nibble of flags

Ist ebenso umgesetzt.

> IRSND hat im Moment auch noch einen unschönen Bug, den ich dabei auch
> noch loswerden möchte: Nach Aussenden des gewünschten Frames wird die
> Pause-Zeit zum nächsten Frame nicht eingehalten, wenn man
> irsnd_send_data() direkt wieder aufruft. Innerhalb von flags > 0 wird
> das korrekt eingehalten, aber nach dem letzten gesendeten Frame kann man
> direkt wieder mittels irsnd_send_data() "feuern". Das ist unschön.

Diesen Bug habe ich nun auch gefixt. Ist zwar noch nicht optimal, aber 
ich bin erstmal damit zufrieden. Die Pause wird nämlich erst dann 
eingefügt, wenn auch tatsächlich ein 2. Frame auf die Reise geschickt 
wird.

Desweiteren habe ich das THOMSON-Protokoll in den IRSND eingebaut.

Cajus H. (cajush):

Kannst Du das bitte testen und berichten?

Gruß,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Hy Frank,

gibts schon was neues zur Pollin Merlin Tastatur, oder hab ich das hier 
überlesen ??

Gruß
Torsten

von Cajus H. (cajush)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

Frank M. schrieb:
> Cajus H. (cajush):
>
> Kannst Du das bitte testen und berichten?

Da ist ein Copy&Paste Fehler in irmp.c
nach
#if IRMP_SUPPORT_MERLIN_PROTOCOL == 1

static PROGMEM IRMP_PARAMETER netbox_param =
sollte vermutlich
static PROGMEM IRMP_PARAMETER merlin_param =
heissen...

Danach arbeitet IRMP gut und liefert sinnvolle Werte für das Thomson 
Protokoll.

IRSND - mein main() sieht so aus:

int main (void)
{
  IRMP_DATA irmp_data;

  irsnd_init(); // initialize irsnd
  timer_init(); // initialize timer
  sei();        // enable interrupts

  for (;;)
  {
    irmp_data.protocol = IRMP_THOMSON_PROTOCOL;
    irmp_data.address  = 0x03;
    irmp_data.command  = 0x1d;
    irmp_data.flags    = 15;

    irsnd_send_data (&irmp_data, TRUE);
    _delay_ms (10000);
    irsnd_stop ();
    _delay_ms (3000);

  }
}
Es sollte also 10 Sekunden das Kommando 0x1d senden, dann 3 Sekunde 
Pause und wieder von vorne. Es passiert aber folgendes:
- 10 Sekunden Senden
- 3 Sekunden Pause
- Senden bis die Batterie alle ist.
Scheinbar funktioniert das irsnd_stop(); nur einmal ?!
Wenn ich
irmp_data.flags = 14;
setze, dann funktioniert es. (auch mit dem irsnd_stop(), vermutlich weil 
das Senden von 14 Wiederholungen keine 10 Sekunden dauert...)
Das Beenden des Sendens nach 256 Wiederholungen funktioniert, außer im 
Fall oben, da hört IRSND mit dem Senden nicht mehr auf,

Gruß
Cajus

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Cajus,

Cajus H. schrieb:

> Da ist ein Copy&Paste Fehler in irmp.c

Danke, ist korrigiert.

> Es sollte also 10 Sekunden das Kommando 0x1d senden, dann 3 Sekunde
> Pause und wieder von vorne. Es passiert aber folgendes:
> - 10 Sekunden Senden
> - 3 Sekunden Pause
> - Senden bis die Batterie alle ist.

Danke für den Test, ich habe den Fehler gefunden und korrigiert. 
irsnd_stop() sollte nun tun, was es soll.

Klappt das denn nun auch mit dem Toggle-Bit, so wie Du es mir 
beschrieben hat? Kann Dein Dimmer nun lange Tastendrücke von mehrfachen 
Tastendrücken per Toggle-Bit unterscheiden?

> Scheinbar funktioniert das irsnd_stop(); nur einmal ?!

Nein, es funktionierte keinmal. irsnd_stop() hatte die falsche Variable 
zurückgesetzt. Das hatte schlicht und ergreifend "Null Effekt".

Korrektur ist im SVN eingecheckt.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Torsten,

Torsten K. schrieb:

> gibts schon was neues zur Pollin Merlin Tastatur, oder hab ich das hier
> überlesen ??

Sorry, habs noch nicht geschafft, die Merlin-Tastatur komplett auf alle 
Tastendrücke durchzuchecken. Ich hoffe, ich schaffe es im Laufe der 
Woche.

Gruß,

Frank

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> och, wird erkannt. Das ist das NEC16-Protokoll

hmm, guten abend

habe gerade mal das aktuelle aus dem SVN installiert

NEC16 flattert nun über alle möglichen Erkennungen NEC16 MERLIN RUWIDO 
kommt alles mögliche bei repeat (also wenn ich den Finger auf der Taste 
lasse)

SAMSUNG32 ist stabil

KASEIKYO flattert wenig aber ich sehe dabei auch gel. MERLIN und SIEMENS

IRMP - Infrared Multi Protocol Decoder
--------------------------------------
Version IRMP:  2.0.0-pre4 20.05.2010
Version IRSND: 1.9.4      22.05.2010

??? wunder einige Sourcen waren vom 22.5. also aktuell

irgendwas ist instabil

evt. schaust mal ?

gruss
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> NEC16 flattert nun über alle möglichen Erkennungen NEC16 MERLIN RUWIDO
> kommt alles mögliche bei repeat (also wenn ich den Finger auf der Taste
> lasse)

Was meinst Du damit? Dass bei einer NEC16-FB zwischendurch auch mal 
MERLIN oder RUWIDO erkannt wird? Welche Protokolle hast Du alle 
eingeschaltet?

> KASEIKYO flattert wenig aber ich sehe dabei auch gel. MERLIN und SIEMENS

Hier also KASEIKYO-FB, wo ab und zu MERLIN bzw. SIEMENS ausgegeben wird?

> irgendwas ist instabil

Ich bräuchte Deine irmpconfig.h, um das nachzustellen. Quarz ist 
angeschlossen und aktiv?

Gruß,

Frank

von Joachim B. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> as meinst Du damit? Dass bei einer NEC16-FB zwischendurch auch mal
> MERLIN oder RUWIDO erkannt wird? Welche Protokolle hast Du alle
> eingeschaltet?

genau bleibe ich auf der Taste werden reium alle mal erkannt

alle ausser on >15000 Hz und Prototyp Protokoll 99

> Hier also KASEIKYO-FB, wo ab und zu MERLIN bzw. SIEMENS ausgegeben wird?
> Ich bräuchte Deine irmpconfig.h, um das nachzustellen. Quarz ist
> angeschlossen und aktiv?

ohne Quarz, war aber vorher stabiler

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
PS könnte man proto String nicht integrieren ?

muss den immer nachfummeln bei jedem Update
static char *Proto[]={ \
"SIRCS","NEC","SAMSUNG","MATSUSH","KASEIKYO","RECS80","RC5(x)","DENON","RC6","SAMSG32",\
"APPLE","RECS80x","NUBERT","BANG_OLUF","GRUNDIG","NOKIA","SIEMENS","FDC","RCCAR","JVC",\
"RC6A","NIKON", "RUWIDO","IR60","KATHREIN","NETBOX","NEC16","NEC42","LEGO","THOMSON", \
"MERLIN"};

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
noch ein kleines Problem:

wird nach
irmp_get_data(&irmp_data)

das irmp_get_data FLAG nicht gelöscht ?

ich kann nur zwischen den Drücken unterscheiden wenn ich zwischendurch 
eine andere Taste drücke

drücke ich die Taste 1x und halte fest, lasse los und drück die selbe 
toogelt das Repeat Bit nicht, erst wenn ci zwischendurch ne andere 
drücke, dabei sollte z.B. TASTE 1 toggeln, wenn losgelassen und wieder 
gedrückt wird ..
    if (irmp_get_data(&irmp_data))
     {  
      merke_fb=(irmp_data.address*100)+irmp_data.command;
      L_Com=merke_fb;
      merke_rc5=merke_fb;

      if (irmp_data.flags & IRMP_FLAG_REPETITION)
       {   // Benutzer hält die Taste länger runter
          // entweder:
          //   ich ignoriere die (Wiederholungs-)Taste
          // oder:
          //   ich benutze diese Info, um einen Repeat-Effekt zu nutzen
        merke_fb  |= (1<<15);
        merke_rc5       |= (1<<15);
        L_Com    |= (1<<15);
                                // simmuliere TOGGELbit
        }
       else // if (irmp_data.flags & IRMP_FLAG_REPETITION)
       {   // Es handelt sich um eine neue Taste
        show_irmp=5;
        merke_fb    &= ~(1<<15);
        merke_rc5  &= ~(1<<15);
        L_Com      &= ~(1<<15);
                                // simmuliere TOGGELbit


von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
keine Antwort ? liegts an mir (weil ich mich unwissend anstelle?)

ich versuchs mal anders zu erklären

DU kennst doch typische Puls- Pausenlängen

ergo müsste es doch in IRMP auffallen wenn zwischen 2 Tastendrücken der 
selbe Code kommt oder innerhalb der Repeatframezeit der selbe Code 
einläuft und das Repeatflag entsprechend gesetzt wird.

Ich blick immer noch nicht durch wielange IRMP das Flag "Code erkannt" 
vorrätig hält, für mein Geschmack wäre es richtig bis man es ausgelesen 
hat, man guckt ja als Controller nicht ständig :-)

bei meiner KEY Abfrage mache ich es so, lese KEY, werte Key aus, lösche 
den gelesen KEY und wenn nix zu tun ist und KEY leer ist, dann hole dir 
wieder einen KEY wenn vorhanden

und da ich KEY und IR benutze wäre es schön wenn man das zusammen 
bekommt

nur muss ich ja die IR Flags befragen und wenn da ewig welche abzuholen 
sind kann ich nicht erkennen ob ich den schon mal geholt habe, bzw. kann 
ja ein neuer KEY , ähhh, IR Code sein der durchaus identisch mit dem 
Vorcode ist, trotzem ist er neu und es sollte toggeln....

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> keine Antwort ? liegts an mir (weil ich mich unwissend anstelle?)

Ich habe Dir bisher nicht antworten können, weil ich noch ein 
Privatleben ohne µC und Elektronik habe ;-)

> ich versuchs mal anders zu erklären
> [...]

Da ich an den Timingparametern nichts geändert habe, kann ich mir im 
Moment gar nicht vorstellen, wo Deine Probleme herrühren. Im Moment kann 
ich mir da nur den fehlenden Quarz vorstellen. Sonst helfen mir da nur 
intensive Tests weiter.

Am Donnerstagabend habe ich vielleicht Zeit, Dein Szenario 
durchzuspielen. Dann kann ich Dir auch antworten. Vorher schaffe ich es 
leider nicht, sorry.

> nur muss ich ja die IR Flags befragen und wenn da ewig welche abzuholen
> sind kann ich nicht erkennen ob ich den schon mal geholt habe, bzw. kann
> ja ein neuer KEY , ähhh, IR Code sein der durchaus identisch mit dem
> Vorcode ist, trotzem ist er neu und es sollte toggeln....

Wenn der nächste IR-Frame innerhalb IRMP_KEY_REPETITION_LEN (150 msec) 
reinkommt, dann geht IRMP davon aus, dass die FB automatisch repetiert. 
Dann wird das Repetition-Flag gesetzt. Das funktioniert sehr gut. Wenn 
Du selber mit dem Finger repetierst, wirst Du das nicht so schnell 
schaffen und IRMP setzt dann auch nicht(!) das Repetition-Flag. Also 
vergiss das mit dem Toggle, das geht nur bei RC5, RC6 und Thomson. Bei 
den 27 anderen FB-Protokollen, die IRMP unterstützt, gibt es gar kein 
Toggle-Bit. Daher kann ich das auch gar nicht auswerten.

EDIT: Wenn Du das Toggle-Bit simulieren musst, weil Du anderen Code 
verwendest, der nicht auf das RC5-Toggle-Bit verzichten kann, dann mach 
einfach folgendes:

 - Repetition-Flag gesetzt: dann nicht togglen
 - Repetition-Flag nicht gesetzt: dann togglen

Dann sollte auch RC5-Legacy-Code zusammen mit IRMP funktionieren ;-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> bei meiner KEY Abfrage mache ich es so, lese KEY, werte Key aus, lösche
> den gelesen KEY und wenn nix zu tun ist und KEY leer ist, dann hole dir
> wieder einen KEY wenn vorhanden

Wenn was zu tun ist: Wie lange brauchst Du, um den Key abzuarbeiten?

Bitte möglichst in msec angeben :-)

Sobald IRMP einen Frame eingelesen hat, sperrt er den Empfang weiterer 
IR-Signale solange, bis Du den Code auch abholst.

Ich kann mir ein Szenario vorstellen, wo das in die Hose geht.

1. Du hältst den Finger auf eine FB-Taste
2. IRMP empfängt 1. Frame
3. Du holtst ihn ab und verarbeitest den Key...
4. Währenddessen empfängt IRMP den 2. Frame und speichert die Daten
5. Du verarbeitest aber immer noch den 1. Key -> IRMP sperrt den Empfang
6. Es kommt der 3. Frame, aber IRMP empfängt nicht
7. Du bist mit der Verarbeitung fertig - mitten im Frame 3
8. Du holst den 2. Frame ab, IRMP gibt den Empfang wieder frei
9. Ein Restfragment vom 3. Frame wird von IRMP aufgezeichnet und
   fälschlicherweise als irgendein Protokoll erkannt, vorzugsweise eines
   ohne ausgezeichnetes Start-Bit.

Wenn dem so ist, kann ich das nur lösen, indem IRMP den Empfang nicht 
sperrt, aber das Ergebnis anschließend verwirft, solange Du den Frame 
davor nicht abgeholt hast.

Gruß,

Frank

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
natürlich darfst du ein Privatleben haben, ich hab momentan keines und 
bin deswegen so ungeduldig ?

Frank M. schrieb:
> Ich kann mir ein Szenario vorstellen, wo das in die Hose geht.
>
> 1. Du hältst den Finger auf eine FB-Taste

logisch, ich weiss ja nicht wann der Code vollständig empfangen wurde 
bis das gewünschte passiert, vermutlich auch das Problem das der Buffer 
meiner lernfähigen FB nie reicht für 4-8 Fernbedienungen (wie der 
Aufdruck und die Werbung behaupten), immer sagt die lern FB : Buffer 
voll obwohl nur 2 halbe FBs (Kaseikyo) gelernt wurden.

Kann aber auch sein die Befehle wurden immer länger und der Speicher der 
FB (alte >5 Jahre  und NEUE !!! grad gekauft ) ist zu knapp

> 2. IRMP empfängt 1. Frame
> 3. Du holtst ihn ab und verarbeitest den Key...
> 4. Währenddessen empfängt IRMP den 2. Frame und speichert die Daten
> 5. Du verarbeitest aber immer noch den 1. Key -> IRMP sperrt den Empfang
> 6. Es kommt der 3. Frame, aber IRMP empfängt nicht

das könnte genau so laufen

> 7. Du bist mit der Verarbeitung fertig - mitten im Frame 3
> 8. Du holst den 2. Frame ab, IRMP gibt den Empfang wieder frei
> 9. Ein Restfragment vom 3. Frame wird von IRMP aufgezeichnet und
>    fälschlicherweise als irgendein Protokoll erkannt, vorzugsweise eines
>    ohne ausgezeichnetes Start-Bit.
>
> Wenn dem so ist, kann ich das nur lösen, indem IRMP den Empfang nicht
> sperrt, aber das Ergebnis anschließend verwirft, solange Du den Frame
> davor nicht abgeholt hast.

wielange KEY dauert ? oder die Abarbeitung nach KEY ? das letztere werde 
ich nie rausfinden, es gibt nur 6 Tasten die in jedem Menue und 
Untermenue je nach Bedingung verschiedenes tun, also die 
Verarbeitungsdauer nach KEY lesen ist unbestimmt

ein Riesendanke für deine Bemühungen

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ich hatte mir was überlegt, aber das scheint auch nicht zu klappen

ich dachte wenn ich ein Bit selber toggeln lasse, in der Art,

...

klappt aber auch nicht, evt. kannst du ein Flag einbauen welches immer 
toggelt wenn eine neue Taste kommt oder wenn eine FramePause erkannt 
wurde also die FB Taste mal nicht gedrückt war
void fb(void)
{  
  if (irmp_get_data(&irmp_data) && !strcmp((char *)Proto[irmp_data.protocol-1], "RC5(x)") )
  {  
    L_Com&=0x8000; // loesche L_Com aber behalte das alte toggleBIT
    L_Com|=(((irmp_data.address*100)+irmp_data.command)&0x7fff); // addiere neues L_Com aber behalte das alte toggleBIT
    merke_rc5=L_Com;

    if (irmp_data.flags & IRMP_FLAG_REPETITION)
     {   // Benutzer hält die Taste länger runter
        // entweder:
        //   ich ignoriere die (Wiederholungs-)Taste
        // oder:
        //   ich benutze diese Info, um einen Repeat-Effekt zu nutzen
      // toggleBIT aendert nicht
      }
     else // if (irmp_data.flags & IRMP_FLAG_REPETITION)
     {   // Es handelt sich um eine neue Taste
      show_irmp=5;
      //_merke_toggleBIT^=(1<<15);
      L_Com  ^= (1<<15);       // toggleBIT aendert sich
      merke_rc5=L_Com;
    }
        // ....
        // ab hier mache ich weiter wie frueher
        // ....
        // ....
        // ....
        // ....
        // ....
        // ....
        
        
   } // if(irmp_get_data(&irmp_data) && !strcmp((char *)Proto[irmp_data.protocol-1], "RC5(x)") )
  else
  {
      L_Com  ^= (1<<15);
    // toggleBIT aendert sich
  }
}

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
warum ist das toggleBIT eigendlich nicht im IRMP erkannten RC5 Code 
vorhanden ?

dann könnte man sich diese Quälerei sparen, im RC5 wird es ja 
mitgeliefert und ich brauche nicht zu tricksen

wenn der Umbau aber klappt mit toggle selber erzeugen -

(nach meinem Vorschlag: evt. kannst du ein Flag einbauen welches immer
toggelt wenn eine neue Taste kommt oder wenn eine FramePause erkannt
wurde also die FB Taste mal nicht gedrückt war )

- für alle Codes waere das auch fein

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> warum ist das toggleBIT eigendlich nicht im IRMP erkannten RC5 Code
> vorhanden ?

Weil Du dann für ein- und dieselbe Taste zwei unterschiedliche Codes 
bekommen würdest.

> dann könnte man sich diese Quälerei sparen, im RC5 wird es ja
> mitgeliefert und ich brauche nicht zu tricksen

Die "Quälerei" hast Du nur deshalb, weil Du Code benutzt, der Original 
RC5 sehen will. IRMP wandelt die Daten aber in ein portables Format, was 
für alle Protokolle einheitlich ist.

> wenn der Umbau aber klappt mit toggle selber erzeugen -
>
> (nach meinem Vorschlag: evt. kannst du ein Flag einbauen welches immer
> toggelt wenn eine neue Taste kommt oder wenn eine FramePause erkannt
> wurde also die FB Taste mal nicht gedrückt war )

Ich habe doch schon geschrieben: Wenn Repetition-Flag nicht gesetzt, 
dann togglen, wenn Flag gesetzt, dann nicht togglen. Hast Du das 
überlesen?

> - für alle Codes waere das auch fein

Warum sollte ich ein Toggle-Bit künstlich einbauen? Die anderen 
Protokolle kennen doch gar kein Toggle-Bit. Dafür gibt es doch das 
Repetition-Flag in IRMP. Das ist doch viel einfacher zu handhaben als so 
ein Toggle-Bit.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> ich hatte mir was überlegt, aber das scheint auch nicht zu klappen
> void fb(void)
> {
>   if (irmp_get_data(&irmp_data) && !strcmp((char
> *)Proto[irmp_data.protocol-1], "RC5(x)") )
>   {
>     L_Com&=0x8000; // loesche L_Com aber behalte das alte toggleBIT

Wie kommst Du auf die Idee, dass das Toggle-Bit an der 16. Stelle sitzt?
>       L_Com  ^= (1<<15);

Auch hier:

Wie kommst Du auf die Idee, dass das Toggle-Bit an der 16. Stelle sitzt?

Schau Dir bitte http://www.sbprojects.com/knowledge/ir/rc5.htm an.

merke_rc5 wird bei Dir gesetzt aber nie benutzt?

Machs doch einfach so:
void fb(void)
{
    static uint16_t toggle_bit;
    ...

    toggle_bit ^= (1<<11);    // Togglen
    L_Com|= toggle_bit;
    ...
}

Und noch etwas:

Dein

   if (... !strcmp((char *)Proto[irmp_data.protocol-1], "RC5(x)"))

ist suboptimal und kostet viel CPU-ZEIT. Warum nicht einfach:

   if (... irmp_data.protocol == IRMP_RC5_PROTOCOL)

Das ist nur ein int16-Vergleich und geht wesentlich schneller als Dein 
Zeichenkettenvergleich. Warum machst Du so etwas?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Deine fb-Funktion ist absoluter Murks, der else-Block ganz am Ende 
gehört da auch nicht hin.

Ich schreibe das mal neu:
void fb(void)
{  
  static uint16_t toggle_bit;

  if (irmp_get_data(&irmp_data) && irmp_data.protocol == IRMP_RC5_PROTOCOL)
  {  
    L_Com = (((irmp_data.address*100) + irmp_data.command) & 0x7fff); // L_Com aus Adresse und Kommando zusammenbauen

    if (! (irmp_data.flags & IRMP_FLAG_REPETITION))
    {
      toggle_bit ^= (1<<11);    // Togglen
      L_Com |= toggle_bit;
    }


    // ....
    // ab hier mache ich weiter wie frueher
    // ....

  }

  // KEIN ELSE!!!!
}

So einfach ist das. :-)

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Zusatz:

Was soll der Ausdruck ((irmp_data.address*100) + irmp_data.command) & 
0x7fff)

Adresse mal hundert + Kommando? Verstehe ich nicht. Damit baust Du 
jedenfalls nicht den Original-Frame zusammen, sondern irgendeine 
Zufallszahl.

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Warum sollte ich ein Toggle-Bit künstlich einbauen? Die anderen
> Protokolle kennen doch gar kein Toggle-Bit. Dafür gibt es doch das
> Repetition-Flag in IRMP. Das ist doch viel einfacher zu handhaben als so
> ein Toggle-Bit.
> Gruß,
> Frank

also im RC5 Code wäre es nicht künstlich eingebaut, da wird das 
mitgeliefert und damit lief mein altes Programm genau wie geplant, ich 
verstehe halt nicht warum IRMP das nicht durchreichen kann ?

Frank M. schrieb:
> Dein
>
>    if (... !strcmp((char *)Proto[irmp_data.protocol-1], "RC5(x)"))
>
> ist suboptimal und kostet viel CPU-ZEIT. Warum nicht einfach:
>
>    if (... irmp_data.protocol == IRMP_RC5_PROTOCOL)
>
> Das ist nur ein int16-Vergleich und geht wesentlich schneller als Dein
> Zeichenkettenvergleich.

ja klar

> Warum machst Du so etwas?

weil das für mich der schnellste Weg war ohne IRMP vollständig zu 
erkunden ?
ich wusste RC5 wird per String ausgegeben wenn erkannt, also war das 
mein Unterscheidungsmerkmal, natürlich suboptimal und kann man ja 
korrigieren, zur Codeoptimierung kann ich ja später vordringen wenns 
erst mal läuft, wenn natürlich schon vorher gute Ideen einfliessen warum 
nicht zur Laufzeit der Prog.Entwicklung einfliessen lassen, mach ich nun

Frank M. schrieb:
> Deine fb-Funktion ist absoluter Murks, der else-Block ganz am Ende
> gehört da auch nicht hin.
>
> Ich schreibe das mal neu:
> ...
> So einfach ist das. :-)


ich probiere es ;-)))

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> also im RC5 Code wäre es nicht künstlich eingebaut, da wird das
> mitgeliefert und damit lief mein altes Programm genau wie geplant, ich
> verstehe halt nicht warum IRMP das nicht durchreichen kann ?

Habe ich doch geschrieben: Dann würdest Du im IRMP für ein- und dieselbe 
Taste 2 verschiedene Codes bekommen.

> weil das für mich der schnellste Weg war ohne IRMP vollständig zu
> erkunden ?

Die Konstante steht in irmp.h und im IRMP-Artikel steht ein 
Anwendungsbeispiel:

   http://www.mikrocontroller.net/articles/IRMP#Anwendung_von_IRMP

Zitat:
      if (irmp_data.protocol == IRMP_NEC_PROTOCOL &&     // NEC-Protokoll
          irmp_data.address == 0x1234)                   // Adresse 0x1234

> ich wusste RC5 wird per String ausgegeben wenn erkannt, also war das
> mein Unterscheidungsmerkmal, natürlich suboptimal und kann man ja
> korrigieren, zur Codeoptimierung kann ich ja später vordringen wenns
> erst mal läuft, wenn natürlich schon vorher gute Ideen einfliessen warum
> nicht zur Laufzeit der Prog.Entwicklung einfliessen lassen, mach ich nun

Jetzt verstehe ich auch, warum Du wolltest, dass ich die Texte in main.c 
vervollständige... :-)

> ich probiere es ;-)))

Viel Glück! :-)

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
funktioniert nicht :-(

Codes werden mehrfach erkannt und sofort ohne Zwischenstop falsch 
abgearbeitet

also Menue -> ENTER -> Untermenue und da warten bis andere Taste oder 
ENTER wieder neu ! gedrückt wird

wird in einem Rutsch abgearbeitet, keine Chance im Untermenue noch 
Optionen zu wählen

wenn ich also auf der FB Taste gedrückt bleibe ! werden die Aktionen im 
ca. 10s ? Takt durchgeführt, z.B. Licht an/aus
obwohl ich ja die Taste nie losgelassen hatte

wenn ich kurz drücke, passiert entweder nix ! oder Licht geht an und 
gleich wieder aus, einen statischen ON/OFF Zustand kann ich so nicht 
erreichen

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> funktioniert nicht :-(

Du hattest auch meine Frage bzgl. der Position des Toggle-Bits nicht 
beantwortet. Wo muss das stecken? An der 16. Stelle? Oder wie im 
Original an der 12. Stelle?

Zeig doch mal den Rest Deines RC5-Programms, damit man sieht, wo das 
Toggle-Bit stecken muss.

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Habe ich doch geschrieben: Dann würdest Du im IRMP für ein- und dieselbe
> Taste 2 verschiedene Codes bekommen.

ja und ? das war schon immer so, der einzige Unterschied wäre das 
originale RC5 ToogleBIT welches ausmaskiert werden kann wenn das 
jemanden stört !

ich hab das ToggleBIT von (1<<11) nur nach (1<<15) verschoben um unten 
Platz zu behalten

ich habe Adresse mit 100 multipliziert weil mir Adresse 30 als 3000 und 
7 als 700 sympatisch war und ich bei RC5 nie mehr als 100 Commands sah 
und weil ich hauptberuflich kein Infomatiker bin

deswegen kämpfe ich ja an allen Fronten gleichzeitig

eagle nervt fast mit wöchenlichen Updates und jedesmal muss ich an allen 
Stellen die LIBs importieren die wires beim Start neu intialisieren, das 
nervt und wehe man vergisst an einem Rechner irgendeine Einstellung....

eine zeitlang waren meine avr_gcc und ASTUDIO nicht auf allen Rechnern 
auf den gleichen Stand aber alles lief, dann hatte ich auf einem Rechner 
ein update gemacht und nix lief mehr, dann habe ich alles gelöscht die 
REG geputzt und noch mal von vorne und nix ging (irgendwas in der REG 
übersehen?), also noch mal von vorne und damit das nicht wieder passiert 
habe ich den win_avr PATH geändert um sicherzugehen, seit dem nervt mich 
MAKE wenn ich an dem einen oder anderen Rechner arbeite das er die LIBs 
nicht findet, gleichwohl ich weiss nicht wie das passiert, werden die 
FILENAMEN nun manchmal in UPPER Case importiert, was den Linker wieder 
ärgert C++ ist nicht in gnu99c enthalten, dabei benutze ich kein C++

wenn ich dann manuell im DIR die Filenamen wieder zu lower Case mache 
ist es wieder OK, jedenfalls temporär

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Zeig doch mal den Rest Deines RC5-Programms, damit man sieht, wo das
> Toggle-Bit stecken muss.

Habs gerade selber gefunden in

   Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

Da steht:
aus dani code
void fb(void)
{  if( i_ )
  {  //_toggelbit = ( i_ >> 11 & 1);
    L_Com  =  (i_ >> 6 & 0x1F)*100;
      L_Com  +=  (i_ & 0x3F) | (~i_ >> 7 & 0x40);

Ein RC5x-Frame sieht folgendermaßen aus:

C6 T A4 A3 A2 A1 A0 C5 C4 C3 C2 C1 C0

Die Zeile
    L_Com  =  (i_ >> 6 & 0x1F)*100;

Speichert in L_Com das Hundertfache von der Adresse: A4 A3 A2 A1 A0.
Dabei werden die Kommando-Bits und auch das Toggle-Bit weggeschnitten.

Die Zeile
      L_Com  +=  (i_ & 0x3F) | (~i_ >> 7 & 0x40);

sollte wohl C6 C5 C4 C3 C2 C1 C0 speichern, wobei C6 invertiert ist nach 
dem RC5x-Protokoll.

Aber das scheint ein Programmierfehler zu sein: Wenn ich richtig zähle, 
stimmt aber die Bitposition für das C6 nicht.

@Joachim B.

Das Toggle-Bit an 12. Stelle wird hier jedenfalls komplett ignoriert. 
Ich brauche den alten RC5-Code, sonst kann ich Dir nicht helfen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> ja und ? das war schon immer so, der einzige Unterschied wäre das
> originale RC5 ToogleBIT welches ausmaskiert werden kann wenn das
> jemanden stört !

Sorry, Du hast den Sinn und Zweck von IRMP nicht verstanden. IRMP 
speichert den Frame in einem kompatiblen Format ab und nicht im 
RC5-Format. Ein IRMP-Anwender braucht gar nicht zu wissen, was RC5 ist 
und dass da ein Toggle-Bit ist, was ausmaskiert werden muss!

Der Vorteil von IRMP ist doch gerade die Protokoll-Unabhängigkeit. Soll 
der jetzt da reinschreiben: "Wenn protokoll gleich RC5, schmeiß dass 
Toggle-Bit weg"?

Nein, die Einführung eines eines allgemeinen Toggle-Bits in IRMP für den 
Spezialfall, dass Dein alter Code wieder läuft, ist für mich nicht 
akzeptabel. Ich helfe Dir gern. Aber ich brauch dafür den alten Source 
von Dir, sonst wird das nix.

von Joachim B. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Zeig doch mal den Rest Deines RC5-Programms, damit man sieht, wo das
> Toggle-Bit stecken muss.

etwas mehr Code als IRMP noch nicht integriert war

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Nein, die Einführung eines eines allgemeinen Toggle-Bits in IRMP für den
> Spezialfall, dass Dein alter Code wieder läuft, ist für mich nicht
> akzeptabel. Ich helfe Dir gern. Aber ich brauch dafür den alten Source
> von Dir, sonst wird das nix.

ich verstehe das ja, nur wie soll man das lösen das das so gewünschte 
programmtechnisch läuft ?

alle Lösungsversuche liefen bis jetzt schief, es scheint als wenn das 
nicht funktioniert

warum geht mein Licht an und aus wenn ich auf der Taste power bleibe ? 
der State hat ja nie gewechselt, ergo dürfte
  if( !(irmp_data.flags & IRMP_FLAG_REPETITION) )
      {
     toggle_bit ^= (1<<15);    // Togglen
           L_Com |= toggle_bit;
      }

nie das toggleBIT ändern, mit L_Com ist gleicher Befehl und das 
togglebit unverändert und __p == HAUPTMENU
        case PINN_GROSSER_KULLER:  // light 
        case PINN_6:  // p6 pinnacle taste "6"
        case 3006:  // light hauppauge taste "6"
        case 3015:  // light hauppauge taste "mute" MUTE
          if(__p==_STATUS || __p==_IRMP)
          {  if(count> 10)  {  p_old=86; __p=_LICHT; count=0;  }  }
          else
            if(Old_L_Com != L_Com)
              speedLED(TOGGLE);
          break;

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> warum geht mein Licht an und aus wenn ich auf der Taste power bleibe ?
> der State hat ja nie gewechselt, ergo dürfte

Jetzt zeige bitte den neuen Source, welcher IRMP nutzt, damit ich das 
vergleichen kann.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> warum geht mein Licht an und aus wenn ich auf der Taste power bleibe ?
> der State hat ja nie gewechselt, ergo dürfte
>
>
>   if( !(irmp_data.flags & IRMP_FLAG_REPETITION) )
>       {
>      toggle_bit ^= (1<<15);    // Togglen
>            L_Com |= toggle_bit;
>       }
> 
>
> nie das toggleBIT ändern, mit L_Com ist gleicher Befehl und das
> togglebit unverändert und __p == HAUPTMENU

Wenn Du diesen Block weglässt, passiert dann das gewünschte bei langem 
Tastendruck?

von Joachim B. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Wenn Du diesen Block weglässt, passiert dann das gewünschte bei langem
> Tastendruck?

wie schon mal

langer Tastendruck z.B. Licht an/aus lässt eine NEUE Taste genau einmal 
reagieren, ob ich draufbleibe oder loslasse und nochmal drücke ändert 
nix, nie wieder reagiert die Routine auf die gewünschte Taste bis ich 
eine andere drücke erst dann wird wieder z.B. Licht geschaltet

evt. geht das Licht auch so schnell an und aus das ich es nicht merke

denn up und downscrollen funktioniert ja

aber wenn ich im Untermenue mehrfach die TAB-Taste drücke, springt die 
nur 1x wie beim Licht, ich muss zwischendurch eine andere Taste drücken 
damit TAB wieder einmal reagiert

neuer Code anbei

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
die Idee warum ich dafür IRMP nutzen möchte

wie du schon sagtes RC5 stirbt aus und mein Timer sollte (lernfähig) mit 
allen FB arbeiten, gleichwohl ist die "Funktion" alle FB erkennen toll 
und hilfreich als Tester in ein Gehäuse gepresst und kann quasi nebenbei 
von meinem Timer erledigt werden, alle Codes erkenne ich ja, nur kann 
ich so die IR Fähigkeit der Bedienung vergessen, es sei denn wir finden 
ne Lösung

die Möglichkeit nur zur Bedienung auf RC5 Decoder auszuweichen und zum 
Test IRMP zu nutzen gäbs ja auch noch, aber damit verbaue ich mir die 
Lernfähigkeit der Timerbedienung für alle FB
#include "cpu.h"
#include <avr/io.h>

#ifndef TYPES_H
  #include "types_.h"
#endif

/************************************************************************/
/*                                                                      */
/*                      RC5 Remote Receiver                             */
/*                                                                      */
/*              Author: Peter Dannegger                                 */
/*                      danni@specs.de                                  */
/*                                                                      */
/************************************************************************/
#include <avr/interrupt.h>
//#include <avr/signal.h>
#include <stdlib.h>

von Joachim B. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hi frank,

ich hab nun den RC5 Aufruf in die ISR hinter dem IRMP Aufruf gesetzt und 
bei RC5 erkannt werte ich dieses nur aus, ergo mein Hauptcode 
funktioniert wieder wie gewünscht,

kein repeat da wo er nicht sein darf,
aber repeat da wo gewünscht

ich kann repeaten bei scroll up/down und nie repeaten bei Licht an/aus 
oder ENTER

ich leg das mal in den Zip

vielleicht fällt dir noch was ein (ich würde sehr gerne für alle FB IRMP 
nutzen)

eines ist mir aufgefallen

ich hole pro main loop genau 1x den RC5 Code ab und der wird von mir 
gleich danach gelöscht
 for (;;)
{
  cli(); //Global Interrupt Disable
     i_ = rc5_data;      // read two bytes from interrupt !
     rc5_data = 0;
     sei(); //Global Interrupt Enable

// der ganze Rest vom main loop 

}

evt. muss ich das auch bei IRMP ?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> vielleicht fällt dir noch was ein (ich würde sehr gerne für alle FB IRMP
> nutzen)

Ich weiß nicht, ob ich es schaffe, mir das in den nächsten Tagen 
anzuschauen.

Wenn Du gern alle FBs mit IRMP für Dein Programm nutzen möchtest, dann 
musst Du Dich gedanklich vom Toggle-Bit lösen. Du vergleichst immer den 
letzten mit dem vorletzten Befehl, um herauszufinden, obs togglet oder 
nicht. Das ist alles viel zu umständlich. Dein Source würde sich 
vereinfachen, wenn Du einfach das Flag konsequent abfragst. Es bringt 
nichts, die IRMP-Werte an Dein Programm anzupassen. Besser wäre die 
Anpassung Deines Sources an IRMP.

Leider ist Dein Source nicht soooo übersichtlich, dass ich mir das in 5 
Minuten zu Gemüte führen kann, da ist schon etwas Detektivarbeit 
gefragt, um da durchzusteigen. Ich machs irgendwann in den nächsten 
Tagen, bin aber viel unterwegs. Kann also etwas dauern.

Gruß,

Frank

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich weiß nicht, ob ich es schaffe, mir das in den nächsten Tagen
> anzuschauen.
>
> Wenn Du gern alle FBs mit IRMP für Dein Programm nutzen möchtest, dann
> musst Du Dich gedanklich vom Toggle-Bit lösen. Du vergleichst immer den
> letzten mit dem vorletzten Befehl, um herauszufinden, obs togglet oder
> nicht. Das ist alles viel zu umständlich. Dein Source würde sich
> vereinfachen, wenn Du einfach das Flag konsequent abfragst.

das hatten wir doch versucht ? ohne Erfolg :-(

> Es bringt
> nichts, die IRMP-Werte an Dein Programm anzupassen. Besser wäre die
> Anpassung Deines Sources an IRMP.

klar ich bin sehr dafür !

> Leider ist Dein Source nicht soooo übersichtlich, dass ich mir das in 5
> Minuten zu Gemüte führen kann, da ist schon etwas Detektivarbeit
> gefragt, um da durchzusteigen.

genau deswegen wird er ja so pö a pö neugeschrieben, war eben ne top 
down Entwicklung (erwähnte ich das ich kein Softi bin :D)
PS. brauchst du noch den umfangreichen Rest ?

> Ich machs irgendwann in den nächsten
> Tagen, bin aber viel unterwegs. Kann also etwas dauern.

alles klar, danke, ich werde mich nun mal um die Straffung und 
Bereinigung kümmern, einiges gefällt mir selber nicht mehr, z.B. mein 
"Multitask" viel zu umständlich (ich hasse delays, jede Menge Timercode 
den man so im Netz findet lässt die CPU ewig in delay-Schleifen unnütz 
warten, dabei kann man in der Zeit auch was anderes tun, die ADC 
befragen, das LCD updaten, die Uhr weiterlaufen lassen, die DCF77 Bits 
befragen die Tastatur abholen und natürlich auf Events reagieren wie LED 
zurücksetzen

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> das hatten wir doch versucht ? ohne Erfolg :-(

Wir? Nein! Bis heute kannte ich Deinen Source doch überhaupt nicht. Und 
mich beschleicht das Gefühl, dass Du Deinen Source auch nicht (mehr) so 
gut kennst :-)

Folgende Maßnahmen sind notwendig, um vom RC5-Protokoll wegzukommen:

 - Das toggle-Bit muss komplett raus.
 - Der Vergleich alter <--> neuer Frame muss raus, ist überflüssig
 - Das Multiplizieren/Addieren der Adresse mit dem Kommando muss raus
   (das funktioniert nur mit RC5 so, bei NEC geht das schon voll in die
    Hose)

> klar ich bin sehr dafür !

Ich schlage vor, dass ich dafür ein Grundgerüst schreibe, dass Du dann 
mit Leben füllst (reinschreiben konkreter numerischer Werte + Test). 
Dann sollte das machbar sein.

> genau deswegen wird er ja so pö a pö neugeschrieben, war eben ne top
> down Entwicklung (erwähnte ich das ich kein Softi bin :D)
> PS. brauchst du noch den umfangreichen Rest ?

Dieses "pö a pö" ist der falsche Weg, das macht alles nur 
unübersichtlicher. Besser ist es, die Funktion fb() komplett neu zu 
schreiben. Schreib doch mal auf, was die Funktion bei welcher Taste 
machen soll, z.B.

TAB kurz:    nächster Menüpunkt Funktion: menu_down()
TAB lang:    Untermenüaufruf, Funktion: sub_menu()

So in der Richtung...

Aber ich bin in der nächsten Woche komplett ausgelastet, ich komme da 
erst übernächste Woche zu.

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Wir? Nein! Bis heute kannte ich Deinen Source doch überhaupt nicht. Und
> mich beschleicht das Gefühl, dass Du Deinen Source auch nicht (mehr) so
> gut kennst :-)

hmm du hattest gesagt wie und ich habs eingetippt, mit der Folge,

Versuch 1
das bei "ewigem" Tastendruck die LED trotzdem an und aus ging, also die 
Einmalabfrage nicht klappte
Versuch 2
die einmal Abfrage zwar klappte, aber nur einmal, Taste loslassen hatte 
danach keinerlei Wirkung mehr, erst der Tastenwechsel und zurück lies 
die Taste wieder erkennen

> Folgende Maßnahmen sind notwendig, um vom RC5-Protokoll wegzukommen:
>  - Das toggle-Bit muss komplett raus.
>  - Der Vergleich alter <--> neuer Frame muss raus, ist überflüssig
>  - Das Multiplizieren/Addieren der Adresse mit dem Kommando muss raus
>    (das funktioniert nur mit RC5 so, bei NEC geht das schon voll in die
>     Hose)

OK

> Ich schlage vor, dass ich dafür ein Grundgerüst schreibe, dass Du dann
> mit Leben füllst (reinschreiben konkreter numerischer Werte + Test).
> Dann sollte das machbar sein.

noch mehr OK

> Dieses "pö a pö" ist der falsche Weg, das macht alles nur
> unübersichtlicher. Besser ist es, die Funktion fb() komplett neu zu
> schreiben. Schreib doch mal auf, was die Funktion bei welcher Taste
> machen soll, z.B.
>
> TAB kurz:    nächster Menüpunkt Funktion: menu_down()
> TAB lang:    Untermenüaufruf, Funktion: sub_menu()
>
> So in der Richtung...

da grübel ich ja gerade, IR und Tastatur sind gleichberechtigt
entweder ich lese die Taste und weise dem einen IR Code zu und erledige 
die Aufgaben da, oder ich lese den IR Code und setze KEY und erledige 
die Aufgaben da ????

natürlich muss ich dann KEY Test und IR Test irgendwie sonderbehandeln

> Aber ich bin in der nächsten Woche komplett ausgelastet, ich komme da
> erst übernächste Woche zu.

no Problem, mache ich erst mal den Rumpf weiter (Display ist größer 
geworden, von 20 x 4 alphanumerisch auf 21 x 8 Z -aber grafisch- )

Ich muss eh die Screens neu definieren, den RAM Verbrauch eindämmen, 
Grafik ohne Lesemöglichkeit kostet, und Strings gleich aus dem flash zu 
lesen, oder ins EEPROM schieben um da ändern zu können

also ich bin beschäftigt solange du noch nicht kannst

Danke und viel Erfolg

von Michael K. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Weiter oben wurde mal wegen Stromsparmechanismen diskutiert. Hat sich 
mal jemand weiter damit auseinandergesetzt und/oder Erfahrungen damit 
gesammelt, zwecks Realisierbarkeit? Die neueren TSOPs (z.B. TSOP34838) 
kommen ja mit weniger als 1mA aus - da würde sich das IMO schon lohnen.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Michael K. schrieb:
> Weiter oben wurde mal wegen Stromsparmechanismen diskutiert. Hat sich
> mal jemand weiter damit auseinandergesetzt und/oder Erfahrungen damit
> gesammelt, zwecks Realisierbarkeit? Die neueren TSOPs (z.B. TSOP34838)
> kommen ja mit weniger als 1mA aus - da würde sich das IMO schon lohnen.

hmm, bedingt, was meinst du damit ? als Sender oder Empfänger ?

im Prinzip einfach, an einer TastenMatrix für IRSND den pin-change 
wakeup und senden, als Empfänger dito pinchange belauscht den TSOP

ich habe es in meinem Timer1 gemacht, luca in einem Cam Trigger, da 
werden sogar die Puls/Pausenzeiten per sleep realisiert, also jedes 
delay schickt die CPU schlafen bis die Zeit um ist

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Michael K. schrieb:
> Weiter oben wurde mal wegen Stromsparmechanismen diskutiert. Hat sich
> mal jemand weiter damit auseinandergesetzt und/oder Erfahrungen damit
> gesammelt, zwecks Realisierbarkeit?

Das ist eigentlich nicht Sache des IRMP - als Bibliothek betrachtet.

> Die neueren TSOPs (z.B. TSOP34838) kommen ja mit weniger als 1mA
> aus - da würde sich das IMO schon lohnen.

Es geht auch mit den älteren TSOPs, wenn man die Stromversorgung des 
TSOPs über einen ATMega-Pin steuert. Ich habe das so in der Lernfähigen 
Fernbedienung so umgesetzt, die auch IRMP nutzt:

http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP

Dafür muss dann aber das Programm "wissen", wann es den TSOP einschalten 
muss, damit etwas empfangen werden kann. Der Stromverbrauch bei diesem 
Mini-Projekt liegt bei weit unter 1µA.

Gruß,

Frank

von Michael K. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich meinte als Empfänger, der allzeit bereit sein soll.

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Es geht auch mit den älteren TSOPs, wenn man die Stromversorgung des
> TSOPs über einen ATMega-Pin steuert.

dann geht das folgende aber nicht, der TSOP muss ja Vcc haben damit er 
ein output an pin change AVR senden kann

Michael K. schrieb:
> Ich meinte als Empfänger, der allzeit bereit sein soll.

klaro, schick die CPU schlafen der TSOP bleibt auch on an Vcc und weckt 
mit Signal out an einen PIN Change den AVR, das AVR delay dürfte 
vernachlässigbar sein ? irgendwas um 65 CLK also bei 20 MHz AVR 3µs,
Frank wird das eher wissen ob das delay die Auswertung stört

@frank, mal zu meinem "Problem" geschaut ?

von Dirk W. (glotzi)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich verwende IRMP zusammen mit dem IR-Receiver in Hugo Portisch. Da der 
IR-Receiver einen älteren Stand aus dem letzen Jahr enthält, habe ich 
ein Upgrade auf IRMP-SVN-Head gemacht. Das funktioniert soweit auch gut, 
bis auf folgendes:

1. ich kann keine Frequenzen > 10000 benutzen, dann wird nichts mehr 
erkannt. Das könnte auch ein IR-Receiver spezifisches Problem sein. Im 
Thread dort habe ich schon nachgefragt aber keine Antwort bekommen. BTW 
der ältere Stand aus dem letzen Jahr hat das gleiche Problem.

2. Die Ruwido Merlin funktioniert bei mir nicht, es wird nur Müll 
erkannt. Wie ist denn der genaue Status der Merlin Implementierung? 
Sollte das funktionieren?

Folgende Protokolle funktionieren bei mir: RC6A, Samsung32, FDC 
Keyboard.

von Michael K. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dirk W. schrieb:
> Im Thread dort habe ich schon nachgefragt aber keine Antwort bekommen.
Ich habe dir doch dort geantwortet 
(Beitrag "Re: USB IR Remote Receiver (V-USB + IRMP)").

Mit IRMP hat das Problem nichts zu tun. Derzeit gibt es keine Lösung, 
daher sollte der Regler IMO in ruhe gelassen werden. Anders sieht es mit 
dem Makro F_INTERRUPTS aus: das kann geändert werden und die Firmware 
sollte nach der Neukompilierung laufen (ich habe es nicht getestet).

Um das zu beheben müsste für jedes Makro in irmp.c, Zeile 385 bis 599, 
eine Variable her, deren Inhalt bei einer Änderung neu berechnet werden 
müsste. Das hätte einen Speicherverbrauch zur Folge der den Rahmen eines 
AVR sprengt.

von Dirk W. (glotzi)


Bewertung
0 lesenswert
nicht lesenswert
Michael K. schrieb:
> Mit IRMP hat das Problem nichts zu tun. Derzeit gibt es keine Lösung,
> daher sollte der Regler IMO in ruhe gelassen werden. Anders sieht es mit
> dem Makro F_INTERRUPTS aus: das kann geändert werden und die Firmware
> sollte nach der Neukompilierung laufen (ich habe es nicht getestet).

Ich habe natürlich F_INTERRUPTS in der IRMP Source geändert und nicht 
über die Windows-DLL. Es funktionert (bei mir) nicht.

von KLez (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Mal eine frage: Wäre es möglich, dass IRMP auch das Ausgangssignal des 
Funkempfängers von z.B. der Logitech Harmony 900 dekodieren kann? Dessen 
Ausgang ist eigentlich dazu da einen extra IR Sender anzuschließen. Da 
dieser Sender aber nur IR-Dioden enthält, gehe ich davon aus, dass das 
Signal bereits mit der Trägerfrequenz versehen ist, usw.

IRMP müsste also zuerst noch die Trägerfrequenz rausrechnen um an das 
Nutzsignal zu kommen... Ist es möglich das einzubauen oder funktioniert 
das ohne extra Hardware allgemein nicht?

P.S.: Die Frage habe ich auch schon im USB IR Empfänger Thread gestellt, 
aber eventuell bin ich hier "richtiger".

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
KLez schrieb:
> IRMP müsste also zuerst noch die Trägerfrequenz rausrechnen um an das
> Nutzsignal zu kommen... Ist es möglich das einzubauen oder funktioniert
> das ohne extra Hardware allgemein nicht?

Ja, das sollte möglich sein.

Gruß,

Frank

von Dirk W. (glotzi)


Bewertung
0 lesenswert
nicht lesenswert
@Frank M.

Darf ich deine Aufmerksamkeit auf diesen Beitrag 
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

lenken. Vorallem Punkt 2 würde mich interessieren.
Danke.

von KLez (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ja, das sollte möglich sein.

Hallo Frank,

Ich habe gerade nochmal geschaut und glaube ehrlichgesagt nicht, dass es 
so einfach möglich ist. Wie ich lesen konnte pollst Du den Eingang mit 
10KHz... Das ist nach meinem Verständnis also um das 3,8 fache zu wenig 
um eine 38Khz Trägerfreuqenz raus zu rechnen, oder habe ich gerade einen 
Denkfehler?

Wie würdest Du das ganze implementieren?

Viele Grüße

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
KLez schrieb:
> Ich habe gerade nochmal geschaut und glaube ehrlichgesagt nicht, dass es
> so einfach möglich ist. Wie ich lesen konnte pollst Du den Eingang mit
> 10KHz... Das ist nach meinem Verständnis also um das 3,8 fache zu wenig
> um eine 38Khz Trägerfreuqenz raus zu rechnen, oder habe ich gerade einen
> Denkfehler?

Eine 38kHz Trägerfrequenz hat eine Periodenlänge von ca. 26 µsec. Du 
musst die Pulse von ca. 13 µsec softwaremäßig auf mehr als 26 µsec 
verlängern, damit IRMP ein durchgängiges Signal "sieht".

> Wie würdest Du das ganze implementieren?

Ich würde mir einen PCINT-Interrupt auf das Eingangssignal setzen. Dort 
setze ich ein globales Flag namens ir_signal, z.B. so:
#define IR_OFF    1             // no IR signal
#define IR_ACTIVE 0             // IR signal active

volatile uint8_t ir_signal = IR_OFF;

ISR(PCINT1_vect)
{
    ir_signal = IR_ACTIVE;      // IR is active
}

In der normalen Timer_ISR, die Du ja sowieso für den Aufruf der IRMP-ISR 
brauchst, würde ich nach(!) dem Aufruf von irmp_ISR() dieses Flag wieder 
zurücksetzen, also:
ISR(TIMER1_COMPA_vect)
{
  (void) irmp_ISR();
  ir_signal = IR_OFF;
}

In irmpconfig.h setzt Du:
#define input(x)        ir_signal


Der Trick ist, dass Du damit jeden Puls des Trägersignals solange 
softwaremäßig verlängerst, dass die IRMP-ISR ihn mindestens einmal 
"sieht". Da der PCINT bei aktivem IR-Signal viel öfter kommt als die 
IRMP-ISR ausgelöst wird, sollte das so klappen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dirk W. schrieb:
> Darf ich deine Aufmerksamkeit auf diesen Beitrag
> Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
> lenken. Vorallem Punkt 2 würde mich interessieren.

Sorry, zum Punkt 1 kann ich nichts beitragen, ich habe mich bisher nicht 
so tief in Hugos V-USB Port reingehängt.

Zum Punkt 2: Muss ich zu Hause nachschauen, wie weit ich da bin, habe 
zwischwendurch viele andere interessante Sachen gemacht. ;-)

Ich melde mich dazu nochmal.

Gruß,

Frank

von Dirk W. (glotzi)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Zum Punkt 2: Muss ich zu Hause nachschauen, wie weit ich da bin, habe
> zwischwendurch viele andere interessante Sachen gemacht. ;-)
>
> Ich melde mich dazu nochmal.

Danke fürs Feedback. Ich habe inzwischen noch eine Netbox Tastatur hier 
und die funktioniert auch nicht. Es wird nur gelegentlich RC6A erkannt. 
Evtl. hängt das mit den Merlin Problem zusammen.

Bei der FDC Tastatur ist mir aufgefallen, dass wenn ich längere Zeit 
eine Taste festhalte nicht auschliesslich Events mit Protokoll FDC 
geschickt werden, sondern auch welche mit Protokoll Merlin. Das kann 
aber auch Zufall sein, dass irgendwas überläuft und ausgerechnet Merlin 
Codes geschickt werden. Die Codes sehen auch ziemlich seltsam aus.

von KLez (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank M,

Vielen Dank für Deine Ausführung! Ich werde mal damit ein wenig 
experimentieren. Trotzdem noch eine Frage: Wäre es nicht einfacher einen 
seperaten Eingang dafür zu nehmen und das Signal direkt auf den 
Interrupt des AVR zu legen? Dann müsste dieser doch nur noch die Flanken 
zählen und das Ergebnis an irmp übergeben.

von Fred (Gast)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

ich hatte mal wieder Zeit etwas zu basteln. Dazu hab ich natürlich die 
aktuelle Version vom svn gezogen und mal mit allen FB durchprobiert.
Funktioniert fast perfekt, nur mit dieser Sagem FB für die d-box klappt 
es nicht so richtig. Es wird als Merlin erkannt und zeigt aber 
verschiedene Adressen und Codes an. Scheint nicht ganz das gleiche zu 
sein.

Da ich das Ganze mal sauber aufgebaut haben wollte und nicht nur auf dem 
Experimentierboard, hsb ich die Pollin RS232-Bas Platine verwendet.
Mit minimalen Änderungen kann man die dazu verwenden und muß sich keine 
eigen Platine ätzen.

Angefügt hab ich mal meine main.c die momentan nur zum Testen der FB 
dient.

Wenn ich mal wieder dazukommen werden ich noch eine Anpassung der FDC 
Tastatur schreiben, damit sie an einen PC angebunden werden kann.

Fred

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

um IRMP mit dem aktuellen GCC 4.6.1 zu übersetzen sind alle PROGMEM
Variablen als const zu markieren, was auch nur logisch ist. Könntest Du 
den SVN Quellcode diesbezüglich bitte aktualisieren.

Danke.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> um IRMP mit dem aktuellen GCC 4.6.1 zu übersetzen sind alle PROGMEM
> Variablen als const zu markieren, was auch nur logisch ist. Könntest Du
> den SVN Quellcode diesbezüglich bitte aktualisieren.

Ist erledigt.

Gruß,

Frank

von Daniel S. (daniel_s38)


Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Nachdem ich die Frage hier

Beitrag "USB IR Remote Receiver (V-USB + IRMP)"

schonmal gestellt habe und dabei auf dieses Forum verwiesen wurde 
versuch ichs nun hier:

Ich habe diesen Empfänger:

http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver

laut Anleitung aufgebaut, funktioniert tadellos.
Allerdings habe ich ein kleines Problem:

Die (Noname) Fernbedienung, welche ich mit dem Empfänger verwenden
möchte, hat einige Tasten, die nicht erkannt werden ("8", "Mute" und
einige weitere).
Diese Tasten funktionieren jedoch über den IgorPlug problemlos.
Alle anderen werden einwandfrei erkannt.

Hat jemand eine Idee, woran das liegen könnte?
Der einzige Unterschied in meinem Aufbau ist, daß ich einen TSOP 1136
verwende.....kann es daran liegen?

Muß dazu sagen daß ich ein absoluter Laie bin was das Thema 
programmieren o.ä. angeht....

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Daniel S. schrieb:
> Nachdem ich die Frage hier
>
> Beitrag "USB IR Remote Receiver (V-USB + IRMP)"
>
> schonmal gestellt habe [...]

... habe ich dir dort geantwortet:

  Beitrag "Re: USB IR Remote Receiver (V-USB + IRMP)"

Die Antwort gilt natürlich hier auch :-)

Gruß,

Frank

von eku (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

würdest Du bitte den Mitschnitt im Anhang analysieren. Mir ist es nicht 
gelungen, die Fernbedienung eines SAT-Receivers von Medion mit 
irgendeinem Protokoll zu dekodieren. Manchmal sprang der RC5-Algorithmus 
an, lieferte aber unabhängig von der gedrückten Taste den selben Code.

Danke.

von Dirk W. (glotzi)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Zum Punkt 2: Muss ich zu Hause nachschauen, wie weit ich da bin, habe
> zwischwendurch viele andere interessante Sachen gemacht. ;-)
>
> Ich melde mich dazu nochmal.

Hmm, darf ich nach 4 Wochen mal vorsichtig fragen wie denn der Status zu 
meiner Anfrage bzgl. Merlin Tastatur ist?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo eku,

eku schrieb:

> würdest Du bitte den Mitschnitt im Anhang analysieren.

Habs mir gerade mal im Editor und mit "irmp -a" angeschaut. Das 
Protokoll ist einfach, aber ziemlich blöde für irmp.

Eigenschaften:

1. Bitserielles Protokoll mit Datenrate von 600Bd
2. 1 Startbit ohne Pause, 8 Datenbits, 1 Stopbit
3. Jeder Frame wird 2x gesendet.

Blöd für IRMP ist der Punkt 2: Ohne Pause nach dem Startbit kann das 
Protokoll nicht eindeutig erkannt werden, weil schon der erste Puls 
1-fache bis 9-fache Länge haben kann.

Ich kann das Protokoll zwar einbauen in IRMP, aber man müsste sämtliche 
anderen Protokolle deaktivieren, damit dieses eindeutig erkannt wird. 
Die Geschichte ist also für einen Multiprotoll-Decoder ziemlich 
unsinnig.

Einfacher wäre es, den TSOP direkt an den UART zu hängen und den UART 
auf 600 Bd einzustellen. Dann kann man die Bytes direkt mit jeder 
üblichen UART-Lib auslesen. Im IRMP wäre es sowieso nichts anderes als 
ein Software-Uart.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dirk W. schrieb:
> Hmm, darf ich nach 4 Wochen mal vorsichtig fragen wie denn der Status zu
> meiner Anfrage bzgl. Merlin Tastatur ist?

Sorry, Dirk. Ich hatte dazu wenig Lust in der letzten Zeit, muss ich 
zugeben. Ich versuche, mich in der kommenden Woche mal dazu aufzuraffen.

Gruß,

Frank

von Dirk W. (glotzi)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Sorry, Dirk. Ich hatte dazu wenig Lust in der letzten Zeit, muss ich
> zugeben.
Dafür habe ich vollstes Verständnis, daher frage ich auch jetzt erst 
nach, ist ja alles deine Freizeit.

> Ich versuche, mich in der kommenden Woche mal dazu aufzuraffen.
Wäre schön. Wie gesagt, mir geht es nur darum: funzt die Merlin mit dem 
Head-Stand oder nicht. Also ein reiner Funktionstest.

von narkus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Toll das!! :))
Großes Lob, Frank!

Ich habe das in einen AT90USB "eingebaut", der zugleich sich als HID 
Keyboard ausgibt. So kann ich die empfangenen RC5-Signale als 
Tastendruck ans Media Center übergeben! :)

Als HID USB nutze ich LUFA. Bei mir funktioniert alles soweit. Mein Code 
für die FB-Auswertung sieht im Groben wie folgt aus:
if (irmp_get_data (&irmp_data))
{    
  if (irmp_data.address == 19)
  {      
    if (!(irmp_data.flags & IRMP_FLAG_REPETITION))
    {  switch(irmp_data.command)
      {  case ir_hoch:  Taste = t_hoch;    break;
        case ir_runter:  Taste = t_runter;  break;
        case ir_links:  Taste = t_links;  break;
        case ir_rechts:  Taste = t_rechts;  break;
        case ir_enter:  Taste = t_enter;  break;
        default:  break;
      }
    }
  }
}
else
{  
  Taste = 0;
}


Wenn ich nun die Abfrage nach dem IRMP_FLAG_REPETITION weglasse, 
reagiert alles rattenschnell. Allerdings läuft LUFA öfter durch als IRMP 
mir Werte liefern kann. Was zur Folge hat, dass meine Variable "Taste" 
zwischendurch Null gesetzt wird, obwohl ich die FB-Taste gedrückt halte, 
und LUFA das als schnelle hintereinanderfolgende Tastendrücke 
interpretiert. Sprich, ich drücke nur kurz für ein Zeichen, aber bekomme 
mein Zeichen auf dem Bildschirm mehrmals ausgegeben.

Dafür ist ja IRMP_FLAG_REPETITION da (siehe Codeschnipsel). Allerdings 
habe ich so umgekehrt das Problem, wenn ich gerade mal eine Taste 
mehrmals schnell hintereinander drücken will (für track skippen oder 
Ähnliches), scheinen Telegramme verloren zu gehen, nicht jeder 
Tastendruck wird erkannt. Woran kann das liegen?

Ich habe versucht, das mit einem Zähler aufzufangen, der abschätzt, ob 
das nächste Telegramm länger als 117ms gebraucht hat, was ich dann als 
neuen Tastendruck interpretiere. Erst nach Ablauf des Zählers setze ich 
meine Variable "Taste" zu Null. Das hat aber zur Folge, dass LUFA nach 
losgelassener Taste merklich länger das Zeichen ausgibt, bevor es die 
Ausgabe stoppt. Das spricht einerseits dafür, dass mein Zähler deutlich 
länger als 117ms braucht - sonst würde ich es nicht merken können -, 
aber wenn ich den Zählerwert nur leicht heruntersetze, habe ich das 
Problem mit ohne IRMP_FLAG_REPETITION-Abfrage wieder. (?)

Ich denke idealer Weise an folgende Lösung: Kannst Du denn deinem 
Programm nicht ähnlich der Pollin IR-Tastatur beibringen, nach 
losgelassener Taste dem Kommando das 8. Bit hinzuzufügen (oder 
beliebiger fester Wert >0x80, mich interessiert nicht unbedingt welche 
Taste losgelassen wurde, sondern dass eine losgelassen wurde)? Das 
wäre nämlich schneller und sicherer als mein Zähler! Ich hatte versucht, 
selber Hand anzulegen, aber ich habe Deinen Code leider doch nicht voll 
und ganz verstanden.

Danke und Gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
narkus schrieb:
> Toll das!! :))
> Großes Lob, Frank!

Danke :-)

>   if (irmp_data.address == 19)

Besser:

>   if (irmp.protocol == IRMP_RC5_PROTOCOL && irmp_data.address == 19)

So kann Dir keine andere FB, die auch die Adresse 19 (aber ein anderes 
Protokoll) hat, dazwischenfunken.

> Dafür ist ja IRMP_FLAG_REPETITION da (siehe Codeschnipsel). Allerdings
> habe ich so umgekehrt das Problem, wenn ich gerade mal eine Taste
> mehrmals schnell hintereinander drücken will (für track skippen oder
> Ähnliches), scheinen Telegramme verloren zu gehen, nicht jeder
> Tastendruck wird erkannt. Woran kann das liegen?

IRMP unterscheidet über die Konstante

  IRMP_KEY_REPETITION_LEN

in irmp.c, ob es sich um eine schnell gedrückte Wiederholungstaste 
handelt oder ob die FB selbst "repetiert" - durch langen Tastendruck. 
Offenbar schaffst Du es, innerhalb von 150msec die Taste mehr als einmal 
zu drücken... Du bist da ganz schön schnell :-)

Verkleinere den Wert einfach mal - z.B. von 150.0 auf 120.0 oder 100.0.

> Ich denke idealer Weise an folgende Lösung: Kannst Du denn deinem
> Programm nicht ähnlich der Pollin IR-Tastatur beibringen, nach
> losgelassener Taste dem Kommando das 8. Bit hinzuzufügen (oder
> beliebiger fester Wert >0x80, mich interessiert nicht unbedingt *welche*
> Taste losgelassen wurde, sondern dass eine losgelassen wurde)?

Das würde ich ungern machen wollen. Es gibt nämlich durchaus FBs, die 
16-Bit-Kommandos rausschicken, da bräuchte ich dann ein 17. Bit.

Was ich besser fände: Bei RC5 und RC6 gibt es das sog. Toggle-Bit im 
IR-Frame. Dieses könnte ich im IRMP auswerten, ob eine Taste lang 
gedrückt wurde oder ob der Anwender diese kurz gedrückt hatte und 
entsprechend das Repetition-Flag setzen. Ändert sich das Toggle-Bit 
nicht und bleibt der Code derselbe, würde ich dann das Repetition-Flag 
setzen - unabhängig von IRMP_KEY_REPETITION_LEN (was ich für die anderen 
Protokolle aber weiterhin benötige!). Im Moment ignoriert IRMP das 
Toggle-Bit.

Ich schaue mal, dass ich das am Wochenende so einbaue. Du könntest 
parallel dazu aber mal den Wert der Konstanten IRMP_KEY_REPETITION_LEN 
testweise herabsetzen und hier berichten.

Gruß,

Frank

P.S.
Hast Du ein Schaltbild zu Deiner Lösung? Ich habe mit den 
AT90USB-Dingern noch nie was gemacht. Vielleicht wäre das ja eine 
Erwähnung im IRMP-Artikel wert....

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Was ich besser fände: Bei RC5 und RC6 gibt es das sog. Toggle-Bit im
> IR-Frame. Dieses könnte ich im IRMP auswerten, ob eine Taste lang
> gedrückt wurde oder ob der Anwender diese kurz gedrückt hatte und
> entsprechend das Repetition-Flag setzen. Ändert sich das Toggle-Bit
> nicht und bleibt der Code derselbe, würde ich dann das Repetition-Flag
> setzen - unabhängig von IRMP_KEY_REPETITION_LEN (was ich für die anderen
> Protokolle aber weiterhin benötige!). Im Moment ignoriert IRMP das
> Toggle-Bit.

das sieht nach meinem "alten" Problem aus, hatte ich ja auch schon mal 
gewünscht, evt. kommts doch noch in IRMP, dann kann ich endlich die RC5 
ISR rauswerfen :-)

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
jar schrieb:

> das sieht nach meinem "alten" Problem aus,

Nicht ganz: Du hast dir immer gewünscht, dass Dir IRMP das Toggle-Bit 
liefert, damit Du den Code nicht umschreiben musst. ;-)

Sorry, das werde ich nicht machen. Ich brauche eine Lösung für alle 
von IRMP unterstützten Protokolle. Ich kann für RC5/RC6 das Toggle-Bit 
auswerten, um das Repetition-Flag korrekt zu setzen... aber mehr nicht.

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich kann für RC5/RC6 das Toggle-Bit
> auswerten, um das Repetition-Flag korrekt zu setzen... aber mehr nicht.

das würde ja reichen :-)

aber wie der letzte User das beschreibt erinnert mich genau ! an mein 
Problem mit der Auswertung, hab ich ja deutlich genug beschrieben, wir 
dokterten ja auch gemeinsam mit allen möglichen Ideen rum, nur nix half

es ist doch so das entweder noch Repeatcodes im Buffer liegen und 
nachgeliefert werden auch wenn die eigendliche Aktion schon gelaufen ist 
oder wie auch immer, mit 1x drücken bekomme ich entweder kein Licht an 
oder gleich wieder aus weil mir das toogle Bit fehlt, nur deswegen 
bedine ich meinen Timer ja mit RC5 und werte die Bedienung mit RC5 aus, 
an dieser Stelle ist IRMP nur gut um Codes zu liefern (hört sich jetzt 
härter an als es gemeint ist !

ne wirklich, finde IRMP gut nutze es auch gerne, nur du wolltest vor 
Monaten mal meine Code durchgucken warum ich mit IRMP nicht bedienen 
kann, der mit RC5 prima läuft.....

von master control (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Eine Frage: welche Pegel gibt IRSND auf der Konsole aus? Ist es 
invertiert?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
master control schrieb:
> Eine Frage: welche Pegel gibt IRSND auf der Konsole aus? Ist es
> invertiert?

Da das Signal mit 32, 36, 38 oder 40kHz moduliert ist, ist der Pegel 
vollkommen unerheblich ;-)

Wenn Du Dir den Minischaltplan unter

  http://www.mikrocontroller.net/articles/IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder

ansiehst, erkennst Du, dass die Pausen Low-Pegel haben.

Gruß,

Frank

von narkus (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>Besser:
>
>>   if (irmp.protocol == IRMP_RC5_PROTOCOL && irmp_data.address == 19)

Stimmt!! :))

Ich bin tatsächlich ein schneller Drücker! Ich habe 
IRMP_KEY_REPETITION_LEN auf 100.0 gesetzt, und habe mit schnellen 
Tastendrücken kaum noch ein Problem. Interessanter Weise wird das 
IRMP_FLAG_REPETITION noch richtig gesetzt, obwohl dieser Werte unterhalb 
der 117,zerquetschte ms liegt. Vielleicht hält aber auch mein Sender den 
RC5 nicht zu 100% ein, müsste ich mal mitm Oszi kontrollieren. Ich nehme 
das jetzt mal so hin.

Toggle Bit ist zwar nett, aber einerseits brauche ich es nicht, wenn das 
repetition flag funktioniert. Andererseits hilft es mir nicht bei der 
Aussage, wie lange eine Taste gedrückt gehalten wurde repektive wann sie 
losgelassen wurde.

Das Problem liegt darin, dass die Funktion irmp_get_data() Nullwerte 
ausgibt, owohl sie eigentlich gerade dabei ist, einen möglichen langen 
Tastendruck auszuwerten. Wenn ich jedoch Null erhalte, setze ich auch 
meine Variable "Taste" auf Null. Mein Programm kann somit nicht ohne 
selbst mitlaufendem Timer erkennen, ob eine Taste nicht mehr gedrückt 
wird. Und dieser Timer erzeugt ei mir die eingangs schon erwähnte 
merkliche Latenz beim Loslassen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
narkus schrieb:
> Ich bin tatsächlich ein schneller Drücker! Ich habe
> IRMP_KEY_REPETITION_LEN auf 100.0 gesetzt, und habe mit schnellen
> Tastendrücken kaum noch ein Problem.

Ich habe nun ins SVN eine neuere Version von IRMP eingecheckt, die das 
RC5-Toggle-Bit als zusätzliches Kriterium heranzieht, ob eine Taste lang 
oder kurz gedrückt wurde.

Bitte teste das nochmal mit dem alten Wert von IRMP_KEY_REPETITION_LEN = 
150. Es sollte nun für RC5 auch mit dem 150er Wert zuverlässig 
funktionieren. Die 150msec brauche ich nämlich für diverse andere 
Protokolle, ich kann es also nicht pauschal auf 100 setzen.

> Interessanter Weise wird das
> IRMP_FLAG_REPETITION noch richtig gesetzt, obwohl dieser Werte unterhalb
> der 117,zerquetschte ms liegt.

Die 150msec beschreiben den Abstand zwischen 2 Frames - exkl. dem 1. 
Frame. Bei der RC5-Repetition-Time von ca. 115msec, die man in diversen 
Quellen findet, ist mir nicht ganz klar, ob der 1. Frame mitgestoppt 
wird, z.B. hier:

   http://users.telenet.be/davshomepage/rc5.htm

> Vielleicht hält aber auch mein Sender den RC5 nicht zu 100% ein,
> müsste ich mal mitm Oszi kontrollieren.

Könnte auch sein. Wäre prima, wenn Du das mal nachmessen würdest.

> Toggle Bit ist zwar nett, aber einerseits brauche ich es nicht, wenn das
> repetition flag funktioniert.

Das Toggle-Bit bekommst Du auch nicht zu sehen. IRMP zieht es nun aber 
als zusätzliches Kriterium hinzu, um zu entscheiden, ob eine Taste lang 
oder mehrfach kurz gedrückt wurde.

> Das Problem liegt darin, dass die Funktion irmp_get_data() Nullwerte
> ausgibt, owohl sie eigentlich gerade dabei ist, einen möglichen langen
> Tastendruck auszuwerten.

Was sollte sie dann machen? Hängen und warten, bis der Frame komplett 
angekommen ist?

Ich könnte eine Funktion

     irmp_busy ()

bereitstellen, die TRUE zurückliefert, wenn gerade ein neuer Frame 
eingelesen wird.

Ein irmp_get_data(), welches blockiert, bis der Frame komplett ist, 
halte ich für nicht notwendig. Dies kann man einfach mit:
   while (! irmp_get_data (..))
   {
       ;  // wait, do nothing
   }
   ....   // action!

erledigen.

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich könnte eine Funktion
>
>      irmp_busy ()
>
> bereitstellen, die TRUE zurückliefert, wenn gerade ein neuer Frame
> eingelesen wird.

wäre auch toll

oder gibt es eine Möglichkeit den Buffer zu leeren wenn eine Taste 
erkannt wurde ? damit wenn ich die Taste auswerte und interagiere nicht 
ein neuer Tastendruck im Buffer lauert ?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
jar schrieb:
> oder gibt es eine Möglichkeit den Buffer zu leeren wenn eine Taste
> erkannt wurde ? damit wenn ich die Taste auswerte und interagiere nicht
> ein neuer Tastendruck im Buffer lauert ?

Könnte man natürlich auch einbauen. Die meisten Frames dauern ca. 30 - 
40 msec. Das ist doch eine halbe Ewigkeit, ich frage mich da, was Du da 
alles in der Zwischenzeit machen willst? ;-)

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Das ist doch eine halbe Ewigkeit, ich frage mich da, was Du da
> alles in der Zwischenzeit machen willst? ;-)

nun ja ich will nur das mein Programm funktioniert, mit jeder FB nicht 
nur mit RC5

eigendlich ganz einfach, man drückt doch solange die Taste bis das 
gewünschte eintritt, z.B. Licht an dann lässt man los, will aber nicht 
das dann das Licht wieder ausgeht weil noch was nachkommt, kürzer 
drücken geht nur wenn man weiss das der Code ankommt, aber die 
Rückmeldung ist doch Licht an, ich hoffe du verstehst warum das toogle 
Bit recht nützlich ist im RC5, das macht es einem leichter, alternativ, 
nach Erkennung Buffer leeren bis zur nächsten Abfrage.....

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
jar schrieb:
> eigendlich ganz einfach, man drückt doch solange die Taste bis das
> gewünschte eintritt, z.B. Licht an dann lässt man los, will aber nicht
> das dann das Licht wieder ausgeht weil noch was nachkommt,

Das ist doch einfach: Du ignorierst einfach alle Frames mit gesetztem 
Repetition-Flag - fertig.

> ich hoffe du verstehst warum das toogle
> Bit recht nützlich ist im RC5, das macht es einem leichter, alternativ,
> nach Erkennung Buffer leeren bis zur nächsten Abfrage.....

Naja, um das Toggle-Bit auszuwerten, brauchst Du immer den letzten und 
den aktuellen Zustand des Toggle-Bits, um diese dann beide zu 
vergleichen. Mit dem Repetition-Flag von IRMP ist es noch einfacher: 
Wenn gesetzt, handelt es sich um einen langen Tastendruck -> wegwerfen, 
fertig. Dass IRMP intern(!) genau das Toggle-Bit (bei RC5) dafür 
auswertet, um das Repetition-Flag zu setzen, muss Dich als IRMP-Anwender 
nicht kümmern.

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Das ist doch einfach: Du ignorierst einfach alle Frames mit gesetztem
> Repetition-Flag - fertig.

sagst du, aber das hatten wir doch alles schon durch und es lief nicht 
(wie gewünscht)

ich weiss ehrlich nicht warum du das immer wieder widerholst, entweder

IRMP liefert das richtige Tooglebit was im RC5 ja vorhanden ist 
transparent durch oder man muss dafür eben wie ich es nun mache in der 
ISR RC5 und IRMP laufen lassen......

klar verstehe ich deinen Wunsch IRMP für alle gleich zu behandeln, aber 
nur deswegen ein geliefertes Toogle Bit  zu repaet frames zu übersetzen 
und das toogle Bit zu unterschlagen kann auch nicht so richtig sein, du 
hast da einen ganz schönen Dickkopf

ich möchte doch nix exotisches, im RC5 steckt das toogle Bit, reiche es 
doch einfach durch und/oder gib uns ne leere_buffer Routine die auf 
Wunsch alles cleart

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
jar schrieb:

> sagst du, aber das hatten wir doch alles schon durch und es lief nicht
> (wie gewünscht)

Das läuft bei Dir nur deshalb nicht, weil Du Deinen Source nicht 
umschreibst und stattdessen versuchst, aus den IRMP-Daten (die nicht 
mehr protokollspezifisch sind) wieder RC5-Daten zu konstruieren - und 
das auch noch unzureichend.

> ich weiss ehrlich nicht warum du das immer wieder widerholst, [...]

Ich wiederhole mich immer wieder, weil Du Dich immer wiederholst. IRMP 
arbeitet korrekt, Du wendest aber IRMP nicht korrekt an! Solange Du 
immer wieder und wieder auf dem Toggle-Bit rumreitest, werde ich wieder 
und wieder das Repetition-Flag hervorkramen - ganz einfach :-)

Denk einfach daran: die Mehrheit aller anderen IR-Protokolle hat 
überhaupt kein Toggle-Bit. Und trotzdem funktioniert es.

> klar verstehe ich deinen Wunsch IRMP für alle gleich zu behandeln, aber
> nur deswegen ein geliefertes Toogle Bit  zu repaet frames zu übersetzen
> und das toogle Bit zu unterschlagen kann auch nicht so richtig sein, du
> hast da einen ganz schönen Dickkopf

Das Toggle-Bit gehört nicht in die IRMP-Daten. Soll ich mir das dann für 
die anderen 30 IR-Protokolle aus den Rippen schneiden?!?

Du hast den Dickkopf: Du reitest auf dem Toggle-Bit herum, weil Du zu 
faul bist, Deinen Code, der RC5-Spezifika nutzt, portabel umzuschreiben. 
Was willst Du denn in 5 Jahren machen, wenn es keine RC5-FB mehr gibt?

> ich möchte doch nix exotisches, im RC5 steckt das toogle Bit, reiche es
> doch einfach durch [...]

Nein, wenn ich es durchreiche, würde ja jeder zweite identische 
Tastendruck unterschiedliche IRMP-Daten liefern.

> und/oder gib uns ne leere_buffer Routine die auf Wunsch alles cleart

Hier hast Du sie:
void
irmp_clear (void)
{
   IRMP_DATA dummy;

   while (irmp_get_data (&dummy))
   {
        ;
   }
}

War das jetzt so schwierig?

Gruß,

Frank

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Hier hast Du sie:
> void
> irmp_clear (void)

> War das jetzt so schwierig?
> Frank

danke probiere ich ;-)

von PimmingerA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
abc

von PimmingerA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sieht wer eine Möglichkeit genau die Funktion des Senders & Empfängers 
auf einen PC zu Implementieren und die Bitmuster über USB-IR 
Sender/Empfänger zu senden/empfangen
Würde gerne verschiedene Fernseher über einen zentralen Server steuern 
und hierzu einen USB-IR Sender verwenden welche ich direkt bei der 
IR-Empfangsfenster beim Fernseher anbringe.

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
PimmingerA schrieb:
> Sieht wer eine Möglichkeit genau die Funktion des Senders & Empfängers
> auf einen PC zu Implementieren und die Bitmuster über USB-IR

will ich auch hier gibt es irgenwo einen Thread IRMP mit USB

wenn ich mich richtig erinnere so als USB RS232 Umsetzer

Atmel mit USB Clientfunktion zu RS232 Umsetzer gibts ja schon, die 
Treiber für win gibts auch, braucht man nur RS232 Codes an die virtuelle 
COM zu schicken, bzw gleich IRMP im Atmel zu integrieren und zu senden

vom PC schickt man nur das Byte Protkoll, Adress, Command

nur mir fehlte bis jetzt noch die Zeit mich da einzulesen unbd das zu 
bauen

evt. schaust du mal und meldest rück ?

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ist leider nur Receiver ?

wir brauchen ja IRSND

IRMP + IRSND in einem Atmel zu bringen geht ja
USB zu RS232 Umsetzer auch
beides zusammen sollte auch gehen, vom PC angesprochen als virtuelle COM 
nur das wir im Atmel nix mehr an die serrielle Schnitte RX + TX ausgeben 
und empfangen, stattdessen IRMP und IRSND nutzen

Idee im Kopf fertig, nur noch nicht in echt

ggffs könnte man Fertigmodule umbauen RS232 Pegelwandler auslöten, IR 
Sende Diode und TSOP einbauen, müsste halt nur Atmel basierend sein und 
genügend Codeplatz und ISP Schnitte haben

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Robert (mein Sohn) und ich hatten mal für die DIY-Fernbedienung 
(basierend auf IRMP/IRSND)

  http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP

testweise ein Kommando-Interface geschrieben, was über die UART lief - 
aber nicht veröffentlicht.

Das Schaltbild könnte man dann vereinfachen auf:

1. TSOP an ATMEGA zum Empfang der Codes über IRMP
2. Transistor + IR-Sendediode an ATmega für IRSND

Eine kleine EXE, die dann das Protokoll, Adresse und Kommando über UART 
an den ATmega schickte, hatten wir damals auch schon programmiert.

Wir hatten das nur noch nicht veröffentlicht, weil wir eigentlich für 
den PC noch eine GUI schreiben wollten, damit man sich selbst eine 
persönliche Fernbedienung unter Windows "zusammenklicken" kann. Dazu war 
aber noch keine Zeit bisher.

Ich kann das heute abend mal raussuchen und hier einstellen. Die 
aktuelle EXE will einfach Protokoll-Nummer, Adresse, Kommando und 
Wiederholungsfaktor als Argument.

Gruß,

Frank

von PimmingerA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn ich Euch richtig verstanden habe, dann wollt ihr über die 
USB-Schnittstelle des PCs nur die Daten runterschicken auf einen MC und 
dort dann das Timing im MC erzeugen und über einen Pin auf die 
IR-Endstufe ausgeben?

Ich wollte mir die Elektronik ersparen und einen USB-IR-Converter den es 
um 10-20 Euro gibt an den PC anschließen und das Timing im PC-Programm 
machen und runterschicken - funktioniert dies auch oder hat da wer eine 
Ahnung?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
PimmingerA schrieb:
> Wenn ich Euch richtig verstanden habe, dann wollt ihr über die
> USB-Schnittstelle des PCs nur die Daten runterschicken auf einen MC und
> dort dann das Timing im MC erzeugen und über einen Pin auf die
> IR-Endstufe ausgeben?

Jepp.

> Ich wollte mir die Elektronik ersparen und einen USB-IR-Converter den es
> um 10-20 Euro gibt an den PC anschließen und das Timing im PC-Programm
> machen und runterschicken - funktioniert dies auch oder hat da wer eine
> Ahnung?

Hast Du mal einen Link oder Schaltplan von diesem "USB-IR-Converter", 
dass man das mal nachlesen kann? Kann funktionieren, kann auch nicht. Ob 
Du unter Windows hinreichend genaue Timings hinbekommst, kann ich nicht 
sagen.

Für die PC -> µC Lösung braucht man:

1. ATmega88 oder ATmega168
2. Transistor + IR-Diode
3. TSOP
4. Ein paar Kondensatoren + Widerstände

Alles in allem macht das ungefähr einen Preis von ca. 5 Euro - ohne das 
Stückchen Lochrasterplatine ;-)

Achja, man braucht noch einen USB->UART-Wandler, z.B. diesen hier:

  http://shop.myavr.de/Bauelemente%20und%20Controller/myUSBtoUART.htm?sp=article.sp.php&artID=200024

von PimmingerA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich wollte einen Standsender oder Empfänger von HAMA hernehmen ... da 
gibt es vom Hersteller natürlich keine Schaltpläne ;O)
Aber ich werde es nun eh über ein kleines MC-Interface lösen, da mein 
Gefühl mir sagt, dass ich da das Timing besser im Griff habe.
Ich werde einen ATMEGA8 PDIP verwenden - hier ist die USB-Schnittstelle 
mit ein paar BauteilenWorkAround schon dabei - dann brauche ich den 
USB/UART Umsetzer nicht oder?
Dann werde ich 2 Pins brauchen für Sender und Empfänger - so wie von Dir 
beschrieben.
Den Source Deines Exe-files wäre toll - bzw. die Tabellen der ganzen 
Codec-Daten ;O)

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
IRMP braucht für alle Protokolle ca 4k IRSND dito wenn ich das richtig 
überschlagen habe

auf Platine bauen hab ich keinen Lust, deswegen denke ich an Pollin 
RS232 BAS Wandler 10 €

anstelle der RS232 Buchse und Wandlerchip USB mit Schutzdioden und R

anstelle das BAS Ausgang TSOP Trasi und IR Sendediode

nur wird das Modul nur mit mega8 geliefert, kein Platz mehr für den 
V-USB, evt. Chip größer wählen, oder AVR Net I/O 20 € dann könnte man 
die Codes auch über Router schicken ohne PC oder eben USB Stecker und 
Beschaltung nachfrickeln, da ist ein mega32 drauf Platz genug

was benötigt v-usb an SW Platz ?

von narkus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hey Frank!

So, war länger nicht dabei. Also, ich habe jetzt den aktuellen Code 
getestet und das mitm RC5 läuft jetzt mitm 150er Wert so wie es soll! 
Super!! :)

So ein busy wäre sehr sinnvoll. Sonst kann ich keinen lang anhaltenden 
Tastendruck erkennen, ohne dass ich parallel einen Timer des letzten 
erkannten Empfangs mitlaufen lasse. Gerne auch als Flag.

Solange IRMP was tut, sollte irmp_get_data() weiterhin TRUE zurückgeben, 
so kann ich dann gesichert meine variablen zurücksetzen, wenn 
tatsächlich kein Empfang mehr stattfindet, sprich keine Taste egal ob 
kurz oder lang gedrückt wurde. Mein Code könnte dann so aussehen:
  if (irmp_get_data (&irmp_data))
  {    
    if (!irmp_data.busy && (irmp_data.protocol == IRMP_RC5_PROTOCOL) && (irmp_data.address == 19))      // << Hier mitprüfen, ob busy
    {  if (!(irmp_data.flags & IRMP_FLAG_REPETITION))
      {  rc5_pressed = 1;
        rc5_do = 1;
      }
      else
      {  if (rc5_pressed < 5000) rc5_pressed++;       // Wiederholverzögerung
        else rc5_do = 1;
      }
      
      irmp_data.flags = 0;                    // reset flags!
    }
  }
  else
  {  rc5_pressed = 0;
    Taste = 0;
  }
  

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich habe nun ins SVN eine neuere Version von IRMP eingecheckt

ich hab auch mal wieder geschaut, komme am IRMP grad nicht weiter, macht 
aber nix

doofe Frage,
wäre es nicht möglich den proto_str in die IRMP.C einzubinden, dann muss 
man im quelltext nie ändern

eine weitere Funktion im IRMP.C
char *get_irmp_prot_str(protokoll)

könnte das dann immer liefern

warum diese Version ? c erlaubt doch
sei();

???

#asm("sei");

was bringt der ASM als Vorteil ?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
jar schrieb:

> wäre es nicht möglich den proto_str in die IRMP.C einzubinden, dann muss
> man im quelltext nie ändern

Nein, ganz im Gegenteil: Da er nur im Codevision-Teil des 
IRMP-Demo(!)programms main.c steht, fliegt er demnächst komplett raus. 
Der Protokoll-Name als String ist nicht Bestandteil der IRMP-LIB.

Vergleiche macht man mittels:
  if (irmp_data.protocol == IRMP_NEC_PROTOCOL)
  {
     ...
  }

und nicht mittels strcmp() auf einen Protokollnamen! Aber das habe ich 
Dir vor Monaten schon mal gesteckt ;-)

Frage: Benutzt Du den Codevision-Compiler?

> eine weitere Funktion im IRMP.C
> char *get_irmp_prot_str(protokoll)

Nein, kostet nur jede Menge Flash, die unsinnig verbraten werden. Die 
Protokoll-Strings sind nur sinnvoll für die Ausgabe auf einem LCD. Da 
aber die LCD-Routinen auch nicht Bestandteil der IRMP-Lib sind, sehe ich 
auch nicht ein, die Strings zum Bestandteil der Lib zu machen.

> warum diese Version ? c erlaubt doch
> sei();

Ja, klar, wird auch so genutzt, siehe AVR-GCC-Teil von main.c.

> #asm("sei");

Du bist im Codevision-Teil von main.c. Der stammt nicht von mir, sondern 
von Klaus Leidinger, der damals mal das main.c auf Codevision-C portiert 
hat. Offenbar kennt der Codevision-Compiler kein sei().

> was bringt der ASM als Vorteil ?

Dass er auch für Codevision funktioniert.

Aber warum machst Du da dauernd im Codevision-Teil rum? Die 
Codevision-Unterstützung werfe ich sowieso demnächst raus, da ich keinen 
Codevision-Compiler habe.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
narkus schrieb:

> So, war länger nicht dabei. Also, ich habe jetzt den aktuellen Code
> getestet und das mitm RC5 läuft jetzt mitm 150er Wert so wie es soll!
> Super!! :)

Freut mich.

> So ein busy wäre sehr sinnvoll. Sonst kann ich keinen lang anhaltenden
> Tastendruck erkennen, ohne dass ich parallel einen Timer des letzten
> erkannten Empfangs mitlaufen lasse. Gerne auch als Flag.

Was soll IRMP zwischen 2 Frames zurückliefern? Jede FB macht auch bei 
lang anhaltender Taste Pausen zwischen den Frames.

Stell Dir folgende Situation vor:

A1. FB sendet ersten Frame
A2. IRMP liest ersten Frame ein
A3. Applikation holt ersten Frame ab
A4. FB macht eine Pause von ca. 40 msec
A5. FB sendet zweiten Frame
A6. IRMP liest ersten Frame ein
A7. Applikation holt zweiten Frame ab, Repetition-Flag ist gesetzt.

Wenn ich nun ein busy-Flag einbaue, passiert folgendes:

B1. FB sendet ersten Frame
B2. IRMP setzt Busy-Flag
B3. IRMP liest ersten Frame ein
B4. IRMP setzt Busy-Flag zurück
B5. Applikation holt ersten Frame ab
B6. FB macht eine Pause von ca. 40 msec
B7. FB sendet zweiten Frame
B8. IRMP setzt Busy-Flag
B9. IRMP liest ersten Frame ein
B10. IRMP setzt Busy-Flag zurück
B11. Applikation holt zweiten Frame ab, Repetition-Flag ist gesetzt.

Problem ist die Zeit zwischen B5 und B7, da ist das Busy-Flag nicht 
gesetzt! Hilft Dir das weiter?

> Solange IRMP was tut, sollte irmp_get_data() weiterhin TRUE zurückgeben,

Sorry, das geht nicht, denn damit würde irmp_get_data() 
aufruf-inkompatibel zu bisherigen Versionen werden. Bisherige Programme, 
die IRMP verwenden, müssten alle in ihrer Logik umgeschrieben werden.

Ich kann Dir höchstens eine Funktion irmp_is_busy() anbieten, die TRUE 
oder FALSE zurückliefert. Aber erst müssten wir klären, in welchem State 
diese Funktion was zurückliefert.

Gruß,

Frank

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> und nicht mittels strcmp() auf einen Protokollnamen! Aber das habe ich
> Dir vor Monaten schon mal gesteckt ;-)

das mache ich doch nicht (mehr) aber als IR Tester gebe ich natürlich 
den Protokollnamen aufs LCDaus !

> Frage: Benutzt Du den Codevision-Compiler?
nö !

>> eine weitere Funktion im IRMP.C
>> char *get_irmp_prot_str(protokoll)
> Nein, kostet nur jede Menge Flash, die unsinnig verbraten werden.

OK muss ! ich akzeptieren

> Protokoll-Strings sind nur sinnvoll für die Ausgabe auf einem LCD. Da
> aber die LCD-Routinen auch nicht Bestandteil der IRMP-Lib sind, sehe ich
> auch nicht ein, die Strings zum Bestandteil der Lib zu machen.

na ja, kann man auch anders sehen, als IR Tester ist für mich der 
Protokollname Bestandteil der IRMP, könnte man mit #if define LCD_H 
einbinden

> Du bist im Codevision-Teil von main.c. Der stammt nicht von mir, sondern
> von Klaus Leidinger, der damals mal das main.c auf Codevision-C portiert

da bin ich grad wieder irrtümlich reingerutscht zwischen 2 Tätigkeiten, 
ich finde es gut wenn die coderversion endlich rausfliegt, dann 
entfallen derlei Irrtümer

danke jar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Neue Version IRMP und IRSND im SVN:

1. Unterstützung von ATtiny85 (bisher nur ATmegas)
2. Codevision-Unterstützung gelöscht
3. Array von IRMP-Protokollnamen zur Verfügung gestellt
4. Kleinere Bugfixes

@jar:

Um auf die Protokollnamen zugreifen zu können, muss
/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * Set IRMP_PROTOCOL_NAMES to 1 if want to access protocol names (for logging etc), costs ~300 bytes RAM!
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
#define IRMP_PROTOCOL_NAMES                     0       // 1: access protocol names, 0: do not (default),

auf 1 gesetzt werden. Dies verbraucht im Moment noch ca. 300 Bytes RAM, 
da die Strings noch nicht als PROGMEM gespeichert werden.

Man kann dann mit irmp_protocol_names[irmp_data.protocol] auf den 
Protokollnamen zugreifen. Die Protokollnamen wurden so gekürzt, dass sie 
die Länge von 8 nicht überschreiten.

Gruß,

Frank

von Sebastian W. (dl3yc)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Neue Version IRMP und IRSND im SVN:
>
> 1. Unterstützung von ATtiny85 (bisher nur ATmegas)

Hallo Frank, hast du auch ein funktionierendes Projekt für einen 
ATtiny85?
Ich habe momentan mit dem aktuellen Projekt aus dem SVN und einen Tiny45 
nur den Pin von PB6 auf PB4 geändert und eine LED an PB0, die an gehen 
soll, wenn etwas erkannt wird. Am Oszi kann ich sehen, dass der TSOP 
funktioniert, aber die LED geht nie an :(
Fuses habe ich auf interne 8MHz (Divider/8 aus).

meine main:
int
main (void)
{
    IRMP_DATA irmp_data;

    irmp_init();                                                            // initialize irmp
    DDRB |= (1<<PB0);
  timer1_init();                                                          // initialize timer 1
    sei ();                                                                 // enable interrupts

    for (;;)
    {
        if (irmp_get_data (&irmp_data))
        {
      PORTB |= (1<<PB0);
            // ir signal decoded, do something here...
            // irmp_data.protocol is the protocol, see irmp.h
            // irmp_data.address is the address/manufacturer code of ir sender
            // irmp_data.command is the command code
            // irmp_protocol_names[irmp_data.protocol] is the protocol name (if enabled, see irmpconfig.h)
        }
    }
}

Hast du eine Idee an was es liegen kann? Habe alle Protokolle und mit 3 
verschd. FB ausprobiert.

Danke im Vorraus!

73 DL3YC

von Sebastian W. (dl3yc)


Bewertung
0 lesenswert
nicht lesenswert
Fehler gefunden: es fehlt die ISR in der main!

Einfach
ISR(TIMER1_COMPA_vect)
{
  irmp_ISR();
}
hinzufügen und es funktioniert :)

73 DL3YC

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Sebastian,

Sebastian Weiß schrieb:
> Fehler gefunden: es fehlt die ISR in der main!

Sorry, die ISR hatte ich beim Rauswerfen der Codevision-Unterstützung 
tatsächlich "wegoptimiert" - sprich versehentlich gelöscht. Ist nun 
wieder drin.

Trotzdem wundert es mich, dass es bei Dir nun auf dem ATtiny 
funktioniert, denn meines Erachtens war da noch ein 
Copy-and-Paste-Fehler meinerseits beim Setzen von TCCR1. Man benötigt 
hier einen Prescaler von 4 und nicht von 2.

Kannst Du mal Deine timer1_init()-Funktion zeigen? Ich habe jetzt 
folgende im SVN eingecheckt:
void
timer1_init (void)
{
#if defined (__AVR_ATtiny85__)                                              // ATtiny85:
    OCR1A   =  (F_CPU / F_INTERRUPTS / 4) - 1;                              // compare value: 1/15000 of CPU frequency, presc = 4
    TCCR1   = (1 << CTC1) | (1 << CS11) | (1 << CS10);                      // switch CTC Mode on, set prescaler to 4
#else                                                                       // ATmegaXX:
    OCR1A   =  (F_CPU / F_INTERRUPTS) - 1;                                  // compare value: 1/15000 of CPU frequency
    TCCR1B  = (1 << WGM12) | (1 << CS10);                                   // switch CTC Mode on, set prescaler to 1
#endif

#ifdef TIMSK1
    TIMSK1  = 1 << OCIE1A;                                                  // OCIE1A: Interrupt by timer compare
#else
    TIMSK   = 1 << OCIE1A;                                                  // OCIE1A: Interrupt by timer compare
#endif
}

Wichtig sind hier die beiden Zeilen für den ATTiny85: Neben dem Bit CS11 
wird auch noch CS10 im TCCR1-Register gesetzt, um den Prescaler auf 4 zu 
bekommen. Eigentlich müsstest Du das auch so korrigiert haben, um das 
zum Laufen zu bekommen. Kannst Du das so bestätigen?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Neue Versionen von IRMP und IRSND im SVN:

IRMP:

1. Unterstützung für ATtiny84 (zusätzlich zu ATTiny85) hinzugefügt.
2. Fehlende ISR in main.c wieder eingefügt
3. Div. Fehler in timer1_init korrigiert (für ATmega & ATTtiny)

IRSND:

1. Unterstützung für ATTiny84 und ATTiny85 hinzugefügt
2. Unterstützung der IR-Protokolle NEC16 und NEC24

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dirk W. schrieb:
> Hmm, darf ich nach 4 Wochen mal vorsichtig fragen wie denn der Status zu
> meiner Anfrage bzgl. Merlin Tastatur ist?

Ich habe am Wochenende einige Tests mit der Merlin gemacht. Wie ich über 
IR_LOGGING per IRMP fesstellen konnte, gibt es einige Tasten, die exakt 
den gleichen IR-Frame senden. Das war bei mir zum Beispiel bei den 
Tasten "t" und "n" der Fall. Entweder habe ich da ein defektes Exemplar 
erwischt oder es handelt sich um einen Serienfehler. Letzteres würde 
erklären, warum Pollin diese Tastaturen zum Schleuderpreis anbietet.

Ich kann da also nichts weiter machen. Da das Merlin-Protokoll vom 
Startbit-Timing ähnlich zu anderen IR-Protokollen ist und daher immer 
mal bei der Erkennung "dazwischenfunkt", wenn es aktiviert ist, habe ich 
mich entschlossen, die Unterstützung für die Merlin-Tastatur komplett 
aus dem IRMP herauszuwerfen. Vom Timing her arbeitet die Tastatur auch 
nicht gerade sehr exakt, so dass ab und zu auch verschiedene Codes für 
ein- und dieselbe Taste decodiert werden.

Fazit: Merlin fliegt raus.

Sorry,

Frank

von Dirk W. (glotzi)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich habe am Wochenende einige Tests mit der Merlin gemacht.
Danke fürs Feedback, hatte schon gar nicht mehr damit gerechnet.

> ... Entweder habe ich da ein defektes Exemplar
> erwischt oder es handelt sich um einen Serienfehler. Letzteres würde
> erklären, warum Pollin diese Tastaturen zum Schleuderpreis anbietet.

Hmm, seltsam. Ich und andere User auch, können die Merlin via lirc im 
Rawmode ohne Probleme benutzen. Ich werde nochmal nachfragen.

> Fazit: Merlin fliegt raus.
Sehr schade.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dirk W. schrieb:
> Hmm, seltsam. Ich und andere User auch, können die Merlin via lirc im
> Rawmode ohne Probleme benutzen. Ich werde nochmal nachfragen.

Vielleicht ist wirklich nur meine Tastatur defekt. Ich meine, ich habe 
irgendwo im Keller noch ein zweites Exemplar davon vergraben. Ich werde 
das heute abend mal rauswühlen und damit nochmal testen.

> Sehr schade.

Okay, wenn es mit der Tastatur im Keller doch geht, dann baue ich es 
wieder ein. Hast mich überredet, denn eigentlich ist das wirklich eine 
niedliche Tastatur ;-)

von Dirk W. (glotzi)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich habe am Wochenende einige Tests mit der Merlin gemacht. Wie ich über
> IR_LOGGING per IRMP fesstellen konnte, gibt es einige Tasten, die exakt
> den gleichen IR-Frame senden. Das war bei mir zum Beispiel bei den
> Tasten "t" und "n" der Fall. Entweder habe ich da ein defektes Exemplar
> erwischt oder es handelt sich um einen Serienfehler. Letzteres würde
> erklären, warum Pollin diese Tastaturen zum Schleuderpreis anbietet.

Ich muss nochmal nachfragen: wurde keine Taste erkannt oder nur manche 
nicht? Bei mir ist es so, dass noch nicht mal das Merlin Protokoll 
erkannt wurde.

von Sebastian W. (dl3yc)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

Frank M. schrieb:
> Trotzdem wundert es mich, dass es bei Dir nun auf dem ATtiny
> funktioniert, denn meines Erachtens war da noch ein
> Copy-and-Paste-Fehler meinerseits beim Setzen von TCCR1. Man benötigt
> hier einen Prescaler von 4 und nicht von 2.
> [...]
> Wichtig sind hier die beiden Zeilen für den ATTiny85: Neben dem Bit CS11
> wird auch noch CS10 im TCCR1-Register gesetzt, um den Prescaler auf 4 zu
> bekommen. Eigentlich müsstest Du das auch so korrigiert haben, um das
> zum Laufen zu bekommen. Kannst Du das so bestätigen?
Nein, ich habe sie unverändert übernommen, auch die F_INTERRUPTS sind 
noch bei 15k.

Der Grund warum hier eine Veränderung benötigt wird ist doch, dass beim 
Tiny Timer1 ein 8bit-Timer statt eines 16bit-Timers wie bei den Megas 
ist.
Mein Wert mit Prescaler 2 ist mit OCR1A   =  (F_CPU / (2 * F_INTERRUPTS) 
/ 2) - 1 rund 132 und passt somit in die 8bit Variable - warum sollte 
das anders sein?

Gruß Sebastian

Nachtrag:

meine Timer1_init():
void
timer1_init (void)
{
#if defined (__AVR_ATtiny45__)                                      // ATtiny85:
    OCR1A   =  (F_CPU / (2 * F_INTERRUPTS) / 2) - 1;                // compare value: 1/28800 of CPU frequency, presc = 2
    TCCR1   = (1 << CTC1) | (1 << CS11);                            // switch CTC Mode on, set prescaler to 2
#else                                                               // ATmegaXX:
    OCR1A   =  (F_CPU / (2 * F_INTERRUPTS)) - 1;                    // compare value: 1/28800 of CPU frequency
    TCCR1B  = (1 << WGM12) | (1 << CS10);                           // switch CTC Mode on, set prescaler to 1
#endif

#ifdef TIMSK1
    TIMSK1  = 1 << OCIE1A;                                          // OCIE1A: Interrupt by timer compare
#else
    TIMSK   = 1 << OCIE1A;                                          // OCIE1A: Interrupt by timer compare
#endif
}

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Sebastian,

Sebastian Weiß schrieb:

> Der Grund warum hier eine Veränderung benötigt wird ist doch, dass beim
> Tiny Timer1 ein 8bit-Timer statt eines 16bit-Timers wie bei den Megas
> ist.

Richtig.

> Mein Wert mit Prescaler 2 ist mit OCR1A   =  (F_CPU / (2 * F_INTERRUPTS)
> / 2) - 1 rund 132 und passt somit in die 8bit Variable - warum sollte
> das anders sein?

Ja. Aber wenn Du Dir die Zuweisung einmal genauer anschaust, steckt der 
Faktor 2 zweimal drin. Also hat man faktisch einen Divisor mit dem Wert 
4. Die obige Zuweisung ist also identisch mit:
 OCR1A   =  (F_CPU / F_INTERRUPTS / 4) - 1; 

Und damit müsste der Prescaler auch auf 4 gestellt werden, also:
 TCCR1   = (1 << CTC1) | (1 << CS11) | (1 << CS10); 

statt
 TCCR1   = (1 << CTC1) | (1 << CS11); 

damit auch der Prescaler von 4 rauskommt.

Oder habe ich da jetzt einen Denkfehler?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dirk W. schrieb:
> Ich muss nochmal nachfragen: wurde keine Taste erkannt oder nur manche
> nicht?

Es werden bei mir eigentlich alle Tasten erkannt, auf jeden Fall immer 
das Merlin-Protokoll.

Aber was auffiel:

1. Bei längerem Herunterdrücken einer Taste kippte ab und zu ein bit,
   d.h. man erhielt dann bei den Wiederholungen einen anderen Code.

2. Manche Tasten sendeten denselben IR-Frame. Das führe ich mal auf
   einen Defekt meiner Tastatur zurück, z.B. Kurzschluss in der
   Tastatur-Matrix oder ähnliches.

> Bei mir ist es so, dass noch nicht mal das Merlin Protokoll erkannt wurde.

Doch, bei mir schon. Allerdings habe ich alle anderen exotischen 
Protokolle abgeschaltet, also nur die Standard-Protokolle von SIRCS bis 
DENON eingeschaltet und zusätzlich nur noch Merlin. Du kannst das ja 
auch mal mit dieser Konstruktion testen. Ich kann mir durchaus 
vorstellen, dass die anderen Exoten wie Ruwido und andere mit ähnlichem 
Startbit-Timing stören könnten.

von Dirk W. (glotzi)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Dirk W. schrieb:
>> Ich muss nochmal nachfragen: wurde keine Taste erkannt oder nur manche
>> nicht?
>
> Es werden bei mir eigentlich alle Tasten erkannt, auf jeden Fall immer
> das Merlin-Protokoll.

Ok, danke für die Info.

Dann habe ich mit meinem V-USB Receiver wohl noch ein ganz anderes 
Problem. Bei mir funktionieren auch keine Frequenzen > 10000, egal 
welche Remote ich benutze. Ich frage mich jetzt doch, ob das ein 
prinzipielles Problem des Portisch-Receivers ist.

von Sebastian W. (dl3yc)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

was du beschreibst ist logisch, aber trotzdem falsch.
Ich habe die neueste SVN-Version gezogen und probiert - es funktioniert 
nicht.

Meine main():
int
main (void)
{
    IRMP_DATA irmp_data;

    irmp_init();                                                            // initialize irmp
  DDRB |= (1<<PB0);                            // initialize LED
    timer1_init();                                                          // initialize timer 1
    sei ();                                                                 // enable interrupts

    for (;;)
    {
        if (irmp_get_data (&irmp_data))
        {
      // toggle LED
      if (PORTB & (1<<PB0))
      PORTB &= ~(1<<PB0);
      else
      PORTB |= (1<<PB0);
            // ir signal decoded, do something here...
            // irmp_data.protocol is the protocol, see irmp.h
            // irmp_data.address is the address/manufacturer code of ir sender
            // irmp_data.command is the command code
            // irmp_protocol_names[irmp_data.protocol] is the protocol name (if enabled, see irmpconfig.h)
        }
    }
}

Ändere ich aber den Prescaler wieder zurück zu 2, also lösche CS10, dann 
funktioniert alles soweit.
Kannst du dir das erklären?

Nun möchte ich dazu auch IRSND benutzen, aber das hat dann wohl 
Probleme, weil es auf der falschen Zeitbasis aufsetzt?

Nebenbei:
Ich habe NEC, SAMSUNG und RC5 aktiviert, also ich teste mit 3 verschd. 
FB.
NEC und RC5 funktioniert(meine LED togglet). Aber SAMSUNG wird nicht 
erkannt. Auf einem 2. Board mit einem ATMega8 und Anzeige von Protokoll, 
Addresse und Befehl per UART funktioniert die Erkennung dort.

Mit F_INTERRUPTS = 20000 geht dann auch RC5 nicht und mit F_INTERRUPTS = 
10000 geht SAMSUNG, aber NEC nicht mehr.

Ich probiere es weiter.

Gruß DL3YC

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Sebastian,

Sebastian Weiß schrieb:
> Ändere ich aber den Prescaler wieder zurück zu 2, also lösche CS10, dann
> funktioniert alles soweit.
> Kannst du dir das erklären?

Nein, das kann ich mir momentan überhaupt nicht erklären. Da mir aber 
die ATTtiny85 ausgegangen sind, habe ich mir gestern neue bestellt, um 
das selbst zu testen. Es muss ja eine Erklärung dafür geben. 
Wahrscheinlich habe ich nur an der falschen Stelle im Datenblatt 
geschaut.

> Nun möchte ich dazu auch IRSND benutzen, aber das hat dann wohl
> Probleme, weil es auf der falschen Zeitbasis aufsetzt?

Nein, das sollte gehen. Du willst IRMP & IRSND verwenden? Dann muss die 
ISR dafür so aussehen (s.a. IRMP-Artikel):
ISR(TIMER1_COMPA_vect)
{
  if (! irsnd_ISR())          // call irsnd ISR
  {                           // if not busy...
      irmp_ISR();             // call irmp ISR
  }
  // call other timer interrupt routines...
}

Wenn dann noch die Konstanten F_INTERRUPTS in irmpconfig.h und 
irsndconfig.h denselben Wert haben, ist alles perfekt.

> Ich habe NEC, SAMSUNG und RC5 aktiviert, also ich teste mit 3 verschd.
> FB.
> NEC und RC5 funktioniert(meine LED togglet). Aber SAMSUNG wird nicht
> erkannt.

Hast Du mal SAMSUNG32 als alternatives Protokoll ausgewählt? Sonst 
schalte soviele Protokolle an, wie mit Deinem ATmega8 möglich sind. Wenn 
es dann auch nicht geht, schalte IRMP_LOGGING an und schicke mir ein 
paar Scans.

> Mit F_INTERRUPTS = 20000 geht dann auch RC5 nicht und mit F_INTERRUPTS =
> 10000 geht SAMSUNG, aber NEC nicht mehr.

In der Regel sind F_INTERRUPTS = 15000 die richtige Wahl.

Gruß,

Frank

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Sonst
> schalte soviele Protokolle an, wie mit Deinem ATmega8 möglich sind.

PS ich hatte mal überschlagen, alle <= 15000 F_Interrupt Protokolle 
brauchen ca 4k und für IRSND auch, reicht der ATmega8 oder braucht man 
schon den 16 ?

hat einer einen Link für einen Adapter von ISP 6 auf ISP 10, meine Kabel 
sind alle auf 10pol aber der letzte gekaufte hat 6pol mag keine neuen 
Kabel bauen lieber einen Adapter Stecker ISP6 auf Kupplung ISP10

von Sebastian W. (dl3yc)


Bewertung
0 lesenswert
nicht lesenswert
Nocheinmal Rückmeldung von mir:
Bei mir funktioniert jetzt alles wie gewollt (IRMP + IRSND) auf dem 
ATtiny45. Einzige Änderung der Prescaler s.o. und meine IR-Sendediode 
habe ich gegen eine 950nm-IR-LED getauscht.

Vielen Dank für das tolle Projekt und den guten Support!

73! DL3YC

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sebastian Weiß schrieb:
> Bei mir funktioniert jetzt alles wie gewollt (IRMP + IRSND) auf dem
> ATtiny45. Einzige Änderung der Prescaler s.o. und meine IR-Sendediode
> habe ich gegen eine 950nm-IR-LED getauscht.

Freut mich, dass es funktioniert. Aber ich muss da nochmal nachhaken:

Mit welcher Frequenz läuft Dein ATtiny? Was ist bei Dir als F_CPU im 
Projekt eingetragen?

Gruß,

Frank

von Sebastian W. (dl3yc)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Mit welcher Frequenz läuft Dein ATtiny? Was ist bei Dir als F_CPU im
> Projekt eingetragen?

Beides 8 MHz. Ich kann es mir auch noch nicht erklären. Deswegen habe 
ich gerade einen Test gemacht mit:

Per Fuse den Takt ausgegeben und gemessen - 8,74MHz.
In der Timer-ISR Pin togglen lassen und gemessen - 8,275kHz.
Pintogglen halbiert die Frequenz also sind es ~16,5kHz
Reale CPU-Frequenz / Timerwert(OCR1A) / Prescaler müsste 16,5kHz 
ergeben.
8740000/133/2=32857 -> da stimmt was nicht!
Somit gibt es trotz einem Prescaler von 2 einen 15kHz Interrupt.

Gruß Sebastian

von gera (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Gibt es auch ein Code für den C18 Compiler.
Den CCS Code habe ich gefunden, habe leider keine
Ahnung wie man von CSS nach C18 portiert.

Gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sebastian Weiß schrieb:
> Beides 8 MHz. Ich kann es mir auch noch nicht erklären.

Ich habe den Fehler gefunden. Fälschlicherweise habe ich das 
OCR1A-Register auch beim ATtiny85 genommen, obwohl es hier das 
OCR1C-Register sein muss. Bei Dir hat es nur deshalb funktioniert, weil 
der errechnete Wert mit dem Prescaler 2 statt 4 ungefähr einen Wert von 
256 (in Wirklichkeit 266) ergibt. Da das OCR1C-Register mit 0 vorbelegt 
ist, hat der Timer immer bis 256 durchgezählt. Dadurch hattest Du dann 
mit einer Abweichung von ca. 5 Prozent die "richtige" Abtastrate. Da 
IRMP mit Toleranzen von bis zu 40% klarkommt, funktionierte das dann bei 
Dir.

Hier der korrekte Code von timer1_init() für ATtiny85:
#if defined (__AVR_ATtiny45__) || defined (__AVR_ATtiny85__)                // ATtiny45 / ATtiny85:
    OCR1C   =  (F_CPU / F_INTERRUPTS / 4) - 1;                              // compare value: 1/15000 of CPU frequency, presc = 4
    TCCR1   = (1 << CTC1) | (1 << CS11) | (1 << CS10);                      // switch CTC Mode on, set prescaler to 4
    ....

Und jetzt passt das auch wieder zusammen mit dem Prescaler von 4.

Den Code im SVN habe ich korrigiert.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
gera schrieb:

> Gibt es auch ein Code für den C18 Compiler.

Bisher nicht. Der hardware-abhängige Teil beschränkt sich auf die Angabe 
des input-Makros (s. irmpconfig.h) und der Definition des Timers.

Bekommst Du das hin? Wäre nett, wennn Du mir dann die Änderungen für den 
PIC-C18-Compiler zur Verfügung stellen könntest.

Gruß,

Frank

von gera (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Habe mal versucht den Code zu übersetzen.
Zwei Probleme:
1. Wie übersetze ich diese Zeile (input gibt es bei C18 nicht)
    irmp_input = input(IRMP_PIN);

  Mein Versuch ?
    irmp_input = IRMP_PIN;

2. Die Input Pin
   #define IRMP_PIN   PIN_B4  // use PB4 as IR input on PIC

 Mein Versuch:

   #define IRMP_PIN   LATBbits.LATB4  // use PB4 as IR input on PIC

 oder evtl das hier ?

   #define IRMP_PIN   PORTBbits.RB4   // use PB4 as IR input on PIC

Was ist die richtige Übersetzung ?

So läuft schon mal bis jetzt der Compiler durch.
Zum Testen bin ich noch nicht gekommen.

Den Timer0 habe ich auf 10000 Hz gestellt und eine INT Routine 
eingebaut.
Passt das so ?
Benutze einen 18F2550 mit 20MHz Quarz.

Gruß

von gera (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Compilieren kann ich es jetzt ohne Probleme.
Leider wird nichts erkannt.

Den Timer0 hab ich auf 10000Hz eingestellt, Timer0 Int funktioniert 
soweit.
Muss ich irgendwo noch was eintragen ? CPU-Frequenz, ... ?
Oder kann man es einfach so benutzen.
Benutze Version 1.90
HW: 18F2550, Quarz 20Mhz, Takt 40Mhz

Gruß
gera

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
gera schrieb:

> Den Timer0 habe ich auf 10000 Hz gestellt und eine INT Routine
> eingebaut.
> Passt das so ?

Hast Du auch F_INTERRUPTS in irmpconfig.h angepasst? Dort ist in der 
SVN-Version standardmäßig 15000 als Wert eingetragen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Im IRMP-Artikel

   http://www.mikrocontroller.net/articles/IRMP

steht nun die Version 2.0.1 sowohl für IRMP als auch für IRSND zum 
Download bereit. Diese Version entspricht der letzten SVN-Version. Somit 
sind nun die Download-Dateien wieder zum SVN synchron.

Hier die Änderungen gegenüber der letzten Download-Version vom Januar:

IRMP:

    - Neues Protokoll: KATHREIN
    - Neues Protokoll: RUWIDO
    - Neues Protokoll: THOMSON
    - Neues Protokoll: IR60
    - Neues Protokoll: LEGO
    - Neues Protokoll: NEC16
    - Neues Protokoll: NEC42
    - Neues Protokoll: NETBOX (Prototyp)
    - Portierung auf ATtiny84 und ATtiny85
    - Verbesserung von Tastenwiederholungen bei RC5
    - Verbessertes Decodieren von Bi-Phase-Protokollen
    - Korrekturen am RECS80-Decoder
    - Korrekturen beim Erkennen von zusätzlichen Bits im SIRCS-Protocol

IRSND:

    - Neues Protokoll: THOMSON
    - Neues Protokoll: LEGO
    - Neues Protokoll: NEC16
    - Neues Protokoll: NEC42
    - Portierung auf ATtiny84 und ATtiny85
    - Korrektur von Pausenlängen
    - Korrekturen von irsnd_stop()
    - Korrektur des SIEMENS-Timings
    - Umstellung auf 36kHz Modulationsfrequenz für DENON-Protokoll
    - Korrektur Behandlung zusätzlicher Bits im SIRCS Protokoll

Viel Spaß,

Frank

von gera (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Nach langer Suche habe den Fehler gefunden.
War ein blöder Schreibfehler in einer define-Anweisung.

Funktioniert soweit mit Microchip C18 !

Vielen Dank für die Library !

Ich hab mir mal die 2.01 runtergeladen und werde die Änderungen in diese 
Version einarbeiten.
Wo soll ich es dann schicken ?

Gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
gera schrieb:
> Nach langer Suche habe den Fehler gefunden.

Prima!

> Funktioniert soweit mit Microchip C18 !

Ich werde Deine Änderungen in den IRMP-Source übernehmen, vielen Dank.

> Wo soll ich es dann schicken ?

Da mich Deine Mail schon erreicht hat, hast Du meine Adresse offenbar 
gefunden. Ich antworte Dir dort zu Deinem RC6-Problem.

von Tom S. (year2525)


Bewertung
0 lesenswert
nicht lesenswert
vielen Dank erstmal für dieses Projekt, eine super Arbeit. Es hat auf 
Anhieb funktioniert, eine Creative Fernbed. RM-1500 geht einwandfrei.

2 Fragen habe ich jedoch:

1. Ich habe eine JVC RM-SV511UE remote, von der ich gern das Steuerkreuz 
nutzen möchte. Nur geht die right-Taste irgendwie überhaupt nicht, die 
up/down/left/enter Tasten gehen einwandfrei:

down
irmp_data.protocol: 20
irmp_data.address : 15
irmp_data.command : 3358
irmp_data.flags   : 0

up
irmp_data.protocol: 20
irmp_data.address : 15
irmp_data.command : 3342
irmp_data.flags   : 0

left
irmp_data.protocol: 20
irmp_data.address : 15
irmp_data.command : 3374
irmp_data.flags   : 0

enter
irmp_data.protocol: 20
irmp_data.address : 15
irmp_data.command : 3406
irmp_data.flags   : 0

right
nichts

Die Taste selbst sendet def. ein IR-Signal. Ist das ein bekannter bug? 
Ansonsten kann ich gerne das Logging aktivieren falls das weiterhilft.

2. Ich möchte das ganze in ein RTOS integrieren und dazu den IRMP 
interrupt erst einschalten wenn was am pin passiert, z.B. über einen pin 
change interrupt, und nach ein paar Sek. Pause den IRMP interrupt wieder 
ausschalten. Ist das prinzipiell mit dem vorliegenden code machbar, oder 
wird es Probleme geben weil z.B. counter hochgezählt werden müssen, die 
state machine damit nicht klarkommt etc.

Vielen Dank für das tolle Projekt.

Gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Tom S. schrieb:
> vielen Dank erstmal für dieses Projekt, eine super Arbeit.

Danke fürs Danke :-)
> Die Taste selbst sendet def. ein IR-Signal. Ist das ein bekannter bug?
> Ansonsten kann ich gerne das Logging aktivieren falls das weiterhilft.

Ja, da bräuchte ich Logging-Daten. Am besten von allen 4 Richtungen des 
Steuerkreuzes.

> 2. Ich möchte das ganze in ein RTOS integrieren und dazu den IRMP
> interrupt erst einschalten wenn was am pin passiert, z.B. über einen pin
> change interrupt, und nach ein paar Sek. Pause den IRMP interrupt wieder
> ausschalten. Ist das prinzipiell mit dem vorliegenden code machbar, oder
> wird es Probleme geben weil z.B. counter hochgezählt werden müssen, die
> state machine damit nicht klarkommt etc.

Das müsste machbar sein. Schalte den Timer-Interrupt einfach beim ersten 
Toggle ein und nach einer bestimmten Zeit wieder ab.

Gruß,

Frank

von Tom S. (year2525)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

anbei der log für die JVC für alle 5 Tasten des Steuerkreuzes. Wie 
gesagt, nur die Taste right liefert bei irmp_get_data() null zurück. 
IRMP timer irq ist 14400 Hz.

Das Enablen des IRMP Interrupts nur bei Infrarot-Aktivität werde ich 
dann also demnächst mal probieren.

Danke und Grüße

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Tom,

Tom S. schrieb:
> anbei der log für die JVC für alle 5 Tasten des Steuerkreuzes. Wie
> gesagt, nur die Taste right liefert bei irmp_get_data() null zurück.

Ich habe mir den Log eben angeschaut: Die Taste right sendet 17 statt 16 
Bits. Da das JVC-Timing exakt dem NEC-Timing entspricht, startet IRMP 
erstmal mit dem Protokoll NEC bei der Startbit-Erkennung. Kommt nach dem 
16. Bit dann eine Pause (weil es eben JVC und nicht NEC ist), schaltet 
IRMP auf JVC um. Das passiert aber leider nicht, wenn da statt der Pause 
noch ein 17. Bit hinterhergeschickt wird.

Da muss ich mir etwas einfallen lassen, habe da auch schon eine Idee...

> IRMP timer irq ist 14400 Hz.

Wie kommt diese "komische" Zahl zustande? Benutzt Du vielleicht einen 
Soft-UART mit einer Abtastrate von 28800, was einer Baudrate von 9600 
entspricht? ;-)

> Das Enablen des IRMP Interrupts nur bei Infrarot-Aktivität werde ich
> dann also demnächst mal probieren.

Ja, finde ich spannend. Sollte meiner Meinung auch problemlos 
funktionieren. Du könntest den Timer-Interrupt eigentlich auch sofort 
abstellen, sobald IRMP den Frame erkannt hat und nicht erst nach einer 
"gewissen" Zeit. Dazu müsstest Du aber in den IRMP-Source eingreifen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Tom S. schrieb:
> anbei der log für die JVC für alle 5 Tasten des Steuerkreuzes. Wie
> gesagt, nur die Taste right liefert bei irmp_get_data() null zurück.

Im SVN ist nun eine neue Version, mit der jetzt auch die Taste "right" 
erkannt wird. War doch etwas mehr Arbeit als ich dachte. Läuft aber 
jetzt :-)

P.S.
Wenn Du Adresse und Code in Hex schreibst, wird die Systematik der 
Tastencodes besser ersichtlich:

# up    p=20 addr=0x000F cmd=0x0d0e
# down  p=20 addr=0x000F cmd=0x0d1e
# left  p=20 addr=0x000F cmd=0x0d2e
# right p=20 addr=0x000F cmd=0x0d3e
# enter p=20 addr=0x000F cmd=0x0d4e

von narkus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> B1. FB sendet ersten Frame
> B2. IRMP setzt Busy-Flag
> B3. IRMP liest ersten Frame ein
> B4. IRMP setzt Busy-Flag zurück
> B5. Applikation holt ersten Frame ab
> B6. FB macht eine Pause von ca. 40 msec
> B7. FB sendet zweiten Frame
> B8. IRMP setzt Busy-Flag
> B9. IRMP liest ersten Frame ein
> B10. IRMP setzt Busy-Flag zurück
> B11. Applikation holt zweiten Frame ab, Repetition-Flag ist gesetzt.

Hmm, B4 (Busy-Flag zurücksetzen) ist eigentlich falsch. IRMP sollte busy 
sein, solange ein wiederholter Tastendruck erkannt werden kann. Und das 
ist frühestens nach 114 ms der Fall!

Wird auf der FB eine Taste gedrückt gehalten, so sollte eine RC5 FB alle 
114 ms das Paket erneut senden. D.h. innerhalb dieser Zeit muss ich 
davon ausgehen, dass die Taste noch gedrückt ist!

Somit darf das Busy-Flag frühestens nach 114 ms (geben wir paar Sekunden 
Puffer drauf, für FBs, die sich nicht ganz daran halten) zurückgesetzt 
werden!

Zur Sicherheit kann man das Toggle-Bit vergleichen, falls es jemand doch 
schaffen sollte, innerhalb dieser Zeit diese Taste oder eine neue 
gedrückt zu haben. ;)

Was meinst Du dazu?
Grüße

von Tom S. (year2525)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

danke für prompte Änderungen. Ich kann bestätigen das jetzt auch die 
right Taste geht (und mit hex siehst besser aus). Ich hoffe das Deine 
Änderung der IRMP_TIMEOUT_TIME nicht andere remotes, die bis jetzt 
gingen, negativ beeinflussen werden :)
Da es eine Original JVC remote ist und der bisherige JVC Teil in IRMP 
wahrscheinlich gut getestet ist, gibt es wohl zumindest 2 Varianten des 
Protokolls im Hause JVC.

>Wie kommt diese "komische" Zahl zustande? Benutzt Du vielleicht einen
>Soft-UART mit einer Abtastrate von 28800, was einer Baudrate von 9600
>entspricht? ;-)

Nein, hat nichts mit einer UART zu tun. Ich habe einen 14.7456 MHz Quarz 
und wollte eine "glatte" interrupt Frequenz haben, also habe ich clk/8 
verwendet und OCR0A auf 127 gesetzt :)

Enablen des IRMP Interrupts nur bei Infrarot-Aktivität werde ich am WE 
probieren.

Danke und Grüße

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Tom S. schrieb:
> danke für prompte Änderungen. Ich kann bestätigen das jetzt auch die
> right Taste geht (und mit hex siehst besser aus). Ich hoffe das Deine
> Änderung der IRMP_TIMEOUT_TIME nicht andere remotes, die bis jetzt
> gingen, negativ beeinflussen werden :)

Ich checke nach Source-Änderungen einen Großteil der Scans im Ordner 
IR-Data unter Linux komplett durch, siehe IR-Data/test-suite.sh. Erst, 
wenn alle Scans ohne Fehler erkannt werden, gebe ich die Software raus.

> Da es eine Original JVC remote ist und der bisherige JVC Teil in IRMP
> wahrscheinlich gut getestet ist, gibt es wohl zumindest 2 Varianten des
> Protokolls im Hause JVC.

JVC ist relativ spät dazugekommen, gibt es erst seit ein paar Monaten. 
Also soooo gut getestet war es bisher nicht. Aber es sind tatsächlich 
Differenzen im Protokoll-Verhalten zwischen den beiden 
JVC-Fernbedienungen, deren Scans ich bisher erhalten habe. Das konnte 
ich aber erst anhand Deiner Right-Taste erkennen.

Gruß,

Frank

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> irmp_protocol_names[irmp_data.protocol]

Frank M. schrieb:
> @jar:
>
> Um auf die Protokollnamen zugreifen zu können, muss

hallo, bin grad wieder bei

muss nun mein code anpassen

kannst du evt. in irmp.h ein

#ifndef TRUE vor line 486 setzen ?

#ifndef FALSE
  #define FALSE 0
#endif
#ifndef TRUE
  #define TRUE !FALSE
#endif


oder liegt der Fehler bei mir
../irmp.h:486:1: warning: "TRUE" redefined

von Cajus H. (cajush)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

meine programmierbare Fernbedienung mit 5" Touch-Screen ist fast fertig 
und ich feile an den letzten Kleinigkeiten.
Das aktuelle Problemkind sind zwei verschieden-alte Samsung LCD-TV, die 
beide das SAMSUNG32 Protokoll verwenden.
Problem 1: Das von IRSND generierte Signal wird vom TV nur erkannt, wenn 
meine FB in geringem Abstand vor dem TV mit Zielfernrohr auf das TV 
Gerät gerichtet wird. Außerdem muss man jede Taste ziemlich lange 
drücken, bis diese vom TV aktzeptiert wird.
Problem 2: Beim hintereinander-senden von mehreren Befehlen (z.B. "2", 
"4", "Enter" für die Anwahl des Programmes 24) wird nur der erste Befehl 
vom TV aktzeptiert.

zu Problem 1: Ich habe die Signale von IRSND und den Original-FB's am 
Ozszilloskop verglichen.
Mir sind folgende Unterschiede aufgefallen:
a) IRSND sendet immer zwei Frames, die Fernbedienungen senden auch 
einzelne Frames, wenn man die Taste kurz genug drückt.
b) die Pause-Zeit für den Bitwert "1" von IRSND ist zu kurz. 
IRSND=1450us, die Original-FB's haben 1680us und 1710us
c) die Pause-Zeit für den Bitwert "0" von IRSND ist zu kurz. 
IRSND=450us, die Original-FB's haben 550us und 580us
Die übrigen Zeiten aus den Definitionen in irmp.h (_START_BIT_xx und 
_PULSE_TIME) stimmen aber exakt!
Ich habe also folgende Änderungen in irmp.h vorgenommen:
#define SAMSUNG_1_PAUSE_TIME  1700.0e-6    // 1700 usec pause
#define SAMSUNG_0_PAUSE_TIME   550.0e-6    //  550 usec pause
#define SAMSUNG32_FRAMES      1            // SAMSUNG32 sends each frame 
1 time
Danach funktionierte meine FB wesentlich besser!

zu Problem 2: Ich konnte das Problem beheben, indem ich zwischen die 
Sendebefehle eine 50ms Pause eingefügt habe.
In Deinem Beitrag vom 20.05.2011 11:43 hattest Du dieses Problem als 
fixed gepostet:

>> IRSND hat im Moment auch noch einen unschönen Bug, den ich dabei auch
>> noch loswerden möchte: Nach Aussenden des gewünschten Frames wird die
>> Pause-Zeit zum nächsten Frame nicht eingehalten, wenn man
>> irsnd_send_data() direkt wieder aufruft. Innerhalb von flags > 0 wird
>> das korrekt eingehalten, aber nach dem letzten gesendeten Frame kann man
>> direkt wieder mittels irsnd_send_data() "feuern". Das ist unschön.

> Diesen Bug habe ich nun auch gefixt. Ist zwar noch nicht optimal, aber
> ich bin erstmal damit zufrieden. Die Pause wird nämlich erst dann
> eingefügt, wenn auch tatsächlich ein 2. Frame auf die Reise geschickt
> wird.

Kann es sein, dass noch nicht ganz funktioniert?

Viele Grüße
Cajus

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
frage zu IRSND

wo muss ich die CPU definieren ?
../irsnd.c:197:2: error: #error mikrocontroller not defined, please fill 
in definitions here.

holt IRSND sich das nicht aus astudio win-gcc den projekt options ? da 
hab ich doch die CPU gewählt

und wenn ich schon definieren muss, wie bitte ? für atmega1284p

   || defined (_AVR_ATmega1284P_)                      // 
ATmega164|324|644|644P|1284 uses OC2A = PD7 or OC2B = PD6 or OC0A = PB3 
or OC0B = PB4

es fehlte der Prozessor 1284p

noch eine kleine Anmerkung, sollte mit der Nennung OC2A und der CPU 
Definition der Port PD7 bekannt sein ? warum muss man den noch extra 
eingeben ?

noch ne doofe Frage, in astudio und im Arbeitsdir, wechseln manchmal die 
Dateinamen zu Uppercase Letter, das provoziert den c++ Fehler, ich weiss 
nicht wieso alle meine Dateinamen manchmal groß werden, auch wenn sie 
noch klein sind öffnet AStudio diese in Großbuchstaben und manchmal wird 
es auch so im Dir angezeigt

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> und wenn ich schon definieren muss, wie bitte ? für atmega1284p
>
>    || defined (_AVR_ATmega1284P_)                      //
> ATmega164|324|644|644P|1284 uses OC2A = PD7 or OC2B = PD6 or OC0A = PB3
> or OC0B = PB4
>
> es fehlte der Prozessor 1284p

Ja, den habe ich einfach vergessen. Eintragen und fertig:
#elif defined (__AVR_ATmega164__)   \
   || defined (__AVR_ATmega324__)   \
   || defined (__AVR_ATmega644__)   \
   || defined (__AVR_ATmega644P__)  \
   || defined (__AVR_ATmega1284__)  \
   || defined (__AVR_ATmega1284P__)                     // ATmega164|324|644|644P|1284 uses OC2A = PD7 or OC2B = PD6 or OC0A = PB3 or OC0B = PB4


> noch eine kleine Anmerkung, sollte mit der Nennung OC2A und der CPU
> Definition der Port PD7 bekannt sein ? warum muss man den noch extra
> eingeben ?

Musst Du ja eben nicht. In irsndconfig einfach OC2A auswählen und 
fertig. Über das obige #if in irsnd.c "weiß" dann der Compiler, welcher 
Portpin verwendet wird.

> noch ne doofe Frage, in astudio und im Arbeitsdir, wechseln manchmal die
> Dateinamen zu Uppercase Letter, das provoziert den c++ Fehler, ich weiss
> nicht wieso alle meine Dateinamen manchmal groß werden, auch wenn sie
> noch klein sind öffnet AStudio diese in Großbuchstaben und manchmal wird
> es auch so im Dir angezeigt

Ich habe alle IRMP-/IRSND-Sources mit Kleinbuchstaben angelegt, gerade 
um solche Probleme zu vermeiden.

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich habe alle IRMP-/IRSND-Sources mit Kleinbuchstaben angelegt, gerade
> um solche Probleme zu vermeiden.

das habe ich auch, nur mein Problem ist ja das die urplötzlich groß 
werden

ich vermute aber das passiert durch primalscript wenn ich ausserhalb vom 
astudio mal eine *.c öffne

also wenns nicht astudio macht, dann wer anderes, ich wollte nur mal 
hören ob den Fehler jemand kennt

von Klaus K. (klkl)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Ich habe das irmp Projekt erfolgreich auf einem ARM SAM7x unter ethernut 
ans laufen bekommen. Die minimalen Änderungen schicke Ich hier mit.
Ein wirklich schönes Projekt....

Mein Vorschlag wäre es die Hardwareabhängigkeiten weitgehend aus irmp.c 
zu entfernen und insbesondere die input-Funktion ohne Parameter als 
extern zu deklarieren. Dann muss auf jeder Platform nur noch eine 
entsprechende Funktion generiert werden, und man muss weniger an irmp 
ändern.

Dann ist mir noch aufgefallen, das die IRQ-Routine für mein Gefühl recht 
viel Zeit beansprucht. 5-7us, damit verbraucht die IR-Erkennung bei 
15000 IRQs/s etwa 10% der Rechenleistung des SAM7. Bei einem AVR sieht 
das bestimmt noch schlechter aus(?)

Die Ethernut-Anbindung kann Ich auch an Interessiert weitergeben. Unter 
www.klkl.de werde Ich in den nächsten Tagen eine Seite dazu schreiben.

Vielen Dank, irmp hat mich schnell an mein Ziel gebracht
Gruß Klaus

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
hallo Frank,

so langsam komme ich voran, kann offensichtlich genau einmal IRSND 
aufrufen, danach hängt der Atmel, muss ich noch suchen (grrrr)

in deiner Projektseite hier :
http://www.mikrocontroller.net/articles/IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder
ist der Aufruf noch beschrieben als :
irsnd_send_data (&irmp_data);

ergibt aber:
Build error weil :
(void) irsnd_send_data (&irmp_data, TRUE);

eine Idee warum der genau nach einmal Aufruf abstürzt ? hab ich was beim 
Einbinden übersehen ?
      if(res_key & ( 1<<KEY_ENTER ))
      {  res_key=0;
        if(__p==_IRSND)
        {  
           irmp_data.protocol = IRMP_SAMSUNG32_PROTOCOL;   // sende im NEC-Protokoll
           irmp_data.address  = 0x0707;              // verwende Adresse 0x00FF
           irmp_data.command  = 0xed12;              // sende Kommando 0001
           irmp_data.flags    = 5;                   // keine Wiederholung!

          lcd_gotoxy(0,1); lcd_puts("R: Code: "); lcd_puts(trimm_string(' ', irmp_protocol_names[irmp_data.protocol], 8));
          lcd_gotoxy(0,2); lcd_puts("A: "); 
          strcpy(s2, "0x"); strcat(s2, utoa(irmp_data.address,s,16)); lcd_puts(trimm_string(' ', s2, 6)); 
          strcpy(s2, "("); strcat(s2, utoa(irmp_data.address,s,10)); strcat(s2, "d)");
          lcd_gotoxy(11,2); lcd_puts(trimm_string(' ', s2, 8));
          
          lcd_gotoxy(0,3); lcd_puts("C: ");
          strcpy(s2, "0x"); strcat(s2, utoa(irmp_data.command,s,16));  lcd_puts(trimm_string(' ', s2, 6)); 
          strcpy(s2, "("); strcat(s2, utoa(irmp_data.command,s,10)); strcat(s2, "d)");
          lcd_gotoxy(11,3); lcd_puts(trimm_string(' ', s2, 8));
            irsnd_send_data (&irmp_data, TRUE);
        }
}

danke jar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Joachim,

Joachim B. schrieb:
> Build error weil :
> (void) irsnd_send_data (&irmp_data, TRUE);

Stimmt, da habe ich vergessen, den Artikel anzupassen. Werde ich 
nachholen.

> eine Idee warum der genau nach einmal Aufruf abstürzt ? hab ich was beim
> Einbinden übersehen ?

Kann ich erstmal nicht sehen. Schickt er denn tatsächlich 1+5 Frames 
raus, so wie du mit

> irmp_data.flags = 5;   // keine Wiederholung!

eingestellt hast?

Am leichtesten siehst Du das, wenn Du Dir die IR-LED mit einer 
Digitalkamera anschaust. Bei 6 Frames müsste es schon mehr als eine 
halbe Sekunde flackern.

Da ich nicht weiß, was das Programm nach Ausführen von irsnd_send_data() 
macht, kann ich Dir auch nicht sagen, wo es danach abstürzt ;-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Klaus,

Klaus Kloos schrieb:

> Ich habe das irmp Projekt erfolgreich auf einem ARM SAM7x unter ethernut
> ans laufen bekommen. Die minimalen Änderungen schicke Ich hier mit.

Vielen Dank für die Änderungen, werde ich in den IRMP-Source einbauen. 
Leider hast Du Deine eigene Input-Funktion weggelassen, hätte mich schon 
interessiert.

> Mein Vorschlag wäre es die Hardwareabhängigkeiten weitgehend aus irmp.c
> zu entfernen und insbesondere die input-Funktion ohne Parameter als
> extern zu deklarieren. Dann muss auf jeder Platform nur noch eine
> entsprechende Funktion generiert werden, und man muss weniger an irmp
> ändern.

Ich wollte eigentlich aus "Zeitgründen" vermeiden, eine externe Funktion 
in der ISR dafür aufzufrufen. Ließe sich Deine input-Funktion nicht auch 
als Makro in irmpconfig.h realisieren?

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Da ich nicht weiß, was das Programm nach Ausführen von irsnd_send_data()
> macht, kann ich Dir auch nicht sagen, wo es danach abstürzt ;-)
> Gruß,
> Frank

bin einen Schritt weiter, kann mehrfach das Kommando mit KEY_ENTER 
auslösen

mir fehlt im Moment noch ein 2ter IRMP Empfänger, deine Idee mit der LED 
hatte ich schon umgesetzt, parallel zur IR ist eine UH rt LED zum 
gucken, einmal hab ich die IR mit der Cam im Handy gecheckt, öfter tut 
erst mal nicht Not

habe die Pollin RS232 zu FBAS bekommen, werde den ATmega 8 zu 168 
tauschen und den TSOP und IR Dioden bestücken, RS232 zu USB nehme ich 
die billigen 9,95 Teile, die aber nur 0 und +V liefern, doof mal sehen 
ob RTS und DTR genug Strom liefern zum betreiben vons ganze, deswegen 
wollte ich ja v-usb, da wäre der Strom gleich mitgekommen, aber den USB 
Adapter aufbohren mag ich nicht

muss man eigendlich den Buffer leeren ? mit
while(irmp_get_data(&irmp_data));

kannst du für IRSND noch die Codes für Sony Panasonic Canon Nikon DSLR 
Cams nachrüsten ?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Cajus,

Cajus H. schrieb:

> Das aktuelle Problemkind sind zwei verschieden-alte Samsung LCD-TV, die
> beide das SAMSUNG32 Protokoll verwenden.
> Problem 1: Das von IRSND generierte Signal wird vom TV nur erkannt, wenn
> meine FB in geringem Abstand vor dem TV mit Zielfernrohr auf das TV
> Gerät gerichtet wird. Außerdem muss man jede Taste ziemlich lange
> drücken, bis diese vom TV aktzeptiert wird.

Könnte das eine falsche Modulationsfrequenz sein? Die schlechte 
Reichweite spricht jedenfalls dafür. Kannst Du Modulationsfrequenz bei 
den Original-Fernbedienungen mit einem Scope (o.ä.) messen? Die 38kHz 
sind beim Samsung32-Protokoll nur "geraten", da ich darüber keine Daten 
im Internet finden konnte.

> zu Problem 1: Ich habe die Signale von IRSND und den Original-FB's am
> Ozszilloskop verglichen.
> Mir sind folgende Unterschiede aufgefallen:
> a) IRSND sendet immer zwei Frames, die Fernbedienungen senden auch
> einzelne Frames, wenn man die Taste kurz genug drückt.

Upps! Danke für die Info! Ich hatte bisher nur Samsung32-Scans bekommen, 
wo immer 2 Frames hintereinander kamen. Die Leute drücken leider beim 
Scannen meist länger die Taste, damit es auch "garantiert" ankommt. Hat 
den Nachteil, dass ich dann falsche Schlussfolgerungen ziehe. ;-)

Also ist für SAMSUNG32 in

  http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail

der Eintrag

  Wiederholung     einmalig nach 45ms

falsch und es muss heißen:

  Wiederholung     keine.

> b) die Pause-Zeit für den Bitwert "1" von IRSND ist zu kurz.
> IRSND=1450us, die Original-FB's haben 1680us und 1710us
> c) die Pause-Zeit für den Bitwert "0" von IRSND ist zu kurz.
> IRSND=450us, die Original-FB's haben 550us und 580us

Danke auch dafür, ich werde das mit den mir vorliegenden Scans 
gegenprüfen. Ich habe da dieselben Werte wie für das SAMSUNG-Protokoll 
angenommen, da es im Rahmen der Messungenauigkeiten war und sich 
ansonsten das SAMSUNG- und das SAMSUNG32-Protokoll doch sehr ähneln.

> Die übrigen Zeiten aus den Definitionen in irmp.h (_START_BIT_xx und
> _PULSE_TIME) stimmen aber exakt!

Und das ohne Dokumentation :-) Ich habe mir das Samsung32-Protokoll 
nämlich lediglich anhand von Scans zusammengereimt.

> Ich habe also folgende Änderungen in irmp.h vorgenommen:
> #define SAMSUNG_1_PAUSE_TIME  1700.0e-6    // 1700 usec pause
> #define SAMSUNG_0_PAUSE_TIME   550.0e-6    //  550 usec pause
> #define SAMSUNG32_FRAMES      1            // SAMSUNG32 sends each frame
> 1 time
> Danach funktionierte meine FB wesentlich besser!

Danke, ist aber die falsche Stelle, da sich damit auch die Timings für 
das SAMSUNG-Protokoll (ohne 32) ändern. Tatsächlich muss ich da wohl 
SAMSUNG und SAMSUNG32 vom Timing her trennen.

> In Deinem Beitrag vom 20.05.2011 11:43 hattest Du dieses Problem als
> fixed gepostet:

Ja, das stimmt, hatte ich eigentlich gefixed... dachte ich jedenfalls 
:-)
Werde ich aber nochmal überprüfen.

Viele Grüße,

Frank

von Klaus K. (klkl)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank

Hier die wichtigsten Teile zu input-Funktion.
Für den Zeitbedarf ist es eigentlich unerheblich, ob eine externe oder 
eine Funktion aus der gleichen Code-Datei aufgerufen wird. Der Linker 
packt diese ja später zusammen, egal woher die Funktionen kommen. Der 
Optimierer hat nur etwas schlechtere Chancen überflüssiges zu entsorgen.

Wenn man die input-Funktion als 'wie ist denn der Stand auf dem 
IR-Eingang' versteht, dann kann dort der übergebene Parameter weg.

Ich betrachte irmp als autarkes Modul. Die Hardware-Abhaengigkeiten sind 
bei mir im aufrufenden Thread. Um die Funktion in irmpconfig() mit 
meiner input-Funktion ans compilieren zu bekommen müsste Ich dort wieder 
Dateien für den SAM7 einbinden.
Vielleicht kann man ein define vorsehen, womit dann die input-Funktion 
extern erwartet wird?

/*!
 * \def IO_PIO_PDS_REG
 * \brief Pin data status register of the button interface.
*/
#define IO_PIO_PDS_REG PIOB_PDSR

/*!
 * \def IO_IR_BIT
 * \brief used PIO bit. */
#define IO_IR_BIT      29

bei der Thread-Initialisierung
    /* Initialize GPIO lines for IR-Read. */
    outr(IO_PIO_PE_REG, IO_IR);
    outr(IO_PIO_OD_REG, IO_IR);
    outr(IO_PIO_PUE_REG, IO_IR);

/*!
 * \brief hier die Funktion fuer irmp um den Status des IO-Pins zu 
ermitteln
 */
uint8_t input(uint8_t test)
{
  return ( (~inr(IO_PIO_PDS_REG) & IO_IR) == 0);
}

Gruß Klaus

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
@frank, hattest du das gelesen ?

Joachim B. schrieb:
> muss man eigendlich den Buffer leeren ? mit
>
> while(irmp_get_data(&irmp_data));
> 
>
> kannst du für IRSND noch die Codes für Sony Panasonic Canon Nikon DSLR
> Cams nachrüsten ?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> @frank, hattest du das gelesen ?

Ja, habe ich eben gelesen.

> muss man eigendlich den Buffer leeren ? mit
>
> while(irmp_get_data(&irmp_data));
> 

Sollte man machen, wenn man dem User (z.B. fürs Anlernen) sagen will:

           "Drücke JETZT Taste auf FB".

Dann sollte man irgendwelche Frames, die man sich DAVOR "eingefangen" 
hat (z.B. weil die Freundin vorher ferngesehen hat) wegwerfen. Wenn Du 
aber sowieso permanent in einer Endlosschleife irmp_get_data() aufrufst, 
wäre oben genannte Zeile sinnfrei.

>> kannst du für IRSND noch die Codes für Sony Panasonic Canon Nikon DSLR
>> Cams nachrüsten ?

Steht natürlich auf meiner TODO-Liste. Jedes Protokoll, welches ich in 
den IRMP einbaue, will ich später dann auch in den IRSND einbauen. Aber 
nicht immer sind dafür Zeit und Lust vorhanden ;-)

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
>>> kannst du für IRSND noch die Codes für Sony Panasonic Canon Nikon DSLR
>>> Cams nachrüsten ?
>
> Steht natürlich auf meiner TODO-Liste. Jedes Protokoll, welches ich in
> den IRMP einbaue, will ich später dann auch in den IRSND einbauen. Aber
> nicht immer sind dafür Zeit und Lust vorhanden ;-)
>
> Gruß,
>
> Frank

ja ist klar, meine todo ist auch länger als meine Zeit, brauchst du die 
Parameter für die Cams ? ich hab im Moment nur Q&D Code erzeugt der 
funktioniert, würde den gerne rauswerfen wenn IRSND eh schon drin 
ist....

mangels aller IR Sender kann ich die logisch nicht in IRMP scannen

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
@ Frank

Frage zu IRSND irmp_data.flags steht ja für Wiederholungen, 
offensichtlich bedeutet 0 eine Aussendung, also müsste 5 Wiederholungen 
6 Aussendungen bedeuten, mein TV Samsung32 hat aber jeweils nur 5 Prg 
weitergeschaltet,
(immerhin wenn man 99 wiederholungen proggt kann man so schnell als 
möglich zappen)
deswegen war ich in dem Glauben 5 bedeutet 5x aussenden und 0 eben 
keinmal, aber eben getestet, 0 bedeutet 1 Sendung aber 5 hat nur 5 PRG+ 
geschaltet und nicht 6

bin leicht verwirrt davon

der Absturz in meiner HW kann nur an der Dauer gelegen haben, bei 5 
repeat wird mein(e) Interrupt(s) zu lange unterbrochen, da kommt alles 
durcheinander

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> Frage zu IRSND irmp_data.flags steht ja für Wiederholungen,
> offensichtlich bedeutet 0 eine Aussendung, also müsste 5 Wiederholungen
> 6 Aussendungen bedeuten, [...]

Ja.

> mein TV Samsung32 hat aber jeweils nur 5 Prg weitergeschaltet,
> (immerhin wenn man 99 wiederholungen proggt kann man so schnell als
> möglich zappen)
> deswegen war ich in dem Glauben 5 bedeutet 5x aussenden und 0 eben
> keinmal, aber eben getestet, 0 bedeutet 1 Sendung aber 5 hat nur 5 PRG+
> geschaltet und nicht 6

Wie schon Cajus in

Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

andeutete, muss da wohl jeweils eine Zwangspause gemacht werden. Diese 
wird zwar gemacht, wenn man irsnd_send_data() mit flags = 5 aufruft, 
aber nicht, wenn man 6x hintereinander irsnd_send_data() mit flags = 0 
aufruft. Die von Cajus gemachten Verbesserungsvorschläge für SAMSUNG32 
werde ich in den Source einarbeiten, Du kannst dies ja auch schonmal 
parallel bei Dir machen.

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> muss da wohl jeweils eine Zwangspause gemacht werden. Diese
> wird zwar gemacht, wenn man irsnd_send_data() mit flags = 5 aufruft,
> aber nicht, wenn man 6x hintereinander irsnd_send_data() mit flags = 0
> aufruft.

da muss ein Verständnisproblem vorliegen

du schreibst die Zwangspause wird benötigt und gemacht für
"irsnd_send_data() mit flags = 5"

wenns so wäre warum dann nur 5 Weiterschaltungen und nicht 6 ?

also 1 +5 Wiederholungen

"6x hintereinander irsnd_send_data() mit flags = 0"
hab ich nicht versucht, also kann deine Erklärung nicht passen ???

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> wenns so wäre warum dann nur 5 Weiterschaltungen und nicht 6 ?

Das weiß ich nicht. Vielleicht akzeptiert das Gerät nicht mehr als 5 
Wiederholungen in so kurzer Zeit?

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Vielleicht akzeptiert das Gerät nicht mehr als 5
> Wiederholungen in so kurzer Zeit?

das wäre ja leicht zu testen :-) mach ich am WE

mit FLAGS 1, FLAGS 2, FLAGS 3, FLAGS 4, FLAGS 5, FLAGS 6,

müsste ja 2, 3, 4, 5, 6, 7 Weiterschaltungen geben :-)

von Cajus H. (cajush)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

>> ...Samsung LCD-TV, die beide das SAMSUNG32 Protokoll verwenden.
>> Das von IRSND generierte Signal wird vom TV nur erkannt, wenn
>> meine FB in geringem Abstand vor dem TV mit Zielfernrohr auf das TV
>> Gerät gerichtet wird. Außerdem muss man jede Taste ziemlich lange
>> drücken, bis diese vom TV aktzeptiert wird.

> Könnte das eine falsche Modulationsfrequenz sein? Die schlechte
> Reichweite spricht jedenfalls dafür. Kannst Du Modulationsfrequenz bei
> den Original-Fernbedienungen mit einem Scope (o.ä.) messen? Die 38kHz
> sind beim Samsung32-Protokoll nur "geraten", da ich darüber keine Daten
> im Internet finden konnte.

nein, ich habe die Frequenzen überprüft. 37.3 und 37.5 kHz. Das scheint 
mir innerhalb der Toleranz zu sein. Außerdem ist das Problem nach der 
Timing-Änderung wesentlich besser was ebenfalls gegen eine falsche 
Modulationsfrequenz spricht.
Ich habe übrigens auch die Wellenlängen der IR-LEDs der original-FBs mit 
der von mir verwendeten LED verglichen. Diese sind ebenfalls identisch.

Die vorgeschlagenen Änderungen werde ich vermutlich in Kürze im 
SVN-Repository wiederfinden, dann werden sie auch den Weg in meine 
Sourcen finden.

Hast Du noch vor die Zwangspause bei Befehlen gleichen Typs einzubauen? 
(bei flags=0). Wäre ganz schick, insbesondere bei Macros für 
Sendernummern ("2","3","Enter")

Viele Grüße
Cajus

von DK3SB (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich versuche hier gerade ein kleines Heimproblem zu beheben: Bisher 
musste ich TV und Reciever hier immer mit 2 Fernbedienungen einschalten, 
die Fernbedienung für den Reciever brauchte ich danach aber nie wieder, 
also ging es mir auf den Geist immer 2 FBs rumliegen zu haben. Also 
dachte ich mir: Wäre es nicht prima, das durch eine unauffällige Kiste 
zu ersetzen, die auf das Power-On via Infrarot von der TV-Remote wartet 
und daraufhin das Power-On für den Reciever sendet.

Also genau das mit IRMP und IRSND realisiert, auf einen Formfaktor 
verkleinert, in dem es bequem in ein kleines Digitalthermometer passt, 
was nun in der Linie Sofa -> TV steht. Geht prima. Nach jetzt ca. 6 
Wochen kam mir das Problem der zu geringen Batterielaufzeit in den Sinn 
- ich musste jetzt das zweite mal die 2 x AAA-Zellen wechseln.
Der AtTiny45 den ich benutze ist bereits auf einen SleepMode 
eingestellt, den er immer betritt, wenn nix zu tun ist (was etwa 90% der 
Zeit der Fall ist schätze ich), aufwachen tut er durch die ISR vom 
Timer, in dem dann IRSND und IRMP aufgerufen werden. Das ging auch 
super, es verbleibt aber die Dauerhafte Stromaufnahme des TSOP, der an 
Vcc hängt. Also wollte ich diesen nun über einen Portpin schaltbar 
machen. Also vor der IRMP-ISR das Ding anschalten, danach wieder aus, 
keine Magie.

Nun wird allerdings nichts mehr deokdiert, das Umschalten des Portpins 
kann ich mit dem Oszi nachvollziehen, geht, ist etwa 10% der Zeit an, 
den Rest aus. Ich habe den Vcc-Pin des TSOP einfach an den µC gelötet 
und schalte so, wenn er an sein soll, den Pin Hi.

Am Data-Ausgang ist nun aber nix zu messen - könnt ihr mir das erklären? 
Brauch der TSOP eine Art "Einschwingzeit", ist mein Vorgehen komplett 
unangebracht? Was gibts für ne bessere Idee, das Ding auf Stromsparen zu 
optimieren?

mfg,
Stefan

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
DK3SB schrieb:
> Am Data-Ausgang ist nun aber nix zu messen - könnt ihr mir das erklären?
> Brauch der TSOP eine Art "Einschwingzeit", [...]

Ja, so wird es wohl sein. Der TSOP empfängt dann ja auch keine 
vollständigen Bits mehr, wenn er nur für einen Bruchteil der Zeit, die 
ein Bit braucht, eingeschaltet ist.

> Was gibts für ne bessere Idee, das Ding auf Stromsparen zu optimieren?

Welchen TSOP benutzt Du? Die neueren TSOP312xx (3mA?) sollen etwas 
sparsamer sein als die TSOP17xx (5mA).

Alternative wäre eine Selbstbau-FB, die mit IRMP/IRSND arbeitet, siehe 
z.B.

http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP

Das Ding kommt mit einigen µA aus. Wahrscheinlich reichen Dir die aber 
die 5 Tasten nicht, hier könnte man evtl. eine Tastatur-Matrix 
verwenden.

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
DK3SB schrieb:
> Der AtTiny45 den ich benutze ist bereits auf einen SleepMode
> eingestellt, den er immer betritt, wenn nix zu tun ist (was etwa 90% der
> Zeit der Fall ist schätze ich), aufwachen tut er durch die ISR vom
> Timer, in dem dann IRSND und IRMP aufgerufen werden. Das ging auch
> super, es verbleibt aber die Dauerhafte Stromaufnahme des TSOP

ich persönlich würde den TINY nicht per Timer aufwachen lassen sondern 
vom Pegelwechsel des TSOP, die Zeit für das Tinyaufwachen dürfte noch 
reichen um den Befehl auszuwerten, das senkt schon mal den 
Stromverbrauch, aber jeder IR Befehl weckt natürlich ! den Tiny ! also 
um dickere Akkus und Wechsel wirst du nicht rumkommen ! ich staune nur 
das der neue mit 3mA weniger verbrauchen soll, meine alten TSOP 17 haben 
nur um 1mA gebraucht

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:ich staune nur
> das der neue mit 3mA weniger verbrauchen soll, meine alten TSOP 17 haben
> nur um 1mA gebraucht

Meine TSOP auch, aber im Datenblatt stehen halt die 5mA bzw. 3mA - warum 
auch immer.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Das Ding kommt mit einigen µA aus. Wahrscheinlich reichen Dir die aber
> die 5 Tasten nicht, hier könnte man evtl. eine Tastatur-Matrix
> verwenden.

genau ! ich grübel gerade, irgendwo hatte ich eine Tastenmatrix gesehen 
die mit einem ! Pinchange Interrupt geweckt wird, da darf dann auch der 
TSOP abgeschaltet sein ! und trotzdem ist eine Tastenmatrix mit viel 
mehr ! Tasten möglich, zum Anlernen weckt man den auf kann bei IR 
Empfang in anlernen gehen, sonst nach aufwecken nur senden ! da braucht 
der TSOP dann keinen Strom saugen, trotzdem scheint mir dazu auch der 
168 von den Port unterdimensioniert wenn ich mal durchzähle 48-60 Tasten 
keine Seltenheit, heisst 8x8 Matrix und so viele Ports + LEDs sind 
selten frei, sieht eher nach mega32 bis 1284(p)aus, dafür auch im DIL40 
zu bekommen

PS. Senden 18mA ? (für Reichweite sollte man die 100mA mindestens 
ausnutzen, für schwache Batterien eher etwas drüber, damit das auch noch 
geht wenn der Batteriepegel sinkt) ich hab den Rv für die IR Sende Diode 
auf 22 Ohm verkleinert und für bessere Winkel lieber 2 IR Dioden in 
Reihe gelegt, meine 3mm Dioden finde ich recht schmal im Abstrahlwinkel, 
kann aber am Steckbrettaufbau liegen, nach unten ist das Brett der 
Begrenzer, optimal sitzen ja Dioden so das sie vorne über die Kante 
stehen und in keine Richtug eingeschränkt werden, aber mehr als 50° 
Dioden fand ich nicht in 3mm, als 5mm geht mehr, will aber optisch zu 
den LED (3mm) kompatibel bleiben

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> genau ! ich grübel gerade, irgendwo hatte ich eine Tastenmatrix gesehen
> die mit einem ! Pinchange Interrupt geweckt wird, da darf dann auch der
> TSOP abgeschaltet sein !

Klar.

> PS. Senden 18mA ?

Ja, aber es sind 18mA im Mittel. Der max. Strom durch die Sendediode ist 
natürlich höher, nämlich fast 100mA. Dies liegt zum einen an der 
Modulation mit einem Puls-Pausen-Verhältnis 50:50, andererseits an den 
Pausen des jeweiligen IR-Protokolls. Der mittlere Strom von 18mA ist 
genau das, was die IR-Sendediode (im Mittel) verkraftet - bei max. 
Sendeleistung. Das passt also ganz gut so.

von Stefan Biereigel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke für eure Anregungen, ein paar kleine Kommentare dazu:

1. Die 5mA Verbrauch für TSOP 1738 sind quatsch, im Datenblatt steht 
dieser Wert in der Tabelle der "Absolute Maxmium Ratings", bei den 
"Normal Conditions" stehen da ~1mA, und das ist auch der reelle 
Verbrauch.

2. Eine Neue lernfähige Fernbedienung zu bauen wäre für meine Anwendung 
quatsch. Ich möchte meine Samsung-Remote benutzen, sie hat alle 
Funktionen und sieht dazu noch gut aus. Das war der Grund, eine solche 
"Verlängerung" für die zweite Fernbedienung zu bauen, und was anderes 
möchte ich auch garnicht. Das Thermometer sieht dekorativ aus, nur war 
halt das Batteriewechseln aller 2-3 Wochen mir nun aufgefallen.
Darum suche ich auch nach Stromsparmaßnahmen für den TSOP - gibt es 
eventuell einen speziell auf Stromverbrauchsminimierung ausgelegten 
Ersatz?

Abschalten kann man ihn wohl nicht, ich sehe in der kurzen On-Zeit kein 
Logisch-Hi am DATA-Out, wo es ja eigentlich sein müsste, das kommt erst 
später.

Aber nunja:

3. Ein Aufwachen auf die Pegelwechsel funktioniert hier nicht, da IRMP 
in festen Zeitintervallen aufgerufen werden will. Was man machen könnte, 
nach einer Art "Timeout" den Interrupt zu deaktivieren und auf externe 
Pegelwechsel zu triggern, wodurch er wieder aktiviert wird. Aber wie 
schon gesagt ist der AtTiny nicht mein Hauptstromverbrauch im Moment, er 
schläft etwa 90% der Zeit. Der TSOP der aber nicht abgeschalten wird 
braucht seine 1-2mA Dauerstrom und zieht die Batterie leer, dagegen kann 
ich nix machen, denke ich mittlerweile.

Danke trotzdem euch allen für eure Vorschläge, falls noch jemand was 
hat: Bin ich immer offen für!

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Stefan Biereigel schrieb:
> 2. Eine Neue lernfähige Fernbedienung zu bauen wäre für meine Anwendung
> quatsch. Ich möchte meine Samsung-Remote benutzen

also Quatsch finde ich zu hart, why not ?
für mich wäre Selbstbau einer neuen in dem Grund begründet da alle meine 
lerndenden zu wenig Bittiefe haben und ich eine mit 433 Mhz will, habe 
eina alte die nach 1/4 Funktionen programiert voll meldet ! kaufe eine 
Neue (10 Jahre später) in der Hoffnung das die mehr Speicher hat und ich 
hab noch nicht mal alle Tasten 2er ! FB drin meldet die neue auch voll !
ich glaub da muss man selber bauen (*grummel grummel, gibt nix 
vernüftiges zu kaufen mit anlernen Bittiefe und Funk und Reichweite !)

> Der TSOP der aber nicht abgeschalten wird
> braucht seine 1-2mA Dauerstrom und zieht die Batterie leer, dagegen kann
> ich nix machen, denke ich mittlerweile.

sag ich doch, also doch richtige FB selber bauen

von Stefan Biereigel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gut, da gehen wohl unsere Vorstellungen etwas auseinander, schätze ich. 
Ich möchte gern die bestehende FB weiternutzen, sie hat ja echt nur EINE 
Taste nicht, auch schon dran gedacht habe ich, meinen µC einfach in die 
FB einzubauen, so könnte ich auf Taste reagieren (Ext. Int) und müsste 
keinen Strom verbrauchen wenn ich nix machen will ... Aber das ist alles 
eher unpraktikabel. Zur großen Not muss ich halt mit dem Batteriewechsel 
leben, aber zuerstmal versuche ich noch den Attiny45-20 gegen den 
AtTiny45-10 zu tauschen, der soll in der Spannung variabler sein (und 
weiter runter gehen) - mal sehen wie es damit aussieht.

Zum Thema Universal-FBs, auch wenn hier etwas OT:

Wenn man da Geld reinsteckt und nicht das 5€-Modell von [hier Discounter 
einsetzen] kauft, kann man für etwas mehr schon nen gutes Teil haben. 
Meine Chamäleon(s) die ich in der Vergangenheit nutzte konnten alle mehr 
lernen als ich lernen wollte, damals gabs noch: VCR, DVD, SAT, TV, 
Radio, PC

Jetzt hat sich das gesamte Geraffel auf TV + Reciever gekürzt, da wollt 
ich eigentlich dass eine FB reicht.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Stefan Biereigel schrieb:
> auch schon dran gedacht habe ich, meinen µC einfach in die
> FB einzubauen, so könnte ich auf Taste reagieren (Ext. Int) und müsste
> keinen Strom verbrauchen wenn ich nix machen will

das würde ich in deinem Fall für am sinnvollsten halten, weil ein immer 
an TSOP einfach unsinnig ist und  immer wieder den Tiny per Timer 
aufwachen lassen genauso, also kleiner Tiny mit Int an Taste und eigener 
IR Sendediode

> Zur großen Not muss ich halt mit dem Batteriewechsel
> leben, aber zuerstmal versuche ich noch den Attiny45-20 gegen den
> AtTiny45-10 zu tauschen, der soll in der Spannung variabler sein (und
> weiter runter gehen) - mal sehen wie es damit aussieht.

oder so !

> Zum Thema Universal-FBs, auch wenn hier etwas OT:
> Wenn man da Geld reinsteckt und nicht das 5€-Modell von [hier Discounter
> einsetzen] kauft, kann man für etwas mehr schon nen gutes Teil haben.

nein und immer wieder nein, ich hab alle universell von 100-400 € 
ausprobiert, die letzte Logitech Harmony ? 350€ so ein Sche*ss

anlernen ? ist nicht -> Codes nur über Logi Server download und wenn der 
mal abgeschaltet wird hat man 350 € Elektronikschrott !
Reichweite, kaum das ich das Wohnzimmer verlassen hatte war Ende mit 
Funk, das konnte und kann die 10 Jahre alte viel besser, Anlernen und 
Reichweite !
am grausamsten war die Programmierung, man muss erst mal alle Geräte und 
FBs vorstellen, dann darf man, muss man Macros programmieren, wer nur 
mal testeise eine programmiert kann später nicht mehr nachrüsten, alles 
auf Reset und dann alle Geräte und Macros neu anlernen, ja so eine 
Schrottprogrammierung und Menüs gibt es wirklich für 350 €

kein Wunder das mein Modell auch schon eine Rückgabe war, ich habs auch 
wieder zurückgegeben, für das Geld erwarte ich mehr, mehr Reichweite, 
mehr Funktionalität und mehr Komfort

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Klar

Frage an den Autor,

bin grad dabei die IR SND einer größeren Funktionalität zuzuführen

würde also gerne irmp_data erweitern mit Tasten-Name und Geräte-Name

2 Möglichkeiten

1 die schlechtere, ich erweitere das Feld, inkompatibel !
2 die bessere ? und da bin ich als nicht gelernter Progger unsicher

ich baue ein neues Array wo irmp_data drin steckt + G-Name und T-Name

hast du dazu ne Idee ?

oder noch besser einen Vorschlag ?

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
und das möglichst platzsparend ?

also Idee
1.
STRUCT {
   g-name char[8];
   t-name char[8];
   IRMP_DATA;
}uni;


ist schon mal doof, verschwendet Platz

Idee
2.
STRUCT {
   t-name char[8];
   IRMP_DATA;
}g-name;

spart Platz, nur wie greife ich von aussen auf G-Name zu ?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
jar schrieb:

> 1.
> STRUCT {
>    g-name char[8];
>    t-name char[8];
>    IRMP_DATA;
> }uni;

Das ist die einzig vernünftige Möglichkeit, jedoch sind in den obigen 
Zeilen einige syntaktische Fehler drin :-)

Wenn schon, dann so:
#define MAXDEVICENAMELEN    8
#define MAXKEYNAMELEN       8

typedef struct
{
   char      devicename[MAXDEVICENAMELEN + 1];
   char      keyname[MAXKEYNAMELEN + 1];
   IRMP_DATA irmp_data;
} EXT_IRMP_DATA;

Dann kann man zum Beispiel folgendermaßen drauf zugreifen:
  EXT_IRMP_DATA  ext;
  ...
  strcpy (ext.devicename, "TV");
  strcpy (ext.keyname, "Volume+");
  ext.irmp_data.protcol = IRMP_SAMSUNG_PROTOCOL;
  ext.irmp_data.address = 0x0012;
  ext.irmp_data.command = 0x0034;
  ext.irmp_data.flags   = 0;


Das Erweitern auf ein Array (Du willst bestimmt mehr als eine Taste) 
überlasse ich Dir :-)

Gruß,

Frank

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
danke, aber da muss ich noch mal drüber schlafen

ich weigere mich für jedes Gerät mehrfach den Namensplatz zu 
verschwenden, so üppig ist EEPROM Platz nicht im Atmel, da hat man ja 
mehr Platz im flash :-)

evt. nehme ich statt NAME 8+1 x-mal f. jede Taste und jedes Gerät (sieht 
irgendwie nach linearen 2-dimensionalen Array aus)

n-Tasten * m-Geräte egal ob Gerät x die Menge an Tasten von Gerät y hat

ein u_int8 für 256 Geräte und weise den Namen in einer table zu

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

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