KC-News 3/2000

Scannermodul M051

von Frank Dachselt

Das Thema Scannermodul scheint sich ja inzwischen fast zu einer unendlichen Geschichte auszuweiten, dennoch haben wir mittlererweile ein wichtiges Etappenziel erreicht: Seit nunmehr schon einigen Monaten sind die 20 Module der ersten Serie bei ihren Besitzern angekommen und funktionieren dort nach vereinzelten, meist durch den Selbstaufbau des Bausatzes verursachten Anlaufschwierigkeiten ohne Probleme. "Erste Serie" deutet es bereits an: Enrico Grämer sammelt bereits Vorbestellungen für eine eventuelle zweite Serie des Moduls. Wer also inzwischen Interesse an einem M051 bekommen hat, oder es in nächster Zeit bekommt, der sollte sich bei Enrico melden. Eine solche Serie lohnt sich natürlich erst ab einer bestimmten Stückzahl (in unserem Fall sind es mindestens 10), so daß wahrscheinlich auch noch etwas Geduld gefragt ist. Enrico wird uns natürlich über Stand der Dinge auf dem Laufenden halten.

Ich möchte mich mit diesem Beitrag insbesondere an alle diejenigen wenden, die das Modul mit Controller betreiben und die serielle Schnittstelle nutzen. Informationen zum Scannerbetrieb finden Ihr in anderen Beiträgen dieser Ausgabe.

Die Software im Controller ist zur Zeit noch eine vorläufige Version, die noch nicht alle in den vorangegangen Beiträgen beschriebenen Funktionen enthält. Das betrifft insbesondere die SIO-Betriebsarten. Die realisierten Funktionen laufen dafür aber endlich stabil und fehlerfrei. Die SIO-Funktion des Controllers kann derzeit nur in der Betriebsart "Senden/Empfangen mit RTS/CTS-Handshake und internen Puffer (je 64 Byte)" verwendet werden. Die Programmierung der anderen Betriebsarten ist noch nicht möglich, ebenso der Interruptbetrieb. Es wird also zu gegebener Zeit ein Software-Update geben, mit dem die Controller noch einmal umprogrammiert werden. Wer zum nächsten Clubtreffen kommt, sollte auf jeden Fall sein M051 mitbringen. Ansonsten muß dann der Controller an Enrico oder mich eingeschickt werden.

Auch hat sich die Programmierung der SIO-Betriebsarten, insbesondere die Belegung der Steuer- und Statusbytes gegenüber den zurückliegenden Veröffentlichungen etwas geändert. Die endgültige Fassung liegt noch nicht vor, da sich die günstigste Gestaltung erst bei der Programmierung im Zusammenhang mit den Treibern für den KC ergibt. Es ist aber sichergestellt, daß die jetzt verteilten Treiber aufwärtskompatibel sein werden, also auch mit späteren Controllerversionen funktionieren. Wer unbedingt jetzt schon an die Treiberprogrammierung Hand anlegen möchte, sollte sich daher zunächst mal an mich wenden, um den aktuellen Stand zu erfahren. Bei dem geringen Funktionsumfang, der bis jetzt zur Verfügung steht, sollte aber jeder mit den mitgelieferten CP/M-Treibern auskommen.

Die gesamte Koppeltreiber-Familie (insgesamt 11 Stück für 11 verschiedene Baudraten) ist in der Datei M051KOP.LBR zusammengepackt und sollte in dieser Form verbleiben. Das spart erheblich Platz auf der Festplatte (nur einmal 4 K statt 11 mal 4 K). Mit DRIVER.COM kann dann ein beliebiger Koppeltreiber aus der LBR-Datei heraus geladen und gestartet werden, z.B.:

   A0>DRIVER M051KOP.LBR M0510096.KOP

Als Parameter wird in der Kommandozeile erst die LBR-Datei und dann der gewünschte Treiber angeben. Die Koppeltreiber heißen alle M051xxxx.KOP, wobei xxxx für ein Hundertstel der Baudrate (mit führenden Nullen) steht. Das fängt bei 0003 für 300 Baud an und geht bis 1152 für 115.200 Baud. Das Beispiel lädt also den Treiber für 9600 Baud.

Als Kabel zur Verbindung zwischen dem M051 und dem PC verwendet man entweder ein handelsübliches Nullmodemkabel, oder man baut es sich selbst. In Bild 1 sind die möglichen Eigenbauvarianten zusammengestellt. Entweder man lötet sich dazu ein neues Kabel mit zwei passenden SUB-D-Steckern zusammen (Variante (a)) oder baut zu einem vorhandenen Kabel zwischen M003 und PC einen Adapter, der die Signale von der 9-pol. SUB-D-Buchse am M051 auf eine 5-pol. DIN-Buchse umsetzt (Variante (b)). Die Belegungen der einzelnen Stecker und Buchsen können in den KC-News 3/98 auf Seite 6 nachgeschlagen werden.

