echtes USB mit AVR

[BlackDevil]

Servus

Ein Freund von mir möchte ein echtes USB Gerät bauen (echt mein Nativ, also mit Stack und Co).

Da ich keinen blassen Schimmer von USB habe blick ich bei dem Wust an Chips nicht so ganz durch . Es gibt Receiver, Transmitter, Stacks, USB-USART Wandler in allen Formen und Farben ... aber wirklich etwas gefunden mit dem ich mit hilfe eines AVR ein "echtes" USB Gerät bauen kann hab ich nicht gefunden. Oder tuts da einfach ein AT90USB mit LUFA? Und wie Programmier ich am besten eine GUI mit USB am PC? C++ fällt weg, das wäre mir persönlich zu Kompliziert ...

Noch mal in Kurz: Ich suche eine möglichkeit ein echtes bzw natives USB Gerät mit einem Atmega zu bauen. At90USB oder gibts Chips die das übernehmen?


Vielleicht weis ja jemand was

 

[Dirk]

Hallo Blackdevil,

At90USB oder gibts Chips die das übernehmen

sowohl als auch.

Ich empfehle erst einmal, die Application Notes von Atmel zum Thema durchzuarbeiten, dann überlegen, was man am besten für seine Anforderungen anwenden möchte oder muss. Zum Starten gibts zum Beispiel das Atmel Developmentboard AT90USBKEY (ab Mitte nächster Woche wieder im Onlineshop verfügbar, oder bei mikrocontroller.net oder eventuell bei reichelt oder conrad ...)

Gruß,
Dirk

 

[Klaus]

Hallo BlackDevil,
was solls denn werden ? Ein USB-Device (Maus, Tastatur, generic I/O, Programmer....) oder ein USB- Host oder ein OTG-Gerät, daß sowohl Device-und Hostfunktionalität beinhaltet.
Für USB-Device eigenet sich zB AT90USB1286 und für Host oder OTG der AT90USB1287.
Wenn's ein Device werden soll, muß man sich entscheiden ob es einer
vordefinierten USB-Klasse entspricht (HID, Kamera/Scanner, Programmer), dann gibt es in Windows schon Treiber, oder ob es etwas eigenes werden soll, dann brauchts auf der Windows Seite auch eigene Treiber.
Für Devices, die nicht einer vordefinierten Klasse entsprechen gibt es generic Treiber (zB. USBIO von www.thesycon.de), dann braucht man sich nur um die Windows-Applikation zu kümmern.
Auf jedem Fall sind die ATMEL-Application-Notes sehr hilfreich. Besonders was den ganzen Enumerationsprozess des Devices betrifft.
Der Enumerationsprozess ist schwierig auf der Deviceseite zu debuggen. Setzt man während der Enumeration einem Breakpoint, gibt es auf der PC-Seite ein Time-Out und es erscheit die gelbe Box "USB-Device not recognized".
Das sei nur als Beispiel erwähnt, um zu zeigen, daß die USB-Programmierung am Anfang ein hartes Brot ist. Aber USB ist nun mal Stand der Technik und man kommt nicht daran vorbei.
OK, erst mal genug, schreib mal ein paar Details.
MfG
Klaus

 

[BlackDevil]

Interessant wäre zum Beispiel auslesen und eingeben von Werten (Beispiel Lüfterregelung: Eingeben von Sollwerten, Anzeigen von Istwerten)

Ich schau mir mal die Appnotes an danke. Wusste gar nicht das das so kompliziert ist

 

[dino03]

Hi,

Interessant wäre zum Beispiel auslesen und eingeben von Werten (Beispiel Lüfterregelung: Eingeben von Sollwerten, Anzeigen von Istwerten)

Ich schau mir mal die Appnotes an danke. Wusste gar nicht das das so kompliziert ist

aus dem Grund arbeite ich lieber mit dem UART und notfalls nem Wandler-IC
auf USB damit ich mir über den USB-Shit nicht den Kopf zerbrechen muß.

USB und LAN sind mit die kompliziertesten Dinge bei nem Microcontroller.
Viel Spaß beim programmieren von den Protokollen
Ich werd mir das auf jeden Fall nicht antun

