USB-Floppy

Als erstes wurde untersucht, ob der Diskettencontroller mit seiner MFM-Schreib- und Lesefunktion überhaupt in Software realisierbar ist. Dies ist für DD und HD locker möglich, und auch ED ist realisierbar.

• USB-Floppy: MFM schreiben (dies ist einfacher)
• USB-Floppy: MFM lesen (komplizierter wegen Synchronisation)

Immerhin passt ein typischer Diskettensektor in den RAM des ATmega32U4. Daher muss man die Daten nicht strömen lassen. Vorerst.

Andere Kodierungsformate wie GCR (Apple) lassen sich im Gegensatz zu einem Hardware-Diskettencontroller einfach per Software nachrüsten.

Um während des Sektorlesens den vorher gelesenen Sektor in 64-Byte-Stückelung zum USB zu schaffen, ist eine entsprechende Routine erforderlich, die maximal 16 Takte dauert. Da CALL und RET viel zu langsam sind, nur mit Sprüngen.

• Studie: USB-FIFO bedienen in < 16 Takten

Der USB-Teil des ATmega32U4 ist sichtlich nicht AVR-typisch und die Dokumentation im Datenblatt unter aller Kanone:

• Interrupts müssen „zu Fuß“ bestätigt werden, auch dann, wenn eine Interruptbedienroutine aufgerufen wird. Das ist allerdings bei einem Multiplex-Interrupt auch nicht anders möglich.
• Die Interruptbestätigung erfolgt durch Löschen von Bits, nicht wie sonst durch Setzen. Damit kein Interrupt durch die Lappen geht, müssen alle anderen Interruptbits gesetzt werden (undokumentiert, aber logische Konsequenz). Also INT_FLAGS = INT_FLAGS | andere_interruptbits & ~mein_interruptbit;
• Sämtliche Register, auch die zur Interruptbestätigung, liegen im unhandlichen Speicheradressraum, nicht im I/O-Adressraum.
• Alle endpoint-spezifischen Operationen, auch für EP0, sind über „gemultiplexte“ Register realisiert. So muss stets erst mal der richtige Endpoint ausgewählt werden. Dies ist bisweilen lästig.
• Die Endpoint-Puffer sind nicht wahlfrei adressierbar (d.h. nicht im Speicher-Adressraum), sondern man muss die Daten immer aus einer FIFO lesen bzw. in eine FIFO schreiben. Besser wäre es, wenn beide Möglichkeiten zur Verfügung ständen.
• Ein USB-Suspend-Interrupt kommt nach 3 s Inaktivität auf dem USB, aber nur, wenn es vorher eine Aktivität gab. Den Fall eines „toten“ USB (etwa beim Anschluss an ein Ladegerät) muss man extra ausprogrammieren. Bisher alle Programmierer vergessen das (ist ja auch undokumentiert) und der Anwender wundert sich dann über den leeren Laptop-Akku beim Anstöpseln an einen suspendierten Laptop, etwa durch Wackelkontakt
• Ein USB-Wakeup-Interrupt entpricht einem Pegelwechsel-Interrupt auf einer der beiden Datenleitungen. Das hätte man auch so mal schreiben können. Damit ist logisch, dass dieser Interrupt praktisch immer aktiviert wird.
• Keinerlei Kodebeispiele im Datenblatt. Eine simple Schleife zum FIFO lesen und FIFO schreiben gehört da hinein. Sowie eine Minimalversion der EP0-Behandlungsroutine. Ohne LUFA. Wichtig ist es, beim Energiemanagement getrennt auf Busversorgung und Selbstversorgung einzugehen.
• Fehler im Datenblatt: Diagramm unterhalb „Figure 21-12“: SUSPI wird nicht durch Software, sondern bei WAKEUPI (tatsächlich) durch die Hardware gelöscht. Ist in Abschnitt 22.8 dokumentiert.
  Genauso beim AT90USB162: „Figure 19-11“ sowie Abschnitt 20.8
• Widerspruch im Datenblatt: SUSPI sollte (automatisch) durch WAKEUPI gelöscht werden, um den PAD-Status im Power-Down zu halten (Bild 21-12) und Remote-Wakeup zu ermöglichen (Abschnitt 22.10). Das Kodebeispiel 6.8.1 zeigt genau das Gegenteil. Auch in 21.13 steht: „Suspending the USB interface: Clear Suspend Bit“. Was ist nun richtig?
• Gehaltenes SUSPI führte bei mir zu gelegentlichen Fehlern bei der USB-Enumerierung beim Ab- und Anstecken des USB-Kabels bei einem selbstversorgten Mikrocontroller. Für diesen Fall muss U_BUS ausgewertet werden, dann klappt's. Siehe auch folgender Punkt.
• OTGPADE (Bit 4) in USBCON muss gesetzt sein, sonst funtioniert USB nicht, auch wenn man U_BUS gar nicht auswertet! Nirgends erwähnt.
• Bild 22.4 hat die Interruptquelle VBUSTI vergessen, im Gegensatz zum Folgetext. Im Bild 21.9 ist diese Interruptquelle drin. Ziemlich wirr.
  Der AT90USB162 hat keinen eingebauten Busspannungsdetektor, dort macht man das zu Fuß mit einem normalen I/O-Port.

• Aufbau der USB-Deskriptoren (mit UsbTreeView angeguckt)
• Kommunikation mit dem Windows-Treiber usbstor.sys (mit SimpleUsbLogger angeguckt)

Ein Eigenbau-Diskettenlaufwerk mit CBI-Protokoll erfordert (zumindest unter Windows 7) eine eigene .INF-Datei zur Installation und ist damit nicht gerade benutzerfreundlich. Im Falle des o.a. Funktionsmusters findet Windows die Vendor- und Product-ID (0x3EE = Mitsumi, 0x6901 = USB-Diskettenlaufwerk) in einer vorinstallierten INF-Datei und lädt usbstor.sys. Man müsste daher bei Eigenbauten jene Vendor- und Product-ID wiederverwenden, um keine INF-Datei mitliefern zu müssen. (Auf welchem Medium? Auf Diskette — das geht nicht!)

Stellt man die Firmware auf das von Microsoft empfohlene Bulk-Only-Protokoll um, lädt Windows den Treiber usbstor.sys auf generischer Basis mit Hilfe der USB-Klasse. Daher verwenden auch die im Internet herumgeisternden Kodebeispiele zum Thema Massenspeicher allesamt das Bulk-Only-Protokoll. Hier wird der SCSI-Steuerblock mit einem 15-Byte-Rahmen versehen und über den gleichen Bulk-Out-Endpoint versendet wie auch die Schreibdaten. Sowohl die Lesedaten als auch der SCSI-Status werden über den Bulk-In-Endpoint in den PC eingelesen, wobei der Status aus einem 9-Byte-Block besteht. Bei Fehlern wird der Bulk-In-Endpoint im Stall-Modus angehalten.