www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Software-USB (obdev) als Massenspeicher


Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

für ein Projekt mit einem ATmega644 an einer SD-Karte (unter Anderem) 
benötige ich eine USB-Schnittstelle. Dazu verwende ich den 
Software-USB-Treiber von obdev, was soweit auch ganz gut zu 
funktionieren scheint (Was die prinzipielle Übertragung angeht), 
allerdings möchte ich das Gerät als Massenspeicher verwenden. Dazu habe 
ich DeviceClass und DeviceSubClass auf 0 und InterfaceClass, 
InterfaceSubClass und InterfaceProtocol auf 0x08 (Mass storage), 0x01 
(Reduced Block Commands) und 0x50 (Bulk-only) gestellt. Soweit so gut. 
Wenn ich das Teil nun aber unter Windows anstecke, dann fragt mich das 
System nach einem Treiber, obwohl die Unterstützung für 
Massenspeichergeräte gegeben ist (Treiber sind im System verfügbar). 
Anhand der Debug-Ausgaben sehe ich, dass die Enumeration bis zur 
Übertragung der String-Deskriptoren läuft und dann abbricht. 
Wahrscheinlich weil dann eben der Treiber zu fehlen scheint. Warum auch 
immer.
Wie auch immer, jedenfalls habe ich das Teil dann mal testweise unter 
Linux angeschlossen und dort wird es korrekt als Massenspeicher erkannt 
und der Treiber installiert?!
Hier wäre vielleicht noch anzumerken, dass für Massenspeicher 
Bulk-Endpoints benötigt werden, die für Low-Speed-Geräte gemäss 
USB-Spezifikation nicht zugelassen sind. Ich kann mir aber schlecht 
vorstellen, dass es daran liegt, Windows hält sich eh nicht an Standards 
und die Enumeration bricht ja nicht nach dem Config-Deskriptor ab, 
sondern erst etwas später.

Langer Rede kurzer Sinn:
Hat schonmal jemand (erfolgreich) ein Massenspeichergerät mit dem 
obdev-Treiber realisiert und was muss ich dabei speziell beachten?
Mit welchen Programmen lässt sich gescheit analysieren, wie die 
Enumeration abläuft und was möglicherweise für Fehler auftreten? 
USB-Monitor von HHD-Software und SnoopyPro habe ich bereits ausprobiert, 
doch beide liefern überhaupt keine übertragene Pakete. Obwohl 
USB-Monitor die Device- und Config-Deskriptoren korrekt anzeigen kann!
Gibt es Alternativen, die ohne Treiber auskommen und sich ebenfalls 
verhalten können wie externer Speicher (In der HID-Klasse vielleicht)?

Achja: Es geht nicht nur um den Zugriff auf die SD-Karte, der Controller 
sollte selber auch noch Dateien vorgaukeln die da nicht drauf sind. 
Fertige USB<->SD-Wandler (-ICs) sind also keine Alternative.


Grüsse,
Philipp

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für MSD benötigst Du BULK Endpoints. Diese gibt es nicht für Low-Speed 
Devices, das ist per Spezifikation verboten. Die logische Konsequenz ist 
das Deaktivieren des Gerätes.

Außerdem lese ich das jetzt so, als hast Du nur die Deskriptoren Deines 
Gerätes verändert (und vermutlich nichtmal vollständig, da die 
Spezifikation auch eine Seriennummer in einem bestimmt Format 
vorschreibt). Das reicht nicht aus, denn der Host wird Dein Gerät mit 
einigen der Geräteklasse zugehörigen Requests kontaktieren (z.B. 
SCSI_INQUIRY, SCSI_MODE_SENSE_6, SCSI_START_STOP_UNIT usw.). Wenn Du 
darauf nicht antwortest, wird das Gerät erst recht deaktiviert.

Wie auch immer, ich kenne obdev nicht. Das scheint aber auschließlich 
eine Low-Speed Implementierung zu sein, deswegen funktioniert das, was 
Du da vor hast, auf jeden Fall nicht. Suche Dir lieber einen Controller 
mit On-Chip USB und füttere diesen mit den AppNotes des Herstellers, 
z.B. SiLabs C8051F340 zusammen mit dem MSD Reference Design.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
René König wrote:
> Für MSD benötigst Du BULK Endpoints. Diese gibt es nicht für Low-Speed
> Devices, das ist per Spezifikation verboten. Die logische Konsequenz ist
> das Deaktivieren des Gerätes.

