BASCOM, SD/MMC und andere (SPI)-Flash-Karten

Dieser Artikel wird z.Z. formatiert;

Die Datei Get_Flash_FileSector.bas ist noch nicht eingebunden !

Hier ist ein Multi-Achs-Controller zur interpolierenden Bahn-Steuerung von (z.Z.) bis zu 8-Achsen entstanden, ich habe ihn RoBo-mac genannt. Vom Roboternetz habe ich vieles gelernt, das in die Entwicklung eingeflossen ist; mit diesem Artikel möchte ich mich revanchieren. Sogar für die C+++ Fans habe ich einen Hinweis.

Vorwort

Kaum war RoBo-mac fertig, kam die Frage auf, ob man so einen CNC- und Roboter Controller nicht auch Stand-Alone, ohne PC betreiben könne. Bevor es nun bald die SD-Card Variante gibt, mußte ich lernen "wie das geht": Nahezu alles was ich hier zu Papier gebracht habe, habe ich (viel zu lange) im Internet recherchiert aber nichts zusammenhängendes zum Thema, sondern nur Fragmente gefunden. Für dieses Tutorial selbst gebührt mir das Copyright, für den zusammengetragenen Code der begleitenden Tutorial-Datei (Get_Flash_FileSector.bas) nur bedingt.

Mit einigen Links verweise ich auf diejenigen, von denen ich "Honig gesaugt" habe – da vieles mehrfach und wiederholt zitiert wurde, ist jedoch nicht immer klar, wer der eigentliche Ur-Autor wirklich ist. Einige sind kommerzielle Anbieter, die durchaus sinnvolles zu verkaufen haben, andere hoch qualifizierte "Hobby-isten"; viel Hintergrund Know-how auch bei http://de.wikipedia.org/wiki/SD_Memory_Card.

SD und MMC Karten

SD, eigentlich SD-Memory Cards sind intelligente MCC Karten, hier ein Blick ins innere: http://de.wikipedia.org/w/index.php?title=Datei:Sdcard_panasonic64mb_inside_front.jpg&filetimestamp=20080829140929

SD steht für Security Digital – und kümmert sich um Urheberschutz und unerlaubtes Kopieren (DRMS = Digital-Rights-Management-Systeme). Dieses Security Know-how unterliegt strenger Geheimhaltung und deren Nutzung einer Lizenz. Wer bereit ist, hierfür mehrjährig mehrere 10.000 US$ Royalty jährlich zu zahlen, kann beantragen, als Geheimnisträger in den Club aufgenommen zu werden. Mehr dazu und vielleicht noch ein paar nützliche Infos unter http://www.sdcard.org

Für alle, die es lieber umsonst möchten, geht es hier weiter:

Ihre explosionsartige Marktakzeptanz verdankt die SD Karte einem genialen Marketing-Schachzug: Nicht alles unterliegt der Lizenz und Geheimhaltung, sondern wurde gezielt für Otto-Normalverbraucher zugänglich gemacht und veröffentlicht. SD-Karten können "Royalty free" über das SPI (Serial Peripheral Interface) angesprochen werden, hierfür stehen die Pin 1 bis 7 zur Verfügung (8 und 9 sind die "geheimen").

Pin-Belegung

Ein Anschlußbild der Pin-Belegung und sein Interface zum ATMega 128 findet sich unter "Schematic" hier: http://members.aon.at/voegel/index.html?Downloads.htm

Pin 8 der SD-Card liegt unmittelbar neben Pin 7, Pin 9 unter der abgeschrägten Ecke neben Pin 1.

SD und MMC Karten sind elektrisch und programm-technisch (zumindest für den veröffentlichten Teil) Pin-kompatibel. Mechanisch gibt es Einschränkungen. SD-Karten haben ein etwas dickeres Gehäuse als MMC-Karten. SD-Karten passen daher nicht in MMC-Steckplätze; umgekehrt ist dies bedingt möglich: Manchmal nur ein mal - falls man die kurze MMC nicht wieder aus dem langen SD Slot heraus bekommt !!!

SD-Schreibschutz

SD-Karten haben einen "Schreibschutz Schieber" der mit der eigentlichen SD-Technologie nichts zu tun hat, sondern im Slot einen mechanischen Kontakt gegen Masse betätigt. Der Schreibschutz kann also geräteseitig vom Microprozessor ausgewertet werden – muß aber nicht.