Evtl noch LAN wenn ich nan nen Chip mit Hardware-Stack drankomme
(bestellmäßig) aber sonst laß ich da schön die Finger von. Kein Bock
zig Stunden damit zu verbrennen. Soviel Zeit hab ich auch nicht übrig.

Gruß
Dino

... Wer hat Lust nen AVR-gesteuerten Kernspin-Tomographen zu bauen :tomato:
... Hat einer für das Teil ne Bezugsquelle für supraleitende Spulen ?
Aua! Nicht hauen ! Nicht mit dem Hammer ...

 

[BlackDevil]

Für LAN gibt es aber einige schöne Chips mit SPI (zum Beispiel). Das ist dann schon mal wesentlich einfacher. Für USB gibts ja auch schon "LUFA", das machts auch noch mal einfacher

Ich schau mir das mal an danke

 

[dino03]

Hallo,

Für LAN gibt es aber einige schöne Chips mit SPI (zum Beispiel). Das ist dann schon mal wesentlich einfacher. Für USB gibts ja auch schon "LUFA", das machts auch noch mal einfacher

Ich schau mir das mal an danke

Meinst du das wirklich ?
Gegenüber nem reinen LAN-Chip wie nem RealTek sicherlich. Aber das man
das dadurch dann einfach mal in ein paar Minuten auf die Reihe bekommt ...
Kannst Du dir abschminken.

Hast Du schon mal mit Wireshark oder SnifferPro ne Netzwerk-Analyse gemacht ?
Wenn du eine Kommunikation auf dem Netzwerk mitlesen, Fehler erkennen
und sagen kannst was da in den Paketen abgeht, dann kannst Du dran
denken sowas zu programmieren. Vorher würde ich sagen ... Viel Spaß !

Für den USB-Port gibt es auch eine Art "Sniffer" der den Verkehr mitlesen und
analysieren kann.

UDP, TCP, TCP Retransmits, Syn-SynAck-Ack, Fragmentierung, ... usw

Gruß
Dino

 

[BlackDevil]

Auf dem NetIO Board ist ein ganz netter Chip. Zum Beispiel. Ulrich Radig hat eigentlich auch schon alles vorbereitet... geht also eigentlich.

LAN auf dem PC zu Programmieren geht auch (LInux).


Zum Thema Sniffen: Ich hatte letztes Semester Industrielle Datenkommunikation, hab also grob die Grundlagen von verschiedensten Bussen drin

 

[dino03]

Hallo,

Zum Thema Sniffen: Ich hatte letztes Semester Industrielle Datenkommunikation, hab also grob die Grundlagen von verschiedensten Bussen drin

die Busse oder die Protokolle ?

Ich meine so etwas ...

No.     Time        Source                Destination           Protocol Info
     10 4.962675    10.0.0.12             212.42.244.80         HTTP     GET / HTTP/1.1 

Frame 10 (424 bytes on wire, 424 bytes captured)
Ethernet II, Src: AsustekC_63:51:8b (00:23:54:63:51:8b), Dst: Cisco_8a:60:61 (00:05:5e:8a:60:61)
Internet Protocol, Src: 10.0.0.12 (10.0.0.12), Dst: 212.42.244.80 (212.42.244.80)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 410
    Identification: 0xf3ad (62381)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0x3329 [correct]
    Source: 10.0.0.12 (10.0.0.12)
    Destination: 212.42.244.80 (212.42.244.80)
Transmission Control Protocol, Src Port: agri-gateway (3026), Dst Port: http (80), Seq: 1, Ack: 1, Len: 370
    Source port: agri-gateway (3026)
    Destination port: http (80)
    Sequence number: 1    (relative sequence number)
    [Next sequence number: 371    (relative sequence number)]
    Acknowledgement number: 1    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
    Window size: 146000 (scaled)
    Checksum: 0xd413 [incorrect, should be 0x2eee (maybe caused by "TCP checksum offload"?)]
Hypertext Transfer Protocol
    GET / HTTP/1.1\r\n
    Host: www.avm.de\r\n
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3\r\n
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
    Accept-Language: de,en;q=0.7,en-us;q=0.3\r\n
    Accept-Encoding: gzip,deflate\r\n
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
    Keep-Alive: 300\r\n
    Connection: keep-alive\r\n
    \r\n