Das ist mir bekannt, schrieb' ich oben ja auch. Allerdings gehe ich 
einfach mal davon aus, dass sich da kaum eine Host-Implementierung drum 
kümmert. Jedenfalls steht in der Firmware von obdev auch, dass es 
meistens funktioniert (Wie (oft) das getestet wurde weiss ich nicht), 
daher möchte ich es gerne mal probieren. Dass es nicht ideal ist, ist 
klar.

> Außerdem lese ich das jetzt so, als hast Du nur die Deskriptoren Deines
> Gerätes verändert (und vermutlich nichtmal vollständig, da die
> Spezifikation auch eine Seriennummer in einem bestimmt Format

Hm, wo finde ich das? Von einer erforderlichen Seriennummer habe ich 
nirgendwo etwas gelesen. Gleich mal nachschauen...

> vorschreibt). Das reicht nicht aus, denn der Host wird Dein Gerät mit
> einigen der Geräteklasse zugehörigen Requests kontaktieren (z.B.
> SCSI_INQUIRY, SCSI_MODE_SENSE_6, SCSI_START_STOP_UNIT usw.). Wenn Du
> darauf nicht antwortest, wird das Gerät erst recht deaktiviert.

Natürlich habe ich noch nix dergleichen implementiert, doch ich bekomme 
ja auch keine solchen Requests. Der Host bricht schon früher (Ohne 
Fehlermeldung) ab. Deaktiviert wird das Gerät aber nicht.

> Wie auch immer, ich kenne obdev nicht. Das scheint aber auschließlich
> eine Low-Speed Implementierung zu sein, deswegen funktioniert das, was
> Du da vor hast, auf jeden Fall nicht. Suche Dir lieber einen Controller

"Auf jeden Fall nicht" mag ich nicht ;)
Aber es ist eine reine Low-Speed-Implementierung, da hast du recht.

> mit On-Chip USB und füttere diesen mit den AppNotes des Herstellers,
> z.B. SiLabs C8051F340 zusammen mit dem MSD Reference Design.

Interessanter Chip. Allerdings würde ich dann lieber bei den AVRs 
bleiben und einen AT90USB verwenden. Aber meine Protos möchte ich 
eigentlich noch so zum Laufen bringen, notfalls halt doch mit 
entsprechender Software auf dem PC.

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp Burch wrote:
> Das ist mir bekannt, schrieb' ich oben ja auch. Allerdings gehe ich
> einfach mal davon aus, dass sich da kaum eine Host-Implementierung drum
> kümmert. Jedenfalls steht in der Firmware von obdev auch, dass es

Na gut, wenn Du zu Deinem Gerät auch gleich noch 'nen Host ausliefern 
willst, um Funktion zu garantieren, kannst Du davon ruhig ausgehen.

> Hm, wo finde ich das? Von einer erforderlichen Seriennummer habe ich
> nirgendwo etwas gelesen. Gleich mal nachschauen...

Das steht auf Seite 9:
http://www.usb.org/developers/devclass_docs/usbmas...

Gewöhne Dir aber ruhig an, für alle Geräteklassen Seriennummern zu 
liefern. ;-)

> Natürlich habe ich noch nix dergleichen implementiert, doch ich bekomme
> ja auch keine solchen Requests. Der Host bricht schon früher (Ohne
> Fehlermeldung) ab. Deaktiviert wird das Gerät aber nicht.

Es wird nicht deaktiviert, das ist sicher? Ich denke, die Leitung bleibt 
IDLE (was nach 3 ms als SUSPEND erkannt wird), oder habe ich Dich noch 
falsch verstanden?

Allerdings ist es so oder so interessant zu sehen, wann der Host 
abbricht. Vielleicht kannst Du mal einen Auszug Deines Logs des 
Protokoll-Analyzers posten, damit wir uns hier ein genaueres Bild der 
Lage machen können.

Oder wird abgebrochen, nachdem Du keine Seriennummer lieferst?

> "Auf jeden Fall nicht" mag ich nicht ;)

Für mich trifft es trotzdem zu, da ich mich nicht auf bestimmte Hosts 
festlegen will. :-)

> Interessanter Chip. Allerdings würde ich dann lieber bei den AVRs
> bleiben und einen AT90USB verwenden. Aber meine Protos möchte ich
> eigentlich noch so zum Laufen bringen, notfalls halt doch mit
> entsprechender Software auf dem PC.

