FB Betty in FHEM einbinden

[KölnSolar]

Hi Telekatz,
hab jetzt auch mal die 2. FB in Betrieb genommen. Das Synchronisieren der Zeit hat gut geklappt.
Leider tut sich auch dort nichts beim FS20-Empfang. Hatte gehofft, dass das evtl. an der FB liegt 

Da ich dort nicht weiterkam, hab ich mich dann doch wider dem B&O-Protokoll gewidmet. Ich hab ein LIRC-File erstellt, welches passen sollte. Wie Du schon sagtest: klappt nicht. Man kriegt wohl scheinbar max. ca. 100kHz hin. Warum ist mir leider immer noch nicht klar. Ich hab zwar einiges investiert, um den Programmablauf zu verstehen, insbesondere die Timersteuerung und die Interrupts, aber das ist echt müüüühselig. Irgendwie fehlt mir da noch der Zusammenhang zwischen key_press, lirc_send, RunIR, welches den timer1 startet und dann ? Wird dann die FIQ_Routine getriggered, die dann den infraredirq aufruft, die wiederum die LIRC_Encode aufruft ?

Im Augenblick hänge ich an hi_ u. lo_border, die ja durch den Parameter duty_cycle im LIRC-file gesetzt werden. Daran hängt ja wiederum der Wert für das match register T1MR0. Kannst Du mir vielleicht in wenigen Worten beschreiben, was die 3 Parameter bedeuten/bewirken ?
Außerdem hab ich noch nicht so ganz verstanden, warum der Timer1 nicht in der VIC eingetragen wird. Heißt das nicht, dass die VICs alle eine höhere Priorität haben ? Hintergrund der Frage ist, dass ich auch ohne Umbau auf PWM gerne testen würde, ob das senden grundsätzlich funktioniert, also erst einmal alles entfernen würde, was Zeit kostet bzw. behindert oder vorhandenes beschleunigen würde. Dann hätte ich auch den kompletten Ablauf verstanden. Danach würd ich mich dann an den Umbau auf PWM geben. Ist dieser Gedanke machbar oder einfach nur Blödsinn eines µC-Dummies ?
Grüße Markus

[Telekatz]

Die IR Encoder sind alle so aufgebaut, dass sie folgende Funktionen bereitstellen:
xx_Encode
xx_Init
xx_Send
xx_Repeate
xx_Stop

xx_Init wird aufgerufen, wenn der Fernbedienungscode gewechselt wird und initialisiert den Encoder
xx_Send wird aufgerufen, nachdem eine Taste gedrückt wird und läd dann z.B. den Encoder mit dem entsprechenden Code für diese Taste.
xx_Repeate wird periodisch aufgerufen, solange die Taste gedrückt wird.
xx_Stop wird aufgerufen, wenn die Taste losgelassen wird.

In xx_Send oder xx_Repeat wir mit runIR der Timer1 Interrupt aktiviert.

T1MR0 ist das Timer Counter 1 Match Register. Erreicht Timer1 diesen Wert, wird der Interrupt ausgelöst. Bei jedem Interrupt wird die Variable c_cnt hochgezählt. Solange c_cnt kleiner hi_boarder ist, bleibt die IR Diode eingeschaltet falls ein Träger erzeugt werden soll. Danach bleibt die IR Diode ausgeschaltet bis c_cnt gleich lo_border ist. Dann ist eine Periode vorbei und c_cnt wird wieder auf 0 gesetzt.

Die Frequenz des Trägers kann man ausrechnen mit: f_Träger =  PCLK / (tval * lo_border)
Am Beispiel von RC5: f_Träger = 15MHz / (139 * 3) = 35,97kHz

Für die duty_cycle gilt: duty_cycle = hi_border / lo_border
Am Beispiel von RC5: duty_cycle = 1 / 3 = 33,3%