Solche Protokolle verstehen und in ihnen Fehler finden. Das ist etwas anderes
als Busstrukturen und Schnittstellenstandards. Ich meine die eigentliche
Kommunikation.

Gruß
Dino

 

[BlackDevil]

Ja Wireshark haben wir auch benutzt. Genauso wie wir ein TCP und UDP Programm auf Linuxbasis Programmiert haben. Ein Webserver auf Atmel Basis stand auch auf dem Plan aber das ging Zeitlich irgendwie nicht auf.

Fehler finden haben wir nie geübt aber ich denke das sollte auch gehen

Einen CAN Sniffer hatten wir auch schon am laufen

 

[mmi]

So schwierig ist die USB-Anbindung eigentlich nicht. Es gibt von FTDI einen USB-UART Chip (FT232R), der relativ einfach integriert werden kann.

Für Windows und im Linux-Kernel ist als Treiber FTDSIO verfügbar, so genügt PC-seitig bereits ein einfaches Terminalprogramm. COMx bzw. /dev/ttyUSBx stehen dann zur Verfügung, die Programmierung ist nicht anders als für eine herkömmliche RS232 Anwendung.

AVR-seitig ists auch nicht so aufwändig, nachdem ja alle USB-spezifischen Dinge der FTDI-Chip erledigt.

Vielleicht auch mal in der Arduino-Welt "spicken", da hat fast jedes Board den Chip drauf und C-Quellcode für die dort mitgelieferte SerialLib gibt's auch.

vg, mmi.

 

[BlackDevil]

FTDI ist aber ein USB Seriell Wandler und taucht auf der PC Seite als virtueller Comport auf. Ist zwar einfach zu handlen aber kein echtes USB

 

[dino03]

Hallo zusammen,

FTDI ist aber ein USB Seriell Wandler und taucht auf der PC Seite als virtueller Comport auf. Ist zwar einfach zu handlen aber kein echtes USB

das ist auch echtes USB aber mit Hardware-Beschleunigung. Genau so wie bei
deinen Beispielen im Thread mit dem LAN. Da gibt es auch Chips mit Hardware-Stack
für TCP/IP. Damit man den Kram nicht komplett in Software schreiben muß.

So schwierig ist die USB-Anbindung eigentlich nicht. Es gibt von FTDI einen USB-UART Chip (FT232R), der relativ einfach integriert werden kann.

Die benutze ich auch. Aber ich bau mir keine HIDs oder anderes Zeugs
komplett mit Software nach.

@BlackDevil : Wie war das mit deinem GLCD ? Ist das auch kein echtes GLCD ?
Es zeigt Grafiken an also ist es ein GLCD. Nur das schon jemand ein wenig
Arbeit in Vorleistung gemacht hat. Die eigentliche Frage ... kann ich es für die
Aufgabe gebrauchen und lohnt sich der Mehrpreis ?

Ob jetzt mit IC (FTDI bei USB und W5100 bei LAN) oder komplett in Software,
es ist ECHTES USB und LAN. Aber mit Hardware vereinfacht.

Wenn es kein echtes wär, dann könnte es nicht mit anderen Geräten mit dem
Standard operieren.

Das wär so als ob jemand sagen würde ...
Nein, ich benutze nicht den TWI des AVRs. Das ist ja kein echter I2C. Ich
mach das mit Software direkt an den IO-Pins. Nur das ist echtes I2C.

Was will dein Kumpel eigentlich machen ? Was versteht er unter "echtem"
USB ?

Naja ... Kleinkariertes Gelaber ... Kein Bock ...

Gruß
Dino

 

[BlackDevil]

Unter echtem USB versteh ich etwas das nicht als virtueller COM Port auftaucht Was er machen will bzw wir? Eine Lüftersteuerung für einen PC mit dem PC verbinden (Anzeige von Stati und Einstellungen treffen)

 

[dino03]

Hi,

Unter echtem USB versteh ich etwas das nicht als virtueller COM Port auftaucht