Gibt es von Atmel keine MSD Reference Designs, auf die Du zurückgreifen 
kannst? Immerhin sieht man soetwas heutzutage immer öfter, bei allen 
möglichen Herstellern. Und Atmel ist doch, wass AppNotes betrifft, recht 
vielfältig.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
René König wrote:
> Philipp Burch wrote:
>> Das ist mir bekannt, schrieb' ich oben ja auch. Allerdings gehe ich
>> einfach mal davon aus, dass sich da kaum eine Host-Implementierung drum
>> kümmert. Jedenfalls steht in der Firmware von obdev auch, dass es
>
> Na gut, wenn Du zu Deinem Gerät auch gleich noch 'nen Host ausliefern
> willst, um Funktion zu garantieren, kannst Du davon ruhig ausgehen.

Aber klar doch, ich implementiere einen Hi-Speed-Host in einem AVR (In 
Software) und packe den auch gleich drauf ;D

>> Hm, wo finde ich das? Von einer erforderlichen Seriennummer habe ich
>> nirgendwo etwas gelesen. Gleich mal nachschauen...
>
> Das steht auf Seite 9:
> http://www.usb.org/developers/devclass_docs/usbmas...
>
> Gewöhne Dir aber ruhig an, für alle Geräteklassen Seriennummern zu
> liefern. ;-)

Naja, hat schon was. Auch wenn die Seriennummer erstmal einfach statisch 
ist. Egal, jetzt ist jedenfalls eine drin, geändert hat sich nix.

>> Natürlich habe ich noch nix dergleichen implementiert, doch ich bekomme
>> ja auch keine solchen Requests. Der Host bricht schon früher (Ohne
>> Fehlermeldung) ab. Deaktiviert wird das Gerät aber nicht.
>
> Es wird nicht deaktiviert, das ist sicher? Ich denke, die Leitung bleibt
> IDLE (was nach 3 ms als SUSPEND erkannt wird), oder habe ich Dich noch
> falsch verstanden?

Nö, es kommt nach wie vor jede Millisekunde ein SE0 (D- und D+ für eine 
Bitzeit auf Low), sieht für mich gar nicht nach IDLE aus...

> Allerdings ist es so oder so interessant zu sehen, wann der Host
> abbricht. Vielleicht kannst Du mal einen Auszug Deines Logs des
> Protokoll-Analyzers posten, damit wir uns hier ein genaueres Bild der
> Lage machen können.

Ich habe leider keinen Protokoll-Analyzer. Der obdev-Treiber hat einige 
Debug-Ausgaben per RS232 eingebaut wenn Daten übertragen werden. Wenn du 
willst, kann ich das hier mal posten, ist allerdings nicht übermässig 
aufschlussreich ohne jedes Byte einzeln zu dekodieren. Wie auch immer, 
ich lese daraus folgende Vorgänge:
1. Device Reset
2. Anforderung von 64 Bytes des Device-Deskriptors
3. Übertragung des Device-Deskriptors (18 Bytes)
4. Device Reset
5. Set Device Address
6. ACK vom Device
7. Anforderung von 64 Bytes des Device-Deskriptors
8. Übertragung des Device-Deskriptors (18 Bytes)
9. Device Reset
10. Set Device Address
11. ACK vom Device
12. Anforderung von 18 Bytes des Device-Deskriptors
13. Übertragung des Device-Deskriptors
14. Anforderung von 9 Bytes des Configuration-Deskriptors
15. Übertragung des Configuration-Deskriptors
16. Anforderung von 255 Bytes des String-Deskriptors 0 (Unterstützte 
Sprachen)
17. Übertragung des String-Deskriptors 0 (EN/US)
18. Anforderung des String-Deskriptors 3 (Seriennummer)
19. Übertragung der Seriennummer (12 Zeichen, 24 Bytes)
20. Anforderung von 255 Bytes des Configuration-Deskriptors
21. Übertragung des Configuration Deskriptors inkl. Interface- und 
Endpoint-Deskriptoren
22. Anforderung von 255 Bytes des String-Deskriptors 0 (Unterstützte 
Sprachen)
23. Übertragung des String-Deskriptors 0 (EN/US)
24. Anforderung von 255 Bytes des String-Deskriptors 2 (Device-Name)
25. Übertragung des String-Deskriptors 2 ('morsix3330')
26. Anforderung des String-Deskriptors 0 (...)
27. Übertragung des String-Deskriptors 0 (EN/US)
28. Anforderung des String-Deskriptors 2 (Device-Name)
29. Übertragung des String-Deskriptors 2 ('morsix3330')
30. Nüscht...

