Hinweise zum Aufbau der Hardware eines KCNET-Interface und die schrittweise Inbetriebnahme durch Benutzung der internen RS232 Diagnose-Schnittstelle.
Nach der Beschreibung von Funktionalität und Nachnutzung geht es hier um ein wichtiges Hilfsmittel, welches vor allem dann gebraucht wird, wenn scheinbar alles richtig gemacht wurde aber im Z80 System rein gar nichts passiert, wenn man das KCNET-Interface in Betrieb nehmen möchte.
Neben diesem sehr unerfreulichen Fall, welchen ich niemand wünsche, gibt es noch eine zweite wichtige Funktion der seriellen Diagnoseschnittstelle. Nur über diesen Weg lassen sich die Konfigurationsdaten für die Anpassung an das Hostsystem, welche im letzten Artikel beschrieben wurden, sicher auslesen.
Natürlich kann man mit Hilfe der primitiven Lese- und Schreibfunktionen auch den RAM des Controllers inspizieren, dazu kommen wir nachher noch genauer. Eine sehr nützliche Funktion war am Anfang der Entwicklung die Echtzeitanzeige der PIO-Kommunikation. Man kann sich direkt in den Datenstrom einklinken und mitlesen, was die PIO mit dem Controller so anstellt, wenn die KCNET-Protokoll Befehle abgearbeitet werden.
Hardware
Idealerweise schliesst man alles ohne Verbindung zum Z80 System an ein einstellbares Netzteil an, hängt ein Amperemeter in die Stromversorgung, dreht die Spannung hoch und kontrolliert permanent die Anzeige der Strommessung.
Wenn das stimmt, kann man nun gleich noch wichtige Eckdaten der Schaltung kontrollieren, wie zum Beispiel:
- 5 V an den IC's 1 bis 5 ensprechend der Tabelle rechts unten im Schaltplan (bei IC4:Pin 16)
- 3,3 V an Pin 2 von IC6 sowie JP1:Pin 1 und JP2:Pin 24 des WIZnet-Modules
- an Pin 9 des ATmega muss H Pegel messbar sein, sonst kann der nicht anlaufen
- falls möglich die 8 MHz an Pin 18/19 des ATmega mit Oszilloskop kontrollieren
Falls einer dieser Prüfpunkte nicht den genannten Messwert hat, braucht man nicht weiterzumachen - das Interface wird nicht funktionieren. Also alles ausschalten, Fehler suchen und beseitigen. Wenn alles stimmt, sollte der Controller auch arbeiten und das Firmwareprogramm bereits laufen, was man sich anschliessend anschauen kann.
RS232 Diagnose-Schnittstelle (Debug-Terminal)
Praktisch verwendet man dafür z.B. den PC mit einem Terminalprogramm und eine COM-Schnittstelle des PC, welche auch per USB-Adapter bereitgestellt werden kann. Zunächst muss man das KCNET und den PC mit Hilfe eines passenden Kabels verbinden:
Im Schaltplan ist für den Anschluss am KCNET eine 9 polige SUB-D Buchse vorgesehen. Man kann dann ein handelsübliches serielles 1:1 Verlängerungskabel verwenden (das Nullmodemkabel für den Betrieb der WTools ist hier nicht geeignet!). Wie man auf dem Bild sehen kann, wird die Kommunikation ohne Handshake abgewickelt, so dass man sich um die restlichen Signale der RS232 Schnittstelle nicht kümmern muss.
Das war es auch schon, nach dem Herstellen der Verbindung kann man auf dem PC das Terminalprogramm starten.
Terminalprogramm
Wenn nicht, alle Parameter, Kabel, Einstellungen u.s.w. noch mal überprüfen. Sonst sieht es ziemlich schlecht aus, da der Fehler dann bei der Programmierung des Controllers passiert sein kann (Fusebits überprüfen!) oder in der Hardware selbst liegt und dort weitergesucht werden muss.
Debugger
Wenn man die Hilfeseite des Debuggers im Terminalfenster angezeigt bekommt, sieht es dagegen schon recht gut aus - das heisst, dass der Contoller läuft und keine groben Fehler mehr zu erwarten sind.
Jedes Kommando, welches ausgeführt werden soll, beginnt mit dem Buchstaben, welcher ganz links steht und muss immer mit >ENTER< abgeschlossen werden. Dafür ist die ENTER-Taste der Haupttastatur des PC zu verwenden und nicht die auf dem Nummernblock!
Schickt man >ENTER< ohne einen Buchstaben zum Interface, wird das Terminalfenster gelöscht und die Hilfeseite komplett neu aufgebaut.
Zuerst sollte man die Konfigurationsdaten überprüfen. Die liest der Controller direkt aus seinem Speicher aus und wenn er korrekt programmiert wurde, muss das immer funktionieren und etwa so aussehen:
Die letzte Funktion der oberen Hälfte "l" greift nun bereits auf den W5100 zurück, welcher an einem Port Pin des Controllers meldet, ob eine physische Verbindung zum Netzwerk besteht oder nicht. Das andere Ende des Netzwerkkabels muss dann natürlich auch am Switch oder Router angesteckt sein!
Das wäre dann der nächste Test, die Meldung auf dem oberen Bild wird mit angestecktem Kabel am KCNET ausgegeben, dann müssen auch bereits die LED's der Netzwerkbuchse flackern bzw. leuchten. Wenn man das Kabel wieder entfernt, gibt es eine diesbezügliche Mitteilung durch den Debugger, wenn man "l" noch einmal gedrückt und bestätigt hat.
Damit weis man dann auch, ob das Netzwerkmodul arbeitet, wenn nicht, kommt nur noch die Hardware bis dahin oder die des Modules selbst in Frage, da der Controller ja funktioniert.
Der nächste mögliche Schritt wäre die Überprüfung, ob man den RAM des W5100 fehlerfrei beschreiben und wieder auslesen kann. Da der Chip auf diesem Wege auch in Betrieb genommen wird, werden wir das auch gleich mal zu Fuss durchführen. Abschliessend senden wir ebenfalls auf diesem Wege einen Befehl ab und kontrollieren, ob ihn der W5100 korrekt ausführt, alle diese Schritte sind im nächsten Bild zu sehen:
Das sieht erst mal etwas kryptisch aus, ist aber im Grunde genommen ganz einfach. Etwas aufpassen muss man bei der Angabe von Parametern. Es gelten folgende Regeln:
- ein 8 Bit Wert ist mit 2 HEX-Zeichen anzugeben
- ein 16 Bit Wert ist mit 4 HEX-Zeichen anzugeben
- führende Nullen müssen mit angegeben werden
- zwischen Befehl und Parameter(n) muss genau ein Leerzeichen angegeben werden
- Gross- und Kleinschreibung wird nicht unterschieden, es kann also beides verwendet werden
- jeder Befehl muss wie oben mit >ENTER< abgeschlossen werden
Die Nichteinhaltung dieser Regeln ahndet der Controller mit der Rückmeldung "Syntaxfehler!" und man darf noch mal von vorn anfangen.
Wozu dient der Befehl "p"? Damit sagt man dem Controller die Adresse im KCNET, wo er die Bytes bei den Befehlen "x" bzw. "y" schreiben bzw. lesen soll. Nach jedem Byte, welches übertragen wurde, erhöht das Programm im Controller diese Adresse selbständig um 1, so dass man auf einmal mehrere Bytes von aufeinanderfolgenden Adressen, also ganze Speicherbereiche, schreiben oder lesen kann.
Im Gegensatz dazu wird bei den beiden Befehlen "w" bzw. "r" die Adresse als Argument immer mit übergeben, so dass der Controller auch ohne den Befehl "p" weis, wo er was machen soll.
Um den Test besser zu verstehen, sollte man das Datenblatt des W5100 mit zur Hand nehmen und in den entsprechenden Abschnitten nachlesen. Nachfolgend dann die Bedeutung und Wirkung der einzelnen Befehle laut Abbildung:
p 8005
Damit wird der Adresszeiger im KCNET auf die Adresse 8005H gesetzt, dort befindet sich das Register SUBR (Subnet Mask Register). Der Controller gibt in der folgenden Zeile als Bestätigung die verstandene Adresse zurück.
x 04 ff ff ff 00
Mit diesem Befehl schreiben wir 4 Bytes auf einmal in die Adressen 8005H=ff, 8006H=ff, 8007H=ff und 8008H=00. Übersetzt bedeutet das, die Subnetzmaske des W5100 hat anschliessend den Wert 255.255.255.0 - der Controller bestätigt die Aktion mit der Rückmeldung, dass 4 von 4 Bytes in den RAM von Adresse 8005H bis 8008H geschrieben wurden.
p 800f
Der Adresszeiger wird nun auf Adresse 800FH gesetzt. Dort beginnt das Register SIPR (Source IP Address Register), Rückmeldung wie oben.
x 04 c0 a8 00 15
Wir schreiben ab SIPR aufwärts die 4 angegebenen Bytes, damit hat das KCNET-Interface die IP-Adresse 192.168.0.21, was vom Controller wieder bestätigt wird.
p 8000
Der Adresszeiger wird auf die Adresse 8000H gebracht.
y 16
Jetzt werden die vorher geschriebenen Speicherinhalte verifiziert, indem wir 16H = 21 dez. Bytes ab Adresse 8000H wieder aus dem RAM des KCNET-Interface zurücklesen und im Terminalfenster anzeigen lassen. Der Controller schickt das gleich fertig aufbereitet als HEX/ASCII-Dump zurück, wobei in einer Zeile nacheinander von links nach rechts Adresse, HEX-Bytes und ASCII-Bytes aufgelistet werden.
Jetzt kann man diese Ausgabe mit den vorher übertragenen Eingaben vergleichen. Nur wenn ab Adresse SUBR (Schritt 2) und Adresse SIPR (Schritt 4) auch die richtigen Inhalte im Listing angezeigt werden, war der Schreibtest erfolgreich. Ansonsten ist die hardwaremässige Verbindung vom Controller zum Netzwerkmodul fehlerhaft, dann sind alle Leitungen, welche zum MCU-Businterface gehören, sowie der Adress- und Datenbus zu überprüfen (IC1 -> IC5, Gatter 3 von IC2, Netzwerkmodul).
War alles richtig, ist der W5100 jetzt bereits im Netzwerk erreichbar. Ein PING auf die oben eingegebene IP-Adresse wird vom KCNET-Interface entsprechend beantwortet, wenn man sich im gleichen Netzwerk befindet.
Abschliessend dann noch zu den restlichen Befehlen laut Abbildung:
w 8000 80
Auf Adresse 8000H befindet sich das MR Register (Mode Register). Wenn man in diesem Register das Bit 7 setzt, führt der W5100 einen Software-Reset durch. Anschliessend befindet sich der TCPIP-Stack wieder in einem jungfräulichen Zustand, alle Register werden zurückgesetzt und mit ihren Standardwerten geladen. Auch das Bit 7 von MR ist anschliessend wieder 0.
Genau diesen Befehl führen wir an dieser Stelle aus, indem wir das Byte 80H = 1000 0000 bin. direkt mit dem "w"-Befehl auf Adresse 8000H schreiben, was uns der Controller in seiner Antwort quittiert.
p 8000
Jetzt den Adresszeiger wieder auf Adresse 8000H setzen...
y 16
... und den Speicher noch mal anzeigen lassen. Wie man sehen kann, sind unsere Eingaben von oben wieder verschwunden, alle Register wurden auf den Standardwert 0 zurückgesetzt. Der PING auf die Adresse von oben wird nun auch nicht mehr beantwortet und warum man im Listing jetzt noch Werte ungleich 0 sieht, beantwortet Euch das Datenblatt und der Artikel zur Nachnutzung des KCNET.
Wenn das alles bis hierher funktioniert hat, kann es schliesslich noch ins Finale gehen. Nun fehlt ja nur noch die Verbindung zur PIO. Jetzt muss das KCNET-Interface natürlich am Z80-System angeschlossen sein, und das Testprogramm gestartet werden.
Beim KC85 ist es prinzipiell egal, ob man CPMNET oder CAOSNET benutzt, beide Programme führen im INTERFACE MENU exakt die gleichen Testfunktionen aus. Unter CP/M werden aber zwischen dem Aufruf einzelner Menübefehle noch andere Sequenzen zum Interface geschickt, was mit der programmeigenen Menüverwaltung von CPMNET zusammenhängt. Das folgende Bild wurde deshalb mit CAOSNET-Befehlen im KC85 erzeugt.
Der Test ist ganz einfach, man schaltet mit den beiden Befehlen "i" und "o" des Debuggers die Protokoll-Anzeige für den Datenverkehr von und zur PIO ein und sendet nun mit dem Programm im Z80 System geeignete Testbefehle des KCNET-Protokolls zum Interface.
Alles was jetzt von der PIO zum Controller gesendet und von ihm wieder zur PIO zurückgeschickt wird, erscheint gleichzeitig im Fenster des Terminalprogramms fein säuberlich Zeile für Zeile, siehe folgendes Bild:
Passiert hier nichts oder etwas anderes sind die Fehler in der Hardware der PIO-Schnittstelle selbst oder in der Verbindung zum Controller zu suchen und zu beseitigen. Die Werte der Antworten werden sich bei Euch natürlich unterscheiden, bis auf Funktion 13 - hoffentlich 
.
Das Bild zeigt das Absenden und die Antwort folgender Befehle des KCNET-Protokolls:
- 0DH = 13dez. - Lese Anzahl Kommando-Fehler -> 00 00 = 0 Fehler
- 03H = 3dez. - Lese Timer -> 90DFH = 37087 ms
- 08H = 8dez. - Lese dynamische Portnummer -> C004H = 49156
Alle geklammerten Ausgaben stellen Adressangaben dar, welche nicht zum Protokoll gehören, das fügt der Controller zusätzlich in Echtzeit ein, damit die Ausgaben verständlicher und besser lesbar sind. Sollte einmal ein Fragezeichen zu sehen sein, hat der Controller den Befehl nicht verstanden, das sind Kommandofehler bei der Benutzung des KCNET-Protokolls!
Bitte nach der Benutzung der PIO Protokoll-Funktion, sowohl die Aus- als auch die Eingabe wieder ausschalten! Da in Echtzeit mitgeschrieben wird, begrenzt man damit auch die Übertragungsgeschwindigkeit von/zur PIO auf die 9600 Baud der seriellen Schnittstelle, was ca. 1 kByte/s entspricht - das ist wie Autofahren mit angezogener Handbremse!
Das DEBUG-Interface wird adressmässig nicht kontrolliert - man hat vollen Zugriff auf den gesamten RAM des Controllers. Man sollte daher die Adressen von 0 bis 500H nicht beschreiben, da man sonst die Firmware zum Absturz bringen kann!
Zusammenfassung
Wer bis hierher mitgemacht hat, ist am Ziel. Das Interface sollte im Z80 System funktionieren. Man muss sich das nicht antun - wer gleich den letzten Schritt macht und die Z80 Software für den ersten Test benutzt und alles läuft, dann ist das auch in Ordnung. Wenn dort aber nichts passiert, sollte man Schritt für Schritt diese ausführliche Inbetriebnahmeanleitung durchgehen, um die Ursache der Fehlfunktion einzugrenzen, damit man sie schneller finden und beseitigen kann.
Noch ein wichtiger Punkt ganz zum Schluss - wenn die Diagnose-Schnittstelle nicht gerade benutzt wird, sollte dort auch nichts angeschlossen sein! Sobald ein Zeichen von aussen an den Controller gesendet wird, unterbricht er alles andere und wartet auf das Ende also den Empfang von >ENTER<. Kommt das nicht, verhält sich auch die PIO-Schnittstelle wie tot!
Das hat mich schon mal einige Minuten Überlegungen gekostet, als ich mit Linux experimentiert habe. Das sendet beim Booten, im Gegensatz zu Windows, irgendwelche Zeichen an den COM-Port und blockiert somit die PIO - dann sieht das aus der Sicht des Z80 Systems aus, als wäre das Interface defekt!