Hallo,
angeregt durch Empfangsroutine für RC5 Infrarot Fernbedienungssignale in diesem thread, habe ich auch versucht eine Routine auf ATTiny2313 zu schreiben.
Da es viele Beschreibungen zu Routinen mit Pollen des Input Pins vom TSOP gibt; es dazu sogar eine Appnote von Microchip gibt, suchte ich nach einer anderen Methode.
Am Ende stand ein Programm, das den Input-Pin nicht pollt, sondern über den Pin Change Interrupt die Zeit von einer Input Flanke zur nächsten mißt. Da das Startbit "1" ist und im RC5 Manchester Code in der Mitte eines Bitfensters der logische Zustand wechseln MUSS, kann sequentiell über den zeitlichen Abstand der Flanken auf das übertragene Bit geschlossen werden; wird hier also nicht über Zustandsabfrage des Input Pins bestimmt. Für die Zeitmessung wird innerhalb der PCINT ISR ein Timer ausgelesen, der mit 125kHz läuft. Der Overflow Interrupt des gleichen Timers wird auch zur Fehlererkennung und Abmessung der Ruhephase genutzt.
Bei jeder Flanke des RC5 Signals kann der Empfänger sozusagen neu synchronisiert werden und man kann in ziemlich weiten Bereichen auf kurze (889µs) und lange Zeitabschnitte (1778µs) entscheiden. Nützlich, wenn zB bei selbstgebauten FB-Sendern ohne Quarz der Takt des Senders nicht so ganz stimmt
Sobald der TSOP eine Zustandsänderung zum µC gibt, erfolgt ein Pin Change Interrupt.
Ablauf in der PCINT Isr in etwa:
1. Nachdem 4ms kein PCINT auftrat -> bereit zum Empfang vom RC5-Startbit.
2. Low Flanke von Startbit trifft ein. Startbit ist bekannt, wird als "1" abgespeichert und der Variablen RC5_Bit zugewiesen. Zeitmessung bis zur nächsten Flanke starten.
3. Nächste Flanke trifft ein. Zeitnahme und Zeitmessung für folgende Flanke starten.
a. Aktuelle Zeitnahme ergibt kurze (889µs) Zeitspanne. RC5_Bit wird getoggelt. RC5_Bit wird nur dem RC5 Telegramm hinzugefügt, wenn zuvor empfangenes Bit nicht gespeichert wurde. Ob gespeichert wurde oder nicht, wird über "Gespeichert"-Flag abgefragt und auch gekennzeichnet.
b. Aktuelle Zeitnahme ergibt lange (1778µs) Zeitspanne. RC5_Bit wird getoggelt und dem RC5 Telegramm hinzugefügt. "Gespeichert"-Flag wird gesetzt.
4. Weiter bei 3. bis alle 14 Bits empfangen wurden.
5. 4ms Ruhephase einleiten
Mechanismen zur Fehlererkennung:
Kurze oder lange Zeitspannen liegen außerhalb der einstellbaren Toleranzen.
8-Bit Timer0 mit 125kHz wird zu Beginn jeder Messung auf 0 gesetzt. Findet ein Timeroverflow während eines Telegrammempfangs nach 2048µs statt -> Fehler, da der max. gültige Abstand zweier Flanken 1778µs (+-) ist.
Findet in der 4ms Ruhephase ein PCINT statt, wird eine weitere 4ms Ruhephase ab diesem PCINT angehangen.
Wird während des Empfangs eines Telegramms ein Fehler festgestellt (zB Störung mit einer anderen FB) , wird der bisherige Empfang verworfen und über die 4ms Ruhephase auf das nächste Startbit gewartet.
Eigentlich wollte ich die Routine in meinen ferngesteuerten Vehikeln einsetzen, da ich dort eine selbstgebaute IR-FB einsetze, die Telegramme im Abstand von 6ms verschicken kann. Bisher nutze ich den GETRC5 Bascom Befehl, die zumindest zu Beginn meiner Fernsteuerversuche anno dazumal mein ganzes Hauptprogramm aufhielt bzw. durcheinander brachte - meine ich mich jedenfalls zu erinnern. Habe deshalb damals den Empfänger auf einem eigenem µC ausgelagert.
Ein Überprüfung ergab nun ein gleiches Zeitverhalten dieses Programms (in Bascom geschrieben) und des Bascom GETRC5 und die Verwendung des GETRC5 spart auch noch etwa 600 Byte Programmspeicher Muß ich das jetzt auch noch in Assembler machen? Ich glaub fast nicht, daß ich das besser als Bascom GETRC5 hinbekomme. Aber mich würd interessieren, nach welcher Methode die Bascom Entwickler das gemacht haben
Ich weiß nicht ob diese Methode Vorteile gegenüber anderen hat Bild hier
Gruß
Searcher
Lesezeichen