Die Anzahl der Perioden wird in b_len gezählt. Über die Variable cycles wird vorgegeben, wieviele Perioden und damit wie lange ein Signal gesendet werden soll. Ist die gewünschte Anzahl an Perioden erreicht, wird in xx_Encode die Anzahl der Perioden für das nächste Signal und ob der Träger gesendet werden soll ermittelt.

Für das Verständnis der IR Funktion würde ich empfehlen, mit einem einfacheren Encoder wie RC5 anzufangen. Der Ablauf ist bei allen IR Encodern gleich.

Der Timer1 Interrupt steht nicht im VIC, weil er im FIQ behandelt wird. Der hat schon die höchste Priorität.

[KölnSolar]

Danke für Deine Mühe. Jetzt fehlt mir nur noch die Stelle, wo die FIQ_Adresse gesetzt wird. spielt aber keine Rolle, wird schon irgendwo gesetzt werden 
Mit Deiner Formel müsste ich bei lo_border = 3 tval = 11 setzen und hätte 454545 Hz. Das ist doch bestimmt zu einfach gedacht, oder ?
Duty cycle ist ja eigentlich das Verhältnis des Pulses zum Space. Der liegt bei einem 0-bit bei ca. 2% und beim pre-bit sogar bei nur 1,3%. Also eher tval =1 und lo_border =33, also duty cycle 3% ?
Ich probiers mal aus...

[Telekatz]

Duty cycle ist ja eigentlich das Verhältnis des Pulses zum Space. Der liegt bei einem 0-bit bei ca. 2% und beim pre-bit sogar bei nur 1,3%. Also eher tval =1 und lo_border =33, also duty cycle 3% ?

Nein, duty_cycle hat nichts mit dem Verhältnis Pulse zu Space zu tun. Duty_cycle betrifft den Träger während des Pulses.

[KölnSolar]

Hmm, Träger während des Pulses  bitte für dummies...

Beide Tests fehlgeschlagen  Hab auch mal probiert die Taktrate auf 60/30 höher zu setzen. War aber auch nix    Betty starb 

Ich häng mal das LIRC-file dran. Passend hab ich die code.c erweitert, eine Anpassung in der LIRC_Init für hi_ u. lo_border, sowie in der LIRC_Encode bei LIRC_DATA_S eine Anpassung, weil nicht einfach 0 u. 1 gesendet wird, sondern, wenn sich der bit-wert gegenüber dem vorhergehenden nicht ändert, eine besondere Space-Pulsweite zu berücksichtigen ist.

Any ideas ? Was hab ich überfordert, dass die Betty den Geist aufgibt ?
Edit: Einen Fehler in meinem zusätzlichen Code oder des LIRC-Files kann ich insofern ausschließen, dass ich die Betty am Leben erhalte, wenn ich die Frequenz im LIRC-File deutlich absenke(um die 100kHz). Es ist also irgendein "Timing"-Problem.
Zum Aufbau des IR-Protokolls: Die B&O hat immer einen Sendepuls von 200, der Spacepuls variiert. Es werden 4 unterschiedliche Startbits gesendet. Die hab ich im header(1.), pre_data(2.), pre(3.) u. das letzte neben den Daten in bits. Nach den 17 Datenbits(16 + 4. start bit) kommt dann noch ein post_bit und ein abschließender Puls als ptrail.

[Telekatz]

Hmm, Träger während des Pulses  bitte für dummies...

Du sendest einen Puls mit 200 µs Länge gefolgt von einem Space variabler Länge. Während des Pulses ist die IR Diode jedoch nicht ständig an sondern wird mit 455kHz moduliert (der Trägerfrequenz). Der 200 µs Puls besteht nicht aus einem langen Puls, sondern aus 91 kurzen Pulsen. Und das Verhältnis aus IR Dioden an und aus während dieser 200 µs ist die duty_cycle.

