Ich habe ein Problem: Ich wollte im Tiny24 eine USB-Schnittstelle integrieren, da aber alle Pins bei PortB belegt sind (Quarz, Reset und D+) musste ich D- auf einen anderen Port legen. Wie kann ich im AVR-USB für D+ und D- zwei verschiedene Ports einstellen? Bzw. hat jemand eine andere USB-Firmware mit der das möglich ist?
Das wird wohl nicht funktionieren. Diese SW USB Implementationen sind performancemäßig sowieso ganz stark an der Grenze des Möglichen. 2 Ports bedeuten aber je Bit 2 Schreib/Lesevorgänge, das wird das Ganze wohl sprengen. Gruß, Marcus
Mir ist vielleicht noch eine Lösung eingefallen, aber würde vorher gern von euch wissen, ob das möglich ist oder nicht: Kann ich nicht einfach die D+ Leitung auf Int0 eines anderen Portes (nur um den Interrupt auszulösen Beispiel PINB2) und dann eben diese D+-Leitung noch einmal auf zum beispiel PINA4 (gewöhnlicher IO-Pin). Somit müssten doch Signale erkannt werden und keine 2 Schreibvorgänge benötigt werden, oder?
Also abgesehen davon, dass die Software USB Lösungen ohnehin großer Müll sind (netter Hack, aber für praktischen Einsatz untauglich), ist das Signal auf dem USB (die meiste Zeit) differenziell, es muss also jeweils der umgekehrte Pegel auf den beiden Leitungen liegen. Das klappt noch bei einem Port, da dann beide Pins gleichzeitig geschrieben werden, aber bei zwei Ports hast Du ständig unzulässige Buszustände.
Müsste eigentlich gehen, dass man nur ein Signal ausgibt und das zweite durch einen Inverter erzeugt. Glaube nicht, dass es so zeitkritisch ist, ansonsten nimmt man einen inv und einen nicht-inv Treiber.
Bensch wrote: > Müsste eigentlich gehen, dass man nur ein Signal ausgibt und das zweite > durch einen Inverter erzeugt. Glaube nicht, dass es so zeitkritisch ist, > ansonsten nimmt man einen inv und einen nicht-inv Treiber. Ach, und der Inveter ist bidirektional?
Angehängte Dateien:
-
usb-avr_io_raster_top.jpg
320 KB
Guido Körber wrote: > Also abgesehen davon, dass die Software USB Lösungen ohnehin großer Müll > sind (netter Hack, aber für praktischen Einsatz untauglich), [...] Ach, ist das so? Ich nutze mehrere USB-Seriell-Wandler auf Basis eines ATtiny2313 (AVR-CDC) produktiv, ich weiß nicht wo das Problem sein soll. Da FTDI die Chips nur als SMD fertigt, gibts für Leute die nicht ätzen sondern Rasterplatinen nehmen keine Alternative (mal von den überteuerten DIP-Modulen abgesehen, die sind preislich nämlich keine Alternative). Allerdings nehme ich auch den µC der USB macht für nix anderes, wenn ich in einem µC-Projekt USB brauche, kommt eben ein tiny2313 als USB-Controller hinzu (siehe Anhang). Gruß Dominiqie Görsch
bensch, denk dran,d ass usb ein bidirektionaler bus ist
Funktioniert es jetzt wie ich es nun mit dem Tiny24 lösen will oder nicht? Ich müsste dann halt noch wenn Daten gesendet werden, den PCINT abschalten, dass hier nicht unnötig viel Rechenzeit vergeudet wird...
>Ach, ist das so? Ich nutze mehrere USB-Seriell-Wandler auf Basis eines >ATtiny2313 (AVR-CDC) produktiv, ich weiß nicht wo das Problem sein soll. >Da FTDI die Chips nur als SMD fertigt, gibts für Leute die nicht ätzen >sondern Rasterplatinen nehmen keine Alternative (mal von den >überteuerten DIP-Modulen abgesehen, die sind preislich nämlich keine >Alternative). Die CDC funktioniert doch nur unter XP, das nutzt du Produktiv und hast nich einen dabei der Vista benutzt ??
Christian Ulrich wrote: >>Ach, ist das so? Ich nutze mehrere USB-Seriell-Wandler auf Basis eines >>ATtiny2313 (AVR-CDC) produktiv, ich weiß nicht wo das Problem sein soll. >>Da FTDI die Chips nur als SMD fertigt, gibts für Leute die nicht ätzen >>sondern Rasterplatinen nehmen keine Alternative (mal von den >>überteuerten DIP-Modulen abgesehen, die sind preislich nämlich keine >>Alternative). > > Die CDC funktioniert doch nur unter XP, das nutzt du Produktiv und hast > nich einen dabei der Vista benutzt ?? Ohne es selber getestet zu haben, laut Doku läuft das Ding auch mit Vista: ,--- Auszug aus der Readme.txt --- | USAGE | ===== | Install the virtual COM/CDC protocol interface driver. | Connect AVR-CDC device and follow the dialog instructions. | Indicate "inf/vista/" folder to install "usbser.sys" and | "lowbulk.sys". | | /inf -- /vista -- lowbulk.inf | -- lowbulk.sys | -- /xp2k -- avrcdc.inf `--- Gruß Dominique Görsch
Marc08 wrote: > Kann ich nicht einfach die D+ Leitung auf Int0 eines anderen Portes (nur > um den Interrupt auszulösen Beispiel PINB2) und dann eben diese > D+-Leitung noch einmal auf zum beispiel PINA4 (gewöhnlicher IO-Pin). Musst du gucken, ob du die Software dafür angepasst bekommst, aber das könnte funktionieren.
Also bisher hat es leider noch nicht geklappt, aber Der Int0 wird ja sowieso defaultmäßig genommen... Eigentlich sollte es ja dann funktionieren... Liegt es vielleicht an falschen Fuses? Braucht AVRUSB eine bestimmte Anlaufzeit? Für was ist die Fuse Clockout on Pin B2, brauch ich die Option für nen Quarz oder ist die nur um den Clock zu verstärken und an andere Bauteile weiterzuleiten?
Marc08 wrote: > Liegt es vielleicht an falschen Fuses? Kann sein. Damit das USB funktioniert, muss der Controller ziemlich genau mit dem (durch die Software) vorgeschriebenen Takt arbeiten, sonst stimmt das Timing nicht. Dafür musst du aller Wahrscheinlich- keit nach einen externen Quarz oder Keramikresonator anschließen und auch per Fuse aktivieren. > Braucht AVRUSB eine bestimmte Anlaufzeit? Die Software sicher nicht, aber ein Quarz oder Keramikresonator braucht eine Anschwingzeit, bevor er stabilen Takt liefert. Dafür sind die SUTx-Fuses ja da. > Für was ist die Fuse Clockout on Pin B2, brauch ich die Option für nen > Quarz oder ist die nur um den Clock zu verstärken und an andere Bauteile > weiterzuleiten? Ja, beinahe so. Mit dieser Fuse wird der Takt an Pin B2 ausgegeben, mit dem die CPU arbeitet -- egal, woher dieser Takt gerade kommt. Im Falle eines Quarzes ist das natürlich erst einmal der gleiche Takt wie bereits an XTAL2, nur eben (insofern richtig) nochmals verstärkt. Aber man kann damit auch den Takt des internen RC-Oszillators an andere Baugruppen weitergeben, falls der Controller selbst von diesem getaktet wird. Das war ohne die CKOUT-Fuse nicht möglich.
Sorry jetzt muss ich hier nochmal schreiben... Ich bekomme den AVR-USB einfach nicht zum laufen! Der Interrupt wird ja unabhängig von dem Konfigurierten Port und Bitnummern auf INT0 gesetzt, das heißt wenn ich den Port D einstelle ist trotzdem der Interrupt INT0 auf dem PinB2 aktiv, oder? Hat jemand noch eine Idee? PS: Die DDR-Register sind alle auf 0, also Eingang... (Ein- und Ausgang stellt sich ja AVR-USB selbst ein, oder?)
Marc08 wrote: > Ich bekomme den AVR-USB einfach nicht zum laufen! Dann wirst du es wohl oder übel debuggen müssen. Du weißt doch, die Glaskugeln von heute sind auch nicht mehr das, was sie mal waren... Meine konnte mir jedenfalls nicht sagen, ob du nur die Verdrahtung vermasselt hast, den Takt falsch gesetzt, das Teil unpassend compiliert, oder ob dein Host nur Schluckauf mit der Art und Weise hatte, wie du die Descriptortabellen aufgesetzt hast. Ich würde, wenn ich das debuggen müsste: . Erst einmal mit einer Minimal-Applikation nachschauen, ob der Controller ,,vernünftig'' reagiert, d. h. ob der passende Takt vorhanden ist (kann man durch einen Timer mit OC-Ausgang machen) und ob alle Pins, die benötigt werden, sauber reagieren. . Maximales USB-Debugging auf dem Host einschalten und erst einmal schauen, was der Host-Treiber zum Ansinnen der "function" (also des Endgerätes) sagt, jetzt am Bus bekannt gemacht zu werden; das betrifft zu allererst einmal den sogenannten HCD (host controller driver), erst wenn die initialen Setup-Meldungen ausgetauscht werden können, kommt dann der klassen- oder gerätespezifische Treiber ins Spiel. . Auf der Function den Verlauf der Verhandlungen irgendwie nachvollziehbar machen, um den Fehler einzukreisen. Da das alles praktisch in Echtzeit ablaufen muss (dreimaliges Nichtmelden auf eine USB-Bus-Transaktion im Abstand von je 1 ms wird als Abmeldung vom Bus gehandhabt), kommt man gerade bei Software-USB mit ,,normalen'' Debug-Mitteln nur begrenzt weiter, d. h. an der Stelle, wo der Debugger einen Breakpoint erreicht, sind alle Wetten gelaufen, und der Host verliert das Gerät. Man kann aber auch das Eintreffen der einzelnen Setup-Meldungen durch Debugausgaben auf einen Port verfolgen lassen (UART, falls vorhanden, oder einfach ein paar Bits hochzählen und das auf dem Oszi, Logic analyzer oder einfach nur mit LEDs anzeigen)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.