TTL-Kompatibilität

Elektrisch zählen SD und MMC Cards zur Flash-Technologie und arbeiten mit einer Systemspannung von 3,3 V (im Gegensatz zur TTL–Welt mit einer Systemspannung von 5 V). - Und damit sind sie mit "normalen" Mikroprozessoren nur bedingt kontaktfähig. Während man "von oben nach unten" mit 2 in Reihe geschalteten Dioden die Spannungssysteme angleichen kann, ist dies umgekehrt natürlich nicht möglich; die 3,3 V liegen zwar knapp über der Trigger-Schwelle des Mikroprozessor Einganges - aber eben sehr knapp.

Dies und ähnliches sind ein ewiger Quell teuflischen Unheils: Tage habe ich schon verschwendet, um festzustellen, das das Netzteil "eigentlich reicht" (reichen müßte) – aber eben nur eigentlich, abgesehen von wenigen usec, die den Datentransfer torpedierten! Also als Low End Bastlerlösung, na ja:

Professionelles bietet http://www.display3000.de

dort gibt es für gute 20,- EU einen SD-Karten Connector mit Spannungs Level Shifter. Wer gerne SMD lötet, kann von Maxim den "MAX 3392 EEUD" hierfür einsetzen. Hier sein Datenblatt:

http://www.datasheetcatalog.com/datasheets_pdf/M/A/X/3/MAX3392EEUD.shtml

SD/MMC Karten und C+++