Edit: Einen Fehler in meinem zusätzlichen Code oder des LIRC-Files kann ich insofern ausschließen, dass ich die Betty am Leben erhalte, wenn ich die Frequenz im LIRC-File deutlich absenke(um die 100kHz). Es ist also irgendein "Timing"-Problem.

Du kannst jetzt noch im lirc File duty cycle auf 50 stellen, dann könntest du um die 150kHz schaffen. Mehr geht nicht mit Software PWM so wie es jetzt im Timer1 Interrupt implementiert ist.

[KölnSolar]

ich beginne mehr zu verstehen ...
Ist es nur eine Schätzung aufgrund von Erfahrungswerten, dass nicht mehr als 150kHz drin sind oder lässt sich das irgendwie (einfach)berechnen/abschätzen ?

Hab mich jetzt mit PWM weiter auseinandergesetzt und könnte mich an den Einbau wagen. Sieht ja erstmal gar nicht so schlimm aus  Als Basis nähme ich den PWM aus der Soundsteuerung, natürlich angepasst für channel 5. Da es ja nur einen Counter für alle PWM channels gibt: siehst Du später ein Problem darin, dass sound und IR PWM-gesteuert werden ? Auch, wenn ich jetzt den Anwendungsfall nicht sehe, die könnten sich ja in die Quere kommen ? Fängt ja schon mit dem prescaler an, der für sound auf 7 gesetzt wurde. Grund ? Gibt es Performance- oder sonstige Gründe den Prescaler zu setzen oder aber eher nicht setzen ? Was würdest Du mit Deiner Erfahrung mit dem Prescaler für IR und speziell dem B&O-Protokoll treiben ? Auf die minimalste Pulslänge setzen ?

Des weiteren dachte ich mir, ich beschreibe das PWMMR5 immer mit der nächsten Pulslänge oder wäre hier ähnlich wie beim timer ein "Basis-puls" besser und die Programmlogik kümmert sich um die Pulslängen ?

Muss ich mich mit double-edge auseinandersetzen oder kann ich mir das sparen ?

Und schließlich verwirrt mich die Doku(ich nutze UM10114) etwas. Es wird eingangs zum PWM beschrieben, man könne high, low, oder toggle beim match setzen. Nur: Ich finde kein(e) Register, wo ich genau diesen Willen kundtun könnte  Muss man also für jede P/S-Kombination PWMMMR0 auf P+S setzen und PWMMR5 auf S ?

Freu mich wie immer über Deine Hilfe...

[Telekatz]

ich beginne mehr zu verstehen ...
Ist es nur eine Schätzung aufgrund von Erfahrungswerten, dass nicht mehr als 150kHz drin sind oder lässt sich das irgendwie (einfach)berechnen/abschätzen ?

Das ist eine Schätzung aufgrund deiner LIRC Konfiguration, bei der 100kHz als maximale Frequenz ermittelt hattest.

Hab mich jetzt mit PWM weiter auseinandergesetzt und könnte mich an den Einbau wagen. Sieht ja erstmal gar nicht so schlimm aus  Als Basis nähme ich den PWM aus der Soundsteuerung, natürlich angepasst für channel 5. Da es ja nur einen Counter für alle PWM channels gibt: siehst Du später ein Problem darin, dass sound und IR PWM-gesteuert werden ? Auch, wenn ich jetzt den Anwendungsfall nicht sehe, die könnten sich ja in die Quere kommen ? Fängt ja schon mit dem prescaler an, der für sound auf 7 gesetzt wurde. Grund ? Gibt es Performance- oder sonstige Gründe den Prescaler zu setzen oder aber eher nicht setzen ? Was würdest Du mit Deiner Erfahrung mit dem Prescaler für IR und speziell dem B&O-Protokoll treiben ? Auf die minimalste Pulslänge setzen ?