Punkt 7 - 11 deutet auf einen Übertragungsfehler beim Device-Deskriptor 
hin, das habe ich jetzt zum Ersten Mal gesehen. Scheint aber nicht 
weiter problematisch zu sein, jedenfalls geht's nachher ganz normal 
weiter.

> Oder wird abgebrochen, nachdem Du keine Seriennummer lieferst?

Neine, es wird zweimal der Device-Name angefordert und dann ist Ende...

>> "Auf jeden Fall nicht" mag ich nicht ;)
>
> Für mich trifft es trotzdem zu, da ich mich nicht auf bestimmte Hosts
> festlegen will. :-)

Schon klar.

>> Interessanter Chip. Allerdings würde ich dann lieber bei den AVRs
>> bleiben und einen AT90USB verwenden. Aber meine Protos möchte ich
>> eigentlich noch so zum Laufen bringen, notfalls halt doch mit
>> entsprechender Software auf dem PC.
>
> Gibt es von Atmel keine MSD Reference Designs, auf die Du zurückgreifen
> kannst? Immerhin sieht man soetwas heutzutage immer öfter, bei allen
> möglichen Herstellern. Und Atmel ist doch, wass AppNotes betrifft, recht
> vielfältig.

Jep, gibt's tatsächlich, danke für den Tipp!
http://atmel.com/dyn/resources/prod_documents/doc6283.pdf

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp Burch wrote:
> Jep, gibt's tatsächlich, danke für den Tipp!
> http://atmel.com/dyn/resources/prod_documents/doc6283.pdf

Hoppla, den ersten Fehler habe ich damit schonmal gefunden:
"For example,
Microsoft® Windows® does not currently support the Reduced Block Command 
set."

Das hatte ich eingestellt, leider ändert auch die Einstellung "SCSI 
transparent command set" nix...

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 4. Device Reset
> 5. Set Device Address
> 6. ACK vom Device
> 7. Anforderung von 64 Bytes des Device-Deskriptors
> 8. Übertragung des Device-Deskriptors (18 Bytes)
> 9. Device Reset
> 10. Set Device Address

Das sehe ich ähnlich wie Du: Gleich 2x "Set Device Address" ist kein 
gutes Zeichen. Wie sieht er denn genau aus, Dein DEVICE_DESCRIPTOR?

> 19. Übertragung der Seriennummer (12 Zeichen, 24 Bytes)

Das müssen natürlich 26 Bytes sein (1 Byte bLength, 1 Byte 
bDescriptorType, 24 Bytes für 12 Zeichen)

