Eine der vielen Ausleseroutinen in PCS500.exe sieht so aus.
Sicherlich ist ein Velleman PCS64i so ähnlich gestrickt. Dafür gibt es QtDSO für Linux. Für sigrok liegen keine Plugins vor.
Für den Betrieb der Originalsoftware (PCS500.exe) unter 64-Bit-Windows mit echten Parallelport wird ein 64-Bit-Treiber benötigt. Dass es überhaupt möglich ist, einen solchen zu implementieren, habe ich am 9. April 2015 herausgefunden. Besser spät als nie: Noch nie hat irgendwer weltweit dokumentiert, dass es auch unter 64-Bit-Windows die gleiche IOPM gibt wie unter 32-Bit-Windows. Damit sind auch hier Portzugriffe vom User-Mode aus möglich. Was für die Originalsoftware unbedingt erforderlich ist; das Umlenken von Exceptions in den Kernel-Mode für jeden einzelnen Portzugriff mittels meiner inpout32.dll erwies sich als zu langsam.
Der USB-Adapter muss Eigenintelligenz aufweisen und erfordert spezielle Auslesesoftware, etwa o.g. Oszi.exe mit geeignetem Plugin. Dieser generische USB-Parallel-Konverter wäre unerträglich langsam.
Eine PIC16F1454 ist dafür geradezu maßgeschneidert, mit den folgenden Vorteilen gegenüber jeder anderen mir bekannten Lösung:
Der Schaltplan ist ziemlich simpel. Das Fußvolk besteht aus gerade mal 3 Stützkondensatoren. Entflechten mit folgender Pinzuordnung:
USB-Pin | SubD-Pin | LPT-Signal | PCS500-Signal | PIC-Port | PIC-Pin | PIC-Pin | PIC-Port | PCS500-Signal | LPT-Signal | SubD-Pin | USB-Pin | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 (rot)6-9,14 ‡ | D4-D7 | Strom für Optokoppler | UCC | 1 | 14 | GND | GND | GND | 18-25 ‡ | 4 (schwarz)
| 5 | D3 | StrobeB | A5 (Ausgang) | 2 | 13 | D+ | 3 (grün)
| 4 | D2 | StrobeA | A4 (Ausgang) | 3 | 12 | D- | 2 (weiß)
| 11 ‡ | BUSY | - | 4 | 11 | UUSB | Kondensator 1 µF nach GND
| 3 | D1 | SCLK | C5 (Ausgang) | 5 | 10 | C0 (Eingang) | A = Nibble-Bit 0 | 15 ‡ |
| 2 | D0 | SDATA | C4 (Ausgang) | 6 | 9 | C1 (Eingang) | B = Nibble-Bit 1 | ONL | 13 ‡
| 10 | D = Nibble-Bit 3 | C3 (Eingang) | 7 | 8 | C2 (Eingang) | C = Nibble-Bit 2 | PE | 12
| |
Die Pinzuordnung der Nibble-Bits ist so gestaltet, dass die PIC-Software das Nibble direkt verarbeiten kann und nicht mit Einzelbits herumhantieren muss. Denn hier ist Geschwindigkeit erforderlich, um das 4-KByte-Datenpaket zügig zum USB zu senden.
Obwohl DIL-Mikrocontroller am liebsten in einer Fassung sitzen, passen Fassung und Controller nicht mehr ins Gehäuse, sind zu hoch. Die passende Lösung hierfür sind Einzelbuchsen, die zum eingelöteten Chip nur etwa 1 mm addieren. Dazu schlachtet man eine IC-Fassung (bricht aus einer Fassung mit gedrehten Kontakten die Einzelkontakte heraus) und lötet diese in entsprechend große, idealerweise durchkontaktierte Löcher.
‡ In-System-Programmieranschlüsse, erfordert nur SubD-Adapter, dadurch Verzicht auf gesonderten Programmieranschluss.
Am PCS500 ist der Anschluss für
Die Bits sind in der Firmware einzeln einzulesen,
in etwa so:
readbyte:
clrf tmp
call readnibble ;High-Nibble einlesen
swapf tmp,f
readnibble: ;Low-Nibble einlesen
btfss PORTC,2
bsf tmp,0 ;gleich invertieren
btfss PORTA,5
bsf tmp,1
btfss PORTA,4
bsf tmp,2
btfss PORTC,5
bsf tmp,3
bcf PORTC,1 ;auf Low-Nibble umschalten
return ;Takte zum Warten auf
;Optokoppler 6N136: ≥1 µs
readall:
movlwf 0x20,cnthi
clrf cntlo
readloop:
call readbyte
movfwf tmp,usb_pipe
bsf PORTC,1
btfsc PORTC,0
goto ch2
bcf PORTC,0
goto ch1
ch2: bcf PORTC,3 ;Zähler-Takt
bsf PORTC,0
bsf PORTC,3
ch1: wait_until_usb_is_ready
decfsz cntlo
goto readloop
decfsz cnthi
goto readloop
return
Die SMD-Lösung erspart das Bohren von Löchern. Mit Löchern sieht's nur schöner aus. Dazu eine simple Ätzmaske als gespiegelte 600-dpi-Bitmap. Zur Kontrolle die Platinenmaße: 35 × 28 mm².
Die USB-Lötanschlüsse sind in „chaotischer“ Reihenfolge. Bei farblich genormten Anschlusskabeln ist die Farbreihenfolge von oben nach unten weiß – grün – schwarz – rot.
Der Nachteil der beiden o.a. Lösungen mit PIC16F1454 ist, dass daran kein Velleman-Funktionsgenerator PCG10 oder K8016 angeschlossen werden kann. Der Entwurf mit PIC16F1459 (ca. 2 €) hat diesen Nachteil nicht. Erkauft wird diese Erweiterung mit engeren und schmaleren Leiterzügen, jeweils 0,4 mm.
Dazu wieder simple Ätzmasken als gespiegelte 600-dpi-Bitmap. Zur Kontrolle die Platinenmaße: 35 × 28 mm². Normalerweise wird nur die Oberseite benötigt; der Luxus einer doppelseitigen Platine erfordert immerhin 7 Durchkontaktierungen und damit 7 Stück Draht.
Im Gegensatz zum vorherigen Entwurf sind die USB-Lötanschlüsse in „genormter“ Reihenfolge, wie beim USB-Stecker. Bei farblich genormten Anschlusskabeln ist die Farbreihenfolge von oben nach unten rot – weiß – grün – schwarz.
Die Leiterplatten-Layouts sind mit Bedacht gestaltet:
Ein externer DC/DC-Wandler 5 V → 12 V kann den PCS500 außerdem noch mit potenzialgetrenntem Strom versorgen; dann ist's jedoch nicht mehr USB-konform, was den Stromverbrauch angeht. Besser wäre es, die interne Stromversorgung auf potenzialgetrennte 5 V umzurüsten (d.h. einen Transverter einzubauen) und auf die Energie verbratenden Längsregler zu verzichten. (Diese können eingebaut bleiben und ermöglichen die wahlweise Speisung.) Der Transverter speist sich dabei vom Pin 6. Für ein feldmäßiges Notebook-Oszi die einzige Chance ohne Strom auszukommen. Genial dabei ist die dennoch wirksame Potenzialtrennung zum Messobjekt.
Der Adapter ist so gebaut, dass das Programmieren mittels Low-Voltage-ICSP™ über den Parallelportstecker „von hinten“ möglich ist, ein gesonderter ISP-Stecker (auf der Leiterplatte) bleibt so erspart. Für die Massenfertigung braucht man nur einen Adapter mit 25-pol. SubD-Stecker wie folgt:
Zur Inbetriebnahme der Firmware ist (wie bei mir so üblich) der LPT-Tester nützlich, den man einfach solo oder zwischen dem Adapter und dem PCS500 gesteckt betreiben kann.
Die Mikrocontroller-Firmware benutzt die im Bastelbereich kaum oder nie verwendete USB-Geräteklasse USB-TMC, Klasse 0xFE, Unterklasse 0x03, Protokoll 0x00. Windows hält dafür keinen Standardtreiber vor, aber es kann der Agilent USB-TMC-Treiber installiert werden, der ausbtmc.sys heißt. Genauso wie bei USB-CDC dienen zwei schnelle Bulk-Pipes zum bidirektionalen Datenaustausch. Von Vorteil ist, dass man keine COM-Portnummer einstellen muss, die Firmware etwas einfacher ist und sich auch unter Windows 98/2k mit HID als zweites Interface kombinieren lässt. (Da gab es Probleme, USB-CDC mit anderen USB-Funktionen zu kombinieren.) HID allein ist für den Sampledatentransfer zu knapp, begrenzt die Datenrate auf 64 KByte/s, das wären 8 Bilder/s bei kompletter Sampledatenübertragung.
Die USB-VID+PID wurde bei Microchip „geordert“, für dieses Projekt wurde USB\VID_04D8&PID_EFDA zugewiesen. Sie wird auch dann benötigt, wenn wie hier Standard-Treiber verwendet werden.
Interessant: Steckt man den Adapter mit der halbfertigen Firmware an einen PC mit installiertem LabVIEW 2010, gibt es nach der erfolgreichen Treiberinstallation einen Bluescreen, verursacht von ausbtmc.sys. Egal ob Protokoll 0x00 (USBTMC) oder 0x01 (USB488). Stülpt man die Treibersoftware von Keysight (oben) als Update darüber, läuft alles glatt; mehr noch, es startet NI SignalExpress. Da jedoch die Firmware noch keinen SCPI-Befehl verarbeitet, geht es vermutlich nicht weiter.
Derzeit, seit 2019, läuft die Entwicklung in eine ganz andere Richtung: Mit WebUSB kann ein Browser die Oszilloskopfunktion übernehmen, sogar ein Smartfon. Javascript ist mittlerweile schnell genug zur Quasi-Echtzeit-Darstellung, und man kann sich das Original-Windowsprogramm sonstwohin stecken.