Thank You Michael K. (Gast)
I successfully build it..Everything is working fien. Now i want to make
it short and stable (in eventghost read below for the problem)
Now i would like to know few thing also you can consider some bug..
1)Adding short crystal than the long one.
I added full (big) Quartz Crystal Q1 12Mhz it works. I tried to replace
it with 12Mhz Small crystal (cut one) but it doesn't work.. The system
gives error when connected "USB DEVICE NOT RECOGNIZED". Can u tell me
how can i do it ? How to make this circuit short also which component to
use to make it short ? I saw a SMD version above do we have a schematic
or component list ?
small(cut) =
http://webbuilder.asiannet.com/617/comm/upimage/p_080905_03867.jpg
Full =
http://webbuilder.asiannet.com/617/comm/upimage/p_080905_03871.jpg
2) DLL intialization and also UNintialize it via windows
In eventghost (program) i add the plugin and done few thing with it. Was
working fien. but there are few things still giving problem...
A---In event ghost the mouse movement doesn't work (it is so slow
slow). I tried to work that out with mouse relative macro. Can u explain
why we can't use the normal mouse up, down etc thing. This thing works
perfectly with Igorplug and LIRC receivers which i already have but they
have limitation like com port windows xp etc etc.
B---In event ghost even after setting the "DISABLE POWERON
intialization" it doesn't function properly. I mean after selecting the
option it must do this
a) Do not work after Initialization (by windows ? or by eventghost ?)
b) Do work after windows shutdown (here is the problem it works one
time after that it doesn't)
So in short,
How to make it work how to intialize the plugin and also UNintialize it
via windows.
How to enable/disable the PowerON function via window "COMMAND LINE"?
3) Can you provide any smaller version of the schematic ? i mean smd and
normal both ? in eagle cadsoft http://www.cadsoftusa.com/?lang=en
4) One thing more will this support windows 7 32bit and also 64bit
version ?
Thank you
VERY GOOD PROJECT I LIKE IT..I am trying to make it work and good. I am
a hobbyist in electronics.
altainta altainta schrieb:> Can u tell me how can i do it ? How to make this circuit short also which> component to use to make it short ? I saw a SMD version above do we have a> schematic or component list ?
Using standard components is not a problem here as there are no special
requirements. So any is ok when the rated voltages and currents are
considered. Using other crystals should also be no problem (I'm using
http://www.reichelt.de/Quarze/12-0000-HC49U-S/index.html?;ACTION=3;LA=444;GROUP=B41;GROUPID=3173;ARTICLE=32850),
maybe you'll have to adjust the corresponding capacitors according to
the crystal datasheet.
altainta altainta schrieb:> 3) Can you provide any smaller version of the schematic ? i mean smd and> normal both ? in eagle cadsoft http://www.cadsoftusa.com/?lang=en
No. I also have only a THT version.
The power-on-thing should IMO be implemented in firmware. Currently I'm
working on an alternative firmware and maybe I'll include this.
I can't answer the other questions as I'm not working with Eventghost
and/or Win 7.
Yes, there is a bug with the "PowerOn Function" in the DLL with
EventGhost.
The function gets disabled but not anymore enabled so you can't switch
on the PC with the optocoupler.
It is already fixed but i missed to upload the new DLL.
I will do this in this week!
Hi,
Kann man die angesprochene BugFix Version schon irgendwo runterladen? Da
ich auch mit Eventghost arbeite wäre die für mich sehr nützlich :)
Viele Grüße
Hallo!
Ich habe den Empfänger laut Anleitung aufgebaut, funktioniert tadellos.
Allerdings habe ich ein kleines Problem:
Die (Noname) Fernbedienung, welche ich mit dem Empfänger verwenden
möchte, hat einige Tasten, die nicht erkannt werden ("8", "Mute" und
einige weitere).
Diese Tasten funktionieren jedoch über den IgorPlug problemlos.
Alle anderen werden einwandfrei erkannt.
Hat jemand eine Idee, woran das liegen könnte?
Der einzige Unterschied in meinem Aufbau ist, daß ich einen TSOP 1136
verwende.....kann es daran liegen?
Daniel S. schrieb:> Hat jemand eine Idee, woran das liegen könnte?> Der einzige Unterschied in meinem Aufbau ist, daß ich einen TSOP 1136> verwende.....kann es daran liegen?
Im IRMP-Thread wird dir eher geholfen werden.
Daniel S. schrieb:> Die (Noname) Fernbedienung, welche ich mit dem Empfänger verwenden> möchte, hat einige Tasten, die nicht erkannt werden ("8", "Mute" und> einige weitere).
Im IRMP-Artikel findest Du eine kleine Anleitung, wie Du Scans von
Deiner Fernbedienung machen kannst.
http://www.mikrocontroller.net/articles/IRMP
Zugehöriger Thread:
Beitrag "IRMP - Infrared Multi Protocol Decoder"> Diese Tasten funktionieren jedoch über den IgorPlug problemlos.> Alle anderen werden einwandfrei erkannt.
Wenn Du mir die Scans zuschickst, kann ich den IRMP entsprechend
erweitern.
Ich bräuchte Scans von funktionierenden Tasten, wie 1-7 und 9, und dann
noch die von den nicht-funktionierenden.
Gruß,
Frank
Hallo,
ich habe die Schaltung in SMD nachgebaut, allerdings nicht den ATMEGA8
sondern den ATMEGA168P-20AU genommen und versuche nun den mit Ponyprog
über die parallele Schnittstelle zu programmieren.
Leider klappt das ums verrecken nicht. Nun habe ich hier irgendwo
gelesen, dass Ponyprog den 168p nicht unterstützt.
Stimmt das und wenn ja, mit was programmiere ich das Ding dann? Brauche
ich einen anderen Programmer, bis jetzt habe ich nur das ganz einfache
ISP-Interface (siehe Schaltplan hier vom Projekt).
Vielen Dank
Gruß
Stefan
Hi,
danke, ich habe mittlerweile AVRdude probiert, damit sieht's bis jetzt
ganz gut aus. Jetzt fehlen mir nur noch die richtigen Fuse-Bits. Das
wird aber hoffentlich auch noch.
Gruß
Stefan
Hallo Hugo,
Ich habe mit dem Gedanken gespielt den USB Receiver HTPC tauglich zu
komplettieren, indem man noch ein Samsung 20L203DA12 (z.B. erhältlich
bei eB*y) dazubaut.
Dieses Display ist günstig erhältlich und wird normalerweise via RS232
angesprochen... Ich dachte nun es wäre vielleicht möglich das Ding über
den Atmega laufen zu lassen, da dieser an USB hängt. Meinst Du das ist
machbar, bzw. in die Firmware integrierbar?
Viele Grüße
Hallo,
ich beschäftige mich gerade mit V-USB als ich dieses Projekt gefunden
habe, habe ich mir gedacht das es ein guter Einstieg in das Thema wäre.
Mein Problem ist nur das ich keine Verbindung mit dem PC erreiche.
Ich habe mir auf ein Steckboard ein Widerstand-Spannungsteiler aufgebaut
weil ich keine Z-Dioden mit 3.6V habe. Desweiteren habe ich die
usbconfig.h verändert und PD2 an D- und PD3 an D+ sowie einen 1.1k Ohm
Widerstand an PD4 angeschlossen. In Ermangelung eines 68 ohms
Widerstandes habe ich mit parallelgeschalteten Widerständen 88_Ohm
erreicht. Mein Mega8 läuft mit einen 20Mhz Quarz wobei ich mein
compilieren 12Mhz eingestellt habe. Das Gerät wird hin und wieder mal
angezeigt aber wird einfach nicht erkannt. Ständig meint Windows das es
ein "unbekanntes Gerät" sei. Auf was muss ich bei V-USB genau achten
damit ich eine Verbindung bekomme?
im Anhang mal der Spannungsteileraufbau.
Viele Grüße
Lars L. schrieb:> Ich habe mir auf ein Steckboard ein Widerstand-Spannungsteiler aufgebaut> weil ich keine Z-Dioden mit 3.6V habe. Desweiteren habe ich die> usbconfig.h verändert und PD2 an D- und PD3 an D+ sowie einen 1.1k Ohm> Widerstand an PD4 angeschlossen. In Ermangelung eines 68 ohms> Widerstandes habe ich mit parallelgeschalteten Widerständen 88_Ohm> erreicht.Lars L. schrieb:> im Anhang mal der Spannungsteileraufbau.
Kannst daraus mal einen vernünftigen, kompletten und aufgeräumten
Schaltplan zeichnen? Mit dem von oben kann man nicht wirklich was
anfangen. Zum einen tauchen deine 88ohm nirgends auf, zum anderen sind
D+ und D- ja sicher nicht kurzgeschlossen.
Lars L. schrieb:> Mein Mega8 läuft mit einen 20Mhz Quarz wobei ich mein> compilieren 12Mhz eingestellt habe. Das Gerät wird hin und wieder mal> angezeigt aber wird einfach nicht erkannt. Ständig meint Windows das es> ein "unbekanntes Gerät" sei. Auf was muss ich bei V-USB genau achten> damit ich eine Verbindung bekomme?
Das funktioniert natürlich nicht. Dein AVR rennt mit der Frequenz des
angeschlossenen Quarzes (oder des internen Oszillators), da kannst du
bei compilieren einstellen was du willst - das ändert daran überhaupt
nichts. Das Einzige was du dadurch erreichst ist, dass sämtliche Zeiten,
die mit Hilfe von F_CPU errechnet werden nicht stimmen.
KLez schrieb:> Dieses Display ist günstig erhältlich und wird normalerweise via RS232> angesprochen... Ich dachte nun es wäre vielleicht möglich das Ding über> den Atmega laufen zu lassen, da dieser an USB hängt. Meinst Du das ist> machbar, bzw. in die Firmware integrierbar?
Ich bin zwar nicht Hugo, kann dir aber vielleicht trotzdem helfen:
machbar ist das auf jeden Fall, wobei du prinzipiell auch jedes andere
Display nehmen kannst. Kann halt sein, dass die Aktualisierung länger
dauert, wenn die Ansteuerung komplexer/zeitaufwändiger wird.
Ich arbeite ebenfalls an einer Firmware, die auf Hugos Version basiert,
aber ein paar zusätzliche Features beinhaltet, z.B. eine Uhr und einen
Timer, mit dem der PC zu einer programmierbaren Zeit eingeschaltet
werden kann, auch wenn er ganz aus ist.
Du würdest also eine neue ID einführen und in der entsprechenden
Botschaft den Displayinhalt übermitteln.
Auf PC-Seite sieht das Ganze schon etwas komplizierter aus: entweder du
hoffst auf Hugo, oder du machst dich selbst an die Implementation. Als
Anfang kannst du dir eine Lib von
http://www.mikrocontroller.net/articles/USB_HID_Host_Treiber aussuchen
und entsprechend anpassen. Bei mir ist es die HidLib von jj-jabb
geworden.
Hallo,
habe jetzt auch mal den Referenzschaltplan hinzugefügt, den ich versuche
aufzubauen, nur halt mit anderen Bauteilen.
Geht das ganze eigentlich mit 20Mhz und ein Spannungsteiler oder bewege
ich mich in eine völlig falsche Richtung?
Ich habe übrigens die IRMP-Bauteile vollkommen weg gelassen, ich wollte
mich erstmal mit V-USB beschäftigen und das Projekt als mein
Referenzprojekt nehmen.
Irgendwo muss man ja Anfangen :-)
Viele Grüße
@Lars L.
Das kann so wie du es aufgezeichnet hast nicht funktionieren.
Auch habe ich einmal deine Schaltung vereinfacht nachgezeichnet.
1. Du machst einen Kurzschluss mit D+ und D-.
2. Es gehört nur D- auf ~3,6V Pegel, D+ hängt in der "Luft". Es wird nur
der Pegel beider Datenleitungen auf 3,6V begrenzt um keine Probleme mit
moderneren USB Host zu haben.
3. Der 1,5k Ohm Pullup bei D- ist wichtig weil ansonsten der PC nicht
erkennt ob USB 1.11 oder USB 2.0 Device.
4. Die 68 Ohm begrenzen den Strom zwischen AVR und PC in den
Datenleitungen, sonst nichts.
Mit Spannungsteilern das aufzubauen ist nicht so einfach und geht
weniger gut. Der AVR spuckt 5V aus und es dürfen aber nur 3,6V an die
Datenleitung.
Mann kann auch 2x1N4184 Dioden in die Versorgung als Spannungsabfall (5V
- 0,6V - 0,6V = 3,8V) des AVRs hängen - wenn dieser dann noch läuft.
Dann kann man sich die Z-Dioden an den Datenleitungen sparen.
Das einfachste ist und bleiben die 2 Z-Dioden. Die kosten dann auch
nicht die Welt.
Und wenn du mit 12Mhz kompilierst solltest du auch einen 12Mhz Quarz
einsetzen.
Hallo,
danke für die Antwort hat mir erstmal geholfen :-)
Also reintheoretisch und aus mein Bauchgefühl heraus müsste ich also
zwei Spannungsteiler mit widerständen aufbauen und vermutlich noch ein
paar Gleichrichterdioden einbringen damit es keine Rückkopplung gibt und
die Pegel sauber an die Datenleitungen gebracht werden?
Bald ist ja wieder Geld aufn Konto da denke ich mal wird Reichelt ne
Bestellung von mir bekommen :D
Viele Grüße
Lars
tag,
ich lese ja seit Jahren nur noch mit. aber hier möchte ich auch mal was
sagen:
Danke, klasse Sache.
Details welche ich noch mitgeben möchte: (insbesondere wenn man win2k
nutzen will)
JA es läuft auch unter win2000.
Es wäre schön wenn die Infos ein bischen übersichtlicher aufbereitet
wären.
an manchen details sucht man sich blöd.
zB das man die *.dll mit zu den *.exe Dateien packen muss, damit da was
läuft. Ist im nachhineien sicher offensichtlich aber für jemand der nur
µc bezogen software macht nicht sofort offensichtlich (irgendwie).
Was auch nett wäre, wäre das makefile WinAVR oder die Einstellungen im
AVR-Studio. von wegen Optimierung usw. kann sich ja doch immer mal
anders verhalten zudem wären dort ja dann auch alle benötigten files
enthalten.
Angehängt habe ich mal eine minimalversion im Eagle-format. ich habe das
auf lochraster aufgebaut ! ich hatte eine beidseitg kaschierte
lochrasterplatine daher konnte ich GND oben führen.
In dem Bild von des Schaltplans kann man die Z-Diodenwerte 3,6 sehr
schlecht lesen.
Als Ersatz für die TSOP17..-Serie eigent sich die TSOP312.. Serie sind
pin- und dimensionskompatibel
Von Eventghost bin ich ebenfalls recht begeistert. Auf Win2k läuft
allerdings nur noch Version 0.4.0r1397 die neuren nicht mehr sondern
erzeugen nur noch einen Eintrag im Fehler log.
Das GDI+ muss man microsoft laden und dann die gdi+.dll kopieren.
Der SAMSUNG32 Ferbedienungstyp bedient sich der 38kHz Trägerfrequenz
so damit hätte ich meine gedanken und mein Danke niedergelegt.
schönen tag noch
Balu
ps: damit kann man echt werbung machen. ich werde es auf jeden fall tun
damit das eine breitere Unterstützung bekommt
Hallo,
Michael K. schrieb:> Ich arbeite ebenfalls an einer Firmware, die auf Hugos Version basiert,> aber ein paar zusätzliche Features beinhaltet, z.B. eine Uhr und einen> Timer, mit dem der PC zu einer programmierbaren Zeit eingeschaltet> werden kann, auch wenn er ganz aus ist.
das ist noch genau das, was ich vermisse. Wirst Du das veröffentlichen?
Und was auch noch richtig klasse wäre: LEDs, die von einer Software
angesteuert Zustände anzeigen. Z.B. wenn VDR auf Tuner1 aufzeichnet,
oder wenn AC3-/DTS Ton aktiv ist, etc.
Es gab mal ein Projekt von Th. Breuer, der hat das tbe-ExtensionBoard
(http://www.tb-electronic.de/vdr/vdr_extension_board.html) entwickelt,
das konnte das alles und es gibt auch ein Plugin für VDR dafür.
Für Thin Clients ist das allerdings nix, Scart-Anschlüüse sind out und
eine Com-Schnittstelle hat auch kaum noch ein Mainboard.
Die Remote-, Wakeup- und LED-Funktionen auf einer kleinen USB-Platine
wären schon der Knaller.
Leider habe ich keinen Plan von Mikrocontroller-Programmierung,
vielleicht hat aber jemand von Euch nun Lunte gerochen. :-)
Gruß
Stefan
Hi Dirk,
das Display habe und kenne ich (habe auch ein Dockstar).
Aber ich will doch kein Display sondern nur ein paar Status-LEDs (mir
reicht es eigentlich, wenn ich sehe, ob eine (mehrere) Aufnahme läuft
ohne ins OSD schauen zu müssen, bzw. so sehe ich das auch sofort, wenn
der TV aus ist). Die LEDs kriegt man in jeden ThinClient rein, das
Display mußt Du irgendwo hinstellen und kannst es dann von der Couch aus
doch nicht lesen...
In dem Plugin zu dem ExtensionBoard von tbe kann man sogar für mehrere
Tuner jeweils eine LED schalten. Sehr praktisch. Und der AVR könnte das
doch nebenbei im Schlaf.
Gruß
Stefan
Stefan Meyer schrieb:> das ist noch genau das, was ich vermisse. Wirst Du das veröffentlichen?
Ja. Allerdings nutze ich MediaPortal unter XP, sprich dotNET-basierend.
Wobei die Hardware natürlich auch unter Linux lauffähig ist, eine
entsprechende Applikation vorausgesetzt. Vielleicht bekommt man es mit
Mono auch direkt zum Laufen, wobei ich mich damit absolut nicht
auskenne.
Michael K. schrieb:> Wobei die Hardware natürlich auch unter Linux lauffähig ist, eine> entsprechende Applikation vorausgesetzt.
Ich habe einen lirc-kompatiblen Daemon auf Basis von inputlirc für den
Receiver geschrieben, läuft ohne Probleme am VDR. Der kann natürlich die
zusätzlichen Features nicht.
Wollte ich bei Gelegenheit mal releasen, aber die Nachfrage nach Linux
Support war bisher eher gering außerdem habe ich meinen Receiver erst
mal wieder eingemottet.
Dirk W. schrieb:> Ich habe einen lirc-kompatiblen Daemon auf Basis von inputlirc für den> Receiver geschrieben, läuft ohne Probleme am VDR. Der kann natürlich die> zusätzlichen Features nicht.
Ja gut, in dem Fall gibt es doch schon eine Basis. Es kommen dann halt
ein paar neue IDs mit entsprechendem Inhalt dazu. Sollte ja kein allzu
großes Problem sein.
hi, ich habe mal das Pollin BAS rs232 Modul (ATmega8) geordert, das war
ja hier schon als Bauvorschlag zum IR Empfänger Thema, nun mit dem
ATmega168 und IRMP scheint perfekt hier reinzupassen, Empfang ist klar
mit der DLL, nur wie bekomme ich IRSND rein ? gibt es einen Treiber für
Send über USB ? oder müsste man auf USB zu RS232 Libs wechseln ? da wäre
mit Treiber Receive und Send möglich
hat da jemand schon Ideen oder einen passenden Link ? vielen Dank
Hintergrund, eigendlich will ich übers Netz (VNC) meinen VCR
programmieren, brauche also vordergründig IRSND, IRMP wäre ein nettes
Gimmik zur PC Fernbedienung, der ATmega168 ist ja groß genug für beides
mit reichlich Protokolle
jar schrieb:> Hintergrund, eigendlich will ich übers Netz (VNC) meinen VCR> programmieren, brauche also vordergründig IRSND, IRMP wäre ein nettes> Gimmik zur PC Fernbedienung, der ATmega168 ist ja groß genug für beides> mit reichlich Protokolle
Habe ich mit meinem Sohn exemplarisch aufgebaut:
PC -> my-AVR-USB-UART-Converter -> ATTiny85
also nicht über V-USB.
Am Attiny85 (kleiner µC mit nur 8 Pins) hängen TSOPxxxx, IR-Sendediode,
eine LED und RX/TX - realisiert als Soft-UART. Über den Soft-UART nimmt
der ATTiny die Sende-Befehle entgegen und "strahlt" sie mit IRSND ab.
Empfangene IR-Frames über den TSOP sendet er über die Soft-UART an den
PC, damit der PC "lernen" kann.
Wir haben das noch nicht veröffentlicht, weil wir im Moment nur ein
kommandozeilen-orientiertes PC-Programm zum Senden der IR-Befehle und
zum "Lernen" der Codes haben. Das funktioniert aber schon. Im Moment
programmiert mein Sohn noch an der graphischen Benutzeroberfläche,
welche eine frei gestaltbare Fernbedienung unter Windows werden soll.
Wenn Du an der Software für den µC und an dem Kommandozeilenprogramm
interessiert bist, schreib mir eine PN, dann kann ich Dir den aktuellen
Stand schon mal schicken. Damit solltest Du das gewünschte realisieren
können.
Gruß,
Frank
Hallo,
Sorry fuer die dummen Fragen, aber ich habe keine Ahnung von windows und
brauche "Starthilfe":
Ich moechte den USB_Remote_Receiver als Basis verwenden fuer eine
Erweiterung , so dass der Empfaneger per IR oder Funk angesprochen
werden kann und dann einen linux-PC-steuert. Ich habe bereits andere
Anwendungen mit V-USB auf AVR mit Linux zum Spielen gebracht - wollte
aber zuerst alles "out of the box" mit windows ausprobieren.
Ich habe die Original Sources genommen, USE_BOOTLOADER in
configUSBIRREmoteReceiver.h auf 0 gesetzt und alles mit AVR-studio
kompiliert. Ich hoffe, ich brauche den BootLoader nicht, denn ich weiss
ehrlich gesagt nicht wirklich was das ist.
Ich habe das hex-file mit avrdude unter linux geflasht(ATMEGA8-16PU).
Die fuses stehen auf 0xd0(high) und 0xe1 (low).
Wenn ich den controller per USB mit einem windows-XP host verbinde,
erscheint die Meldung: "USB-Geraet wurde nicht erkannt". Ich habe zwar
noch keinen IR-Empfaenger angeschlossen, aber das sollte bis hierher ja
wohl egal sein. Daher hier meine Fragen:
1)Kann ich wie beschrieben ohne den Bootloader arbeiten?
2)Welche fuse-Einstellungen solle ich nehmen (bitte in Hex, in meinem
GUI (avrfuse) heissen die Bits offenbar anders.
3)wie kann ich XP beibringen, die DLL zu laden?
Danke,
Wolfgang
Hallo,
ich fuerchte ich brauche noch konkretere Hilfe. Was bisher geschah:
-Ich habe die fuses geaendert auf
Low: 0x1F
high: 0xC1
-Ich arbeite weiterhin mit USB_BOOTLOADER = 0
-Mittlerweile scheint XP das device zu erkennen: Im Geraetemanager
werden zwei neue USB-HID-devices als betriebsbereit angezeigt.
-Wenn ich aber .../Demo_Sources/Releases/DLL_Demo.exe anklicke bekomme
ich ein Fenster, in dem ich nur load DLL anklicken kann. Wenn ich das
tue, passiert nichts weiter.
-Wenn ich von der DOS-Console aus DLL_Demo_Console.exe starte, bekomme
ich die Fehlermeldung
ERROR: unable to load DLL
Was mache ich falsch? Muss ich die DLL irgendwo hinkopieren? Welche DLL?
Sorry fuer die dummen Fragen, aber ich bin ein UNIX-Mensch und weiss von
Windows eigentlich nur, wie man es ausschaltet.
Danke
Wolfgang
Danke fuer den link. Das ist ziemlich genau das, was ich machen will!
Werde ich testen.
Mittlerweile laeufts auch unter windows (ich musste die DLL neben das
.exe kopieren). Ein 3-zeiliges howto auf der Webseite waere vielleicht
hilfreich.
Gibt es eigentlich zu IRSND auch einen V-USB-wrapper? So wie ich das
verstehe stellen die sources "nur" eine subroutine zur Verfuegung.
Wolfgang
Hallo,
erst einmal danke für so ein super projekt!
ich habe mir den USB IRMP als prototyp auf lochraster nachgebaut, das
flaschen ging einwandfrei (bootloadHID.hex aus atmaga8/default/).
allerdings wir er jetzt von windows als unknowen device erkannt. jemand
eine idee woran das liegen könnte?
grüße
@Moto:
Dazu sind mehr Infos notwendig? Ist der Source neu kompeliert worden?
Für welche Frequenz, welche Frequenz hat der Quarz,....
Bei den Fusebits muss der 2048 Bytes Bootloader aktiviert sein...
Moto schrieb:> ich habe mir den USB IRMP als prototyp auf lochraster nachgebaut, das> flaschen ging einwandfrei (bootloadHID.hex aus atmaga8/default/).> allerdings wir er jetzt von windows als unknowen device erkannt. jemand> eine idee woran das liegen könnte?
Wie immer am Erbauer.
Habe die Schaltung laut Schaltbild aufgebaut.
(alle Teile außer Jumper und Pony-Interface)
Nur den Bootloader geflasht.
Beim Einstecken wird er bereits als HID Interface erkannt.
Also nix unbekanntes!
Die Firmware ist noch nicht drauf, nur der Bootloader!
Peter
Wie ich solche antworten liebe... Momentan ist die platine bestückt mit
rst pullup, quarz mit c's, isp buchse und dem usb zweig mit 4 R's und 2
z-dioden
Leiter bahnen sollten passen bauteile eben so. Kalte lötstellen waren
unter dem mikroscope auch keine ersichtlich
Grüße
Moto schrieb:> Leiter bahnen sollten passen bauteile eben so. Kalte lötstellen waren> unter dem mikroscope auch keine ersichtlich
Mein Hinweis sollte Dir dienen um den Fehler in
der selbstgebauten Hardware zu suchen.
Finden ist da wohl nicht Deine Stärke.
Antworten wie "sollten passen" sind schlecht bzw. oberflächlich.
Kalte Lötstellen und Mikroskop, haha.
Mit dem Ohmmeter "durchgeklingelt" wäre schon besser.
Der fertigen Software nicht trauen,
dann selbst kompilieren und klappt auch nicht,
meinem Hinweis auf "aufgebaut und klappt"
und den erfolgreichen vorgenannten Erfolgsmeldungen
auch keinen Glauben schenken.
Ich würde Dir ja eine Leiterplatte überlassen,
aber wenn Du die dann fehlerhaft aufbaust ziehst Du mich runter.
Peter
Stelle doch mal ein Bild Deiner Hardware hier ein.
So das problem ist nun behoben, der quarz wars. Es stand zwar 12mhz
drauf, waren aber scheinbar nicht drin. Da nach einem tausch des quarzes
der bootloader sofort erkannt wurde.
Grüße
Gutentag,
ich habe den Empfänger aufgebaut, die einzige Änderung ist das ich den
TSOP31238 anstelle eines 17.. verbaut habe. Der Empfänger läuft auch
soweit allerdings erkennt er mir kein RC5, NEC funktioniert. (Source ist
neu kompiliert, mit samsung, nec und rc5 auf 1 der Rest auf 0). Muss ich
etwas weiteres einstellen damit RC5 erkannt wird?
Rezzo
Ich selber habe bei meinem letzen Aufbau mit der Tonertransfermethode:
http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver#Foto_eines_aufgebauten_USB_IR_Remote_Reciever
eine TSOP4838 verwendet. Die ist um einiges kleiner als die "alte" TSOP
1738. Geht ohne Probleme!
Wichtig für die IR-Diode ist:
>> Die maximale Versorgungsspannung muss 5V oder höher sein>> Frequenz für das benutzte IR Protokoll (meistens 38kHz ausreichend)>> Ausgang Active Low. Dies kann aber sicher ansonsten im IRMP Source >>
irgendwo ausgedreht werden.
Hallo, Nachdem ich über das vdr-Portal und dessen daemon für diesen
IR-Empfänger hier gelandet bin, hab ich mich auch gleich mal an den
Nachbau gemacht (geniales Projekt! Danke Frank + Hugo). Das funktioniert
auch soweit ganz gut, aber ich wollte mich auch einen Schritt weiter
wagen und IRSend mit implementieren. Nur leider stolpere ich schon beim
Einsetzen der irsnd.c in die main.c.
Was ich bislang gemacht habe:
1. in der main.c die Includes
//from irsnd
#include <inttypes.h>
#include "Irsnd\irsndconfig.h"
#include "Irsnd\irsnd.h"
vorn hinzugefügt.
2. in den USB-Descriptoren die Werte auf
PROGMEM char usbHidReportDescriptor[107] ... else PROGMEM char
usbHidReportDescriptor[98]
Geändert
3. in den USBDescriptoren
vor 0cx0 (dem ende)
0x85, 0x0a, // REPORT_ID (10)
0x95, 0x06, // REPORT_COUNT (6)
0x09, 0x00, // USAGE (Undefined)
0xb2, 0x02, 0x01, // FEATURE (Data,Var,Abs,Buf)
hinzugefügt.
4. in den V-USB-Feature-Const
const uchar SendIRCodeOut = 10;
hinzugefügt.
5. In init_io
/* config Snd pin */
SND_PORT ^= _BV (SND_BIT); /* deactivate pull-ups on SND pin */
SND_DDR ^= _BV (SND_BIT); /* set snd pin as digital output */
hinzugefügt.
6. im Timer1 cor irmp_ISR()
irsnd_ISR(); //
call irsnd ISR
Hinzugefügt.
7. in usbfunctionWrite nach SetTrainedIRCode
else if ( DoWriteReport == SndIRCodeOut )
{
irmp_data.protocol = IRMP_NEC_PROTOCOL;
irmp_data.address = 0x00FF;
irmp_data.command = 0x0001;
irmp_data.flags = 0;
irsnd_send_data (&irmp_data, TRUE); // Send IR code out
eingefügt
8. in der main Func tion vor irmp_init()
irsnd_init(); // initialize irsnd
eingefügt.
9. in der configUSBIRRemoteReceiver_h
//define output pin for IRsnd:
#define USE_IrSndFunction 1 /* 1, use IRsend function (default), 0
to disable */
#if USE_IrSndFunction
#define IRSND_PORT PORTD /* PORTx - register for IRsnd output
*/
#define IRSND_BIT PD6 /* bit where IRS-diode will be connected
*/
#define IRSND_DDR DDRD /* Switch data direction register */
#endif
Es lässt sich kompilieren, aber ich weiß nicht, wie ich dem Teil dann am
besten Daten übergeben soll oder ob es überhaupt so funktioniert.
(meine C /C++ Kenntnisse sind .... mangelhaft). Vielleicht greift ja
jemand das Ganze auf und rundet es ab. (Anbei die das USB-Irmp-zip-File
mit IRsnd ergänzt.)
@ Andy P.
Was genau willst du denn erreichen? Aus Windows/Linux heraus IR codes
senden, oder empfangene codes weiterreichen?
Ich arbeite gerade an einer Version, die letzteres kann und
darüberhinaus eine Uhr zum Aufwecken des PCs und die Möglichkeit den PC
zu resetten beinhaltet. Ich hatte aber auch schon darüber nachgedacht
eine Funktion zum Senden von IR codes von Windows/Linux zu
implementieren. Wäre keine große Sache mehr.
Leider kann ich nur gelegentlich abends daran arbeiten, weswegen das
Ganze schon eine Weile dauert und auch noch eine Weile dauern wird.
Wobei die Firmware schon recht weit ist, die Host-Software ist noch die
größere Baustelle.
@Andy P.
schaut nicht so schlecht aus. Kann es leider nicht durchtesten da ich
hier kein AVR 4.x Studio habe.
Der usbHidReportDescriptor scheint richtig zu sein. Die Länge passt dann
auch.
Vom PC schickt man dann per SetFeature:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff539684(v=vs.85).aspx
die Daten zum AVR.
Der ReportBuffer ist dann:
0A >> Report ID
02 >> Protokol ID
0000 >> Adresse
0000 >> command
00 >> Flags
1
elseif(DoWriteReport==SndIRCodeOut)
2
{
3
irmp_data.protocol=IRMP_NEC_PROTOCOL;
4
irmp_data.address=0x00FF;
5
irmp_data.command=0x0001;
6
irmp_data.flags=0;
7
irsnd_send_data(&irmp_data,TRUE);// Send IR code out
8
}
Sollte dann so sein:
1
elseif(DoWriteReport==SndIRCodeOut)
2
{
3
memcpy(&irmp_data,&data[1],sizeof(irmp_data));
4
irsnd_send_data(&irmp_data,TRUE);// Send IR code out
5
}
Ist aber nicht getestet und mit irsnd habe ich gar keine Erfahrung...
Bei Delphi ist es zusätzlich wichtig ein "Packed" Record zu verwenden.
http://www.delphibasics.co.uk/RTL.asp?Name=Packed
Ich glaub, dass ist aber Visual Studio sowieso so!?
@kichi:
Ich habe beim Zusammenstellen der Platine erst versucht, das ganze in
einen ATTiny85 zu verfrachten, was mit Kampf auch geht. Dann habe ich
aber gesehen, daß die ganzen Protokolle komplett (inkl V-USB etc.) nicht
in den kleinen Speicher passen, ergo musste ein größerer 16K-AVR her.
Daraus wurde dann eine einseitige Platine nur mit
DIL-Chips+Drahtbauteilen die kaum größer als ein USB-Stick ist. Da aber
noch immer Platz war, gabs halt das Hühnerfutter für IRsend mit hinzu.
Die ganze Platine ist dann für HTPCs gedacht - entweder außen dran als
Stick oder innen drin hochkant direkt auf einen der 9-poligen
USB-Steckplätze eines Mainboards (Platine ist leicht +klein genug, um
dort sich selbst auf den Kontakten zu halten).
Und wenn das Teil schon so hardwarefertig da steht und sich um die
kontolle des HTPCs kümmert, dann kann das auch gleich die passende
Hardware sein, um sich um die andere Braune Ware zu kümmern. (Lautstärke
des AV-Verstärkers, TV-Eingangsumschaltung etc).
Bei mir soll das Teil als Empfänger für VDR unter Linux dienen. Hier
wäre es sehr einfach möglich, im Menü des VDR oder bei Einschalten des
PC auch andere Geräte zu wecken. Somit sendet der Linux-PC via USB
selbst die Signale.
Auch kann der entsprechende Daemom unter Linux auch eine
Repeaterfunktion oder ein Codeumsetzer spielen.
Theoretisch kann ein Repeater oder Codeumsetzer auch im AVR sitzen, wenn
man es nicht mit der Anzahl der Codes übertreibt. (Spontane Idee, noch
nicht zuende gedacht).
Dazu muß ich aber lirc-ersatz-Daemon von Glotzi aufbohren und dazu
werden mit Sicherheit meine Programmierkenntnisse nicht reichen. (Hab ja
oben lediglich in den Quellen "rumgeschmiert" Sorry, Hugo).
Für den Einsatz innerhalb von Windows kann ich nicht viel sagen. Hugos
Demo hab ich hier testweise am Start, um der Intention des Programmiers
zu folgen,
aber für den realen Einsatz fehlen Motiv, Gelegenheit, Knowhow und
Wille.
@Pottisch:
Vielen Dank fürs Drüberschauen. Vielleicht können wir das ja zusammen
hinbekommen: Du bohrst deine Demo-DLL um ein SendButton + ein
6byte-Eingabefeld auf und ich seh zu, daß das auf der AVR-Seite korrekt
weitergegeben wird.
Andy P.
Jetzt wirklich ungetestet, da ich hier keinen Receiver rumliegen habe!
Im AVR Source ist nun IRSND eingebaut, per USE_IRSND deaktivierbar.
Das kompelierte HEX ist für den Atmega168(p), 12MHz.
Zum IR-Senden wird PD3 verwendet.
In IRSND nur die Standard Protokolle aktiviert.
Anbei auch eine Überarbeitung der Delphi Demo wo man nun einen IR Code
zum AVR schicken kann. (Auch nicht getestet)
Frage zwischendurch da ich IRSNd noch nie benützt habe:
Kann ich einfach eine alte Fernbedienung wegen der IR Diode
ausschlachten!?
Muss diese über einen Transistor geschaltet werden oder kann ich die
Diode direkt auf den Ausgang des AVRs hängen?
EDIT:
Jetzt habe ich ganz vergessen, dass dieses Projekt mit AVR Studio 5
bearbeitet wurde!
Hugo Portisch schrieb:> Kann ich einfach eine alte Fernbedienung wegen der IR Diode> ausschlachten!?
Könnte funktionieren.
> Muss diese über einen Transistor geschaltet werden oder kann ich die> Diode direkt auf den Ausgang des AVRs hängen?
Da die IR-LED gepulst betrieben wird, empfiehlt es sich, den Strom
zwecks Reichweitenmaximierung entsprechend hochzutreiben.
Ich benutze die folgende Schaltung für IRMP seit längerem erfolgreich:
http://www.mikrocontroller.net/articles/IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder
(Bild rechts)
Gruß,
Frank
Genau diese habe ich gesehen.
Ich habe nun eine alte Mouse geschlachtet. Da sind sogar 2+1 STK IR LEDs
drinnen.
Die 2 kleineren können so mit 20-100mA betrieben werden. Datenblatt gibt
es natürlich nicht da die Diode keine Beschriftung hat...
Aber meine Idee ist sowieso die IR-Dioden direkt am Empfänger
(Fernseher, Verstärker) anzubringen. Somit ist die Reichweite kein
Problem.
Aber ich weis nicht ob die Wellenlänge usw past - muss ich testen.
Bei 20mA brauche ich die Diode nur per Vorwiderstand an PD3 anbringen.
Der Atmega kann 40mA am Ausgang und somit könnte ich die 2 Dioden
einfach parallel hängen. Dann einfach die 2 Codes nacheinander
rausschicken. Der Harman Kardon Verstärker versteht das Protokoll vom
Toshiba Fernseher sowieso nicht ;)
Also ich habe jetzt die Durchsichtige IR LED von der Mouse angebracht.
Mit einem Vorwiderstand von 200 Ohm (also ~20mA) direkt am AVR Output.
Mit dieser IR LED komme ich auf jeden Fall 1 Meter. Weiter bekomme ich
die 2 IRMP AVRs leider nicht auseinander.
Also das nächste Mal die Mouse nicht einfach in den Müll schmeißen!
Da die IR LED auch Transparent ist sollte man sie ohne Probleme am Gerät
anbringen können das auch noch die Fernbedienung funktioniert.
Nun habe ich aber ein "Problem" beim NEC Protokoll:
Mit der Fernbedienung werden diese Codes empfangen:
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0001, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0002, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0003, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0004, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0005, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0006, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0007, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0008, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0009, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0000, Flags: 0x00
Wenn ich es per IRSND versende:
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0001, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0002, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0003, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0004, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0005, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0006, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0007, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0008, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0009, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0000, Flags: 0x00
Man sieht, das statt 0x5F40 als Adresse 0x3F40 gesendet wird!?
Wenn ich als Adresse 0xFFFF eingebe kommt 0x7FFF an.
Das Command bei NEC scheint auch auf 0x00FF begrenzt zu sein. Wird halt
das Protokoll selber sein.
Wenn ich die Adressen durchteste:
>> Send: 0x0FFF, Receive: 0x0FFF>> Send: 0x1FFF, Receive: 0x1FFF>> Send: 0x2FFF, Receive: 0x1FFF>> Send: 0x3FFF, Receive: 0x1FFF>> Send: 0x4FFF, Receive: 0x2FFF>> Send: 0x5FFF, Receive: 0x3FFF>> Send: 0x6FFF, Receive: 0x3FFF>> Send: 0x7FFF, Receive: 0x3FFF>> Send: 0x8FFF, Receive: 0x4FFF>> Send: 0x9FFF, Receive: 0x5FFF>> Send: 0xAFFF, Receive: 0x5FFF>> Send: 0xBFFF, Receive: 0x5FFF>> Send: 0xCFFF, Receive: 0x6FFF>> Send: 0xDFFF, Receive: 0x7FFF>> Send: 0xEFFF, Receive: 0x7FFF>> Send: 0xFFFF, Receive: 0x7FFF
Meine Originale Fernbedienung vom Toshiba Fernseher sendet aber 0x5F40.
Beide Empfänger und Sender sind mit der letzten IRMP Version vom
20.09.2011 ausgestattet.
Hugo Portisch schrieb:>>> Send: 0x0FFF, Receive: 0x0FFF>>> Send: 0x1FFF, Receive: 0x1FFF>>> Send: 0x2FFF, Receive: 0x1FFF>>> Send: 0x3FFF, Receive: 0x1FFF>>> Send: 0x4FFF, Receive: 0x2FFF>>> Send: 0x5FFF, Receive: 0x3FFF>>> Send: 0x6FFF, Receive: 0x3FFF>>> Send: 0x7FFF, Receive: 0x3FFF>>> Send: 0x8FFF, Receive: 0x4FFF>>> Send: 0x9FFF, Receive: 0x5FFF>>> Send: 0xAFFF, Receive: 0x5FFF>>> Send: 0xBFFF, Receive: 0x5FFF>>> Send: 0xCFFF, Receive: 0x6FFF>>> Send: 0xDFFF, Receive: 0x7FFF>>> Send: 0xEFFF, Receive: 0x7FFF>>> Send: 0xFFFF, Receive: 0x7FFF
Kann ich leider nicht nachvollziehen. Unter Linux bekomme ich für jede
dieser Adressen auch diese Adresse wieder zurück, z.B.
1
./irsnd 2 5FFF 0001 0 | ./irmp
Ausgabe:
1
11111111111110101000000001111111 p = 2, a = 0x5fff, c = 0x0001, f = 0x00
Ich bekomme also das raus, was ich gesendet habe.
Bei Dir gehen im obersten Nibble die Bits kaputt, nämlich:
0 -> 0: 0000 -> 0000
1 -> 1: 0001 -> 0001 ???
2 -> 1: 0010 -> 0001
3 -> 1: 0011 -> 0001
4 -> 2: 0100 -> 0010
5 -> 3: 0101 -> 0011 ???
6 -> 3: 0110 -> 0011
7 -> 3: 0111 -> 0011
8 -> 4: 1000 -> 0100
9 -> 5: 1001 -> 0101 ???
A -> 5: 1010 -> 0101
B -> 5: 1011 -> 0101
C -> 6: 1100 -> 0110
D -> 7: 1101 -> 0111 ???
E -> 7: 1110 -> 0111
F -> 7: 1111 -> 0111
Bist Du Dir sicher bei den mit "???" markierten Stellen? Da hätte ich
nämlich eine 0 statt 1 am Ende erwartet. Dann wäre es eine Division
durch 2, d.h. eine Bitverschiebung.
So sieht es mir wie eine Verschiebung um eins, wobei das herausfallende
Bit mit dem nun obersten "geodert" ist. Kann es sein, dass das Senden
über V-USB da nicht ganz bit-transparent ist?
Vielleicht machst Du mal das Ganze auch mit dem Kommando, sende mal
0xFFFF als command.
EDIT: Quatsch, das Kommando ist bei NEC auf 0x00FF beschränkt, die
anderen 8 Bit sind zwecks Datensicherheit/Redundanz einfach invertiert.
Also Kommando zurück. :-)
Gruß,
Frank
Danke für deine Analyse!
Habe mir schon gedacht, dass da was mit den oberen Nibble vermurkst
wird.
Ich werde heute noch eine andere IR LED ausprobieren. Kann ja bei meiner
nicht sicher gehen ob es an dieser liegt. ;)
Die unteren 12 Bits werden jedoch ohne Fehler übertragen.
>> EDIT: Quatsch, das Kommando ist bei NEC auf 0x00FF beschränkt, die>> anderen 8 Bit sind zwecks Datensicherheit/Redundanz einfach invertiert.>> Also Kommando zurück. :-)>> Das Command bei NEC scheint auch auf 0x00FF begrenzt zu sein. Wird halt>> das Protokoll selber sein.
In IRSND habe ich nur das NEC Protokol reingenommen. Als ich dann auch
noch NEC16 und NEC42 reingenommen hatte funktionierte es fast gar nicht
mehr. Werde das heute nocheinmal probieren. Ein Debug kann ich leider
nicht machen somit kann ich mich nur darauf verlassen, dass mir IRMP die
richtigen Daten gibt und das 0x5F40 überhaupt stimmt.
Einen Fehler bei der Datenübergabe konnte ich nicht finden. Werde es mir
nocheinmal ansehen.
Nochmal zum IRMP Logging!
>> irmp_log (uint8_t val)
Mit wievielen startcycles ist den zu rechnen?
Ich bin der Überlegung nahe, den buf[700] von der irmp.c in die irmp.h
zu verlegen. Somit habe ich von meiner main.c auch darauf Zugriff.
Meine Idee ist statt der Ausgabe über den UART die Daten per USB zu
übertragen.
Wegen den 700 Bytes ist das aber nicht so einfach:
Zuerst füllt IRMP den buf.
Statt der Ausgabe auf den UART (cnt > ENDBITS) wird dem Host per
usbSetInterrupt bescheidgegeben das Daten verfügbar sind.
buf muss hier gelocked werden. Ansonsten würden weitere 700 Bytes nötig
sein.
Der Host holt sich dann über ein GetFeature selber die Daten vom Device
(Example VUSB: HID Data).
Nun kann der buf wieder freigeben werden um weitere Daten zu loggen.
Danach soll der Host die Daten in die '0' und '1' zerlegen um mit IRMP
kompatible zu sein.
EDIT:
>> for (i = 0; i < STARTCYCLES; i++)
STARTCYCLES ist ja eh eine Konstante (2) und somit muss ich die
beginnenden '0' nicht übertragen werden.
Hugo Portisch schrieb:> Mit wievielen startcycles ist den zu rechnen?
Das kommt aufs Protokoll an. Bei RECS80 sind es ganz wenige, bei NEC
sind es einige dutzend. Hier soll eigentlich nur verhindert werden, dass
kurze Störungen, die durchaus beim TSOP auftreten, nicht versehentlich
den Scan triggern.
> Ich bin der Überlegung nahe, den buf[700] von der irmp.c in die irmp.h> zu verlegen. Somit habe ich von meiner main.c auch darauf Zugriff.
Kannst Du natürlich machen. Ich würde den buf aber nicht verlagern,
sondern lediglich aus der log-Funktion rausziehen und damit global
machen, z.B. mit
1
uint8_tirmp_log_buf[DATALEN];
und dann in irmp.h ein:
1
externuint8_tirmp_log_buf[DATALEN];
> Meine Idee ist statt der Ausgabe über den UART die Daten per USB zu> übertragen.
Ja, schon klar :-)
> Wegen den 700 Bytes ist das aber nicht so einfach:
Oft reichen schon 256 Bytes aus, um einen kompletten Frame einzufangen.
> STARTCYCLES ist ja eh eine Konstante (2) und somit muss ich die> beginnenden '0' nicht übertragen werden.
Das ist richtig, spart 2 Bytes ;-)
Warum benutzt Du eigentlich für F_INTERRUPTS den Wert 20000? Gehe besser
mal auf 15000 runter. Sollte eigentlich reichen und auch den erzeugten
Code verkleinern, da dann teiweise 8-Bit-Counter (statt 16-Bit) reichen.
Vielleicht als Anregung:
Um den Fehler zu finden, würde ich erstmal checken, ob die
USB-Kommunikation bzgl. µC-Richtung korrekt funktioniert. Du könntest
einfach mal als Hack die IRMP_DATA-Struct an IRSND übergeben, welches
die über USB empfangenen Werte dann einfach wieder über USB
zurückschickt. Wenn das 1:1 funktioniert, tippe ich auf einen Fehler im
IRSND. Aber komischerweise kann ich den nicht reproduzieren...
Gruß,
Frank
Frank M. schrieb:> Warum benutzt Du eigentlich für F_INTERRUPTS den Wert 20000? Gehe besser> mal auf 15000 runter. Sollte eigentlich reichen und auch den erzeugten> Code verkleinern, da dann teiweise 8-Bit-Counter (statt 16-Bit) reichen.
Nur mal so zu Erinnerung: ich hatte schon mehrfach berichtet, dass der
Empfang mit INTERRUPTS != 10000 nicht funktioniert (zumindest bei mir).
Evtl. ist das beim senden genauso.
>> Vielleicht als Anregung:>> Um den Fehler zu finden, würde ich erstmal checken, ob die>> USB-Kommunikation bzgl. µC-Richtung korrekt funktioniert. Du könntest>> einfach mal als Hack die IRMP_DATA-Struct an IRSND übergeben, welches>> die über USB empfangenen Werte dann einfach wieder über USB>> zurückschickt. Wenn das 1:1 funktioniert, tippe ich auf einen Fehler im>> IRSND. Aber komischerweise kann ich den nicht reproduzieren...
Danke für den Tipp! Der war schnell umgesetzt.
1
#if USE_IRSND
2
}
3
elseif(DoWriteReport==SndIRCodeOut)// send received ir code from host
4
{
5
memcpy(&irmp_data,&data[1],sizeof(irmp_data));
6
//irsnd_send_data(&irmp_data, FALSE); // Send IR code out
7
SendINTData();
8
#endif
9
}
Es werden also die Daten vom Host gleich wieder 1:1 an den Host
zurückgeschickt ohne über IRSND oder IRMP:
Send: Protocol : IRMP_NEC_PROTOCOL, Address: 0xFFFF, Command: 0xFFFF,
Flags: 0x00
Receive: Protocol : IRMP_NEC_PROTOCOL, Address: 0xFFFF, Command: 0xFFFF,
Flags: 0x00
Und auch Danke für den Tipp mit irmp_log_buf!
Bin einfach kein C++ Programmierer...
>> Warum benutzt Du eigentlich für F_INTERRUPTS den Wert 20000? Gehe besser>> mal auf 15000 runter. Sollte eigentlich reichen und auch den erzeugten>> Code verkleinern, da dann teiweise 8-Bit-Counter (statt 16-Bit) reichen.
Das hatte ich nur drinnen, damit alle Protokolle auf dem AVR sind.
Heute habe ich aber gemerkt, dass eine Fernbedienung mit SIRCS nur gut
mit 10000 funktioniert. Bei 15000 kommt nichts gutes mehr raus.
>> Nur mal so zu Erinnerung: ich hatte schon mehrfach berichtet, dass der>> Empfang mit INTERRUPTS != 10000 nicht funktioniert (zumindest bei mir).>> Evtl. ist das beim senden genauso.
Tut leid. ich bin mit IRMP Artikel nicht so Uptodate ;)
Ich habe jetzt Sender UND Empfänger auf 10000 eingestellt.
Nun geht es:
Protocol : IRMP_NEC_PROTOCOL, Address: 0xFFFF, Command: 0x00FF, Flags:
0x00
Wenn nur IRSND auf 10000 war und IRMP auf 15000-20000. Ging es auch
nicht ohne Fehler. Wenn beide auf 10000 eingestellt sind geht es!
Gut das dass jetzt geht! Dann kann ich mir jetzt mit dem Logging
einbauen etwas Zeit lassen ;)
Ich bin auch noch auf keine Idee gekommen wie das mit IRSND am besten
umgesetzt werden soll:
Wie erkennt der AVR ob der PC nun läuft oder aus ist!?
Mein AVR Verstärker hat einen extra Code für Ein und Aus. Somit muss das
erkannt werden.
Dann wär es besser wenn die IR Codes für IRSND im EEPROM hinterlegt sind
damit IRSND gleich beim Einschalten des PCs auch die anderen Geräte
einschalten kann ohne erst auf ein Commando vom Host zu warten.
Dann bräuchte man auch noch eine variable Verzögerung (0-10 Sekunden
z.B) beim IRSND. Den ich muss dank HDMI meinen Fernseher nach dem PC
Ausschalten und beim Einschalten vor dem PC - sonst kommt es zu
Problemen. usw usw...
Danke vielmals! Wünsche noch schöne Feiertage!
Hugo Portisch schrieb:> Tut leid. ich bin mit IRMP Artikel nicht so Uptodate ;)
Das war hier im Thread nicht bei IRMP.
> Ich habe jetzt Sender UND Empfänger auf 10000 eingestellt.> Nun geht es:> Protocol : IRMP_NEC_PROTOCOL, Address: 0xFFFF, Command: 0x00FF, Flags:> 0x00>> Wenn nur IRSND auf 10000 war und IRMP auf 15000-20000. Ging es auch> nicht ohne Fehler. Wenn beide auf 10000 eingestellt sind geht es!
Ok, jetzt weiß ich wenigstens, dass es nicht an meinem Empfänger liegt,
sondern ein prinzipielles Problem ist. Es wäre schön zu wissen, woran
das liegt, da manche Protokolle nicht mit F == 10000 funktionieren.
Ging besser und schneller als ich mir gedacht habe!
Der Source ist noch nicht ganz sauber und es müsste auch in IRMP was
angepasst werden... ;)
Aber zuerst einmal ein Beispiel um Überprüfen zu können ob die Daten
überhaupt stimmen:
Die DataLength = buf_idx, sollten also Bits sein.
Die Daten sind der Inhalt von buf[DATALEN].
Stimmt das und wenn ja, was kommt Binär raus. Nur damit ich dann die
Umwandlung in den Binären String richtig mache ;)
EDIT:
Damit ich es gleich testen kann!
Hier ein Log von der OK Taste meiner Toshiba Fernbedienung. IRMP erkennt
sie nicht, einen Log bekomme ich aber:
1
ReportID : NewLogAvailable, 0x0B, Data Length (Bits) : 0x068C
Hugo Portisch schrieb:> Heute habe ich aber gemerkt, dass eine Fernbedienung mit SIRCS nur gut> mit 10000 funktioniert. Bei 15000 kommt nichts gutes mehr raus.
Wahrscheinlich gibt es da Timing-Probleme im Zusammenhang mit V-USB.
IRMP/IRSND funktionieren eigentlich ganz gut sowohl bei 10kHz, 15kHz und
auch bei 20kHz. Die Belastung des µCs steigt natürlich. Wahrscheinlich
kommen sich da irgendwann V-USV und IRMP in die Quere...
> Wenn nur IRSND auf 10000 war und IRMP auf 15000-20000. Ging es auch> nicht ohne Fehler. Wenn beide auf 10000 eingestellt sind geht es!
Ich benutze bei meinen Anwendungen meist 15kHz und habe diese Probleme
dabei nicht.
Gruß,
Frank
Hugo Portisch schrieb:> Stimmt das und wenn ja, was kommt Binär raus. Nur damit ich dann die> Umwandlung in den Binären String richtig mache ;)
Die IRMP-Log-Funktion schiebt nur Nullen und Einsen auf dem UART raus,
d.h. die Umwandlung in den "Binärstring" erfolgt noch auf dem µC. Bei
der USB-Übertragung könntest Du diese Umwandlung erst auf dem PC machen,
das schrumpft die zu übertragene Datenmenge auf ein Achtel.
> Hier ein Log von der OK Taste meiner Toshiba Fernbedienung. IRMP erkennt> sie nicht, einen Log bekomme ich aber:
Ich wandle das mal in einen "Binärstring" und schicke es anschließend in
den IRMP. Mal schauen, was da rauskommt.
Gruß,
Frank
Ich habe einen Deiner Logs mit folgendem C-Progrämmchen unter Linux in
einen "Binärstring" gewandelt:
1
#include<stdio.h>
2
3
staticvoid
4
hex2bin(intvalue)
5
{
6
inti;
7
8
for(i=0;i<8;i++)// send LSB first!
9
{
10
if(value&(1<<i))
11
{
12
putchar('1');
13
}
14
else
15
{
16
putchar('0');
17
}
18
}
19
}
20
21
int
22
main()
23
{
24
intvalue;
25
26
while(scanf("%02x",&value)==1)
27
{
28
hex2bin(value);
29
}
30
putchar('\n');
31
32
return(0);
33
}
Dieses dann compiliert als hex2bin und anschließend folgendes
aufgerufen:
./hex2bin <usblog.txt | ./irmp
Dabei kam dann folgendes raus:
1
00000010111111010100000010111111 p = 2, a = 0xbf40, c = 0x0002, f = 0x00
2
p = 2, a = 0xbf40, c = 0x0002, f = 0x01
(Die 2. Zeile ist ein NEC-Repetition-Frame)
Der Logbuffer hat also einen korrekten Inhalt. Was mir aber aufgefallen
ist, dass Du wohl den kompletten Log-Buffer sendest. Dadurch werden am
Ende noch jede Menge Nullen geschickt, die da nicht hingehören. Du
solltest daher noch die gefüllte Länge des Log-Buffers berücksichtigen.
Das ist insb. dann wichtig, wenn später der Logbuffer ein zweites Mal
verwendet wird, aber der Frame kürzer ist. Dann würdest Du noch den
verbliebenen (noch nicht überschriebenen) Rest des ersten Frames als
Datenschrott mitsenden.
Am Schluss habe ich den Frame getestet, den IRMP bei Dir nicht erkennen
konnte. Bei mir hat IRMP den Frame direkt erkannt.
Ausgabe:
1
00000010111111011000010001111011 p = 2, a = 0xbf40, c = 0x0021, f = 0x00
Danke!
Jetzt stehe ich aber etwas auf dem Schlauch!
Linux hab ich keines um es nachzustellen.
Aber soweit ich sehe wandelst du den Datenbuffer in einen Binären String
und lässt in gleich mit IRMP auswerten.
Wenn ich die Daten in einen Binären String Umwandle komme ich auf diesen
String:
Das ist jetzt vom ersten Log mit Command 0x01. Zusätzlich fehlt aber
noch am Anfang ein '00' (STARTCYCLES).
Stimmt diese Übersetzung? Kann IRMP diesen Binär String richtig
auswerten?
Kann es leider wegen fehlendem Linux selber nicht testen.
>> Was mir aber aufgefallen>> ist, dass Du wohl den kompletten Log-Buffer sendest. Dadurch werden am>> Ende noch jede Menge Nullen geschickt, die da nicht hingehören.
Oben die Logs sind zu lang, stimmt!
Der AVR sendet per Interrupt die Anzahl Bits (buf_idx) an den Host.
Danach holt sich der Host die Daten. Derzeit holt er sich dann immer 700
Bytes wegen der Buffergröße. Ich habe noch nicht Probiert, wie V-USB
darauf reagiert wenn ich jetzt nur 250 Bytes hole...
Der Buffer[700] wird aber dann mit buf_idx gekürzt. Und da ist mir oben
ein Fehler untergekommen. Ich habe alle Bits von buf_idx genommen.
eigentlich brauche ich aber nur: buf_idx - 1000 + 20 Bits.
Also aus 0x890 werden 0x4BC Bits. Dann sind hinten auch keine Nullen
mehr drann.
>> Am Schluss habe ich den Frame getestet, den IRMP bei Dir nicht erkennen>> konnte. Bei mir hat IRMP den Frame direkt erkannt.
Ich glaube da habe ich mir wieder selber ein Ei gelegt. Ich glaube meine
PowerOn Funktion hat den Code gesperrt...
Hugo Portisch schrieb:> Linux hab ich keines um es nachzustellen.
Es ging mir ja nur ums Prinzip.
> Wenn ich die Daten in einen Binären String Umwandle komme ich auf diesen> String:>
1
000000000000000000...
Dieser ist nicht korrekt. Du hast die Bytes mit MSB first in den
Binärstring gewandelt, Du musst es aber mit LSB first machen, deshalb
hatte ich oben in meiner Funktion hex2bin() extra den Kommentar gesetzt
;-)
Also: Erst das unterste Bit rausschreiben, das höchstwertigste erst am
Schluss eines jeden Bytes.
> Das ist jetzt vom ersten Log mit Command 0x01. Zusätzlich fehlt aber> noch am Anfang ein '00' (STARTCYCLES).
Ja, die beiden Nullen sollten auch noch mit rein. Und dann am Ende noch
ein '\n' um die Zeile abzuschließen. Wenn Du dann noch vor Deine eigenen
Kommentar-Ausgaben noch ein Kommentarzeichen '#' setzt, wäre es perfekt.
Siehe dazu auch die Beispiel-Log-Dateien unter IR-Data/*.txt
> Kann es leider wegen fehlendem Linux selber nicht testen.
Eine irmp.exe für Windows ist im IRMP-Paket dabei, Du kannst das also
testen mit
irmp.exe <irgendwas.txt
bzw.
irmp.exe -v <irgendwas.txt
> Der Buffer[700] wird aber dann mit buf_idx gekürzt. Und da ist mir oben> ein Fehler untergekommen. Ich habe alle Bits von buf_idx genommen.> eigentlich brauche ich aber nur: buf_idx - 1000 + 20 Bits.> Also aus 0x890 werden 0x4BC Bits. Dann sind hinten auch keine Nullen> mehr drann.
Prima.
> Ich glaube da habe ich mir wieder selber ein Ei gelegt. Ich glaube meine> PowerOn Funktion hat den Code gesperrt...
:-))))
Gruß,
Frank
Hello,
Can someone confirm that the ON/OFF function is working with an RC6
remote? (Generic PC-MCE remote with RC6 code).
All the keys of the remote work as they should, but the ON/OFF button
doesn't do nothing.
By using the demo program I can see that the power code is inserted in
the EEPROM (Address 0x000F, Command 0x040c) but still it won't do
nothing.
Just for testing, to be sure that the circuit or the uC aren't damaged,
I've tried with an RC5 remote with the default .hex file and it works!
Is it something else that should be enabled in the configuration besides
enabling the RC6 code?
>> Is it something else that should be enabled in the configuration besides>> enabling the RC6 code?
No, I don't think so.
But I remember that there where some problems with RC6 and IRMP because
of missing logs/hardware. I don't know if this got already fixed.
You can try to clear the trained poweron code by the options dialog of
the dll. After this again the first decoded IR code will be stored as
poweron code. Or you deaktivate the PowerOn function and check if the
received IR code is changing when pressing the button multiple times on
the remote.
If this will not help:
I currently working on implementing the IR log function by USB.
For this I uploaded a beta for Atmega168(p) and Atmega8.
Flash this HEX file on the device and use the new included
'USB_IR_Remote_Receiver_Demo.exe' from the archive.
Each received IR code will be stored in a text file 'IRMP_Log.txt'
located in the same folder like the exe. This text file can be decoded
by 'irmp.exe' (included in the IRMP package) itself:
>> D:\Eigene Datein\VB\AVR_IRMP>irmp.exe <IRMP_Log.txt>> ------------------------------------------------------------------->> # OK>> ------------------------------------------------------------------->> # 29.12.11 15:35:55>> 00000010111111011000010001111011 p = 2, a = 0xbf40, c = 0x0021, f = 0x00
Please remember that the poweron function will block the trained code.
So may clear the trained code and use another dummy button on the remote
- just for logging.
I can't work on my receiver anymore as I've finally installed it into my
HTPC, so I'm sorry but I can't try the new hexfile.
After a few more tries I gave up trying to make the RC6 PowerOn function
work, so I programmed RC5+RC6 codes and currently use another remote
(RC5) to power ON/OFF the HTPC.
But I can tell you that by using the dll it was impossible to change the
PowerOn code: Once you erased the RC6 PowerOn code it wouldn't accept it
anymore.
Ich habe nun den Artikel USB IR Remote Receiver wieder etwas
überarbeitet.
Neu: IRMP Logging über die USB Schnittstelle.
Es können nun die Rohdaten des IR Signals auch über USB (vorher nur über
RS232) geloggt werden. Dazu einfach den Source mit IRMP_LOGGING = 1 neu
kompilieren.
Ich hoffe ich bekomme nicht zu viel haue von Frank M. weil ich sein IRMP
etwas "plump" umgeschrieben habe... ;)
Hallo Portisch!
Ich kenn dich aus dem DVBViewer Forum. Ich hab selbst ein Inputplugin
(X10) für mehrere Hosts geschrieben. DVBViewer und Girder sind OK. Für
EventGhost fehlten mir bisher die Informationen. Die wollte ich mir nun
aus der Source von USB_IR_Remote_Receiver.dll raussuchen. Die ist im
Download nicht dabei?
Wenn du die nicht als Ganzes freigeben möchtest wäre ich dir dennoch für
ein par Hints dankbar.
Grüße erwin
erwin@DVBViewer schrieb:> Für>> EventGhost fehlten mir bisher die Informationen. Die wollte ich mir nun>> aus der Source von USB_IR_Remote_Receiver.dll raussuchen. Die ist im>> Download nicht dabei?
Hallo erwin!
Nein, der Source der DLL ist nicht mit dabei. Die DLL selber hat aber
auch nichts mit EventGhost zu tun. Dafür ist das Plugin "__init__.py"
zuständig.
Dieses Plugin lädt die DLL wie ein normales Programm über die
"InitPAnsiChar" Funktion. Über eine Callback Funktion werden die Daten
an EventGhost übergeben. Die InitPAnsiChar und InitNative sind für
externe/andere Programme damit sie die DLL verwenden können. (Die
Funktionen sind im PDF beschrieben)
Dieses Plugin habe ich selber aus verschiedene Plugins die bei
EventGhost dabei waren zusammen gebaut...
Hugo Portisch schrieb:> Neu: IRMP Logging über die USB Schnittstelle.> ...> Ich hoffe ich bekomme nicht zu viel haue von Frank M. weil ich sein IRMP> etwas "plump" umgeschrieben habe... ;)
Hast Du das mit Frank abgestimmt, damit er die Änderungen übernimmt?
Jetzt kann man den IRMP-Teil im Receiver nicht mehr so ohne weiteres via
DropIn-Update aktualisieren.
Prinzipiell ist das USB-Logging eine gute Sache, mich stört aber der
IRMP-Fork.
Dank dir für die schnelle Antwort.
Ich schicke mal voraus: Python ist total neu für mich.
Also ich hab dich jetzt mal so verstanden: EventGhost besteht nicht auf
speziell exportierte Funktionen wie etwa DVBViewer und Girder. Das
steckt in der "__init__.py". ???
> Über eine Callback Funktion werden die Daten an EventGhost übergeben.
???
Bei einem DVBViewer-Input-Plugin wird ja die Adresse einer
Callbackfunktion vom DVBViewer durch den Aufruf einer speziellen
Funktion die die DLL exportieren MUSS seitens des DVBV übergeben. Wie
ist das bei EventGhost?
erwin
Dirk W. schrieb:> Hast Du das mit Frank abgestimmt, damit er die Änderungen übernimmt?
Hugo hatte mich wg. dem Logging bereits vor Weihnachten angeschrieben,
ich hatte aber über die Feiertage keine Zeit, ihm zu antworten. So hat
er es erstmal allein eingebaut, um es überhaupt schon mal zum Laufen zu
bekommen.
Ich werde mir Hugos Änderungen näher anschauen und dann in Abstimmung
mit ihm versuchen, eine allgemeinere Lösung für das USB-Logging zu
finden, so dass der Source weiterhin einheitlich bleibt.
> Jetzt kann man den IRMP-Teil im Receiver nicht mehr so ohne weiteres via> DropIn-Update aktualisieren.
Das wird demnächst wieder gehen, keine Sorge.
> Prinzipiell ist das USB-Logging eine gute Sache, mich stört aber der> IRMP-Fork.
Es wird keinen Fork geben. Hugo hat da nichts im Alleingang gemacht.
Betrachte Hugos Implementation des Loggings über USB erstmal als ersten
Prototyp.
Gruß,
Frank
P.S.
Ich verfolge diesen Thread sowieso, bin daher immer auf dem Laufenden
:-)
Frank M. schrieb:> Es wird keinen Fork geben. Hugo hat da nichts im Alleingang gemacht.> Betrachte Hugos Implementation des Loggings über USB erstmal als ersten> Prototyp.>> Gruß,>> Frank
Danke!
Genau so war es gedacht!
Ich habe um es erst einmal überhaupt umzusetzen etwas unschön so
umgebaut.
Ist nicht Sinn der Sache das es so bleibt.
Mit einem neuem IRMP_LOGGING_USB Kompilerswitsch in der irmpconfig.h
könnte man das schon gut lösen. Aber wie gesagt - ich bin hier nicht der
richtige um das zu Entscheiden (auch zwecks fehlendem können)
@erwin
> Ich schicke mal voraus: Python ist total neu für mich.
War es für mich auch. war eine ganz schöne Bastelei um das Plugin für
EventGhost zu schreiben.
Beim Start von EventGhost werden alle Plugins in den Unterordnern
gesucht ("__init__.py"). Je nach optionen wird dann das Plugin geladen
oder halt nicht.
Dank Dir nochmal Hugo!
Mein Inputplugin läuft jetzt u.a. auch mit EventGhost. Mit den richtigen
Hinweisen war das dann auch nicht mehr allzu schwer. Der Punkt war halt
dass EventGhost nicht selbst - wie DVBV oder Girder - eine
Calbackfunktion installlieren so dass man die Signatur der
Installationsfunktion kennen muss und entsprechend in der DLL benutzen
muss - sondern das dies das Script "__init__.py" tut, welches man selbst
erstellt, d.h. man kennt alle benötigten Signaturen und braucht evt.
auch die DLL nicht mehr zu verändern sondern kann z.B die bereits für
den DVBV bereitgestellte Funktion "SetCallback" weiter nutzen.
Hallo,
ich habe schon länger nach einer Lösung gesucht um meinen guten alten
seriellen PIC12c509 IR-Empfänger zu ersetzen der schon gut 12 Jahre alt
ist. Dabei bin ich nun hier über das geniale Projekt gestolpert,
allerdings hatte ich mir in den Kopf gesetzt das ganze auf
minimalistischer Hardware laufen zu lassen. Das könnte ggf. auch für
andere interessant sein, deshalb habe ich das mal zusammengeschrieben.
Ich habe Hugos aktuelle Quellen angepasst (USB Infrarot Receiver V1.8
vom 02.01.2012), so dass sie sich für einen ATtiny85 kompilieren lassen.
Viel war wirklich nicht mehr zu tun - was gefehlt hat war neben kleinen
Änderungen durch die andere Hardware die Synchronisierung für V-USB, das
wollte zunächst einfach nicht funktionieren bis ich über George
Ruinellis Seite gestolpert bin, er hat hier beschrieben was für den
ATtiny fehlt:
http://www.ruinelli.ch/how-to-use-v-usb-on-an-attiny85
Vorhanden war bereits ein "USB-Dongle" welches bislang nur mal zur
Belustigung von Kollegen diente ("Capslocker"), daran habe ich lediglich
einen Infrarotempfänger angelötet. Der Schaltplan ist als Bild im
angehängten Zip enthalten, das soll nicht als Referenzdesign dienen,
siehe Warnungen :)
Eckdaten:
* der ATtiny85 ohne Quarz mit V-USB, mit dem internen Oszillator
bei 12.8MHz
* IRMP mit 15k Interrupts/s (andere Werte habe ich nicht getestet)
Im Gegensatz zur Originalhardware nicht vorhanden sind derzeit:
- Bootloader
- Remote-Wakeup
Getestete Fernbedienungen (IR-Protokolle):
* Standard Hauppauge (RC5)
* Panasonic TV (KASEIKYO)
* mit Tevii Sat-Karte gelieferte Fernbedienung (NEC)
PC-seitig auf einem Linux-PC in Verwendung:
* irmplircd von Dirk W. als 1:1-Ersatz für den original lircd
* lirc-clients: VDR und lircrc/irexec
Das ganze läuft hier seit zwei Tagen störungsfrei und hat meinen
seriellen Empfänger somit einfach 1:1 ersetzt.
Ein paar Warnungen zum Schaltplan:
- Der ATtiny läuft bei ~3.6V / 12.8MHz außerhalb der Atmel-Spec, die
Spannungsreduktion mit zwei Dioden statt Verwendung von Z-Dioden in
D+/D- ist eine Notlösung weil ich schlicht keine hatte als ich das
zusammengelötet habe - aber lieber die USB-Spec als die Atmel-Spec
erfüllen wollte um meine restliche Hardware zu schützen. Status:
"works for me", keine Garantie.
- aktuell benutze ich statt dem beschriebenen TSOP1738 einen unbekannten
angesteckten IR-Empfänger (mit 1.2m Kabel und 3.5mm Klinke, wurde bei
einer Sat-Karte mitgeliefert). Meinen letzten TSOP1738 habe ich mir
aus Versehen zerschossen, und zerschneiden möchte ich das Kabel des
Empfängers nicht, deshalb ist der Chip unbekannt. Der IR-Empfänger ist
aber ebenfalls Active Low und die Schaltung sollte damit auch
problemlos mit den TSOPxxxx laufen
Die im Zip-File enthaltenen Dateien können entweder einfach so 1:1 in
Hugos Originalsourcen kopiert werden und lassen sich dort mit einem
"make" von avr-gcc übersetzen, ein kleines aus V-USB übernommenes
Makefile ist vorhanden. AVR Studio benutze ich nicht, für meine Zwecke
war das bislang nie nötig, ich verwende hier einen Debian-PC mit avr-gcc
V4.3.5 und avr-libc v1.6.8.
Ich habe mir Mühe gegeben die Änderungen minimalinvasiv durchzuführen
und frage über Direktiven ab für welchen Controller kompiliert wird, der
Source übersetzt sich hier genauso wenn ich atmega8 / 12MHz einstelle,
die wenigen Änderungen könnten also theoretisch auch im
Originalsourcecode übernommen werden falls Interesse besteht -> Hugo,
ich weiss nicht was Du davon hälst.
Das Verzeichnis "libs-device" stammt aus den aktuellen V-USB - Quellen.
Da der AtTiny85 nur PORTB besitzt ändert sich natürlich auch die Config,
hier bin ich mir auch nicht sicher ob es Sinn macht so etwas über
Direktiven abzufragen, ich habe es jetzt mal so umgesetzt. Feedback ist
gerne gesehen.
Gruß,
Lars
Lars, coole Sache und danke für dein Feedback. Besonders interessant
finde ich, dass bei dir der Empfänger auch mit 15k HZ läuft. Den
ruinelli Link zum Sync sollte man sich wohl näher anschauen, evtl
klappts dann auch künftig mit F != 10k HZ
Lars Bürding schrieb:> Originalsourcecode übernommen werden falls Interesse besteht -> Hugo,>> ich weiss nicht was Du davon hälst.
Das Problem dabei ist, dass ich es selber nicht testen kann. Wenn ich
also was ändere kann ich nicht garantieren ob's auch geht ;)
Wenn ich wieder etwas Zeit habe werde ich mir die Änderungen ansehen und
wahrscheinlich auch übernehmen. Wegen den IRMP_Logging steht sowieso
noch eine Änderung aus.
Generell arbeite ich im Moment mit dem Atmega168, da der Atmega8 eh
schon zu wenig Speicher für IRMP mit allen Protokollen hat.
Aber ATtiny (besonders weil ohne Quarz) ist eine gute Alternative!
Hallo!
Da ich das erste mal einen µC programmiere, frag ich lieber noch einmal
genauer nach:
Ich habe einene Atmega168 in Verwendung - im Paket ist aber nur die
Datei für den Atmega168P enthalten. --> Muss daher jetzt neu kompiliert
werden? Was ist dabei zu beachten? Welche Fuses muss ich bei mir setzen?
Also die Firmware hab ich nun aufspielen können.
Leider habe ich noch ein Problem:
Die Software/das Plugin empfängt keinen einzigen IR-Code (mehrere FB
probiert)! Die LED blinkt aber auf und signalisiert damit, dass etwas
empfangen wird. Kann es trotzdem an der IR-Empfängerdiode liegen?
Ich habe die "SFH5110-36" in Verwendung.
Willi schrieb:> Leider habe ich noch ein Problem:>> Die Software/das Plugin empfängt keinen einzigen IR-Code (mehrere FB>> probiert)! Die LED blinkt aber auf und signalisiert damit, dass etwas>> empfangen wird. Kann es trotzdem an der IR-Empfängerdiode liegen?>> Ich habe die "SFH5110-36" in Verwendung.
Äh... welche LED?
Im HEX-File was im Paket dabei ist sind nur die Standard Protokolle in
IRMP aktiviert.
Um zu überprüfen ob wirklich IR Signale reinkommen kannst du auch die
Hexdatei "_with_IRMP_Logging" verwenden.
Hier werden alle empfangene IR Signale dann Roh an den PC gesendet egal
ob das Protokoll in IRMP mit drinnen ist oder nicht.
Um die Daten zu empfangen muss der Optionen Dialog der DLL geöffnet
sein.
Die Textdatei kannst du dann einfach hier anhängen.
http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver#IRMP_Logging
Hugo Portisch schrieb:> Für die Led-Anzeige müsste es reichen wenn du die Kathode der Led an dem> IR Dioden Ausgang hängst. Die Led Anode über einen Widerstand (~560-1000> Ohm) auf +5V hängen. Den Widerstand halt nicht zu gering auswählen> ansonsten kann es zu Problemen der Stromversorgung über den USB-Port im> Ruhezustand/Standby kommen.
Hallo!
Ich habe nach dem darunter geposteten Lochrasterlayout aufgebaut mit
einer LED, die den Empfang anzeigt. Mein LED Vorwiderstand ist 1,2k.
Also auch mit einem Tsop 4838 ergibt sich das gleiche Bild. Es wird
etwas empfangen - IRMT loggen geht - aber nicht vom Plugin erkannt /
übersetzt und an Eventghost oder DVBViewer weitergeleitet. Ich habe eine
Fernbedienung einer TechnoTrend SatKarte, Technisat Receiver, Philips TV
und Philips Hifi-Anlage probiert - nix.
> Im HEX-File was im Paket dabei ist sind nur die Standard Protokolle in> IRMP aktiviert.
Ach ich dachte bei dem HEX des atmega 168 ist alles aktiviert weil der
einen größeren Speicher hat? Wenn ich die irmpconfig.h in AVR Studio 4
angepasst habe, muss ich danach "main.c" öffnen und neu kompilieren
(sorry, hab vorher noch nie etwas mit µC gemacht...)? Kann ich AVR
Studio 4 nehmen oder muss es die 5 sein?
Anbei noch ein IRMP Logfile (TT steht für Technotrend und die Zahlen für
die Nummerntasten)
Dann hat das USB Logging schon mal was gebracht! ;)
Ich habe dein IRMP_Log.txt durch die "irmp.exe" gejagt und raus kommt
das:
>> C:\Temp\löschen>irmp.exe <IRMP_Log.txt>> ------------------------------------------------------------------->> # TT1>> ------------------------------------------------------------------->> # 17.01.12 21:23:39>> 0>> 1010100001>> 1110101000011 p = 7, a = 0x0015, c = 0x0003, f = 0x00
Also Protokoll 7 == RC5!
Das ist Standardmäßig im Receiver nicht mit drinnen! Ich hänge dir
einmal das HEX File für den Atmega168(p) an wo RC5 mit drinnen ist.
Mit AVR Studio v5 kann man sich ansonsten schnell und einfach das HEX
Files selber erstellen. Bei der v5 braucht man kein extra WinAVR mehr.
Der Download ist halt dann um einiges größer. Programmieren und Debuggen
geht aber um einiges besser als bei der v4.
Also einfach v5 installieren und fertig!
mfg
Portisch
Vielen Dank!
Endlich funktioniert alles!
Aber warum sind eigendlich RC5 und die ganzen anderen Protokolle
standardmäßig deaktiviert bei dem atmega168p? Am Speicher kanns ja nicht
liegen ;)
Hallo!
Ich hab leider noch ein Problem mit der PowerOn Funktion! Sie
funktioniert einfach nicht.
Im Plugin kann ich problemlos eine Taste anlernen (bei mir ein
RC5-Code). Ich habe eine LED verbaut, die den Empfang von IR-Signalen
anzeigt - und die blinkt munter - also wird die Schalung auch wenn der
PC aus ist mit Spannung versorgt. Als Optokoppler verwende ich den KB817
von Reichelt mit einem Vorwiderstand von 560 Ohm. Der Optokoppler hängt
an PC5 des Atmega168p.
Kann ich den Fehler noch irgendwie eingrenzen? Könnte ich am Ausgang PC5
mit dem Multimeter was sinnvolles messen oder ist die Schaltzeit zu kurz
dafür?
Wenn ich Spannung kennen würde, die der Atmega an den Optokoppler
anlegen müsste, könnte ich ja noch testen ob es am Optokoppler hängt...
Also da der AVR mit 5V versorgt wird, werden natürlich auch 5V an den
Optokoppler ausgegeben. Bei 560 Ohm also ~9mA.
Die Schaltzeit ist um ca. 250ms. Das wirst du mit einem Messgerät nicht
sehen. Ich habe ja einen Optokoppler im DIL Gehäuse und ich habe zum
Testen einfach eine LED statt den Optokoppler eingesetzt.
Dann kann man schön kontrolieren ob es geht.
Der KB817 scheint SMD zu sein, aber man kann ja trotzdem testweise
einfach eine LED statt den Optokoppler an Pin 1 u 2 anlöten.
Wenn es noch immer nicht geht am besten einmal eine andere Fernbedienung
die nicht RC5 hat probieren!
Auch ist die Polarität am Optokopplerausgang wichtig da es sich um einen
Transistorausgang handelt.
Ich glaube, dass am Mainboard beim PowerOn 5V durchgeschaltet werden.
Die 5V müssen an Pin 4 des KB817 liegen. Der Pin3 ist dann der
geschaltete Ausgang des Optokopplers.
chris16 schrieb:> Ist es möglich auch das MCE Protokoll in der nächsten Version mit auf zu> nehmen.> Wäre toll wenn das ohne viel aufwand gehen würde.
Soweit ich das Verstehe wird das nicht so einfach gehen. Es müsste ein
Programm her, dass die IR Signale für die richtigen MCE Befehle
auswertet und sozusagen übersetzt.
Ich glaube die MCE Befehle sind globale Befehle.
Die DLL muss aber von einem Programm geladen werden...
Ich habe aber keine MCE Fernbedienung und kann nichts probieren.
Ich hoffe du meinst auch den USB IR Remote Receiver. Andere Empfänger
können von der DLL sowieso nicht verwendet werden.
Werden die Tastendrücke der Fernbedienung überhaupt erkannt!? Soweit ich
das jetzt rausgefunden habe sollte das IR Protokoll das RC5 und/oder RC6
sein.
Hugo Portisch schrieb:> Ich hoffe du meinst auch den USB IR Remote Receiver.
Ja ich meine den hier Beschriebenen USB IR Remote Receiver,den ich mir
aufgebaut habe.
An dieser Stelle möchte ich mich für dieses super Projekt Bedanken.
Auch für Anfänger wie ich es bin gut nachzubauen.
Das was ich im Netz gefunden habe soll das MCE Protokoll über RC5/RC6
anzusteuern sein,leider funktionieren die RC5/RC6 Protokolle die jetzt
schon dabei sind nicht.
Ich steuer mein J.River MediaCenter das eigendlich MCE empfangen kann
über Eventghost.
Hallo Hugo Portisch,
bis jetzt bin ich immer so vorgegangen
1. Code in FB gesetzt (Medion FB)
2. DLL Demo gestartet um zu sehen welches Protokoll gesendet wird
(RC5/RC6 oder aber RC6a)
3. J.River MediaCenter geöffnet um zu sehen ob etwas empfangen wird
In wie weit würde mir ein Loggin da weiter helfen das ist mir nicht ganz
schlüssig?
Ok, schön langsam kommt Licht in die Sache.
Also kannst du mit der DLL Demo die IR Befehle der Fernbedienung
auswerten!?
Wenn IRMP keine Daten ausspuckt kann man mit dem Log den RAW IR Code
auswerten und schauen ob ein Decoden mit IRMP überhaupt möglich ist.
Die DLL selber unterstützt aber das J.River MediaCenter nicht.
Jedoch habe ich gesehen, dass das Mediacenter Inputplugins unterstützt.
Mal sehen ob da was möglich ist...
Wenn ich im Code IRMP Logging = 1 setze,habe ich natürlich die
Möglichkeit jeden Tastendruck der FB auszuwerten.
Aber eine Hilfe für J.River ist das nicht,da ich keine FB + Empfänger
für das senden von MCE Code habe.
Aber wie Du oben schon geschrieben hast besitzt der J.River ein MCE
Plugin der auf jeden Fall dieses Protokoll empfangen kann.
Ich kenne mich zwar nicht aus aber wenn der Aufwand nicht zu groß ist
wäre es Möglich in der bestehenden Firmware ein MCE Protokoll
einzubinden.
Ich hoffe ich habe mich nicht allzu umständlich Ausgedrückt,Danke
@Hugo: hättest du das gleich gesagt. ich hab hier noch eine
USB-Stick-große Leerplatine, alles mit THT-Bauteilen zum Dranrumbasteln.
Ich habe das so angelegt, daß man auch einen ISP hat, den USB-Anschluß
gegen eine 4pol. Buchsenlseite für
direktes-auf-den-USB-Port-des-Mainbords-stecken usw. IRsend und
PWR-Switch kann da natürlich auch bedient werden.
Allerdings sind die einzelnen Kompenenten an anderen Pins, sodaß man vor
Compilieren noch ein paar Config-Werte korrigieren muß.
Andy P.
also ich hab jetzt mal ein bisschen rumprobiert aber entweder ist es
schon zu spaet bzw. ich bin zu doof oder ich hab hier 1-2 bugs gefunden.
beim parsen der version (vermutlich direkt in der DLL) kommt teilweise
bitmuell mit. ich vermute jetzt einfach mal das nicht oder falsch
terminiert wird (\0). aber das ist mir eher so nebenbei aufgefallen und
eigentlich auch nicht weiter schlimm.. wollte es nur loswerden :P
das zweite ist:
beim ersten start sah ich einen bereits gespeicherten IR code fuer
poweron. diesen habe ich geloescht und wollte dann halt die
entsprechende taste meiner FB dafuer verwenden aber weder im settings
dialog noch ausserhalb wird die taste gespeichert. habe sowohl die
console app als auch die C# und delphi app getestet. (vllt. liegt auch
hier ein problem in der DLL vor?)
weder "Read Trained IR Code" noch "Received IR Code" zeigen irgendwas
an.
das empfangen scheint ansich aber zu funktionieren da ich im settings
dialog nach den descriptions gefragt werde und die dann auch im log
auftaucht.
ich bin mir jetzt nicht 100% sicher ob es vllt. doch an "mir" liegt
daher meine frage jetzt: kann das jemand anderes azch
bestaetigen/reproduzieren?
so.. kleines update:
das problem mit den IR codes hat sich erledigt.
F_INTERRUPTS muss fuer meine wunsch FB 15000 sein, nicht 10000. %)
btw. es gibt updates fuer IRMP und V-USB, scheint beides bei mir zu
laufen so far.
es waere auch toll wenn du/wir das IRMP_LOGGING unberuehrt lassen
wuerden und alternativ IRMP_LOGGING_USB benutzen wuerden, so kann man
auch weiterhin UART o.ae. benutzen. dadurch wird die firmware ja nicht
groesser und ich denke auf dauer wird das maintainen/updaten auch
einfacher.
ich hab das ganze jetzt mal ein bisschen unter linux getestet und habe
festgestellt das:
sobald ich bestimmte tasten druecke (z.b. 4, 5 u. 6, habe alle noch
nicht getestet) wird das device aus unerklaerlichen gruenden resetet.
<snip>
</snip>
ich habe das ganze mit 4 fernbedienungen getestet, alle 4 haben
unterschiedliche protokolle, sowohl mit als auch ohne USB autosuspend.
das ist sicherlich nicht gewollt/normal allerdings bin ich mir jetzt
nicht sicher ob es an diesem prokelt oder an V-USB liegt. IRMP wuerde
ich jetzt erstmal ausschliessen. auch mit den neusten versionen von IRMP
und V-USB laesst sich das ganze reproduzieren, getestet mit kernel
3.3.1. mit und ohne bootloader getestet.
FUSE bits:
High: 0xD4
Low: 0xFF
Extended: 0xF8
die schaltung entspricht "ganau" der des projekts ausser das ich einen
6pin header (AVR ISP) zum programmmieren verwende anstatt ponyprog/LPT.
irgendwelche ideen?
Ich kann das Problem mit dem USB-Disconnect bei mir hier auch
reproduzieren. Aber nur, wenn irmplircd nicht läuft:
1
Apr 15 22:14:40 server kernel: usb 3-5.5: USB disconnect, device number 5
2
Apr 15 22:14:41 server kernel: usb 3-5.5: new low-speed USB device number 11 using ehci_hcd
3
Apr 15 22:14:41 server kernel: usb 3-5.5: New USB device found, idVendor=16c0, idProduct=05df
4
Apr 15 22:14:41 server kernel: usb 3-5.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
5
Apr 15 22:14:41 server kernel: usb 3-5.5: Product: USB IR Remote Receiver
6
Apr 15 22:14:41 server kernel: usb 3-5.5: Manufacturer: www.dvbviewer.info
7
Apr 15 22:14:41 server kernel: generic-usb 0003:16C0:05DF.0008: hiddev0,hidraw4: USB HID v1.01 Device [www.dvbviewer.info USB IR Remote Receiver] on usb-0000:04:06.2-5.5/input0
falls es hilft:
es werden genau 3 keypress events akzeptiert danach gibt es nen komplett
reset vom device.
*edit
bevor ich es vergesse..
ganz ohne IRMP passiert das nicht. ich werde jetzt noch versuchen
herauszufinden warum und vorallem wo genau der fehler liegt.
Christian Ruppert schrieb:> falls es hilft:> es werden genau 3 keypress events akzeptiert danach gibt es nen komplett> reset vom device.
Dann liegts wohl daran, daß die Events nicht abgeholt werden und
irgendwas intern überschrieben wird.
Dirk W. schrieb:> Christian Ruppert schrieb:>> falls es hilft:>> es werden genau 3 keypress events akzeptiert danach gibt es nen komplett>> reset vom device.>> Dann liegts wohl daran, daß die Events nicht abgeholt werden und> irgendwas intern überschrieben wird.
also ich habe das nochmal mit dem irmplcd (hidraw) getestet und auch
dann passiert das.
und meine vorherige aussage muss ich nochmal korrigieren:
auch bei einem oder zwei keypress events passiert das, dauert aber nen
moment und wenn ich das richtig sehe auch nicht immer...
es liegt definitiv an:
usbSetInterrupt(&replyBuf[0], sizeof(irmp_data) + sizeof(uchar));
in void SendINTData(void) der main.c
und es muesste normal betriebssystem unabhaengig sein, d.h auch unter
windows muesste es zu diesem fehler kommen.
Dirk W. schrieb:> Dann liegts wohl daran, daß die Events nicht abgeholt werden und> irgendwas intern überschrieben wird.
Richtig! Es liegt an der V-USB Funktion: usbInterruptIsReady
Ändert einmal das in der SendINTData ab:
1
while(!usbInterruptIsReady())usbPoll();// check if USB int is ready
2
usbSetInterrupt(&replyBuf[0],sizeof(irmp_data)+sizeof(uchar));// send ReportID + IR data
Neu:
1
usbSetInterrupt(&replyBuf[0],sizeof(irmp_data)+sizeof(uchar));// send ReportID + IR data
Das "while (!usbInterruptIsReady()) usbPoll();" überprüft ob der
USB-Interrupt vom Host PC bereit ist. Je nach Datenmenge * Durchläufe
bleibt es hier dann hängen wenn die Daten nicht abgeholt werden ->
Watchdog -> Reset.
Bei diesem Fall sind es ca. 3 Durchläufe, dann hängt es.
Wenn man das Warten auf den Interrupt deaktiviert werden die Daten
einfach gesendet. Egal ob der Host sie abholt oder nicht -> Datenverlust
möglich, aber es sollte hier dann nicht mehr hängenbleiben. Der
Datenverlust ist jetzt hier nicht so wichtig.
Das ist mir schon länger Zeit aufgefallen und ist auch schon längst
geändert worden - aber halt noch nicht offiziel hochgeladen!
Hallo zusammen,
ich war ja seit längerem dabei eine Host-Anwendung zu schreiben mit dem
Ziel den Empfänger (um einige Funktionen erweitert) in MediaPortal
einzubinden. Je umfangreicher die Firmware wurde, desto öfter tauchten
Probleme auf, d.h. die Hardware wurde nicht (mehr) richtig von Windows
erkannt, funktionierte nur eine zeitlang und ähnliches.
Daher habe ich beschlossen den ATMEGA168 samt V-USB durch einen
STM32L15x mit USB-Device-Funktionalität in Hardware zu ersetzen. Zu
diesem Zweck habe ich ein kleines Adapterplatinchen mit dem STM32
entwickelt, das statt dem MEGA168 auf die vorhandene Platine bestückt
wird. Die restliche Hardware kann also gleich bleiben. Mit der Software
möchte ich demnächst beginnen.
Falls jemand das Ganze mit dem MEGA168 weiter entwickeln will habe ich
einen älteren Stand der C#-Host-Anwendung angehängt, die mit Hugo's
Firmware läuft und gänzlich ohne seine DLL auskommt und stattdessen nur
Windows-Funktionen nutzt. Soweit hat das immer recht gut funktioniert,
da ich das aber aus einem älteren Stand rekonstruiert (neue
Funktionalitäten wieder entfernt) habe, ist nicht ausgeschlossen, dass
es an ein paar kleineren Stellen klemmt.
Bisher lief das immer nur unter XP, andere Windows-Versionen wurden
nicht getestet, müssten aber auch gangbar zu machen sein.
Viel Spass damit und vielen Dank an Hugo für die gute Basis.
Ich habe mir mal den Source angesehen. Da ist das drinnen was ich immer
schon einmal machen wollte - mich aber nie gefreut hat: Ein Mapping für
die IR-codes auf globale Tastendrücke (Tastatur Emulator).
Am besten wär es wenn das Programm mit dem originalen USBIRRR kompatibel
bleibt. Die Sachen wie RTC kann man dann im Programm je nach Empfänger
deaktivieren/aktivieren.
Um die Empfänger auseinander zu kennen würden sich die Daten der HID
Reports anbieten. Man kann sich für jedes HID Gerät die verfügbaren
ReportIDs anzeigen lassen.
Wenn nun die RTC eine neue zusätzliche ReportID hat, die der Originale
nicht hat kann man einfach in der Anwendung die Funktion
aktivieren/deaktivieren.
Am besten wär es noch bei den ReportIDs etwas höher zum Zählen
anzufangen.
Z.B. bei 20 statt einfach bei 10 weiter zu zählen.
Beim Originalen geht es aktuell bis ID 9. Wenn deine dann erst bei 20
Anfangen hätte man noch einen Buffer um dem Originalen in Zukunft
erweitern zu können.
mfg
Portisch
Hugo Portisch schrieb:> Am besten wär es wenn das Programm mit dem originalen USBIRRR kompatibel> bleibt.
So war es ursprünglich gedacht und hat auch so funktioniert.
Hugo Portisch schrieb:> Am besten wär es noch bei den ReportIDs etwas höher zum Zählen> anzufangen.
Habe ich später auch gemacht (beginnend bei 50), aber bei dieser Version
noch nicht.
Wie gesagt: bei obigem Download handelt es sich um einen älteren Stand,
der nur die USBIRRR-Funktionalitäten bietet. Die weiteren Funktionen
kamen erst später dazu. Hast du es mal getestet? Läuft es? Ehrlich
gesagt habe ich das gestern nur zusammengepackt und hochgeladen ohne die
Funktion nochmal zu testen.
Mein Plan sieht vor mich erst um die STM32-Firmware zu kümmern und das
mit der Host-Applikation zum Laufen zu bekommen. Dabei werde ich zwar
versuchen kompatibel zu bleiben, kann aber nichts versprechen. Je
nachdem kann das Programm dann auch mit USBIRRR verwendet werden.
Ich dachte nur ich lade den Stand mal hoch falls jemand daran
weitermachen will bzw. eine Basis für die Kommunikation zwischen Host
(C#) und Device (V-USB) sucht.
Also kompilieren und starten lies es sich.
Habe hier aber keinen Empfänger und kann es nicht testen.
Das mit den IDs werde ich AVR aber auch noch etwas abändern.
Z.b. wenn die PowerON Funktion nicht gwünscht ist, dass dann auch nicht
die ReportID auftaucht. Diese wird jetzt ja trotzdem an den Host
gesendet.
Wenn diese dann auch nicht an den Host geschickt wird kann sich dieser
auch darauf einstellen was der Empfänger alles kann.
Hugo Portisch schrieb:> Dirk W. schrieb:>> Dann liegts wohl daran, daß die Events nicht abgeholt werden und>> irgendwas intern überschrieben wird.>> Richtig! Es liegt an der V-USB Funktion: usbInterruptIsReady>> Ändert einmal das in der SendINTData ab: while (!usbInterruptIsReady())
usbPoll(); // check if USB int is ready
> usbSetInterrupt(&replyBuf[0], sizeof(irmp_data) + sizeof(uchar));
// send ReportID + IR data
> Neu: usbSetInterrupt(&replyBuf[0], sizeof(irmp_data) + sizeof(uchar));
// send ReportID + IR data
funktioniert wunderbar.
btw. in der main.c koennte man einige der functions auch noch als static
deklarieren was noch ein paar zusaetzliche bytes verschaffen sollte.
Erst mal vielen Dank für das Projekt, funktioniert einwandfrei!
Ich hoffe natürlich, dass es noch weiterentwickelt wird, auch wenn es in
Kombination mit Eventghost eigentlich schon alles macht, was ich
benötige.
Noch ein paar Bilder von meinem Empfänger. Muss noch ein bisschen
verschönert werden, aber funktioniert schon sehr gut =). Das Gehäuse war
von einem WLAN-Stick, der irgendwann mal ein anderes Gehäuse bekommen
hat. Gerne stelle ich auch das Layout zur Verfügung, falls Interesse
besteht. Bei meinem Layout ist zu beachten, dass man evtl. zum
Programmieren noch für ISP Pads oder dgl. einfügen sollte und sowohl
USB, als auch IR-Empfänger müssen in dem Fall oben verlötet werden, wenn
die Platine einseitig bleiben soll.
Auch wenns nichts mit dem Empfänger zu tun hat, hab ich noch ne Frage.
Und zwar hab ich 2 SMD-Kondensatoren gegrillt, den 10µ, wo auf meiner
Platine sehr unschön jetzt ein tht Kondi angelötet ist, weils mir das
Lötpad weggeschmort hat. Am USB-Port eingesteckt und nach 5 Min hats
ordentlich geraucht und gestunken ;). Das war so ein gelber, wie der
4,7µ rechts neben dem IR-Empfänger. Ich gehe mal davon aus, dass die
Markierung Minus sein soll oder lieg ich da falsch? Außer durch
Verpolung kann ich mir das grad nicht erklären...aber bei 2 kann das ja
fast nicht sein^^
achja Bauteile(smd/tht) hab ich wild alles verbaut, was ich grad
gefunden hab ;)
Schönen Abend,
pedro
pedro f. schrieb:> Ich gehe mal davon aus, dass die> Markierung Minus sein soll oder lieg ich da falsch?
Und wie! Bei SMD Elkos ist der Strich !Plus!
Wegen der IR Diode:
Schaue dir einmal die TSOP4838 an. Ist um einiges kleiner und geht genau
so gut!
Hugo Portisch schrieb:> Und wie! Bei SMD Elkos ist der Strich !Plus!
Naja
So gaaanz stimmt das nicht.
Bei NORMALEN SMD Elkos ist der Strich ebenso Minus
Bei SMD Tantals ist der Strich das PLUS
Hallo alle zusammen,
ich habe das Projekt nun schon eine lange Zeit im Visier und bin gestern
endlich zum Nachbau gekommen.
Ich verwende die Pollin Tastatur FDC-3402. Die IR-Codes werden richtig
ausgewertet und mit dem USB-IRRR angezeigt. Ich habe die Kleinbuchstaben
erfolgreich zuweißen können, aber bei den Großbuchstaben habe ich
Probleme.
Da ich die Caps-Taste drücken muss und dann eine andere Taste kommt
nachher ja beim Drücken der Caps-Taste der Großbuchstabe heraus. Man
müsste also bei Großbuchstabenzuweisungen mehrere IR-Codes miteinander
verknüpfen, oder?
Gibt es da schon eine Lösung die ich noch nicht herausgefunden habe?
Mit freundlichen Grüßen
Sebastian
Wie wertest du die IR-Codes aus?
Ich selber habe kein IR Tastatur. Stöbere einmal den Thread von IRMP
durch:
Beitrag "IRMP - Infrared Multi Protocol Decoder"
Da habe ich was in Erinnerung das dort einmal beschrieben wurde wie das
mit "Shift" usw funktioniert.
Ich glaube beim Drücken der "Shift" Taste wird ein Code X gesendet. Nun
weis die auswertende Software das Shift gedrückt ist. Beim Loslassen der
Shift Taste sollte ein anderer Code Y kommen was bedeutet, dass die
Shift Taste losgelassen wurde.
Also sozusagen ein Shift/CAP/...-Down und Up.
Sebastian schrieb:> Da ich die Caps-Taste drücken muss und dann eine andere Taste kommt> nachher ja beim Drücken der Caps-Taste der Großbuchstabe heraus. Man> müsste also bei Großbuchstabenzuweisungen mehrere IR-Codes miteinander> verknüpfen, oder?
Hast Du Dir schon einmal
http://www.mikrocontroller.net/articles/IRMP#IR-Tastaturen
durchgelesen? Da ist erklärt, was passiert, wenn Du die
SHIFT/STRG-usw-Taste drückst bzw. loslässt. Du musst Dir diese Events
als Status speichern, um dann die richtige Taste zu ermitteln, wenn Du
ein 'a' bekommst.
Dort ist auch eine kleine C-Funktion abgebildet, welches genau das
erledigt.
Hallo,
die C-Funktion steht doch schon in der irmp.c drin, oder?
Irgendwo hab ich auch das aktuelle irmp.zip gefunden. In diesem Archiv
war die irmp.exe wozu ist die eigentlich?
Ich muss doch nach wie vor z.B. mit EventGhost die Tasten-Events den
einzelnen Buchstaben zuweisen, sodass ich mit der Tastatur auch tippen
kann, oder?
Sebastian schrieb:> die C-Funktion steht doch schon in der irmp.c drin, oder?
Ja, aber durch Preprocessor-Defines deaktiviert. Die steht da nur drin,
damit man sie da rauskopieren kann.
Wo nämlich aus Protokoll, Adresse & Kommando der eigentliche Tastencode
gebildet wird, ist eigentlich egal. Das kann auf dem µC sein, es kann
aber auch erst auf dem PC passieren.
> Irgendwo hab ich auch das aktuelle irmp.zip gefunden.
Download-Link im Artikel IRMP.
> In diesem Archiv war die irmp.exe wozu ist die eigentlich?
Steht auch im Artikel. Benötigst Du aber nicht.
> Ich muss doch nach wie vor z.B. mit EventGhost die Tasten-Events den> einzelnen Buchstaben zuweisen, sodass ich mit der Tastatur auch tippen> kann, oder?
Ich kenne Eventghost nicht und kann deshalb nichts dazu sagen.
Hallo an alle Experten hier,
nachdem ich schon seit einiger Zeit immer mal wieder diverse Beiträge
hier lese, muss ich mich jetzt mit einem Problem an euch wenden.
Ich habe die Schaltung gemäß Schaltplan und BOM aufgebaut ( siehe
Anhang, Schaltplan wurde nur schnell auf Eagle übertragen ))
Leider bekomme ich immer nur Unknown Device unter Windows ( Windows 7
Ultimate x64 ).
Habe schon diverses ausprobiert ( Datenleitungen getauscht, Quarz durch
Resonator getauscht, Original V-USB Bootloader getestet ) leider ohne
Erfolg.
Was kann ich noch Probieren ? Bilder der fertigen Schaltung kann ich
auch gerne noch machen. ( Nach Multimetertest scheint soweit alles in
Ordnung zu sein )
Hat sich erledigt.
Eine von den Zenerdioden war durch ( beidseitig durchgang )
Den Bootloader bekomme ich zwar trotzdem nicht ans laufen, aber das
Hauptprogramm läuft.
Moin!
Hab den Receiver unter Linux im Einsatz und wunderte mich heute, daß
nach einem Kernel-Update, welches gestern eingespielt wurde, für den
Receiver kein hidraw-Gerät mehr angelegt wurde.
Nach einigem Suchen fand ich das hier:
http://www.easyvdr-forum.de/forum/index.php?topic=13723.msg133283#msg133283
Habe auch erfolgreich ein Update mit der neuen Device-ID über VirtualBox
gemacht und es geht auch alles unter Linux, allerdings wird der
Empfänger im Windows nun nicht mehr im Einstellungs-/Optionen- und
Update-Dialog angezeigt.
Kann man entweder eine passende DLL bekommen oder die DLL vielleicht so
erstellen, daß auch Empfänger mit unterschiedlichen Device-IDs
bearbeitet werden können? Die Erkennung läuft doch über die DLL, oder?
Danke.
MfG
MrFX
Ich habe hier schon länger nichts mehr gemacht.
Eigentlich habe ich schon mal angefangen den Source nach GitHub zu
bringen:
https://github.com/Portisch/USB-IR-Remote-Receiver
Aber hier fehlt noch die neue DLL!
Die DLL sucht per USB_CFG_VENDOR_ID, USB_CFG_DEVICE_ID und dem
USB_CFG_DEVICE_NAME den Empfänger. Diese IDs sind im AVR Source fix
definiert.
Hello,
after latest Windows update, the DLL stopped working. It always displays
error "Ungultige Zeigeroperation" and IR codes are not received.
Because the source code of the DLL is not available, I cannot fix it
myself. Please fix it :(
Mek
Windows 10 v1809 has a great bug in hidclass.sys driver. A lot of HID
devices stopped working. We have to wait until windows fixes this bug.
At this time the only change to get the tool working is to go back to
Windows 1803.
Thread beobachten
Seitenaufteilung abschalten