Sound und IR wird nicht gleichzeitig funktionieren.
PWMR0 muss passend zur PWM Auflösung gewählt werden. Zusammen mit Prescaler muss das dann die gewünschte Frequenz ergeben. Beim Sound PWM sind das dann etwa 4,4kHz.
Für IR wirst du keinen Prescaler benötigen um auf 455kHZ zu kommen. Eingestellt werden die 455kHz über PWMR0 (müsste dann 33 sein)

Des weiteren dachte ich mir, ich beschreibe das PWMMR5 immer mit der nächsten Pulslänge oder wäre hier ähnlich wie beim timer ein "Basis-puls" besser und die Programmlogik kümmert sich um die Pulslängen ?

Muss ich mich mit double-edge auseinandersetzen oder kann ich mir das sparen ?

Und schließlich verwirrt mich die Doku(ich nutze UM10114) etwas. Es wird eingangs zum PWM beschrieben, man könne high, low, oder toggle beim match setzen. Nur: Ich finde kein(e) Register, wo ich genau diesen Willen kundtun könnte  Muss man also für jede P/S-Kombination PWMMMR0 auf P+S setzen und PWMMR5 auf S ?

Über PWMMR5 wird die duty cycle der Trägerfrequenz eingestellt. Für die Puls und Pausenlängen des IR Signals ist ist weiterhin Timer1 zuständig. Nur muss hier der Timer1 Interrupt nicht mehr so oft aufgerufen werden. PWM kümmert sich nur um die Trägerfrequenz und benötigt dazu auch keinen Interrupt.

[KölnSolar]

jaja, die Trägerfrequenz. Die hatte ich in meinem Post völlig vergessen, was mir dann bei der Umsetzung klar geworden war. 

Über PWMMR5 wird die duty cycle der Trägerfrequenz eingestellt.

ist mir also soweit klar. Aber warum brauche ich noch den timer 1? Bei den Spaces muss ich doch sowieso den pin abschalten und beim nächsten pulse die Trägerfrequenz wieder auf die LED schalten, oder nicht ?

Die richtigen Probleme, die ich hab, sind aber andere  Der ersten Betty hab ich wohl die Diode zerstört    Damit nicht genug. Bis ich mal auf die Idee kam, dass PINSEL1 gesetzt werden muss  Danach blinkte die Diode, aber irgendwie ist alles durcheinander. Sie blinkt rythmisch endlos weiter, trotz coding für stopIR  Fehlt der Aufruf ? Aber das ist nicht alles  Die Hintergrundbeleuchtung spinnt auch. Die wird aber doch über timer0 gesteuert oder etwa nicht ? Wieso funktioniert der nicht mehr richtig, obwohl die Register zwischen timer und PWM doch unterschiedlich sind ?

Testen tu ich über das LIRC-Samsung-Protokoll, was mit timer1 ja einwandfrei funktioniert. Erst, wenn das über PWM funktioniert, versuche ch mich an den 455kHz.

Jetzt nehm ich mal den  sound raus und gucke, ob die Geister sich beruhigen....

Edit: der Sound war es nicht. Ich hatte nach dem Senden den PWMTCR nicht richtig zurückgesetzt  Backlight bleibt aber immer noch aus 
Und jetzt kann ich das erste mal das Senden beobachten. Gefühlt bleibt die Diode viel zu lange an 

[KölnSolar]

So, neue Diode angelötet. Geht selbst für mich Löt-Dummy relativ problemlos. Die 2. Betty ist also wieder geheilt.

Um die Probleme mit der Hintergrundbeleuchtung und dem Sound abzustellen, habe ich das Ganze etwas entgegen der üblichen Ablaufstruktur nun direkt in den LIRC_Send bzw. LIRC_Stop eingebaut. irIRQ und FIQ_Routine passend umgebaut, den timer1 nicht gestartet(kein runIR())

Der Output der Diode sieht "richtiger" aus, schaltet aber leider nicht auf 38kHz 

Bei 433kHz scheint ebenfalls der Erfolg auszubleiben. Die Diode kommt nicht zur Ruhe 

