Die Funktionsweise von zjlink

Ursprünglich wollte ich auf der DOS-Seite des Programms die BIOS-Routinen nutzen. Allerdings hat das aus unbekannten Gründen nicht funktioniert, weshalb ich auf der Suche nach anderen Wegen auf Interfacing the Serial / RS232 Port bei Beyond Logic gestossen bin. Da ich mich mit der Programmierung mit Interrupts unter DOS nicht auskannte, habe ich mich für den ersten Wurf für eine Variante entscheiden, bei der die UART-Register gepollt werden. Zunächst habe ich versucht, einfach die gelesenen Bytes in eine Datei zu schreiben. Dabei kam jedoch ziemlich viel Blödsinn raus. Die Ursache lag darin, dass das Lesen vom UART und das Schreiben in die Datei zu viel Zeit benötigt hat, sodass die weiter vom UART empfangenen Daten sich teilweise überschrieben haben. Der Einsatz von SMARTDRV hat das Problem ... sagen wir: verändert, aber bei Weitem nicht beseitigt.

Zur Lösung dieses Problems habe ich ein Kommunikations-Protokoll entwickelt:

  1. Der Sender schreibt einen Block (z.B. 1024 Zeichen)
    Der Empfänger liest diese immer sofort aus dem UART in einen Puffer
  2. Der Sender berechnet eine Checksumme über den Block und sendet diese
  3. Der Empfänger prüft die Daten anhand der Checksumme
  4. Wenn die Daten OK sind werden sie in die Datei geschrieben (was beliebig lange dauert)
  5. Der Empfänger signalisiert dem Sender ob die Daten in Ordnung waren oder nicht

Der Sender kann daraufhin entscheiden, ob er den gleichen Block erneut sendet (wenn er fehlerhaft übertragen wurde, was allerdings bei mir in der Praxis nie auftritt; wenn etwas schief geht dann meist viel fataler), oder mit dem nächsten Block fortfährt. Durch das Warten des Senders auf die Bestätigung in Punkt 5 bleibt dem Empfänger beliebig viel Zeit zum Speichern der Daten auf die Festplatte.

Über diese blockweise Datenübertragung habe ich ein Anwendungs-Protokoll gesetzt, das Dateinamen und Längenangaben überträgt. Damit ist zum einen das Senden mehrerer Dateien in einer Sitzung möglich, zum anderen weiß der Empfänger, wie viel zu lesen ist, was den Einsatz blockierender Lesefunktionen erlaubt. Für eine folgende Version ist geplant, dieses Protokoll zu erweitern und ein wenig an FTP anzulehnen. Der Server ist in diesem Fall nicht länger auf das Empfangen beschränkt, sondern kann auch Dateien an den Client übermitteln. Da jedoch der Entwicklungsdrang mit der vorerst funktionierenden Lösung gebremst ist, kann eine erweiterte Version noch etwas auf sich warten lassen...