Bevor wir nun zu BASCOM kommen noch der Tip für die C-Fans: Ulrich Radig (http://www.ulrichradig.de/home/index.php/avr/mmc-sd ) bietet einen SD-Kartenleser von Roland Riegel (http://www.roland-riegel.de/sd-reader/index.html ) mit detaillierten Informationen aus der C+++ Welt. Da dies nicht meine Welt ist, kann ich nur den Quell-Hinweis geben.

Ein Vorschlag zur Low End Hardware Verdrahtung auf Basis eines "alten ISA Slots" und ohne den o.g. Spannungs Level Shifter findet sich ebenfalls bei Ulrich Radig.

BASCOM, SD/MMC und andere Flash-Karten

Es gibt mit BASCOM zwei Möglichkeiten, Daten auf der (SD/MMC)-Karte zu speichern bzw. zu lesen:

• zum einen mit AVR-DOS
• zum anderen mit DriveWriteSektor() bzw. DriveReadSektor()

Beide sind Bestandteile von BASCOM - und für den nicht kommerziellen Gebrauch ist AVR-DOS bereits Bestandteil der BASCOM Lizenz. Da das ganze recht strukturiert angelegt ist, beherrscht BASCOM noch einige andere Karten wie z.B. CF und wohl auch richtige Laufwerke. An Stelle der hier und im folgenden verwendeten "MMC.LBX / MMC.LIB / Config_MMC.bas" sind dann die entsprechenden Pendants einzusetzen.

Schlüsselfunktion im BASCOM-Dateimanagement hat der Befehl "Initfilesystem()"; er liest den Master-Boot Record, die FAT etc. und muß vor allen anderen Datei-Befehlen als erster aufgerufen werden. Wird nach einem "Initfilesystem()" die Speicherkarte gewechselt, so geht alles durcheinander! Es macht also Sinn, über den Slot-Kontakt (Interrupt oder Polling) zu prüfen, ob die Karte seit dem letzten "Initfilesystem()" nicht gezogen wurde.

• Hier ein Code-Schnipsel, der allerdings nur überprüft, ob auf dem Entwicklungsboard überhaupt die Karte gesteckt ist. Bei den ersten Gehversuchen und Software Tests war ich ins stolpern geraten; das Aufstehen dauerte mehrere Stunden, bis ich merkte, daß die Karte nicht gesteckt war!

Hardware: Mega 128 / LCD-Display 4 * 20 / SD-Kartenhalter von Display 3000

'--- Config Lcdbus = 4 '4-bit Step_Step_Mode Config Lcd = 20 * 4 '20x4 LCD display Config Lcdpin = Pin , Db4 = Porte.4 , Db5 = Porte.5 , Db6 = Porte.6 , Db7 = Porte.7 , E = Porte.3 , Rs = Porte.2

Const Lcd_line1 = "Get_Flash_FileSector" Const Lcd_line2 = "CopyRight:" Const Lcd_line3 = " www.RoBo-mac.de"

Cls : Cursor Off Noblink Locate 1 , 1 : Lcd Lcd_line1 Locate 2 , 1 : Lcd Lcd_line2 Locate 3 , 1 : Lcd Lcd_line3

'Special Function (Display 3000) Config Pinb.4 = Input 'Pad Nr. 9 Cardsensor Config Pinb.5 = Output ' Pad Nr.10 SD-Card active (High) / inaktiv (Low) Config Pinb.6 = Input ' Pad Nr.11 Writprotect active (Low) / inaktiv (High) Config Pinb.7 = Output 'nicht belegt

Portb = &B01110000

  If Pinb.4 = 1 Then
     Locate 4 , 1 : Lcd "Card NO"
  Else
     Locate 4 , 1 : Lcd "Card YES "

     If Pinb.6 = 1 Then
       Locate 4 , 11 : Lcd "read only"
     Else
       Locate 4 , 11 : Lcd "read/write"
     End If
  End If

'---

• Nach einem "Initfilesystem()" weiß BASCOM, wie die Flash-Card organisiert ist.

Während AVR-DOS sich um alles kümmert, wird beim direkten Zugriff jeder Datentransfer per DriveWriteSektor() bzw. DriveReadSektor() über Sektoren blockweise abgewickelt. Um an bestimmte Informationen und ihre Bytes heranzukommen müssen wir nur wissen, in welchem Sektor sie "wo" stehen. NUR – und darum dreht es sich hier.

AVR-DOS

kann Files erzeugen, öffnen, überschreiben, Daten anhängen usw. Es ist ausgesprochen mächtig, braucht aber auch mächtig viel System Ressourcen (Empfehlung Mega 128). Was es kann, findet sich auf der Autoren-WebSite: http://members.aon.at/voegel/index.html?Downloads.htm unter "Interactive File System Interpreter with Description of commands"; laden Sie beide herunter, wir brauchen sie gleich!

Das ist nicht die BASCOM-Website (www.mcselec.com) , sondern die von Josef Franz Vögel, der viel zu BASCOM beigesteuert hat. Gezählt habe ich ca. 70 Befehle "aus der guten alten DOS-Zeit" und darüber hinaus bis zur FAT 32 !

Um SD/MMC Karten mit AVR-DOS aus dem eigenen Programm zu lesen müssen sich im BASCOM - LIB Ordner die Dateien

• AVR-DOS.LBX
• MMC.LBX

befindenden sowie die Dateien

• CONFIG_AVR-DOS.bas
• CONFIG_MMC.bas

in den Ordner kopiert werden, indem sich das eigene Projekt befindet. Mit dem Befehl

• $include "Config_AVR-DOS.BAS"
• $include "Config_ MMC.BAS"

im eigenen Programm werden sie beim compilieren eingebunden.

Alternativ hierzu kann der Code von CONFIG_AVR-DOS.bas und Config_MMC.bas ins eigene Programm kopiert werden, die beiden "$Include Befehle entfallen dann. Beide Wege sind im Ergebnis absolut gleichwertig.

In den Internetforen "geistern" eine Menge von Beiträgen herum, die den 2ten Weg des Kopierens genutzt haben – und sich gelegentlich als "Neuer Lösungsansatz" präsentieren. Wenn in diesen Quellcodes Variablen der (schwer lesbaren) Art " Cperrdrivereadresponse / Cpsectorsperclusternotsupported etc." enthalten sind, so stammen die Ur-Lösungsansätze mit hoher Wahrscheinlichkeit aus der Schmiede von Josef Franz Vögel.

Machen wir es uns nochmals bewußt: Ein DOS findet Dateien, weil die von ihr befragte FAT weiß, wo und wie der Dateiinhalt (ggf. auch noch fragmentiert) gespeichert ist.

DOS-Interpreter, ein Schnupper-Kurs

Über das Terminalprogramm von BASCOM (Aufruf mit Control T) und eine COM Verbindung zwischen PC und Mikroprozessor können wir jetzt die Flash-Card ansprechen.

• Installations-Info am Ende von Test_DOS_Drive.bas zu File System Interpreter beachten, sowie die Datei FS-Interpreter.bas in den Ordner kopieren, indem sich das eigene Projekt befindet.

• Tip

Für die ersten Gehversuche recht hilfreich ist die Datei Test_DOS_Drive.bas (Download Vögel, s.o.), in die man weit oben meinen Karten-Prüf-Schnipsel einbauen sollte.

• Ich habe mit dem PC die Datei "Kurztext.txt" mit dem sinnvollen Inhalt:

Das ist ein Kurztext

123456789

erzeugt und in die erste Verzeichnis Ebene kopiert (um es lebensnah zu gestalten, befinden sich hier noch einige andere Dateien und Verzeichnisse).

AVR-DOS Directory

Mit diesen Befehlen finden sich die Dateien im Directory, die wir zuvor mit dem PC geschrieben haben.

• TYPE Kurztext.txt

zeigt den Inhalt der Datei

• DUMP Kurztext.txt

das Hex-Dump hierzu

Das ist vielleicht schön aber sinnlos! Letztendlich wollen wir Daten per Mikroprozessor sammeln, auf der Flash-Card speichern und diese am PC auswerten oder mit Daten, die ein PC-Programm geschrieben hat, den Mikroprozessor etwas tun lassen.

AVR-DOS File

Studieren wir hierzu die Befehle der Gruppe File open, read and write

• Die meisten dieser Befehle arbeiten nicht mit dem Datei-Namen, sondern einer File-Nummer – und die wissen wir nicht.

• Die File-open Befehle geben freundlicher weise dies File-Nummer zurück, wenn wir sie mit dem Namen aufrufen
• FOB Kurztext.txt

bringt z.B. 128 (kann natürlich auch eine andere Nr. sein)!

• FILEINFO 128

zeigt den Hex-Dump der Datei Kurztext.txt und einige Informationen,

u.a. Sector#: z.B. 3200 (kann natürlich auch eine andere Nr. sein)!

Nun wird's spannend: Unter Drive/Card sector finden wir den Befehl SD, und wahrlich:

• SD 3200

zeigt den Hex-Dump der Datei Kurztext.txt

• CLOSE 128

schließt die Datei Kurztext.txt

• FILEINFO 128

meldet: No Filehandle for 128 found

aber

• SD 3200

zeigt trotzdem den Hex-Dump der Datei Kurztext.txt

wir probieren

• RL 128

und erhalten Error: 67 (die Datei ist ja auch geschlossen)

also nochmals

• FOB Kurztext.txt

bringt z.B. 128 (kann natürlich auch eine andere Nr. sein)!

• Das erste RL 128

zeigt die Zeile 1 "Das ist ein Kurztext"

• Das zweite RL 128

zeigt die Zeile 2 "123456789"

• Das dritte RL 128

bringt die Fehlermeldung DOS Error: 1

Nun ja, die Datei hat nur 2 Zeilen!

AVR-DOS Error-Code

Falls irgendwas schief läuft, erhalten wir eine Information:

• DOS Error: xxx

Diese Nr. (xxx) bezieht sich auf ein DOS eigenes Nummernsystem, daß mit den BASCOM Error-Nr. nichts zu tun hat. Es ist unter AVR-DOS beschrieben.

Direkter Sektor Zugriff

Mit deutlich weniger Möglichkeiten, dafür aber ohne den Zeitfresser-Umweg über die FAT arbeiten die Befehle

• DriveWriteSektor() und DriveReadSektor() etc;

sie lesen/schreiben einen vollständigen Sector (512 Byte). Ob dies der richtige Sector ist und ob er überhaupt beschrieben werden darf, hierum kümmern sich diese Befehle nicht; dafür gibt es das DOS! - Oder wir müssen selber wissen, was wir tun!

Beide Befehle arbeiten mit der gleichen Syntax:

• Fehler = DriveReadSector(SRAM, Flash) Read schiebt von Flash nach SRAM
• Fehler = DriveWriteSector(SRAM, Flash) Write schiebt von SRAM nach Flash

• Fehler

Wenn kein Fehler auftritt, ist der Rückgabewert 0 und die Welt in Ordnung.

Ist der Rückgabewert <> 0 , so gibt die ERROR-Tabelle Auskunft, was schief gelaufen ist. Ob und wie wir dies Programm technisch auswerten bleibt uns überlassen.

• SRAM

Ist die Adresse einer Variablen im SRAM !!!

Unangenehm, die wissen wir nicht. Was wir wissen, ist wie die Variable heißt, weil wir ihr mit

Dim Buffer As String * 512 ein Plätzchen von 512 Byte im SRAM zugewiesen haben.

• • Mit Pointer = Varptr(buffer)

schreibt BASCOM die SRAM-Adresse von Buffer in die Variable Pointer.

• Flash

Ist der Sector auf der SD/MMC-Karte, den wir bearbeiten wollen.

So einen komfortablen Befehl wie Varptr() für die SRAM-Adresse gibt es hierfür leider nicht – und darum habe ich dieses Tutorial und die Datei Get_Flash_FileSector.bas geschrieben. Das ist eine Art Kochbuch zum Thema!

Get_Flash_FileSector.bas baut auf Test_DOS_Drive.bas (Download Vögel, s.o.) und vielen Fragmenten, die ich in Internet-Foren gefunden habe, auf. Daher nochmals: Für die Formulierungen gebührt mir das Copyright, für den Code der begleitenden Tutorial-Datei nur sehr bedingt.

FAT, Sektoren und Cluster

Damit es nicht zu einfach wird: Mehrere Sektoren bilden einen Cluster. Bei den SD-Cards sind es wohl meist 32. Wieviel Sektoren das je Cluster wirklich sind, bestimmt das Betriebssystem entsprechend dem eingesetzten Speichermedium. Wichtig ist: DOS / Windows speichert eine Datei immer in ganzen Clustern.

Wenngleich die folgende Tabelle nicht mehr ganz taufrisch ist, erkennen wir, daß eine Cluster Größe von 32 Sektoren nicht zwangsläufig eine FAT 32 erfordert.

                  Laufwerksgröße     FAT-Typ     Sektoren     Cluster-
               (logischer Datenträger)          pro Cluster    größe
                 ----------------   --------   -----------   -------
  (Disketten)         360K           12-bit         2         1K
                      720K           12-bit         2         1K
                     1.2 MB          12-bit         1       512 Byte
                     1.44 MB         12-bit         1       512 Byte
                     2.88 MB         12-bit         2         1K
  (Festplatten)    0 MB - 15 MB      12-bit         8         4K
                  16 MB - 127 MB     16-bit         4         2K
                 128 MB - 255 MB     16-bit         8         4K
                 256 MB - 511 MB     16-bit        16         8K
                 512 MB - 1023 MB    16-bit        32        16K
                1024 MB - 2048 MB    16-bit        64        32K

Auf einem MS-DOS-Datenträger wird einer Datei mit einer Größe von 1 Byte 1 Cluster Speicherplatz zugeordnet, wobei der nicht genutzte Teil des Clusters verschwendet ist. Einer Datei, die gemäß ihrer Größe 3,2 Cluster benötigt, werden 4 Cluster zugewiesen. Insgesamt folgt daraus, daß kleinere Cluster weniger Verschwendung zur Folge haben. Quelle und mehr dazu unter: http://support.microsoft.com/kb/67321

Der Begriff FAT16 steht für ein 16 Byte Adressiersystem der Cluster, FAT32 für ein 32 Byte Adressiersystem. Mehr hierzu unter: http://users.iafrica.com/c/cq/cquirke/fat.htm#EntryStructure ebenfalls hilfreich: http://www.dewassoc.com/kbase/index.html – Aber sehr mächtig!!!

Während innerhalb eines Clusters die Sektoren immer fortlaufend sind, können die Cluster mehrerer Dateien im Laufe der Zeit in Ihrer Reihenfolge gemischt (fragmentiert) werden.

Immer wieder Jungfrau

Wenn wir eine Datei mit dem PC auf der Flash-Card speichern, kann es passieren, daß die Datei nicht zusammenhängend in fortlaufenden Clustern und mithin Sektoren, sondern fragmentiert gespeichert wird. AVR-DOS findet die Zusammenhänge; die Drive...Sector() Befehle nicht. Um das Problem zu umgehen, empfiehlt es sich frisch formatierte SD/MMC zu verwenden und für den Datentransfer vom AVR zum PC ein Dummy-File (lieber zu groß als zu klein) als Platzhalter anzulegen.

Ein Formatierer befindet sich hier: http://www.sdcard.org/consumers/formatter/#download Der Formatierer hat eine "Qick" Funktion. Die löscht zwar nicht den Dateninhalt, sondern lediglich die FAT etc. dies ist jedoch völlig ausreichend. Alternativ hierzu, kann eine vorhandene Datei mit den Windows – üblichen Befehlen gelöscht werden – in jedem Falle muß das Stammverzeichnis im Explorer als "leer" angezeigt werden.

Ein Dummy-Datei Generator hier http://www.raylow.com/2009/01/dummy-file-generator-v200.html Dieses Dummy-File können wir umbenennen. Wenn es das erste ist, daß wir geschrieben haben, befindet es sich sein Start-Sektor (bei einer FAT 32) mit hoher Sicherheit an Sector# 512. Ob 512 wirklich der Start-Sektor ist, wird mit Get_Flash_FileSector.bas oder Test_DOS_Drive.bas unter "Data First Sector:" ausgewiesen. Programm technisch kann dies vieles vereinfachen.

System Resourcen

Der Mega128 hat ja schon eine ganz ansehnliche Speicherkapazität. Trotzdem:

Compilieren wir die Datei Get_Flash_FileSector.bas mit Function_Switch = 1 so belegt dies 32% seines Programm-Speichers; die beiden anderen Varianten (2 bzw.3) liegen um 5% bzw. 1%. Aber: Function_Switch = 1 bzw. 2 haben einen nahezu gleich großen SRAM bedarf von gut 3.000 Byte und belegen rund 75 % seiner Kapazität. Und nun das Wunder: Function_Switch = 3 frißt nur knapp 800 SRAM Byte, denn die Sektor-Befehle benötigen kein: Config_AVR-DOS.bas !!!

Diesen Vorteil erkaufen wir uns damit, daß wir letztendlich auf der Flash-Card nur eine Datei (mit dem Start-Sektor 512) nutzen können. Natürlich können wir mehrere Flash-Cards (jeweils eine je Datei) verwenden, aber da kann wohl beim Verwechseln einiges Unglück passieren – denn den Dateinamen können wir so nicht lesen. Zwar weist der Root Start Sector 480 einiges aus, was an den Dateinamen entfernt erinnert – aber hier wird es kryptisch; das packt nur noch AVR-DOS. Spätestens bei langen Dateinamen (also denen mit mehr als 8-Buchstaben) steigt aber auch AVR-DOS aus.

Lange DateiNamen & Date/Time

Es geht trotzdem: Zugegeben, etwas tricky und nur, wenn der AVR eine vom PC geschriebene Datei auswerten soll, die wir kennen – weil wir sie selbst erzeugt haben. Wenn das PC-Programm die ersten (z.B. 64) Byte des Sektors 512 mit dem Filename und dem Zeitstempel belegt, können wir diese gezielt auslesen und über das LCD oder das Terminal-Programm anzeigen. Und hierfür brauchen wir noch nicht mal eine zusätzliche Variable im SRAM, - Overlay macht's möglich!

Wenn Sie mit der DIM Overlay-Option nicht vertraut sind, sollten Sie unbedingt das BASCOM Manual hierzu und den Artikel ... lesen.

Get_Flash_FileSector.bas zeigt im Gültigkeitsbereich des Compiler-Schalters 3 ein Code-Beispiel für einen Dateinamen von max. 40 Zeichen zuz. Extension (40.3).

==Daten-Transferzeit" Verbleibt die Frage: Wie schnell ist der Datentransfer? Das Hardware SPI des AVR MEGA128 wird mit 4 MHz getaktet. Hiermit liegt die Lesezeit je Sektor von DriveReadSector() recht stabil bei ca. 1,35 msec, beim Schreiben bei ca. 1,65 msec. Mit dem Software SPI stark schwankend bei dem 4 bis 5 fachen Wert.

512 Byte je 1,35 msec entspricht 2,6 usec pro Byte bzw. einer Datentransferrate von ca. 380 kByte/sec. Im Vergleich zur COM-Schnittstelle ist dies extrem schnell, im Vergleich zu USB und FireWire gemächlich.

Und nun die gute Nachricht:

Falls die 1,35 msec zu lang sind –Robo-mac muß in dieser Zeit bis zu 50 Schritte für 8 Achsen interpolieren – kann der Datentransfer per Interrupt unterbrochen werden.