Kommentar: Einfügen von HTML im Kommentar: Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a> Bild einfügen: <img src="BILDURL"> Text formatieren: <b>fetter Text</b> <i>kursiver Text</i> <u>unterstrichener Text</u> Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b> C Quellcode formatieren: <code>Quellcode</code> BASIC Quellcode formatieren: <basic>Quellcode</basic> (Innerhalb eines Quellcodeabschnitts ist kein html möglich.) Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst ! -> I > > > > > > Hallo, > > > > > > > Hallo Peter, hallo alle RC5 interessierten, > > > > in der Hilfe steht > > > > > > > > "Es werden auf dem mit RC5_Init() angegebenen Portpin empfangenen 14 Bit des RC5 Kommandos > > > > zurückgeliefert. Wird kein Signal empfangen, so wartet die Leseroutine bis zu 130ms, bis sie zurückkehrt." > > > > > > > > Da ich ja nicht weiß wann der Nutzer eine Taste am IR Sender drückt müßte man wohl regelmäßig > > > > über einen RC5_Read() pollen. Dann passiert bis zu 130ms nichts!?!? (Das wären 13% CPU für nichts > > > > verschwendet!). Frage: Werden in der Zeit andere Interrupts verarbeitet? > > > > Oder können z.B. an der Ser. Schnittstelle Zeichen verloren gehen? > > > > > > Ja die Hardware Interrupts laufen weiter. Die seriellen Interrupts damit auch. Allerdings laufen die > > > im Interpreter definierten Interrupt Routinen erst nach der Rückkehr aus RC5_Read() an. > > > > > > Wenn Dir zuviel Rechenzeit wegläuft, dann setz doch den Empfangspin auf einen Interrupt, und erst wenn > > > Du dort Signale empfängst ruf RC5_recv() auf. So gehen maximal die 130ms nur dann verloren, wenn Du > > > wirklich Signale empfängst. > > > > > > Gruss Peter > > <b> > > Hallo Peter, danke für die schnelle Antwort. > > 130 ms sind natürlich trotzdem eine unendlich lange Zeit für Anwendungsfälle die Steuerungsaufgaben im > > 10 ms Bereich ( Auflösung des Timer) realisieren muß. Verstehe ich die Aussage > > "Allerdings laufen die > > > im Interpreter definierten Interrupt Routinen erst nach der Rückkehr aus RC5_Read() an." richtig, > > das auch während RC5_Read() die Timer ISR nicht aufgerufen wird? Es würde dann wohl auch nicht > > helfen wenn ich die RC5_Read() Funktion in eine eigene Task mit kleinerer Prio lege, das keine > > Taskswitches während die Zeit stattfinden. Ist diese Aussage richtig? > > Ja, das stimmt, es würde nicht helfen. > > Das Problem ist, das ein Bit in RC5 1,7ms benötigt. Selbst wenn man im Interrupt nur das Signal > wegschreibt, dann bräuchte man auch eine interne Zeitbasis die besser als 1ms ist, um die > Zeitabläufe später zu analysieren. Oder man opfert einen Timer für ein 36khz Signal und würde > in einer Assembler Interruptroutine die Kongruenz zwischen 36khz und Eingangssignal speichern. > > Das ist alles nur so speziell, das man das in eine allgemeine Library nicht einbauen kann, da ja auch ein > Timer dann wegfällt. > > > > > Ich habe in anderen Foren einige interessante Projekte mit ATMEL zum reinen Empfang von RC5 > > gesehen, somit ist mit ein paar wenigen Zusatzbausteinen möglich die zeitkritischen langen Empfang > > vom MEGA128 wegzunehmen. Wenn Interesse besteht kann ich gerne meine weiteren Erfahrungen > > in diesem Forum Posten. > > Gerne! > > > > > Viele Grüße > > > > Jo > > > > </b> > > > > > > > > > > > Wäre es nicht besser, ein Verfahren wie bei der ser. Schnittstelle anzuwenden, also beim Init einen > > > > Buffer mit übergeben der dann schnell ausgelesen werden kann. Den Empfang der RC5 Daten über interrupt. > > > > > > > > Kennt jemand u.U. ein IC das den RC5 Empfang HW Technisch realisiert und zwischenpuffert sodaß mit > > > > dem C-Control nur die empfangsdaten gelesen gelesen werden müssen? > > > > > > > > Ich bin gespannt auf euere Feedbacks, das RC5 Thema ist für mein akt. Projekt sehr interessant- > > > > Danke & Grüße > > > > > > > > Jo > > > > > > > >
