RC5 Sende Routine

[Janiiix3]

So,

ich habe den PIN mal Togglen lassen.

Wenn ich meinen Timer1 (CTC) laufen habe, komme ich auf ca. 600ms bei
einem _delay_ms(500);

und ohne Timer auf 504ms...

Ist wohl eine blöde Idee diese Verfahren mit dem externen RC Oszillator
zu erledigen?

 

[LotadaC]

Du meinst via. Konfigurationbit?

Dir ist schon klar, daß Dein Controller mehrere Konfigurationsbits hat...
Es soll sogar ganze Konfigurationsregister geben - das von Dir verwendete TCCR1B zum Beispiel ist das Timer and Counter 1 Control Register B, das enthält mehrere Konfigurationsbits...

Ob die LED (gepulst) leuchten oder (dauerhaft) aus sein soll, kann man dann mit den Compare-Output-Mode-Bits des Beinchens festlegen:
COM1x1..0=0b00 -> Portbit gilt, LED ist aus
COM1x1..0=0b10 -> Timer gilt (nichtinvertierender PWM), LED flimmert. (oder 0b11 mit invertierendem PWM)
Es muß also lediglich eines der beiden COM-Bits gesetzt werden, um die LED flimmern zu lassen, sind beide gelöscht, ist die LED entsprechend des Zustandes im PORT-Bit.

Erst mit den WGM-Bits einen passenden Waveform Generation Mode wählen/einstellen, und dann in der geltenden Tabelle die Bits für den gewünschten Compare Output Mode ablesen.

Zum letzten Beitrag: Das liegt nicht allgemein am Timer oder CTC, sondern an der arbeitsweise der Wait-Instruktion und den Interrupts des Timers.
'Ne zeitabhängige Wait-Instruktion kennt Dein Mikrocontroller gar nicht. Man könnte sowas entweder über einen Timer realisieren, oder (wie hier) einfach irgendwelche sinnlosen Instruktionen verwenden, die definiert viele Takte kosten. (Aus einem Wait (10Jahre) bastelt Dir der C-Compiler dann 'n entsprechendes Schleifenkonstrukt, für dessen Abarbeitung der Controller (bei der angeblichen vorgegebenen Taktfrequenz) eben 10 Jahre brauchen würde - wenn diese Schleife allerdings unterbrochen wird, braucht er entsprechend länger.

Wenn Du meinem Vorschlag mit dem PWM zur Bursterzeugung folgst, hast Du da keine IRQs, könntest also die Halbbits auch abWAITen.

 

[Janiiix3]

Also muss ich lediglich meinen Timer auf 38kHz fast PWM konfigurieren?

 

[Dirk]

LotadaC hat da schon recht. Wenn du parallel zur Übertragung sinnvolles abarbeiten möchtest, solltest du das so machen wie er beschreibt. Vielleicht kann er dir das ja so erklären dass du es in C hinbekommst und mit viel Glück ist dann vielleicht der Fehler weg.

Einige Fehler habe ich ja gefunden, die auf jedenfall Ursache für eine fehlerhafte Datenübertragung waren, weitere finde ich leider nicht. Vielleicht schaust du mal nach dem Systemtakt oder auch noch mal nach der LED, wie diese angeschlossen ist (Portpin Strom oder separater Transistor). Ansonsten habe ich keine weiteren Ideen.

 

[Janiiix3]

Du meintest du würdest das anders lösen in C? Auch mit dem Lösungsweg?

 

[Dirk]

Du meintest du würdest das anders lösen in C? Auch mit dem Lösungsweg?

Jain. LotadaC hat da schon recht.

---

Ich würde es so machen:

Ein Timer A macht nur CompareOutput und erzeugt das 38kHz Signal (mit gewünschtem duty cycle). Der Mikrocontroller wird hier nicht belastet, da nur das Hardwaremodul und keine Applikation läuft.

Ein zweiter Timer B erzeugt eine TimerISR mit Periodendauer halbe Bit-Zeit. In dieser Timer B ISR wird dann Timer A (OutputCompare) gesteuert und die kompletten Bits übertragen.

Im Hauptprogramm stößt man einfach einmal eine Übertragung an. Und man kann hier auch einfach prüfen, ob die Übertragung beendet ist, so dass man erneut übertragen kann. Ähnlich wie bei Usart oder SPI.

---