Wie sieht es dann mit HIDs aus ? (Tastatur, Maus, Joystick, ...) oder Audio oder
Massenspeichergerät (USB-Stick) ... ???

Was er machen will bzw wir? Eine Lüftersteuerung für einen PC mit dem PC verbinden (Anzeige von Stati und Einstellungen treffen)

Als was soll das Teil auftauchen ? Wollt ihr ne eigene Geräteklasse erzeugen ?
Oder wollt ihr die Daten roh durch das USB-Device laufen lassen ?
Soll das Rad das zweite mal erfunden werden ? Warum macht ihr eigentlich
alles so kompliziert ? Alles gleich viel besser viel größer und mit vergoldeten
Griffen. Fangt doch erst mal klein an und wenn es läuft kann man es immer
noch erweitern.

Erst mal die Steuerung bauen. Und wenn die läuft kann man immer noch von
UART auf USB ändern. Dann steht aber wenigstens schon mal die Grundstruktur.
Irgendwie sieht das aus als ob ihr erst mal das Zündschloß baut und danach
zuseht wie man das Auto drum rum bauen kann. Die Schnittstelle kann man
relativ einfach modular anlegen und später recht schnell tauschen.

Gruß
Dino

 

[BlackDevil]

Da der rest in der Planungsphase zu 90% steht und keine Rätsel offen lässt auser der implementierung kam halt die frage auf wie man am dümmsten über USB "echt" Kommuniziert.

Für mich gibt es bisher immer zwei Verisonen: Echtes USB das als Gerät auftaucht (Maus, Keyboard, Headset meinet wegen) und solches das als COM Port angesprochen wird (FT232). Wenn das beides das gleiche ist ist ja gut

 

[Dirk]

Hallo Blackdevil,

für eure Annwendung dürfte doch der virtuelle COM Port ausreichen.

Ich mag die Lösung mit VCP nicht so, weil der COM Port nun mal nicht software- und hardwareseitig plug-and-play-fähig ist, einige Programme mögen es nicht so, wenn aufeinmal ein COM Port nicht mehr verfügbar ist und melden dies dann mit einem "Auf Wiedersehen" Im eigenen Programm kann man da schon einige Sicherheiten einbauen, damit soetwas nicht passiert. Beim Silabs USB-UART-Bridge (siehe unsere Mikrocontrollermodule MEGA128-USB und XMega-A1-USB hier im Forum) wie auch sicherlich beim FTDI, kann man auch einen direkten USB-Treiber nutzen, hier hat man dann mehr Features (zum Beispiel eine höhere Transferrate), allerdings ist der Entwicklungsaufwand der PC-Software auch ein bisschen höher.

Dirk

 

[mmi]

Hallo zusammen,

ich kann nur aus Linux-Sicht sprechen und von einem virtuellen Comport kann bei FTDI nicht die Rede sein. Wenn es bei Windows so ist, liegts vermutlich eher am Treiber als an der Hardware.

FTDI meldet sich (HardwareID 0403:6001) und wird als ganz normales USB Device eingebunden wie jedes andere Gerät (Tastatur, Maus, Modem, etc.) auch und ist softwaremässig uneingeschränkt ansprechbar.

Das ist zumindest aus meiner Sicht "echtes USB".

VG, mmi.

 

[BlackDevil]

Ja okay wenn das so ist akzeptier ich das auch als echtes. Wie sprech ich das dann am PC an wenn nicht als Virtueller COM Port? Das ist, jedenfalls für mich, die größte Hürde: Das PC Programm. Dafür muss ich mich noch mal in C# einlesen, C++ is mir da zu assig Oo

 

[mmi]

Du arbeitest unter Windows, oder?

Dort müsste doch im Gerätemanager irgendein COMx auftauchen?
Wenn Du darauf OPEN bzw. READ/WRITE Kommandos absetzt, sollte es doch funktionieren? Ein einfaches Terminalprogramm sollte testweise auch erstmal genügen.

Vielleicht Speed, Parity, Stoppbits sicherheitshalber schon mal als Standard vorgeben?

Leider kann ich kaum etwas zu Windows sagen, da bin ich zugunsten Linux vor ein paar Jahren ausgestiegen.

VG, LW.