von Sven » So 3. Mai 2015, 17:16
Ich muss mal etwas die Hosen runter lassen... bitte nicht hinschauen
In der Entwicklung von ATARI Hard- und Software bin ich ja nicht gerade eine Leuchte.
Daher würde ich gerne meine Erfahrungen in Bezug auf dieses Projekt gerne mal zur Diskussion stellen, damit am Ende nicht totaler Murks raus kommt. Insbesondere, da ich eh kaum dazu komme in Ruhe weiterzuentwickeln. Sollte ich irgendwann mal fertig werden sollte es schon Sinn machen.
1.) Kommunikation
Generell läuft die SIO-Kommunikation mit den 19020 Baud oder alternativ per Speeder mit Index-Byte >=3. Hier habe ich derzeit nur eine Highspeed-Geschwindigkeit hardcoded, könnte man aber sicherlich auch per SW einstellen. Ich nutze zwar bereits das Clock-Signal am SIO für die Bestimmung der Geschwindigkeit (High/Low), es reicht aber noch nicht für das automatische Einstellen des SIO-Speeds (=Todo-Liste).
Als Protokoll nutze ich derzeit das des SIO2USB, hat aber den derzeitigen Nachteil, das die Datenmenge pro Block limitiert ist. Ziel soll es später sein, alle Daten im Buffer des SIO2IP auf einmal auslesen zu können. Allerdings hat es den Vorteil, das die Anzahl der Nutzbytes im Header des Frames enthalten sind. Eine sinnvolle Größe des Buffers wäre auch noch zu bestimmen um den ATARI nicht auf einmal mit 64k Daten zu überrollen, eine derzeitige MTU von etwa 1500 Bytes als Basis.
2.) IP-Socket
Zunächst hatte ich vor, verschiedene Sockets parallel zu unterstützen, habe bisher aber nur Einen zum Testen am Laufen. Wie viele es werden können habe ich derzeit noch nicht errechnet, denke das ich da etwas in Trouble mit dem Speicher komme. Mindestens 2 sollten es später schon sein um eine Art Token-Ring-Kommunikation hinzubekommen ohne zu viele Datenpakete bearbeiten zu müssen. Eine Selektion des Sockets hat natürlich auch Auswirkung auf das nachfolgende Protokoll, z.B. sende Daten über Socket 1, Abfrage an welchem Socket Daten empfangen wurden...
3.) Aufbau Socket
Zunächst wird eine IPv4-Adresse benötigt, die im Vorfeld per DNS-Abfrage ermittelt wird.
Danach wird ein Open-Request mit den 4 Bytes der Zieladresse, sowie des Zielports losgeschickt. Der ATARI bekommt ein OK wenn der Request erfolgreich war. Hier scheint es sporadisch noch ein Timing-Problem zu geben (-> Todo-Liste)
4.) Datentransfer
Nachdem der Socket aufgebaut ist können die Daten übertragen werden. Hierzu wird die komplette URL an SIO2IP gesendet, der ATARI bekommt wieder ein OK. Hier habe ich bewusst nicht auf die Antwort der Gegenseite gewartet, da mitunter viele Millisekunden zusammen kommen können bevor die Antwort da ist was ein sinnvolles Arbeiten mitunter verhindert, da der ATARI immer bis zu einer Antwort warten müsste.
Wird eine Antwort empfangen, legt SIO2IP für 100ms (=to be discussed) einen H-Pegel auf den PIN13 (Interrupt) des SIO-Ports. Die Daten können dann vom ATARI ausgelesen werden. Ein Risiko wäre hier natürlich, dass bei mehreren SIO2IPs im SIO-BUS der ATARI keine Info bekommt von welchem Device er Daten holen müsste.
Und hier stehe ich gerade im Projekt. Ziel derzeit ist, zunächst eine Abfrage über die Anzahl der Bytes zu machen und diese in einem 2. Schritt abzurufen. Dies hätte aber den Nachteil, dass immer mind. 2 Kommunikationen erfolgen müssten. Alternativ könnte man vielleicht wie oben genannt immer eine feste Länge an Frame verschicken und wenn der Payload des Frames =128 Bytes ist einen weiteren Frame "nachlesen". Das wäre nun ein weiterer Diskussionspunkt, denn der Payload hängt stark von der Applikation ab (z.B. Chat-Nachrichten sind kurz, HTML-Files mitunter richtig groß).
5.) Abbau Socket
Der Socket wird per Command regulär geschlossen.
6.) Priorisierung
Derzeit ist eigentlich die Bearbeitung von SD-Card-Anfragen höher priorisiert als die von IP-Paketen (ein Ethernet-Paket wird intern bearbeitet). Dies bedeutet: findet eine schnelle und permanente Aktion mit der SD-Card statt (z.B. laden von großen Dateien), besteht die Gefahr, Ethernet-Pakete nicht zu bearbeiten. Die Gefahr sehe ich zwar nicht ganz so gefährlich, da die bisherigen Tests eigentlich gezeigt haben, dass ein normaler Ping mit einer höheren Payload durchaus noch weitestgehend sauber durchgeht, aber natürlich einiges an Delay entsteht.
Fazit:
Einige Punkte sind sicherlich diskussionswürdig, insbesondere was den Ablauf der SIO-Kommunikation betrifft. Hier wäre es super, wenn ich euer Feedback bekommen könnte. Einerseits zur Abfolge der Kommunikation, andererseits zum Protokoll selbst.
Ein solches Stück HW macht ja nur Sinn wenn man es vernünftig nutzen kann.
Danke für's Lesen
Liebe Grüße
Sven