Zu beachten ist, daß das Modul M051 die Leitungen RTS und CTS zum Handshake benutzt. Die anderen Handshake-Leitungen (DTR, DSR und DCD) könnten am Modul zwar unbeschaltet bleiben, aber dann hat das Kabel eine exklusive KC-Seite. Wenn das Kabel auch mit vertauschten Enden funktionieren oder auch mal zur PC-PC-Kopplung Verwendung finden soll, dann müssen die gestrichelt gezeichneten Verbindungen an der KC-Seite ebenfalls vorhanden sein.

Bild 1: Eigenbau-Kabelvarianten für die serielle Schnittstelle des M051.

Nun noch etwas zum Reset-Problem: Leider hat sich herausgestellt, daß die urspünglich vorgesehene Nutzung der zentralen RESET-Leitung im KC für den Controller nicht geeignet ist. Hier tritt wahrscheinlich ein ähnliches Problem auf wie damals beim RTC-Chip des GIDE-Interfaces. Von den zwei in der Bauanleitung angegeben Ausweichvarianten würde ich des geringeren Aufwandes wegen die mit dem alleinigen Kondensator vorschlagen. Das hat zwar den Nachteil, daß der Controller nur noch beim Einschalten der Betriebsspannung zurückgesetzt wird, aber nach allen bisherigen Tests bin ich der Meinung, daß die Controllersoftware hinreichend stabil funktioniert, so daß das Um- bzw. Neuprogrammieren vom KC aus immer möglich ist. Ich habe in meinem Modul die einfachere Variante verwendet und bisher noch keine Probleme damit feststellen können.

Die Umstellung der MTOOLS auf die Verwendung des M051 ist mit wenigen Handgriffen getan: Nachdem das passende Nullmodem-Kabel zwischen M051 und PC gesteckt ist, muß am KC der Koppeltreiber mit der gewünschten Baudrate geladen und am PC in der Datei START.BAT der MTOOLS diese Baudrate in das ADF-Kommando eingetragen werden. Schon kann es losgehen.

Nun stellt sich natürlich die Frage, was das ganze überhaupt bringt. Die potentiellen Übertragungsraten der Controller-SIO mit bis zu 115.200 Baud klingen ja vielversprechend. Doch an dieser Stelle muß ich die Erwartungen leider erst mal etwas dämpfen. Die tatsächlich erreichte Übertragungsrate wird nicht allein durch die Geschwindigkeit der seriellen Schnittstelle bestimmt, sondern auch von den beteiligten Softwarekomponenten. Und da haben im KC neben dem Koppeltreiber auch die ZAS-Schleife, die BIOS-Routinen und MTOOLS-Programme ihren Einfluß. Die maximalen Übertragungsraten, die ich beim Senden und Empfangen von und zum RAM-Floppy (RF) bzw. von und zur Festplatte (HD) erreicht habe, sind in der folgenden Tabelle zusammengestellt:

Die Baudrate ist immer etwa 10 mal so hoch wie die Übertragungsrate in Byte/s, da pro Byte acht Datenbits sowie ein Start- und ein Stopbit - also insgesamt 10 Bits - übertragen werden. Daß die MTOOLS der neuen Version 1.3 etwas niedrigere Werte haben, liegt an der neu hinzugekommenen CRC-Berechnung. Doch dazu mehr im folgenden Beitrag.

Mit dem Treiber für 19.200 Baud (M0510192.KOP) wird also zur Zeit bereits die Geschwindigkeitsgrenze erreicht, und es lohnt sich - abgesehen von Tests - nicht, höhere Baudraten einzustellen. Niedrigere Baudraten haben zudem noch den Vorteil, daß die Energie pro übertragenem Bit auf der Leitung größer ist und damit die Fehlerwahrscheinlichkeit sinkt. Allerdings haben nächtelange Dauertests selbst bei der höchsten Baudrate mit einem etwa 10 m langen Kabel keine Übertragunsgfehler gezeigt, so daß man von einer ziemlich sicheren Übertragung ausgehen kann.

Es gibt noch eine Erscheinung, für die ich bisher noch keine Erklärung gefunden habe. Beim Empfangen mit Baudraten oberhalb der effektiv erreichbaren Baudrate (also ab etwa 19.200 Baud) kommt es beim Empfangen (PC --> KC) von längeren Dateien im DOS-Fenster unter WINDOWS mitunter zu einer Fehlermeldung, bei der Übertragung abgebrochen werden muß (mit <BRK> das Programm im KC beenden und dann mit <Cancel> oder <Abbruch> am PC). Die Ursache liegt offenbar im WINDOWS versteckt, denn im DOS-Mode tritt dieser Fehler nie auf. Genauere Messungen haben auch gezeigt, daß das Zeitverhalten der Handshake-Signale in beiden Fällen unterschiedlich ist. Wahrscheinlich gibt WINDOWS trotz des ADF-Treibers noch nicht ganz die Kontrolle über die serielle Schnittstelle auf...

Als Konsequenz empfehle ich allen, die die MTOOLS im DOS-Fenster unter Windows nutzen, die Baudrate nicht höher als 9600 Baud zu wählen. Wer die maximale Geschwindigkeit beim Senden ausnutzen möchte (z.B. bei einem nächtlichen Back-Up), der kann die Baudrate auf 19.200 Baud stellen, sollte dann aber am PC den DOS-Mode verwenden.