Hallo zusammen! Ich bin neu hier und auch ein Anfänger mit AVR. Denoch ist es mir vor einiger Zeit gelungen den Igor AVR USB RC5 Empfänger zu modifizieren: http://www.dvbviewer.info/forum/index.php?showtopic=33309&hl= Das ist halt nur der AT90S2312 Chip - bei dem ist nun der Speicher voll. Um die neue Funktion PowerOn/Off rein zu bekommen musste schon etwas Orignal-Code gekürzt werden. Auch ist es mir schon öfter passiert, dass sich der Chip weghängt und ich ihn vom USB (Stromlos) abstecken muss damit er wieder geht. Und mit meiner Universallfernbedienung gibt es auch Probleme. Da gehen z.B. nur Nokia Geräte am besten. Viele andere werden nicht richtig erkannt. Nun meine Aufgaben: 1. Ich möchte den Code um RC6 und wenn möglich andere Codes erweitern. Das Thema: RC5 Decoder von P. Danegger ist ja schon sehr interessant 2. Dazu brauche ich einen neuen AVR/PIC... 3. Gibt es da einen AVR der sich eignet mit einer USB-Schnittstelle? Wie sieht es dazu aus mit Treiber für Windows (XP-Win7)? Vendor-ID usw... 4. Wenn der AVR nun per USB angeschlossen ist, wie bekomme ich die Daten? Geht das wirklich nur über Polling oder kann das auch Event-Getriggert arbeiten? Zum Programieren des Chips habe ich einen GALEP-5 zur Verfügung. Programmieren tu ich mit liebsten mit AVR-Studio. C-Code ist mir am liebsten - Assembler ist aber auch möglich. Ich hoffe das jemand für mich ein paar Tipps hat welcher AVR/PIC sich für sowas gut eignet. Danke!
Also ich habe solch ein Projekt schon einmal gemacht. D.h. ich habe in einen ATmega8 den USB Stack von http://www.obdev.at/products/vusb/projects.html integriert. Schließlich habe ich noch einen IR Empfänger hinzugefügt, so dass ich mein Notebook nun mit einer Fernbedienung fernsteuern kann. Der ATmega8 meldet sich dazu als normales HID am Rechner an (Tastatur) und sendet entsprechend der empfangenen IR Codes Tastaturbefehle an den Rechner. Damit lässt sich super alles fernsteuern (WinAmp, VLC, etc.). Als Einstieg solltest du dir zunächst die Beispielprojekte auf der oben genannten Seite anschauen. Da gibt es auch Beispiele wo eine Tastatur simuliert wird. Das bräuchtest du dann eigentlich nur noch mit dem RC5 erweitern oder was auch immer du dann erweitern möchtest. http://www.obdev.at/products/vusb/hidkeys.html sollte dir als Beispielprojekt gut dienen.
Hugo Portisch schrieb: > [...] > 3. Gibt es da einen AVR der sich eignet mit einer USB-Schnittstelle? Wie > sieht es dazu aus mit Treiber für Windows (XP-Win7)? Vendor-ID usw... Fuer die Verbindung zwischen µC und PC ueber USB, haben sich die Seriell-USB-Wandler-Chips von FTDI bewaehrt. Auf dem µC braucht man dann nur noch eine UART auf dem PC hat man einen "virtuellen COM Port". Treiber gibt es fuer eigentliche alle OS. > 4. Wenn der AVR nun per USB angeschlossen ist, wie bekomme ich die > Daten? Geht das wirklich nur über Polling oder kann das auch > Event-Getriggert arbeiten? Bei soeben genannter Loesung bekommst Du die Daten dann wie ueber eine serielle Schnittstelle. Geht auch per Event. > Ich hoffe das jemand für mich ein paar Tipps hat welcher AVR/PIC sich > für sowas gut eignet. Jeder mit mindestens einer UART und genuegend Speicher fuer Deine Anwendung. ;) Volker
Hugo Portisch schrieb: > Ich hoffe das jemand für mich ein paar Tipps hat welcher AVR/PIC sich > für sowas gut eignet. Hab letztens so etwas mit einem PIC18F14K50 gemacht: http://www.fundf.net/usbnub/#rc5_hid. Das Prinzip dabei ist wie von "Remote One" weiter oben beschrieben: Der Controller meldet sich als HID-Gerät und setzt Fernbedienungssignale in USB-HID-Tastendrücke um.
Volker Schulz schrieb: > Fuer die Verbindung zwischen µC und PC ueber USB, haben sich die > Seriell-USB-Wandler-Chips von FTDI bewaehrt Da kommst du billiger, wenn du dir für 3€ bei 1, 2, 3 ... einen USB2Serial Wandler holst (hab ich auch letzte Woche gemacht^^). Da hast du auch eine virtuelle serielle Schnittstelle. Du musst dir nur noch ein REchnerprogramm schreiben, welches die Daten dann auswertet.
Remote One schrieb: > Volker Schulz schrieb: >> Fuer die Verbindung zwischen µC und PC ueber USB, haben sich die >> Seriell-USB-Wandler-Chips von FTDI bewaehrt > > Da kommst du billiger, wenn du dir für 3€ bei 1, 2, 3 ... einen > USB2Serial Wandler holst (hab ich auch letzte Woche gemacht^^). Da hast > du auch eine virtuelle serielle Schnittstelle. Du musst dir nur noch ein > REchnerprogramm schreiben, welches die Daten dann auswertet. Zu dem USB2Serial-Wandler brauchst Du aber noch einen Pegelwandler um auf TTL-Level zu kommen. Der FTDI hat schon TTL. Aber es funktioniert natuerlich beides. ;) Volker
So schnell - so viele Antworten! Vielen dank an alle für die Hilfe! @Remote One: Danke für den Tipp! Werd mir das HID & Atmega8 mal ansehen. Von den VUSB habe ich schon mal gelesen - aber noch nie probiert. Vielleicht kannst du mir etwas mit deinem Code unter die Arme greifen... Will ja eigentlich genau das machen was du gemacht hast. Nur will ich halt dann den empfangen Code statt einen Tastendruck senden. Muss mich erst noch etwas in HID usw einarbeiten.
Hugo Portisch schrieb: > [...] Nur will ich > halt dann den empfangen Code statt einen Tastendruck senden. Aber warum dann HID? Volker
Weil HID anscheinend ja keinen Treiber braucht. Mit dem Igor Treiber hatte ich schon mal einige Probleme
HID bedeutet zum ersten nicht automatisch treiberfrei. HID-Treiber fuer Tastatur und Maus hat Windows aber an Bord, richtig. Nur sind diese ziemlich ungeeignet um Daten an eine Applikation zu senden, da HID-Eingaben entweder nur an's Fenster mit Fokus oder an alle Fenster gleichzeitig gehen. Zudem sind HID-Eingaben der unterschiedlich Tastaturen nur mit einigem Aufwand dem Device zuzuordnen (was 3rd-Party-Apps natuerlich sowieso nicht machen). Will man also die Daten NICHT als Tastendruck senden, dann ist HID ungeeignet (weil's eben Tastendruecke sendet ;)). Hugo Portisch schrieb: > [...] Nur will ich > halt dann den empfangen Code statt einen Tastendruck senden. Ein Serial-To-USB-Chip waere meines Erachtens hier besser geeignet... Auch wenn man Treiber installieren muss. Volker
Jetzt muss ich wegen USB nocheinmal nachfragen: Die V-USB arbeitet ja auch anscheinend mit LibUSB. Bei Win7 x86 geht bei mir aber LibUSB nicht. Bei XP schon. Gibts zu LibUSB und Win7 etwas oder wird das nicht mehr weiter entwickelt? Habe auch noch von WinUSB gelesen.
Erst willst Du HID nehmen, weil's ohne Treiber funktionieren koennte, und jetzt willst Du Dir selbst einen schreiben? Du machst es aber ganz schoen kompliziert... Mit dem FTDI-Chip oder einem MAX232 + USB-Wandler waerst Du vermutlich laengst fertig. ;) Volker
Habe mit HID nur vorher noch nie was gemacht. Das da leider nur Tastendrücke übertragen werden wusste ich nicht... Der ganze Aufbau soll dann im HTPC Gehäuse verschwinden, angesteckt über die USB-Pins am Mainboard.
Portisch schrieb: > Der ganze Aufbau soll dann im HTPC Gehäuse verschwinden, angesteckt über > die USB-Pins am Mainboard. Hatte schon korrekt vermutet, was Du erreichen willst. Und deshalb ja gleich auf die FTDI-ICs verwiesen, die machen genau das: Auf der einen Seite die UART des Mikrocontrollers, auf der anderen Seite der USB-Port des PC. Fertig is die Laube. ;) In Deinem Betriebssystem hast Du dann (nach Treiberinstallation) einen sogenannten "Virtuellen COM-Port", der wie jede andere serielle Schnittstelle auch, mit jeder Programmiersprache ohne groesseren Aufwand benutzt werden kann. Ich hab genau das gleiche aufgebaut, mit: IR-Empfaenger (TSOP) an ATMEGA8535, UART auf MAX232 und ueber Prolific-IC auf USB. Durch den FTDI-Chip spart man sich die Pegelwandlung (also den MAX232). Volker
Danke für dein Info! Ich habe mich aber trotzdem etwas in HID eingearbeitet. Dazu das von MSDN: http://msdn.microsoft.com/en-us/library/ms645536(VS.85).aspx Kann dann zwar nichst runterschreiben, jedoch gut die Empfangen Daten auswerten. Habe es jetzt nur mit der Mouse & Keyboard getestet. Da geht es schon sehr gut, dass ich über RAWHID die empfangen Daten ansehen. Zum AVR: Dazu habe ich mir nun das Projekt von V-USB mit den 17 Keys angesehen. Da wird ja die HID Description so ausgefüllt:
1 | PROGMEM char usbHidReportDescriptor[35] = { /* USB report descriptor */
|
2 | 0x05, 0x01, // USAGE_PAGE (Generic Desktop) |
3 | 0x09, 0x06, // USAGE (Keyboard) |
4 | 0xa1, 0x01, // COLLECTION (Application) |
5 | 0x05, 0x07, // USAGE_PAGE (Keyboard) |
6 | 0x19, 0xe0, // USAGE_MINIMUM (Keyboard LeftControl) |
7 | 0x29, 0xe7, // USAGE_MAXIMUM (Keyboard Right GUI) |
8 | 0x15, 0x00, // LOGICAL_MINIMUM (0) |
9 | 0x25, 0x01, // LOGICAL_MAXIMUM (1) |
10 | 0x75, 0x01, // REPORT_SIZE (1) |
11 | 0x95, 0x08, // REPORT_COUNT (8) |
12 | 0x81, 0x02, // INPUT (Data,Var,Abs) |
13 | 0x95, 0x01, // REPORT_COUNT (1) |
14 | 0x75, 0x08, // REPORT_SIZE (8) |
15 | 0x25, 0x65, // LOGICAL_MAXIMUM (101) |
16 | 0x19, 0x00, // USAGE_MINIMUM (Reserved (no event indicated)) |
17 | 0x29, 0x65, // USAGE_MAXIMUM (Keyboard Application) |
18 | 0x81, 0x00, // INPUT (Data,Ary,Abs) |
19 | 0xc0 // END_COLLECTION |
20 | }; |
21 | /* We use a simplifed keyboard report descriptor which does not support the |
22 | * boot protocol. We don't allow setting status LEDs and we only allow one |
23 | * simultaneous key press (except modifiers). We can therefore use short |
24 | * 2 byte input reports. |
25 | * The report descriptor has been created with usb.org's "HID Descriptor Tool" |
26 | * which can be downloaded from http://www.usb.org/developers/hidpage/. |
27 | * Redundant entries (such as LOGICAL_MINIMUM and USAGE_PAGE) have been omitted |
28 | * for the second INPUT item. |
29 | */ |
Also habe ich mir das HID Descriptor Tool heruntergeladen und etwas gespielt - jedoch habe ich dazu noch zu wenig Durchblick. Ich möchte szusagen ein HID Device erstellen: USAGE_PAGE (Generic Desktop) USAGE (Consumer Control) Dann hört mein Verständis dazu schon auf. Wie/wo definiere ich die Vendor ID. Bei GetRawInputDeviceList kann ich alle verfügbaren HID Geräte auslesen. Da stehen auch Vendor IDs dabei. Wenn es mehrere gleiche HID Geräte gibt muss ich ja durch die Vendor ID das Gerät unterscheiden können. Wie muss meine remote.hid aussehen wenn ich sozusagen Daten von 8 Bytes (0x00-0xFF) pro event vom AVR zum Host übertragen möchte? Kann mir da noch jemand weiterhelfen?
in der usbconfig.h gibt es folgende Einträge welche das machen was du suchst ;) #define USB_CFG_VENDOR_ID 0x42, 0x42 /* USB vendor ID for the device, low byte first. If you have registered your * own Vendor ID, define it here. Otherwise you use obdev's free shared * VID/PID pair. Be sure to read USBID-License.txt for rules! */ #define USB_CFG_DEVICE_ID 0x31, 0xe1 /* This is the ID of the product, low byte first. It is interpreted in the * scope of the vendor ID. If you have registered your own VID with usb.org * or if you have licensed a PID from somebody else, define it here. Otherwise * you use obdev's free shared VID/PID pair. Be sure to read the rules in * USBID-License.txt! */ #define USB_CFG_DEVICE_VERSION 0x00, 0x01 /* Version number of the device: Minor number first, then major number. */ #define USB_CFG_VENDOR_NAME 'o', 'b', 'd', 'e', 'v', '.', 'a', 't' #define USB_CFG_VENDOR_NAME_LEN 8 /* These two values define the vendor name returned by the USB device. The name * must be given as a list of characters under single quotes. The characters * are interpreted as Unicode (UTF-16) entities. * If you don't want a vendor name string, undefine these macros. * ALWAYS define a vendor name containing your Internet domain name if you use * obdev's free shared VID/PID pair. See the file USBID-License.txt for * details. */ #define USB_CFG_DEVICE_NAME 'H', 'I', 'D', 'K', 'e', 'y', 's' #define USB_CFG_DEVICE_NAME_LEN 7 /* Same as above for the device name. If you don't want a device name, undefine * the macros. See the file USBID-License.txt before you assign a name. */ /*#define USB_CFG_SERIAL_NUMBER 'N', 'o', 'n', 'e' */ /*#define USB_CFG_SERIAL_NUMBER_LEN 0 */ /* Same as above for the serial number. If you don't want a serial number, * undefine the macros. * It may be useful to provide the serial number through other means than at * compile time. See the section about descriptor properties below for how * to fine tune control over USB descriptors such as the string descriptor * for the serial number. */
ihr verschweigt alle das bei der RS232/FTDI Lösung eine Anpassung der PC Software vorgenommern werden muss. Das ist bei einem HID Gerät nicht der Fall
... ... schrieb: > ihr verschweigt alle das bei der RS232/FTDI Lösung eine Anpassung der PC > Software vorgenommern werden muss. > > Das ist bei einem HID Gerät nicht der Fall Welche PC-Software? Hab ich was verpasst? Volker
Danke remote1! Dann muss ich mich nur noch mit dem usbHidReportDescriptor spielen! Könnte das gehen:
1 | char ReportDescriptor[23] = {
|
2 | 0x05, 0x0c, // USAGE_PAGE (Consumer Devices) |
3 | 0x09, 0x01, // USAGE (Consumer Control) |
4 | 0xa1, 0x01, // COLLECTION (Application) |
5 | 0x05, 0x0c, // USAGE_PAGE (Consumer Devices) |
6 | 0x19, 0x00, // USAGE_MINIMUM (Unassigned) |
7 | 0x29, 0x00, // USAGE_MAXIMUM (Unassigned) |
8 | 0x15, 0x00, // LOGICAL_MINIMUM (0) |
9 | 0x25, 0xff, // LOGICAL_MAXIMUM (-1) |
10 | 0x75, 0x08, // REPORT_SIZE (8) |
11 | 0x95, 0x01, // REPORT_COUNT (1) |
12 | 0x81, 0x00, // INPUT (Data,Ary,Abs) |
13 | 0xc0 // END_COLLECTION |
Den Filter dann für:
1 | HID_USAGE_PAGE_CONSUMER = $0C; |
setzen. Wie gesagt, ich möchte vom AVR 8 Bytes von 0x00-0xFF schicken. In den 8 Bytes sollten alle IR-Codes Platz haben.
Portisch schrieb: > Dann hört mein Verständis dazu schon auf. > Wie/wo definiere ich die Vendor ID. Bei GetRawInputDeviceList kann ich > alle verfügbaren HID Geräte auslesen. Da stehen auch Vendor IDs dabei. > Wenn es mehrere gleiche HID Geräte gibt muss ich ja durch die Vendor ID > das Gerät unterscheiden können. Zum Unterscheiden nimmt man natuerlich nicht die Vendor-ID, da die bei gleichen HID natuerlich auch gleich ist. GetRawInputDeviceList gibt Dir doch fuer jedes HID ein Handle (hDevice), das einzigartig ist. Das nimmt man dann auch zum Unterscheiden... Eine eigene Vendor-ID darfst Du Dir natuerlich auch nicht einfach nehmen, sowas muss man kaeuflich erwerben (guenstigste Option $2000), wenn Du Dein Geraet spaeter nicht aus der Hand gibst, merkt es allerdings auch niemand wenn Du Dir eine klaust. ;) > Wie muss meine remote.hid aussehen wenn ich sozusagen Daten von 8 Bytes > (0x00-0xFF) pro event vom AVR zum Host übertragen möchte? Ich verstehe schon nicht wie (0x00-0xFF) 8 Byte sein sollen. Das ist ein Byte... Ich benutze 12 Bit in zwei Bytes um die RC5-Daten an den Rechner zu uebertragen (Command, Device, Toggle Bit). Volker
[quote]Ich verstehe schon nicht wie (0x00-0xFF) 8 Byte sein sollen. Das ist ein Byte... Ich benutze 12 Bit in zwei Bytes um die RC5-Daten an den Rechner zu uebertragen (Command, Device, Toggle Bit).[/quote] Ich meine natürlich 8 Bytes. Mit 0x00 -0xFF hatte ich nur den Bereich des Bytes gemeint. Also 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 bis 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF Werde bald meinem Atmega8 bekommen (dauert halt etwas länger wenn man ihn kostenlos will ;)). Dann werde ich mich durch den HID Descriptor durchprügeln müssen.
Hugo Portisch schrieb: > 1. Ich möchte den Code um RC6 und wenn möglich andere Codes erweitern. > Das Thema: RC5 Decoder von P. Danegger ist ja schon sehr interessant Schau Dir mal den Thread Beitrag "IRMP - Infrared Multi Protocol Decoder" bzw. den zugehörigen Artikel nebst Download der aktuellen Version von IRMP an: http://www.mikrocontroller.net/articles/IRMP Damit ist die Decodierung von ca. 90% aller heute im Umlauf befindlichen IR-Protokolle möglich. Gruß, Frank
@Remote One Habe nun dein USB-HID runtergeladen und einfach einmal das HEX-File mit einem Galep-4 Programmer raufgeschrieben. Habe die Schaltung laut HID-Keys aufgebaut. Die ganzen Taster natürlich nicht. Dafür den OUT von der TSOP1736 auf INT1/PD3. Die 2 Dioden habe ich einmal weggelassen. Quarz ist ein 12MHz, AVR: Atmega8-16PU Wenn ich nun das am USB anschließe kommen die Meldungen: Neue Hardware gefunden, Unbekanntes Gerät, Hardware fertig zum Benützen, nach kurzer Zeit dann die Meldung USB-Gerät funktioniert nicht. Laut Datenblatt läuft der Atmeg8-16PU mit 16Mhz. Kann das, dass Problem sein? Danke!
Die Frequenz muss definitiv 12MHz sein. Da müssen natürlich auch die Fuses stimmen. Zudem sind die Dioden an den USB Datenleitungen enorm wichtig, da USB keine großen Schwankungen verträgt. D+ und D- evtl. noch vertauscht?
Angehängte Dateien:
-
1.JPG
22 KB -
2.JPG
26 KB -
level-conversion-with-zener.gif
2,5 KB
Ich kann meinen alten Post leider nicht mehr Bearbeiten, also nicht erschlagen wenn ich Doppelpost mache. Wirf den Schaltplan mal komplett über den Haufen. Ich hab's anders aufgebaut (siehe Anhang). Da sind die Dioden auch an der richtigen Stelle. Die PDF mit dem Schaltplan einfach gleich komplett löschen. SRY, hab's erst jetzt bemerkt. Damit versorge ich den µC gleich vom USB Port (deswegen auch der Zwischenkondensator) und habe die Datenleitungen auf dem richtigen Pegel.
Die Dioden sind ja nur da um die 5V um 1,2V zu senken, oder? Laut Datenblatt braucht der Atmega8-16PU aber 4,5-5,5V. Müssen D+ & D- auf ~3,3V Arbeiten, oder gehen auch 5V? Zu den Fuses, wo setze ich die? AVR-Studio macht mir ja ein HEX-file. Das spiele ich mit dem Galep-4 einfach drauf. D+, D- hatte ich schon einmal zu Versuchszwecken vetauscht, leider kein Erfolg.
Portisch schrieb: > Die Dioden sind ja nur da um die 5V um 1,2V zu senken, oder? > Laut Datenblatt braucht der Atmega8-16PU aber 4,5-5,5V. Schau dir mal meinen letzten Beitrag an. Der Schaltplan aus der PDF reduziert die Spannung des µC auf 3,6V. Damit sind die Pegel der Pins des µC auch bei max 3,6V. Ich habe den ATmega aber mit 5V am laufen und reduzieren über die Z-Dioden die Pegel der Pins der Datenleitungen D+ und D- auf 3,6V (so wie es im Wiki von V-USB Lib angegeben ist). Die Datenleitungen vertragen definitiv keine 5V Pegel, also unbedingt Dioden einbauen. Laut USB Spezifikation sind die Pegel der Datenleitungen: Low: 0-0,8 V High: 2,7-3,6 V Wenn du einen neuen ATmega hast, dann läuft der ab Werk mit internen 1MHz. Da kannst du noch so viele Quarze dranhängen, da passiert nichts. Deswegen musst du die Fuses des ATmega so umstellen, dass dieser den externen Quarz als Taktquelle nutzt. Das kann z.B. vor dem Flashen über das AVR-Studio erfolgen. Mit was brennst du (also softwareseitig)?
Genau das habe ich gerade gefunden: [quote]The device is shipped with CKSEL = “0001” and SUT = “10” (1 MHz Internal RC Oscillator, slowly rising power).[/quote] Ich benutze den Galep-4 mit der neuesten Galep32 Software: http://www.conitec.com/german/galep4.php Habe dazu noch nichts gefunden wie man die Fuse Bits einstellen kann. Danke für dein Schaltplanupdate!
Leider kann ich den Post oben editieren da ich nur als Gast angemeldet war. Habe nun die Option im Programmer Galep32 gefunden! Fuse Bits richtig gesetzt, und siehe da: HID Keys gefunden. Super! Dann kann ich ja dann loslegen...
Portisch schrieb: > Ich benutze den Galep-4 mit der neuesten Galep32 Software: > http://www.conitec.com/german/galep4.php Du hast nicht wirklich 306€ für einen Programmer mit LTP Anschluss ausgegeben. Das hat man für 1-2€ selber nach gebaut...... Sei es drum, die Software kenn ich nicht. Da muss man aber irgendwo die Fuses einstellen können, sonst ist es erst recht raus geschmissenes Geld.
Remote One schrieb: > Du hast nicht wirklich 306€ für einen Programmer mit LTP Anschluss > ausgegeben. Das hat man für 1-2€ selber nach gebaut...... Kann man auch anders sehen wenn man sieh was alles mit dem Galep programmiert werden kann. Für nur Atmel ist der allerdings zu teuer, aber Eprom, EEPROM, PIC, viele MCU gehen damit, Hexeditor ist eingebaut, verfusete AVRs können wiederbelebt werden, Seriennummer setzen, Akkubetrieb möglich usw. Habe selbst den Galep-III (leider auch für LPT) und möchte den nicht missen (neben meinem seriellen PonyProg und div. USB-Proggern) cdg
Nein, den Programmer haben wir in der Firma ;) Hatte bis jetzt halt noch keinen Chip bei dem ich Fuse Bits setzen musste. War gar nicht einfach zu finden...
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.