Werner's Seiten - Werkstatt

Manche Selbstbauschaltung zickt am Anfang bis sie zur ordentlichen Mitarbeit überzeugt werden kann. Ein Oszi ist da schon sehr hilfreich, nur meiner ist kein Speicher-Oszi und mit den zwei Kanälen ist man schon schnell am Ende des Lateins.

Bei zyklisch wiederkehrenden Ereignissen geht's noch so eben, wenn aber mehr als zwei Signale betrachten werden müssen ist mit den Gegebenheiten Schluß - also muss was besseres her...

Es gibt Logicanalyzer mit allem Zick und Zack nur übersteigen diese, selbst als Gebrauchtgerät das Hobby-Budget deutlich. Da der Moppel nur mit 3Mhz getaktet wird wäre das auch mit Kanonen nach Spatzen schießen. Also ein Hantek 6022BL angeschafft, die Technischendaten lasen sich sehr gut und hatte neben den 16 digitalen Kanälen noch ein Speicher-Oszi an Board. Eigendlich ein gutes Gerät für den Heimgebrauch nur leider konnte er im Analogbetrieb kein ordentlich stehendes Bild erzeugen und im Analyzermodus gab es auch keine gescheite Triggermöglichkeit z.B. auf das CS-Signals eines Uhrenbausteins. Die Software war immer noch auf dem Prototypenstand von 2013. Bei "SigRok Org" (https://sigrok.org/wiki/Hantek_6022BL) gibt es zwar eine deutlich bessere Software, diese kann aber nur acht der 16 vorhandenen Kanäle nutzen - Return to Sender.

Mir das Projekt "Open Bench Logic Sniffer" genauer angeschaut und schließlich bei Antratek bestellt. Wunderbar, alles auf einer kleinen Platine in perfekter Qualität. Er bietet 16 TTL-Kanäle, 100Mhz Abtastrate bei max 12k Samples, für die Moppelumgebung völlig ausreichend und das alles für rund 60Euros. Da kann man über das fehlende Gehäuse locker hinweg sehen - dafür gibt es schließlich die Fräse...

Erste Aufgabe liegt schon auf dem Basteltisch - die Moppel Multi-IO-Karte - Die Systemuhr produzierte eigenwillige Ausgaben auf dem Bildschirm.

Hier der "Messaufbau", Kanal 0 und 1 stellen das CS- und Stop-Signal dar, diese lösen auch bei High-Pegel den Trigger aus.

An den beiden Signalverläufen kann man das Zusammenspiel der Steuerleitungen gut erkennen, beim Lesen des Uhrenbausteins zeigt die Modusumschaltung des PIO-Bausteins 8255 von Aus- auf Eingabe dass auch alle anderen Ports zurücksetzt werden, ist aber kein Bug sondern Feature ;-)). Dieses Verhalten stört in dieser Schaltung glücklicherweise nicht - sollte aber im Gedächnis bleiben um z.B. in einer Maschinensteuerung keine bösen Überraschungen zu erleben.

In meiner Bastelkiste warten noch einige Anwendungsfälle für den Sniffer, ...

Der Workaround für Programmentwicklung am Moppel-2 sollte einfacher gestaltet werden, denn derzeit schaufel ich die Daten mit PEPS auf die Promer-Karte und lese dann das Pseudo-EPROM im Moppel ein. Also den Intel-Hexlader auf die V24-Karte umgestrickt und ab in den Moppel (Speicherkarte Platz 4 wo mal der Basic-Interpreter wohnte). Mit 9600Bd purzeln nun aus dem XP-Laptop mit Hyperterminal die Daten rein - soweit so schön. Funktioniert aber mit dem Arbeitsplatz PC (WIN7 64bit) nicht, großes Rätselraten ...

Also eine Adapterplatine mit entsprechendem Pegelwandler aufgebaut, nun kann der Logicsniffer an den V24-Leitungen horchen und den Datenverkehr aufzeichnen. Hyperterm auf 9600Bd und Hardwarehandshake eingestellt, Trigger auf RTS und RXD low und Mitschnitt gestartet ...

Und was macht der PC daraus, sendet einfach nur mit 4800Bd - Schnittstellen überprüft, Treiber neu installiert, Fehler ist nicht zu lokalisieren. Wobei zwei PC's mit Nullmodem-Kabel sich ausgezeichnet verstehen und auch die Datenübertragung zum PEPS mit 38400Bd funktionieren einwandfrei .

Da ich gerade alles auf dem Tisch liegen habe, wurde die Verbindung vom XP-Laptop auch noch näher betrachtet. Der Logicsniffer konnte bei diesem Mitschnitt 100Bytes mit 9600Bd aufzeichnen (Speichergrenzen), das reicht aber um sich einen guten Überblick zu verschaffen (Bild 2).

Die Startbedingung ist im Bild 3 sehr genau darstellbar. Der Moppel hat beim Start des Intel-Hexladers die RTS-Leitung auf High gesetzt damit er vom vorlauten PC nicht überrannt wird und gibt sie zum Empfang jeweils frei.

Hier sieht man schön wie der 6850 bei der Freigabe etwas prellt (ca. 5µs). Nach weiteren 130µs trudelt dann eine Hexzeile ein. Nach jedem Byte gibt es noch ein kurzes aufflackern der RTS-Leitung und am Ende der Zeile wird der Sender für ca. 5ms angehalten damit der Hexinterpreter alles sauber verarbeiten kann (Bild 4).

Und genau hier liegt das Timingproblem Bild 5, obwohl der Moppel das RTS-Signal gesetzt hat, senden die PC's munter weiter bis der FIFO im 16850 geleert ist. Auch wenn ich diesen Abschalte, purzeln immer noch ein bis zwei Bytes heraus die der Moppel dann im falschen Hals bekommt.

Im CP/M-Moppel habe ich ja einen ATMEGA644 auf dem CF-Karten-Interface zur Unterstützung, der Speichert die ankommenden Daten per IRQ im Buffer und übergibt es häppchenweise an den Moppel.

Resuemee:
V24 ist nicht gleich V24, so eine einfache Schnittstelle kann einem viel Kopfzerbrechen bereiten. Also Programmentwicklung für diese Altertümer sind auf einem alten XP-Rechner besser aufgehoben. Denn bei den modernen Dingern hat man kaum noch eine V24 und wenn, lassen sich nicht alle Parameter vernüftig beeinflussen.

Oder ich baue einen Schnittstellenumsetzter der die verschiedenen Welten miteinander Verbindet...