Autor: die ??? (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp Burch wrote:
> Naja, hat schon was. Auch wenn die Seriennummer erstmal einfach statisch
> ist. Egal, jetzt ist jedenfalls eine drin, geändert hat sich nix.

Natürlich nicht, dafür interessiert sich der Treiber/Installer nicht. Da 
langt ggf. die PID/VID bzw. die Klassenzugehörigkeit. Aber zur 
eigentlichen Problemlösung kann ich leider nichts beitragen...

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Natürlich nicht, dafür interessiert sich der Treiber/Installer nicht.

Massenspeicher ohne Seriennummer funktioniert nicht unter Windows. 
Probier es einfach mal aus.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
René König wrote:
>> 4. Device Reset
>> 5. Set Device Address
>> 6. ACK vom Device
>> 7. Anforderung von 64 Bytes des Device-Deskriptors
>> 8. Übertragung des Device-Deskriptors (18 Bytes)
>> 9. Device Reset
>> 10. Set Device Address
>
> Das sehe ich ähnlich wie Du: Gleich 2x "Set Device Address" ist kein
> gutes Zeichen. Wie sieht er denn genau aus, Dein DEVICE_DESCRIPTOR?

So sieht der aus:
32 30 3A 4B 12 01 10 01 00 00 00 08 11 77 0A 32 30 3A C3 C0 16 DF 05 01 
00 01 02 9A A7 0A 32 30 3A 4B 03 01 3F 7F 0A

Wie gesagt, ist nicht so einfach zu dekodieren. Das Teil ist in vier 
Pakete zu acht Bytes aufgeteilt und aus Debugging-Gründen steht vor 
jedem Paket noch "20:" (32, 30, 3A) und die PID (4B -> 1011b -> DATA1, 
bzw. C3 -> 0011b -> DATA0). Ausserdem hängt am Ende jeweils noch die CRC 
und ein Zeilenumbruch. Der reine Deskriptor sieht damit so aus:
12 01 10 01 00 00 00 08 C0 16 DF 05 01 00 01 02 03 01

>> 19. Übertragung der Seriennummer (12 Zeichen, 24 Bytes)
>
> Das müssen natürlich 26 Bytes sein (1 Byte bLength, 1 Byte
> bDescriptorType, 24 Bytes für 12 Zeichen)

Ja richtig, hatte mich geirrt. Wird aber schon richtig übertragen.

Autor: Petr Tomášek (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was für ein OS hast Du? Ich glaube, ich habe irgendwo gelesen (war es 
"USB in the Nutshell?" oder so etwas?), das es eine "Feature" von 
MS-Windows ist...

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Petr Tomášek wrote:
> Was für ein OS hast Du? Ich glaube, ich habe irgendwo gelesen (war es

Windows XP.

> "USB in the Nutshell?" oder so etwas?), das es eine "Feature" von
> MS-Windows ist...

Meinst du das hier?
"Step 4 often confuses people writing firmware for the first time. The 
Host asks for the first 64 bytes of the device descriptor, so when the 
host resets your device after it receives the first 8 bytes, it is only 
natural to think there is something wrong with your device descriptor or 
how your firmware handles the request. However as many will tell you, if 
you keep persisting by implementing the Set Address Command it will pay 
off by asking for a full 18 bytes of device descriptor next."

Das ist schon richtig, er macht ja zwei Resets. Was mich mehr 
verwundert, ist die Wiederholung von Step 3 bis Step 5 (Anforderung von 
64 Bytes des Device-Deskriptors und SET_ADDRESS). Siehe hier: 
http://www.beyondlogic.org/usbnutshell/usb7.htm#Enumeration

Allerdings steht da, dass der Host nach den ersten 8 Bytes einen Reset 
macht, bei mir passiert das erst nach 18 Bytes. Ist das nun ein 
Schreibfehler, oder soll der Host wirklich mitten im Deskriptor einen 
Reset machen?

In der Spec steht das so:
4. The hub performs the required reset processing for that port (see 
Section 11.5.1.5). When the reset
signal is released, the port has been enabled. The USB device is now in 
the Default state and can draw
no more than 100 mA from VBUS. All of its registers and state have been 
reset and it answers to the
default address.
5. The host assigns a unique address to the USB device, moving the 
device to the Address state.
6. Before the USB device receives a unique address, its Default Control 
Pipe is still accessible via the
default address. The host reads the device descriptor to determine what 
actual maximum data payload
size this USB device’s default pipe can use.

Schaut in meinen Augen eigentlich ok aus...

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Allerdings steht da, dass der Host nach den ersten 8 Bytes einen Reset
> macht, bei mir passiert das erst nach 18 Bytes.

Ja, das macht der (Windows-)Host. Jetzt frage ich mich aber gerade, wie 
Du die 18 Bytes überträgst. Ich hoffe, Du machst das nicht am Stück. Das 
könnte den Host nämlich auch zweifeln lassen, da Du im DEVICE_DESCRIPTOR 
richtigerweise bMaxPacketSize mit 8 angegeben hast (auch ansonsten 
schaut der DEVICE_DESCRIPTOR nicht falsch aus). Du mußt das Ganze in 
drei Transfers verpacken!

Jetzt wäre natürlich ein Protokoll-Analyzer nicht schlecht...

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Petr Tomášek wrote:
> Was für ein OS hast Du? Ich glaube, ich habe irgendwo gelesen (war es
> "USB in the Nutshell?" oder so etwas?), das es eine "Feature" von
> MS-Windows ist...

Der SET_ADDRESS Request darf nur ein mal kommen, das ist definitv kein 
"Feature" von Windows.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
René König wrote:
>> Allerdings steht da, dass der Host nach den ersten 8 Bytes einen Reset
>> macht, bei mir passiert das erst nach 18 Bytes.
>
> Ja, das macht der (Windows-)Host. Jetzt frage ich mich aber gerade, wie
> Du die 18 Bytes überträgst. Ich hoffe, Du machst das nicht am Stück. Das
> könnte den Host nämlich auch zweifeln lassen, da Du im DEVICE_DESCRIPTOR
> richtigerweise bMaxPacketSize mit 8 angegeben hast (auch ansonsten
> schaut der DEVICE_DESCRIPTOR nicht falsch aus). Du mußt das Ganze in
> drei Transfers verpacken!

Natürlich sind es drei einzelne Transfers (Ich schrieb oben ja "Wie 
gesagt, ist nicht so einfach zu dekodieren. Das Teil ist in vier
Pakete zu acht Bytes aufgeteilt und aus Debugging-Gründen steht vor
jedem Paket noch "20:" (32, 30, 3A) und die PID (4B -> 1011b -> DATA1,", 
obwohl es natürlich drei Teile heissen müsste).

> Jetzt wäre natürlich ein Protokoll-Analyzer nicht schlecht...

Korrekt. Allerdings kleines Status-Update: ES GEHT! Das Teil wird 
korrekt als Massenspeichergerät enumeriert und der entsprechende Treiber 
geladen. Warum ist mir jedoch ein Rätsel, ich habe nix geändert?! Ob das 
nun an der Verletzung der Spezifikation durch Low-Speed-Bulks liegen 
mag?

Naja, ich habe jetzt wenigstens eine "Basis" zum Weiterentwicklung, ob 
das nur zeitweise geht oder nicht wird sich wohl bald zeigen...

Jedenfalls kommt er jetzt bis zum Anfordern des CBW (Command Block 
Wrapper) und bricht dann ab, da keine Antwort kommt (Ist ja auch noch 
nicht implementiert).

Ich werde euch auf dem Laufenden halten, ist jedenfalls schonmal ein 
grosser Fortschritt. Danke für die Hilfe!

Autor: Guido Körber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das wäre dann wohl eine Bugmeldung an die USB Gruppe bei Linux wert...

Was ist eigentlich so schlimm an Standards, dass keiner versucht sie 
einzuhalten?

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist überhaupt nix Schlimmes an Standards. Aber wenn die Möglichkeit 
besteht, ein sehr einfaches Interface bereitzustellen, dann darf ich das 
doch wohl nutzen wenn es denn funktioniert. Das ist ja auch kein Gerät 
zum Verkaufen, sonst würde ich einen Full-Speed-USB-Controller (Für 
entsprechendes Geld) verwenden und alles hätte wieder seine Richtigkeit. 
Ausserdem dürfte in diesem Fall die Einschränkung auf Full-Speed-Geräte 
mit der "Last" auf dem Bus zusammenhängen (Durch das Polling ist der Bus 
zu etwa 90% "belastet", da die Mitteilungen nur mit 1.5Mbit/s übertragen 
werden).

Autor: Moppel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Was ist eigentlich so schlimm an Standards, dass keiner versucht sie
> einzuhalten?

Das hier geht doch fast noch. Ich kann mich dunkel an einen Thread hier 
im Forum erinnern, in dem erklärt wurde, was der USB für eine 
Fehl-Konstruktion ist. Da entwickelt man bewusst an der Spezifikation 
vorbei und hinterher funktioniert es nicht an allen möglichen Hosts, 
Frechheit sowas.


> Aber wenn die Möglichkeit besteht, ein sehr einfaches Interface
> bereitzustellen, dann darf ich das doch wohl nutzen wenn es denn
> funktioniert.

Na klar. Und wenn die Möglichkeit besteht, mit 120 durch die 
geschlossene Ortschaft zu fahren, dann darfst Du das auch. Die 
Spezifikation ist ein Gesetz, nicht eine Empfehlung!

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moppel wrote:
>> Aber wenn die Möglichkeit besteht, ein sehr einfaches Interface
>> bereitzustellen, dann darf ich das doch wohl nutzen wenn es denn
>> funktioniert.
>
> Na klar. Und wenn die Möglichkeit besteht, mit 120 durch die
> geschlossene Ortschaft zu fahren, dann darfst Du das auch. Die
> Spezifikation ist ein Gesetz, nicht eine Empfehlung!

Ein Gesetz. Na aber loool. Würden sich alle Leute an alle 
Spezifikationen halten, gäbe es keine Probleme mit Inkompatibilitäten 
und solchem Mist. Willst du jetzt alle einsperren, die sich nicht daran 
halten?
Ausserdem: Euch braucht meine Verletzung der Spezifikation ja nicht zu 
stören, ich zwinge niemanden, den Code zu verwenden.

Übrigens: Äpfel und Birnen sind gut für Fruchtsalat, nicht für 
Vergleiche.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.