So sieht der Code in LIRC_Send aus:

Code Auswählen Erweitern

PWMTCR = 0x00;
PINSEL1 |=  (1 << (2 * (IR_PWM - 16))); // Pin function PWM5
PWMPCR  |=  (1 << 13); // enable output f. pwm5
PWMTC  = 0;
PWMPC  = 0;
PWMPR  = 0; //precale register initialize
PWMMCR = 0x03; //match MR0: reset counter and interrupt; no further action
PWMMR2 = 0;
PWMMR0 = T1MR0;
PWMMR5 = PWMMR0 / lo_border * hi_border; // high cycles for carrier frequence
PWMLER = 0x25;
PWMTCR = 0x0b;
PWMTCR &= (0<<1);


das on-off-keying passiert dann am Ende der LIRC_Encode mit

Code Auswählen Erweitern

if(mod_enable) PWMPCR |= (1<<13);
else  PWMPCR &= ~(1<<13);


Da ich ja auch C-Amateur bin verstehe ich auch nicht warum PWMTCR = 0x09;
nach   PWMTCR = 0x0b; funktioniert,    PWMTCR   &= (0<<1);  aber nicht  Mache ich da generell beim setzen u. löschen von Bits etwas falsch ?

[Per]

@all: 1 download für die IT-Funktionalität ist arg wenig  Mag denn neben der Unterstützung von telekatz niemand mitmachen ?

Meinerseits gibt es dafür zwei Gründe:
1. habe ich den Thread erst heute gefunden
2. wäre ich euch keine Hilfe
Aber ich habe den Thread aboniert und bin schonmal extrem gespannt!

[Telekatz]

Du brauchst weiterhin den Timer1, um die Puls und Pausen Zeiten auszugeben. LIRC_Encode wird sonst nicht aufgerufen. T1MR0 wird dann auf die entsprechenden Zeiten geladen.

Code Auswählen Erweitern

PWMMR0 = T1MR0;
PWMMR0 muss auf die Trägerfrequenz eingestellt werden. T1MR0 ist dabei nicht der korrekte Wert. Der korrekte Wert ergibt sich aus 15MHz/Trägerfrequenz.

Da ich ja auch C-Amateur bin verstehe ich auch nicht warum PWMTCR = 0x09;
nach   PWMTCR = 0x0b; funktioniert,    PWMTCR   &= (0<<1);  aber nicht  Mache ich da generell beim setzen u. löschen von Bits etwas falsch ?

Eine 0 zu shiften bringt nicht, das Ergebnis ist immer 0. Und ein AND mit 0 ist auch immer 0.

Korrekterweise schiebt man eine 1 an die richtige Stelle, invertiert alle Bits und verknüpft dann mit AND:

Code Auswählen Erweitern

PWMTCR &= ~(1<<1)

   

[KölnSolar]

Und ein AND mit 0 ist auch immer 0.

Das war ja auch beabsichtigt. Funktioniert aber nicht, während die von Dir gepostete Syntax bestens funktioniert. 
Durch Deine Beharrlichkeit mit timer1 hab ich dann noch einen Fehler gefunden. Ich hatte beim Umbau nach LIRC_Send einen Fehler gemacht. Es muss natürlich heißen

Code Auswählen Erweitern

PWMMR0 = T1MR0 * lo_border;
PWMMR5 = T1MR0 * hi_border;
Und dann funktioniert das Samsung-Protokoll  Bis hierhin viel gelernt über Boop, Betty, C....aber das war ja nicht das Ziel. Nur leider funktioniert so das B&O immer noch nicht. 155kHz laufen durch, 205kHz aber schon nicht mehr 