So würde ich es lösen. Aber! Man kann ja klein anfangen, arbeitet erst mal mit Pause und macht manuelles Toggeln (so wie in deinem Programm) und sucht den Fehler. Ein Tipp: fange klein an und beachte die Hinweise, die ich dir gegeben habe. Ich habe manchmal das Gefühl du übergehst ein paar Sachen. Plötzlich sind im Programmcode irgendwelche Änderungen, von denen wir hier nichts wissen, die aber wichtig sind. Gehe strukturiert vor, am besten nur in einem Forum. Und wenn in anderen Foren parallel postest dann bitte gleich darauf hinweisen.
Ich habe leider nicht so viel Zeit, um dir LotadaCs oder mein Konzept so weit zu erklären, dass du es selber hinbekommst. Aber vielleicht kann dir LotadaC es ja ausreichend erklären.

 

[Janiiix3]

Jetzt scheint es zu klappen. Habe jetzt wie lotadac gesagt hat die "FastPWM" Methode genommen und siehe da...

Was mir aufgefallen ist, dass meine Bits alle Invertiert sein müssen damit es geht... Evtl. lag da auch die ganze Zeit der Fehler -.-*

Nur leider wenn ich das Byte Invertieren (~) möchte, klappt das nicht... Wieso ?



CodeBox C

/* send a 14 bit command to the IR - Receiver */
void rc5_send_command(uint16_t command)
{
   uint16_t send_byte = command;
   
 [COLOR=#ff0000][B]  send_byte = ~send_byte;[/B][/COLOR]
   
   for (uint16_t x = 0 ; x < 14 ; x++)
   {
     if (send_byte & 0x2000)
     {
       rc5_send_one();
     }
     else
     {
       rc5_send_zero();
     }
     send_byte <<= 0x0001;
   }
     RC5_SEND_OFF;
     RC5_MODULATION_DISABLE;
}

 

[LotadaC]

Habe jetzt wie lotadac gesagt hat die "FastPWM" Methode genommen

Davon sieht man leider im geposteten Code-Ausschnitt nicht viel. Das müßte dann ja irgendwo in den 3 rc5_send-... Routinen und der disable-Routine stecken.

Das ganze zu sendende Byte jedesmal zu invertieren ist auch umständlich - Du kannst stattdessen einfach IF und ELSE vertauschen (also den dann ausgeführten Code)

 

[Janiiix3]

Warum auch immer, dass mit dem tauschen klappt komischer Weise nicht.

 

[Dirk]

Das mit dem Invertieren war wahrscheinlich noch der Fehler.

Im Code bist du vom Empfänger ausgegangen, du musst vom Sender ausgehen.
(Beim Empfängerausgang ist beim Burst immer ein low Pegel)
Somit gilt
1 senden: 889us Pause + 889us Burst
0 senden: 889us Burst + 889us Pause


Quelle:
http://www.sprut.de/electronic/ir/rc5.htm

Hier auch noch weitere Infos:
https://en.wikipedia.org/wiki/RC-5

 

[Dirk]

Hallo,

inzwischen sind ja einige Tage vergangen. Wir hatten dir ein paar Tipps und Hinweise gegeben, konntest du die Fehlerursache(n) inzwischen finden?

 

[Janiiix3]

Hallo Dirk,

Ja, der Quellcode funktioniert jetzt so wie er soll. Das Problem war einfach nur die "Invertierung" wie du es schon beschrieben hattest.

Den Tipp von lotadac habe ich auch angewandt. Mit hilfe der Hardware PWM (fast PWM) toggle ich nun im 38kHz Takt meine Led (wenn sie es denn auch wirklich soll)!

Vielen dank noch mal an euch beide!

 

[LotadaC]

Toggeln lassen, oder per non-/invertierendem PWM?

 

[Janiiix3]

Vermutlich toggeln... So wie ich es laut Datenblatt verstanden habe.

 

[LotadaC]

Ich schlug aber invertierenden oder nichtinvertierenden PWM vor, dann kannst Du nämlich auch wie von Dirk vorgeschlagen den PWM-duty variieren.
Was hast Du dennn konkret für die WGM-Bits eingestellt?

 

[Janiiix3]

Mode 15 und Toggle bit ...

 

[LotadaC]

In Mode 15 legt OCRnA die Frequenz fest, PWM-duty könnte also nur noch über OCRnB am OCPnB erfolgen. Willst Du OCPnA oder beide benutzen, mußt Du Mode 14 und ICRn für die Frequenz Einstellung nehmen, und beim Compare Output dann den entsprechenden PWM.

 

[Janiiix3]

Was bringt mit ein anderes Tastverhältniss außer Strom einzusparen?