Hallo zusammen,
ich habe Probleme meinen Attiny44 mit V-USB zum laufen zu bekommen.
Das Gerät wird unter Windows nicht erkannt; der Controller läuft aber.
Meine Main-Funktion und die geänderte usbconfig.h sind im Anhang.
Außerdem habe ich mit einem USB Sniffer (UsbTrace) geschaut was
passiert(ebenfalls im Anhang). Leider hilft mir das alles nicht weiter,
da ich nur wenig bis garkeine Erfahrung mit USB habe.
Funktion meines Programms:
Das Programm soll eine USB Tastatur (HID Gerät) emulieren und bei einem
Tastendruck die Pfeil-Rechts-Taste drücken (und loslassen). Das Projekt,
von dem ich abgeschaut habe ist dieses hier:
http://codeandlife.com/2012/06/18/usb-hid-keyboard-with-v-usb/#more-694http://codeandlife.com/data/usb_keydemo.zip
Daher sollte auch eine LED mit der CapsLock Taste ein- und ausschaltbar
sein.
Als USB Deskriptor habe ich schon verschiedene ausprobiert. Der
Descriptor aus dem Projekt ist der selbe, welcher mit dem USB Descriptor
Tool für ein USB Keyboard erstellt werden kann:
http://www.usb.org/developers/hidpage#HID%20Descriptor%20Tool
Leider komme ich an diesem Punkt nicht weiter. Der Kontoller wird vom PC
nicht erkannt. (Unbekanntes Gerät angeschlossen) Teilweise mit
Fehlercode 43.
Der tiny läuft stabil auf 12.000MHz. Das habe ich bereits mit einem
Ausgang und einem Oszi getestet F=1,000Hz:
1
while(1)
2
{
3
_delay_ms(500);
4
PORTA^=(1<<PA7);
5
}
Die Schaltung habe ich von Obdev.at und diversen Internetseiten
übernommen (siehe Anhang).
Die Beiträge hier im Forum habe ich schon durchstöbert, und verschiedene
Beispielprojekte habe ich auch schon ausprobiert (nur den Code auf meine
HW angepasst). Immer der selbe Fehler...
An welcher Stelle muss ich weiter suchen? Hardware?
Bitte um Hilfe!
EDIT:
1)Das ganze ist auf Lochraster aufgebaut mit ca 20cm USB Kabel. Mein
USBasp läuft aber auch mit 1,5m kabel ohne Probleme. Und schön ist die
Leiterplatte auch nicht (vom Routing her).
2)Die Deaktivierung des Watchdog war mein letzter Versuch das Ding zum
laufen zu bekommen. War aber auch erfolglos...
Gruß und einen schönen Abend,
Jan
Nein, ich habe das Projekt mit AVR Studio Version 4 Compiliert.
Es gab eine Warnung wegen eines impliziten castings, sonst war alles OK.
Das Projekt habe ich ebenfalls im Anhang oben (zip-File).
Gruß Jan
@ Jan S.
Ich hatte genau an der Stelle mal das gleiche Problem.
Probiere es mal nicht mit einem 1.5k, sondern mit einem 1k Ohm
Widerstand von +3.6V nach D- !
Du könntest auch einen 1M Ohm Widerstand von GND nach D+ legen.
Mein USBasp (mit PDI-Interface für die Xmega) funktioniert zum Beispiel
nicht an meinem USB 2.0 Hub, sondern nur direkt am USB-Port vom Laptop.
Es gab aber schon Fälle in denen die V-USB Geräte nur an einem USB-Hub
funktioniert haben da die Southbridge des Computers ein etwas anderes
Timing vom USB-Gerät erwartet hat.
"Mein USBasp (mit PDI-Interface für die Xmega) funktioniert zum Beispiel
nicht an meinem USB 2.0 Hub, sondern nur direkt am USB-Port vom Laptop."
Steht das nicht auch explizit bei USBasp dabei? Und win7 unterstützt
einen spez USB Modus nicht mehr, der dort benötigt wird - oder
verwechsel ich da etwas? Irgendwas war da...also "prüfen"!
Klaus.
Klaus R. schrieb:> Steht das nicht auch explizit bei USBasp dabei?
Ich habe meinen USBasp mit einem Patch für die Xmega vorbereitet und
auch AVRdude gepatcht damit die Xmega beschrieben werden können.
http://szulat.blogspot.de/2012/08/atxmega-programmer-for-050.html> Und win7 unterstützt einen spez USB Modus nicht mehr, der dort benötigt> wird - oder verwechsel ich da etwas?
CDC wurde nicht mehr unterstützt, damit kann ein Com-Port über ein
USB-Gerät erstellt werden wenn es eingehangen wurde, aber unter Linux
geht das wieder und bei Windows wurde das jetzt glaube ich auch
Standard-conform implementiert.
Daran liegt es aber nicht da hier ja das HID-Protokoll verwendet wird,
da braucht man keine Treiber.
Ich denke dass er einfach einen Schaltungsfehler gemacht hat, vielleicht
hat er einen Pin vertauscht oder das USB-Kabel war ein China-Kabel bei
dem rot und schwart zwar für +5V und GND stehen, aber die beiden anderen
Farben (weiß/grün) vertauscht sind ... war bei einem Kabel von mir mal
so.
Da kann man nur alles nachmessen und testen ob die Signale wirklich an
der richtigen Stelle rauskommen.
Danke für die vielen Infos!
Mike J. schrieb:> nicht mit einem 1.5k, sondern mit einem 1k Ohm
Das habe ich ausprobiert. Macht leider keinen Unterschied. Habe auch 2k2
ausprobiert, weil man es in vielen Schaltungen sieht. Ebenfalls
erfolglos
Mike J. schrieb:> vielleicht> hat er einen Pin vertauscht
Habe alles schon ein paar mal durchgemessen. Bei der Pinbelegung habe
ich mich an Wikipedia orientiert:
http://de.wikipedia.org/wiki/Universal_Serial_Bus#Farbkodierung_und_Pinouts
Die Belegung stimmt.
Außerdem habe ich gerade noch einmal einen anderen USB Sniffer
ausprobiert. Es kommt leider garnichts vom Controller hoch. Kein
Descriptor und der Rest dann sowieso nicht.
Könnte das an meinem Aufbau auf Lochraster liegen? Ich habe allerdings
auch schon Aufbauten auf dem Steckbrett (als Foto im internet) gesehen.
Meine Verdrahtung ist quasi Fädeltechnik, aber auch schon alles mehrmals
durchgepiept.
An welcher Stelle kann ich noch suchen? Tippt ihr mehr auf Soft- oder
Hardware?
Ich habe mir außerdem noch einmal die Interrupt-Beschaltung des Tiny44A
angesehen. Aber da ist auch alles per default korrekt eingestellt.
Grüße vom (nicht eingeloggten) Jan
Jan S jannemann schrieb:> An welcher Stelle kann ich noch suchen? Tippt ihr mehr auf Soft- oder> Hardware?
Also bei mir hatte es auch nicht beim ersten mal funktioniert.
Ich hatte mir das Custom-HID Beispiel genommen, auf meinen Controller
etwas umgeschrieben ... und es ging nicht.
Als ich dann das Originale Beispiel genau so verwendet hatte ging es
auch erst nach dem ich zwei Fehler aus meiner Schaltung entfernt hatte.
Ein normales V-USB-Gerät funktioniert bei mir auch an jedem USB-Port,
also direkt am Laptop und auch an jedem Hub.
Theoretisch sollte man 2.2k von +5v nach D- nehmen und 1.5k von +3.3V
nach D+ , es geht dabei um einen Strom von 2mA der fließen muss damit
das Gerät erkannt wird. Bei mir funktionierte es mit 3mA besser, das lag
vielleicht an der Southbridge meines PC's.
Kannst du einmal einen AVR mit dem Standardbeispiel aus der Quelle,
einem 12MHz Quarz, einer Minimalbeschaltung, mit stabilisierter 3.3V
Versorgung und wirklich nur dem USB-Anschluss aufbauen?
(also das was du momentan hast, nur mit 3.3V Regler und dem Beispielcode
von V-USB, meinetwegen auch das Custom-HID Beispiel in dem eine LED an
und ausgeschaltet wird, bzw. deren Status abgefragt wird)
Wenn du momentan keinen 3.3V Regler hast kannst du einen einfachen
Spannungsfolger aufbauen. [wie auf dem Bild im Anhang]
Mike J. schrieb:>> Und win7 unterstützt einen spez USB Modus nicht mehr, der dort benötigt>> wird - oder verwechsel ich da etwas?>> CDC wurde nicht mehr unterstützt, damit kann ein Com-Port über ein> USB-Gerät erstellt werden wenn es eingehangen wurde, aber unter Linux> geht das wieder und bei Windows wurde das jetzt glaube ich auch> Standard-conform implementiert.
Diese Darstellung des Sachverhalts ist (fast) komplett falsch.
Richtig ist folgendes:
USB-CDC benutzt lt. Standard Bulk-Transfers. Das Problem ist nun, daß
V-USB ein LowSpeed-Gerät darstellt, der USB-Standard aber für
LowSpeed-Geräte eigentlich nur Interrupt-Transfers zuläßt.
Früher(tm) haben sich weder die USB-Treiber von Windows noch von Linux
darum geschert und ein LowSpeed-Gerät mit Bulk-Endpoints einfach
akzeptiert, also auch eine CDC-Implementierung auf Basis von V-USB.
Als dann V-USB allgemein verfügbar wurde und in der Folge massenweise
dieses "Schlupfloch" auch tatsächlich genutzt wurde, haben beide
Betriebssysteme ihre Treiber dahingehend geändert, daß sie diese
Situation abfangen, also keine Bulk-Transfers mehr für LowSpeed-Geräte
zulassen.
Wenn man sich die uralte Frage des "cui bono" stellt, dann bekomt man
als einzig sinnvolles Ergebnis, daß das höchstwahrscheinlich auf Druck
des USB-Konsortiums geschah, denn wenn ein Industriekonsortium Druck
macht, sind immer vor allem die wirtschaftlichen Interessen von dessen
Mitgliedern im Spiel...
Bei Linux wurde aber wenigstens zusätzlich ein Patch eingebaut, der bei
LowSpeed-Geräten aus einem Bulk-Endpoint einen Interrupt-Endpoint macht.
Damit funktionieren diese Geräte zwar wenigstens weiter, allerdings ca.
8 mal langsamer, als sie eigentlich funktionieren könnten. Streng
genommen ist aber auch dieses "Umrubeln" des Endpoint-Typs ein Verstoß
gegen den Standard. Was Linux betrifft, hätte also eigentlich auch alles
so bleiben können, wie es war, denn es wird jetzt nur auf eine andere
Art gegen den Standard verstoßen, aber es wird nach wie vor dagegen
verstoßen.
Windows hingegen hat keinen solchen Patch eingebaut bekommen, damit
funktionierte garnichts mehr, was auf CDC over V-USB beruht. Damit ist
der Standardverstoß zwar grandios behoben, aber noch mehr auf Kosten der
Nutzer als bei Linux. Aber Hauptsache, die Mitglieder des
USB-Konsortiums freut's und es füllt die Taschen ihrer Shareholder...
> Daran liegt es aber nicht da hier ja das HID-Protokoll verwendet wird,> da braucht man keine Treiber.
Natürlich braucht auch HID einen Treiber, aber der ist bei beiden
Systemen gleichermaßen eingebaut wie der CDC-Treiber, nämlich als
generischer Klassentreiber. Der entscheidende Unterschied in diesem
Zusammenhang ist nur der, daß HID von Hause aus mit Interrupt-Endpoints
läuft. Deswegen gibt es hier auch im Gegensatz zu CDC auch kein Problem,
wenn ein HID-Device auf Basis von V-USB implementiert ist.
Mike J. schrieb:> Kannst du einmal einen AVR mit dem Standardbeispiel aus der Quelle,> einem 12MHz Quarz, einer Minimalbeschaltung, mit stabilisierter 3.3V> Versorgung und wirklich nur dem USB-Anschluss aufbauen?>> (also das was du momentan hast, nur mit 3.3V Regler und dem Beispielcode> von V-USB, meinetwegen auch das Custom-HID Beispiel in dem eine LED an> und ausgeschaltet wird, bzw. deren Status abgefragt wird)
Hardwareaufbau mit stabilisierten 3,3V werde ich ausprobieren. Ist ja
kein großer Akt.
Von den Standardbeispielen habe ich die HID Mouse ausprobiert. Selbes
Fehlerbild. Daher vermute ich eigentlich ein Hardware Problem.
Ich würde jetzt eine Platine machen, wo alles ein bisschen sauberer
drauf liegt.
Dann auch gleich einen Tiny85 nehmen, da es für diesen schon eine Menge
an Beispielen gibt. Den Tiny44 hatte ich halt noch zu Hause.
Schönen start in die Woche!
Jan
@c.hater:
Also der einzige Workaround wäre dann ja quasi ein altes OS zur
Kommunikation zu nutzen. Ich arbeite hier an einen Digispark (ATtiny85),
der nutzt auch CDC über V-USB was halt nicht (mehr) funktioniert.
Ich werde dann wohl oder übel eine Windows-XP VM aufsetzen müssen (oder
mit einem anderen alten OS) und dann den USB-Port dahin durchreichen...
Um Zeichen im Betrieb von PC an das Ding zu senden käme sonst nur eine
echte serielle Schnittstelle in Frage, ich habe aber weder einen
USB-Adapter noch einen COM-Port. Siehe:
http://digistump.com/wiki/digispark/tutorials/debugging
Thread beobachten
Seitenaufteilung abschalten