Hallo, zu meiner Frage hole ich lieber mal etwas aus. Ich habe ein Projekt gestartet. Es handelt sich dabei um einen Lirc-kompatiblen IR-Empfänger auf Basis des USBTiny. http://www.xs4all.nl/~dicks/avr/usbtiny/ Den LCD-Krams habe ich rausgeschmissen und den Code für einen Attiny44 angepasst. Die Schaltung habe ich zudem noch erweitert, damit man auf Tastendruck den PC einschalten kann. Und hier ist das Problem: Die Software bearbeitet die Daten nicht sondern schmeißt diese nach Lirc, wo dann die Auswertung stattfindet. Jeder Versuch, einfach diese "Rohdaten" zu speichern und zu vergleichen endete damit, dass ich den Empfänger auf eine bestimmte Fernbedienung programmieren konnte, aber nicht auf eine feste Taste der FB. Hat da jemand vielleicht eine Idee? Bevor die Fragen auftauchen von wegen, dass es fertige Lösungen im Netz gibt. Da stört mich, dass mehrere AVRs verwendet werden, die Taste blockiert ist, dem PC somit nicht mehr zur Verfügung steht und die Firmware auch nicht verfügbar ist, um diese anzupassen. Gruß, Sven
Sven Z. schrieb: > Da stört mich, dass mehrere AVRs verwendet werden, die Taste blockiert > ist, dem PC somit nicht mehr zur Verfügung steht und die Firmware auch > nicht verfügbar ist, um diese anzupassen. Ich habe glaube ich den Anschluss verloren. Wieso mehrere AVRs? Wieso ist eine Taste blockiert? Und warum schreibst Du nicht eine eigene Firmware? Mein Ansatz hierzu wäre ein USB-tauglicher AVR mit LUFA und IRMP. Bzw. das habe ich schonmal gemacht: http://www.home.unix-ag.org/simon/files/irfoo.tgz Man hätte auch noch genügend reserven, echtes HID zu implementieren, so dass LIRC gar nicht mehr gebraucht würde... Viele Grüße, Simon
Ich habe ja eine eigene Firmware geschrieben. Die Lösungen, die ich bislang gefunden habe, verwenden einen AVR für Lirc und einen AVR (Attiny13) zum Einschalten. Die Taste zum Einschalten wird nicht freigegeben, so dass ein Poweroff-Befehl erfolgen würde per ACPI und das möchte ich nicht. Es gibt hier auch ein Projekt auf HID-Basis, aber da muss man seine FB kennen und mit im Chip speichern, ich suche aber eher die universelle Lösung!
Sven Z. schrieb: > Die Lösungen, die ich bislang gefunden habe, verwenden einen AVR für > Lirc und einen AVR (Attiny13) zum Einschalten. > Die Taste zum Einschalten wird nicht freigegeben, so dass ein > Poweroff-Befehl erfolgen würde per ACPI und das möchte ich nicht. Man merkt, dass Du Dich mit dem Problem schon eine Weile beschäftigst - Du kannst nicht mehr ordentlich erklären wie es funktionieren soll... :-) Wie genau wird der PC denn eingeschaltet? Der zweite AVR von dem Du da sprichst, wie genau ist der mit dem ersten verbunden? Und wie schaltet der den PC? Versuche doch bitte mal, eine systematische Beschreibung deines Aufbaus zu geben. Und gehe davon aus, dass ich exakt nichts über existierende Aufbauten weiß. Viele Grüße, Simon
Zwei AVRs. Der "Große" Attiny2313 arbeitet als Lirc-Empfänger. Beim 2. hat man einfach nur den Ausgang vom TSOP auf einen Eingang gelegt und der wertet eigenständig für sich das Signal aus. Ist es identisch mit dem gespeicherten, wird für 250ms oder so ein Ausgang geschaltet, der mittels Optokoppler den PC anschmeißt. Und ich habe mir gesagt, dass ich beide Funktionen in einen Attiny44 packe. Ich gebe die 5V vom Netzteil auf einen Eingang und erkenne so, ob der PC an ist oder nicht und je nachdem schalte ich dann die Funktion um, also quasi welchen "AVR"-Teil er benutzen soll.
IMHO brauchst Du eine Auswertung auf dem AVR. IRMP funktioniert gut, ich weiß aber nicht, ob es einem Software-USB-Stack genügend Rechenleistung übrig lässt. IRMP dampft Fernbedienungssignale auf zwei 16bit-Werte ein und kann mehrere IR-Protokolle simultan erkennen, während Du vielleicht nicht alle Fernbedienungen erkennen kannst, kannst Du sicherlich eine Abdeckung von 90% oder so erreichen. Man könnte natürlich versuchen, das dann wieder in etwas zu wandeln, was von LIRC gut erkannt wird, ggf. simuliert man das erwähnte "igorplugusb"-Protokoll, wobei ich mir fast sicher bin, dass das eine Lösung von hinten durch die Brust ins Auge wäre... Den Spezial-Code zum Ein/Ausschalten kann man sich im AVR-EEProm speichern, und einen Pin zum Ansteuern des Optokopplers findet man sicherlich auch noch... Viele Grüße, Simon
Die Hardware steht ja mit einem Attiny44, also sprich inklusive Optokopller-Ansteuerung. Die Software ist nur das Problem.
wenn du im tn44 noch genügend Platz hast, könntest du IRMP zusätzlich mit einbauen. Dein externes Signal, welches den Einschaltzustand deines PC anzeigt, schaltet dann zwischen der Auswerteroutine für LIRC und IRMP um. Zum Programmieren must die beiden von IRMP gelieferten 16Bit-Werte für Adresse und Tastencode im EEProm speichern. Im normalen Betrieb vergleichst du dann die gespeicherten Werte mit den von IRMP gelieferten Daten. Sascha
Naja ich habe noch knapp 2kB Platz, sagen wir mal 1,5kB. Das externe Signal für den PC-Einschaltzustand ist auch (später) genau dafür gedacht, umzuschalten. Aber die USBTiny-Routine empfängt ja ROhdaten und die IR-Mouse wertet diese Daten auch aus und das mit einer ähnlichen Empfangsroutine - ich könnte also Platz sparen. Meine Auswertungsversuche sind indes aber so weit gescheitert, dass ich nur die Fernbedienung festlegen kann, aber nicht die Taste. Was mich aber noch viel mehr wundert ist, dass das Toggle-Bit (RC5) Einfluss hat, sprich ich meistens 2x eine Taste drücken muss, bis der Einschaltimpuls kommt. Irgendwo habe ich noch einen Denkfehler, aber die "Rohdaten" müssten sich doch unterscheiden, oder nicht? IRMP könnte knapp werden - ich überlege, ob ich mich ggf. nur auf RC5/6 begrenze und die Routine vom Robotornetz einbaue, aber ich finde das irgendwo doppelt gemoppelt...
soweit ich (nach kurzem überfliegen) rausgelesen habe werden bei LIRC von der Hardware nur die Bitzeiten gemessen, und dann per USB an die Software übermittelt, von der sie dann ausgewertet werden. Sven Z. schrieb: > ... > Meine Auswertungsversuche sind indes aber so weit gescheitert, dass ich > nur die Fernbedienung festlegen kann, aber nicht die Taste. Was mich > aber noch viel mehr wundert ist, dass das Toggle-Bit (RC5) Einfluss hat, > sprich ich meistens 2x eine Taste drücken muss, bis der Einschaltimpuls > kommt. die IR-Protokolle haben immer Bits die als Adresse dienen und welche die die Taste codieren. Wenn du mit deiner Programmierung immer nur die Fernbedienung, aber nicht die Taste festlegen kannst, dann wertest du nur die Ardesse aus, nicht aber die Taste. Zum Problem mit dem Toggle-Bit: Der Zustand dieses Bits wird ja von der Dekoderroutine entweder der Adresse oder dem Tastecode zugeordnet. Wenn du diese Information nicht brauchst, dann must du das entsprechende Bit ausmaskieren. Sascha
Okay, das Toggle-Bit ist das kleinere Übel. Das Andere nervt schon irgendwie mehr...
Ich meine, irgendwie muss das doch auch "einfacher" gehen. Bei diesen 2 AVR-Lösungen wird zum Teil ein Attiny13 verwendet zum Einschalten. Da passt ja nun kaum was rein...
Sven Z. schrieb: > Das Andere nervt schon irgendwie mehr... na dann zeig doch deinen Code mal her, der sich nur auf die Fernbedienung, aber nicht auf die Taste programmieren lässt! Sascha
Okay, aber ich muss sagen, dass das sehr sehr "quick&dirty" ist. Der Code ist ein Mischmasch aus USBTiny, dieser IR-Mouse und Eigenentwicklung. Beim Codespeichern ermittel ich zuerst die Länge des übertragenen Codes, damit die Schaltung weniger auf andere FBs reagiert. Wie gesagt noch quick&dirty, da ich es auch erst einmal hinbekommen wollte und dann verfeinern wollte. Der PC-Zustand wird z.B. noch nicht überwacht usw.
hm... hab's mir mal angeschaut: 1; mit deinen 24Bit hast du aber auch nur eine Auswahl an Protokollen 2; dieses 'irdelta' ist auch protokollspezifisch 3; was ist wenn 'ir.length' keine 24Bit hergibt? >dann wird cc in der Schleife negativ! Was für einen Code verwenden deine Fernbedienungen? Hat das Protokoll auch genau 24-Nutzdatenbits? bei deiner Auswertung/Programmierung des Tastencodes ist mir noch unklar was das ganze soll. Das ist sicher auch einfacher zu machen Kannst du den berechneten 'code' irgendwie ausgeben zu Testzwecken? Sascha
Danke für die Mühe! Die Auswertung habe ich von der IR-Mouse übernommen, darum 24 Bits. Ich verstehe auch nicht, warum es cc-2 heißt und nicht cc-1 und warum die letzten beiden Bits verworfen werden (cc=ir.length-2). Meine FB verwendet RC5, glaube ich. 1. Wie gesagt IR-Mouse, die Auswertung habe ich nicht verstanden, weil er irgendwie auch eine Zeitangabe benötigt. 2. Was ist überhaupt irdelta? Die IR-Mouse braucht leider auch spezifische FB-Einstellungen sprich die Zeit, wie lang das High-Signal ist. 3. Bei meiner FB sind es eigentlich nur 21 Bit, das habe ich mir schon mal ausgeben lassen. Wenn ich irgendwie die Rohdaten auswerten könnte (und ggf. das Toggle-Bit löschen), würde das mir vollkommen langen. Aber dieses System mit irdelta habe ich nicht verstanden, das gebe ich auch zu. Er reagiert ja irgendwie auf Flanken, aber was steht da drin?! Müsste ich bei RC5 nicht 28-Codes haben? Leider kann ich den "code" nicht ausgeben, wie auch? Ich bin noch relativer Anfänger in Sachen AVR und vom Treiberschreiben unter Linux habe ich keine Ahnung. Für ein Display wären keine Pins frei, mal davon abgesehen, dass ich evtl. auch keines mehr habe. Ich bin kurz davor einfach parallel eine RC5-Auswertung einzubauen und dann je nach PC-Zustand umzuschalten, aber das fände ich etwas überladen.
Sven Z. schrieb: > Danke für die Mühe! > > Die Auswertung habe ich von der IR-Mouse übernommen, darum 24 Bits. > Ich verstehe auch nicht, warum es cc-2 heißt und nicht cc-1 und warum die > letzten beiden Bits verworfen werden (cc=ir.length-2). das Datenfeld speichert im Wechsel die Sendedauer und die Dauer der Pause (es werden ja immer die Zeiten zwischen den Flanken gemessen). Mit der Auswertung (cc-2) werden nur die Pausenzeiten oder nur die Impulslängen ausgewertet. Das ist eher was für Pulse-Distance-Codierung, aber nicht für RC5-Code der Manchester-Codierung verwendet. > Meine FB verwendet RC5, glaube ich. > > 1. Wie gesagt IR-Mouse, die Auswertung habe ich nicht verstanden, weil > er irgendwie auch eine Zeitangabe benötigt. > > 2. Was ist überhaupt irdelta? Die IR-Mouse braucht leider auch > spezifische FB-Einstellungen sprich die Zeit, wie lang das High-Signal > ist. irdelta ist ein Protokollspezifischer Zeit-Wert, der im Falle von einer Pulse-Distance-Codierung eine Zeit zwischen der im Protokoll verwendeten kurzen und langen Pausendauer definiert. Damit kann man durch einfachen Vergleich den Bitzustand (0/1) ermitteln. > 3. Bei meiner FB sind es eigentlich nur 21 Bit, das habe ich mir schon > mal ausgeben lassen. Wie? Am PC? -> dann kannst du dir auch die Werte ausgeben lassen?! Durch die Bi-Phase-Codierung müssten sich eigentlich je nach Taste unterschiedliche Flankenanzahlen ergeben. Bzw. müsste bei ein und derselben Taste der Wert um eins schwanken > Wenn ich irgendwie die Rohdaten auswerten könnte (und ggf. das > Toggle-Bit löschen), würde das mir vollkommen langen. Aber dieses System > mit irdelta habe ich nicht verstanden, das gebe ich auch zu. Er reagiert > ja irgendwie auf Flanken, aber was steht da drin?! Müsste ich bei RC5 > nicht 28-Codes haben? 28 ja, wenn alle übertragenen Bits 1 sind > Leider kann ich den "code" nicht ausgeben, wie auch? UART? notfalls Software-UART Sascha >IRMP_Protokollliste: http://www.mikrocontroller.net/articles/IRMP#Bi-Phase_Protokolle
Ja okay, das würde die Auswertung echt verkomplizieren, wenn er sie Flankenzeiten speichert. Kommt ein 1-Signal nach dem 0-Signal wäre diese ja doppelt so lang und umgekehrt. Hmm, das wäre doch eine Idee. Ich kenne das Start-Bit und könnte anhand der Zeiten die Bits bestimmen. Ich würde einfach gerne irgendwie den vorhandenen Code weiterverwenden, aber ich muss mir mal überlegen, ob ggf. eine komplett andere Signalauswertung platzsparender wäre. Die Ausgabe habe ich im Übrigen ganz "billig" gelöst und die LED im entsprechenden Wert von ir.length blinken lassen. Ausgabe per UART wohin?
hier noch mal ein Link wie der Manchestercode aussieht: http://de.wikipedia.org/wiki/Manchester-Code da es dir nur um eine Taste geht, könnstest du auch die ganzen Bitzeiten speichern also z.B. 21 Werte, beim späteren Vergleich müsste man natürlich etwas Spielraum lassen, da die Zeiten je nach Empfangsbedingung etwas schwanken. Damit lässt sich natürlich das Toggle-Bit nicht rausrechnen. >Ausgabe per UART wohin? an deinen PC Sascha
Den Manchester-Code hatte ich gerade erst kürzlich und ich habe mich ja auch mit dem RC5-Signalaufbau beschäftigt. Ich wollte gerade behaupten, dass ich nicht die kompletten Flanken wegspeichern könnte, aber das könnte ich ja sogar! Das hätte den Nachteil, dass ich das Toggle-Bit nicht ausblenden kann, aber den Vorteil, dass ich Code-unabhänig speichern kann. Da bei der Auswertung Assembler usw. verwendet wurde, hatte ich nicht so ganz verstanden, was das mit dem irdelta auf sich hat. Aber warte mal. Willst Du mir erzählen, dass es eine Möglichkeit gibt (und das bestimmt), dass ich einen Atmel an die serielle Schnittstelle hänge und der spuckt mir per Hyperterminal (o.ä.) was aus?! Das wäre einerseits genial, andererseits ist der Tiny44 voll belegt, aber für künftige Projekte wäre das nicht verkehrt. Ich wollte mal eine Analogsignalauswertung mit einem Atmega machen und bin gescheitert. Da wäre es ja hilfreich, wenn er Zwischenwerte auf dem PC ausgeben würde usw.. Aber ich habe mittlerweile eine Vermutung, woran es lag! Apropos Toleranzen. Das könnte erklären, warum er manchmal etwas "träge" war, als ich die irdeltas ausgewertet habe. Man könnte ansonsten auch eine "Dirty"-Auswertung machen. Es können ja "nur" 2 Zeiten auftreten. Also Signallänge messen und speichern und dann enstprechende Bits 0 für 889ms und 1 für 1778ms speichern und man hat auch einen individuellen Code. Hmm, aber da wäre man wieder zeitabhängig oder man müsste die Zeiten ermitteln. Jetzt verstehe ich auch, warum er auf manche Tasten nicht reagiert hat oder bei einer FB nur auf ein paar wenige (0 hätten es sein sollen). Naja mit dem Toggle-Bit könnte man ja noch leben...
bei den tiny's hat nur der 2313 eine extra Hardware-UART, machmal kann man auch den SPI dazu verwenden müsste man mal schauen. Die mega's haben alle mind. eine Hardware-UART. Software UART geht natürlich immer wenn auch etwas aufwendiger. Du könntest ja auch beide Versionen des Datenstroms speichern (mit Togglebit =0 und mit =1). Sascha
Hmm, anstatt des ersten Codes die ersten zwei Codes speichern - das wäre natürlich auch eine Idee. Ich habe im Übrigen eine lernfähige FB, die kommt mit RC5 nicht 100% klar. Ich habe sie mal mit meiner RC5-FB angelernt. Entweder sie sendet keine Wiederholungen oder aber, wenn die Wiederholungen funktionieren sendet sie immer 2x die Taste... SUPER! Ich danke Dir noch mal für die Hilfe. Ich werde es wie gesagt dann so machen, dass ich die Puls- und Pausenzeiten auswerte, sprich bei RC5 z.B. 1300ms als Grenzwert setze. Alles darunter wird 0 und darüber 1 und das Ergebnis speichere ich in eine Variable - quasi so ähnlich, wie dass die IR-Mouse gemacht hat. Ich bin mal gespannt, ob das klappt...
Hallo, also ich habe keine Ahnung, was in ir.data nun gespeichert wird, aber wenn ich den Mittelwert bilde, kann ich einen Code generieren. Zur Zeit habe ich noch das Problem, dass er nicht nur auf eine, sondern doch auf ein paar, ca. 4 reagiert. Ich vermute mal, dass die dann denselben Anfangscode haben, aber länger sind. Naja ich muss dann mal sehen, aber es sind schon deutlich weniger Tasten! Danke noch einmal für die Hilfe soweit. Gruß, Sven
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.