Und bevor ich das poste und mir den Rüffel einhandele, dass ich ja den IRQ beim PWM rausnehmen und den timer1 wieder benutzen soll, habe ich dies gemacht. Im "Standard" keine Veränderung  Aber Ziel ist ja auch den IRQ seltener auslösen zu lassen. Das hat mir aber mal wieder enorme Schwierigkeiten bereitet  Ich hatte timer1 auf 20 Zyklen gesetzt, was in keiner Konstellation funktionierte  Bis ich auf den Gedanken kam es einfach mal nur mit 2 Zyklen zu probieren. Kein Fehler ! Weiter getestet mit 5, dann mit 10. Ab 10 ging wieder nichts mehr. Gibt's eine Erklärung dafür, dass man den timer nicht höher setzen kann ?
Mittlerweile hab ich mir dann die genauen Zeitenberechnungen angesehen und bestmöglich auf das B&O-Protokoll eingestellt: Frequenz im Lirc-File auf 450000, damit auch 33 Zyklen errechnet werden. Den timer1 auf den Faktor 4(Interrupt nach 132 Zyklen) eingestellt, so dass eine Abweichung der Pulsdauern von ca. 1% entsteht. Samsung funktioniert so einwandfrei. Aber leider geht bei der B&O nix. Mir gehen jetzt die Ideen aus, was ich noch verändern könnte  Ob es an der Diode liegt ? zu schwach, falsche Wellenlänge, doch noch Fehler im Protokoll ......

Da ich da nicht weiterkomme hab ich mir mal Gedanken über die weiteren Teile gemacht, also Scart- u. TAE-Adapter.  Den Scart müsste man doch fast als Betty-CUL mit eingeschränkter Funktionalität(nur 8kB flash) umbauen können... Im ersten Schritt scheitert es natürlich mal wieder an der Toolchain    wird ich wohl mal den SDCC installieren...

[szoller]

Möchte auch nur kurz Interesse bekunden, auch wenn ich inhaltlich eher Bahnhof und Abfahrt verstehe, aber ich habe wieder Hoffnung, meine in einem Moment des Enthusiasmus gekauften Bettys doch noch in Verbindung mit FHEM nutzen zu können 

Wenn's da was brauchbares gibt, wäre ich über einen Wiki-Eintrag sehr dankbar, bin kein Programmierer 

[KölnSolar]

Na wenigstens mal wieder einer, der die verstaubten Bettys nutzen möchte. 

Wiki ? Die Zeit hab ich nicht auch noch  Hier im Thread steckt ja schon ne Menge Info drin: Link aufs Betty-Wiki, Nutzung als Uni-FB für IT-Schalter, womit wir natürlich bei der derzeit funktionierenden Nutzung wären: Uni-FB für IR und IT. Funktioniert bei mir prima !

Ziel sind für mich die Einbindung meiner B&O(IR-Frequenz 455kHz und aktuell auf Eis, weil ich nicht weiterkam) und die Anbindung an FHEM über die aculfw.

Letzteres ist dann meine laufende Arbeit. Ich versuche, vergleichbar der aculfw@ARM, die aculfw(erster Schritt IT senden) zu integrieren. Aufgrund der deutlich geringeren Peripherie dachte ich erst ich versuchs mit dem Scart-Adapter. Das hab ich aber schnell aufgegeben, weil ich keine Debuggingmöglichkeit habe und auch der Flashprozess umständlicher ist. Für die Betty ist es auch recht zäh, weil ich zig neue Themen auf einmal habe: Toolchain(make/makefile/includes), AVR-/ATMega-Prozessoren, aculfw/culfw, CC1100/CC1101, Betty....

Ich hab dabei verschiedene Ansätze verfolgt und immer wieder erfolglos verworfen 

Anders als Telekatz für die aculfw@ARM möchte ich dabei in geringerem Umfang in die Sourcen der aculfw eingreifen. Ich habe die Hoffnung, dass ich das Ganze über Pointer auf die AVR-Register gestalten kann

Im Augenblick scheitere ich aber immer noch an einem fehlerfreien Compile