PC Kabel für ELNEC PIKprog

Sieht so aus, als ob da ein normales Verlängerungskabel dran gehört. PC hat Buchse und das Teil hat Stecker. Es ist nicht sehr wahrscheinlich, dass die was eigenes gemacht haben, wenn es die Kabel von der Stange gibt. Die warnen vor hot plug, schreiben aber, dass ihr Gerät das könnte, man aber den PC schützen solle. Du könntst so ein Kabel selber löten und in die Signalleitungen Serienwiderstände einbauen.

MfG hjs

Moin, Moin,

Mein PIKProg hat eine 9polige-Female-Cannon-Sub-D-Buchse und keine Buchse für ein 25poliges PC-Druckerport-Verlängerskabel wie viele andere Programmierer.

Christian

Am 06.10.24 um 15:56 schrieb Hans-Juergen Schneider:

Das Problem bei Hot-Plug und Sub-D ist eher, dass nicht definiert ist, in welcher Reihenfolge die Kontakte verbinden. Wenn dann statische Aufladung oder auch nur Geräte ohne Schutzleiter im Spiel sind, fließen die Ableitströme ggf. über die Port-Leitungen, wobei selbige auch gerne mal verrecken. Wenn vorher schon eine Masseverbindung zwischen den Geräten besteht, passiert nichts.

Was auch immer das bringen soll.

Marcel

Am 07.10.24 um 11:50 schrieb Christian Keck:

Und du bist sicher, dass das an den _Parallelport_ gehören soll? Das sind viel zu wenige Pins für einen Parallelport. Der hat ja schon 8 Datenleitungen.

Das hört sich für mich eher nach einem seriellen Port an.

Marcel

Na, die Regeln gegen hot plug sind doch sowieso zu beachten. Wenn aber irgendwelche Signalleitungen vertauscht sind, dann besteht doch die Gefahr, dass er Ausgänge gegen etwas härteres jagt.

MfG hjs

Am 08.10.2024 um 03:59 schrieb Marcel Mueller:

Immerhin schreibt die ELNEC-Seite das der am Parallelport hängt und auch Bilder und Beschreibungen im Web sagen LPT. Auch kann man am PP mehr Pins mit Bitbanging betreiben, an der Sellerie nur eingeschränkt.

Im Januar 2012 hat jemand noch die Kabelbelegung von ELNEC erhalten:

Bernd

Elnec schreibt, an einem automatischen Druckerumschalter funktioniere der Programmer nicht. Das deutet IMO darauf hin, daß hier die Daten und Handshakeleitungen nicht Centronics konform benutzt werden. Eine Messung mit Oszilloskop könnte evtl. zur Identifizierung der benutzten Leitungen dienen. Reverse engineering der Software wäre auch denkbar. Ansetzen würde ich hier bei der Software für MS-DOS.

Am 08.10.2024 um 09:46 schrieb Peter Heitzer:

Ich würde zuerst mal messen welche der Leitungen am DB9 belegt sind und welches Ein- und Ausgänge sowie Masse sind. Das ergibt schonmal einen Hinweis auf die Belegung, hoffnungsweise sind da auch nicht alle 8 freien Pins belegt. Bitbanging war damals zwar üblich, aber schon immer Mist. Die DOS-Software sucht auch den Programmer, klimpert also zumindest irgendwie an den Leitungen. Sind aber trotzdem evtl. viele Möglichkeiten die Anschlüsse zu verbinden. Das Reverse engineering der Software dürfte dennoch auch mit Tools wie Ghidra mühsam werden und liefert höchstens Hinweise welche Pins am LPT benutzt werden.

Bernd

Dasselbe beim Elnec SIMEPROM aus dem letzten Jahrtausend, ein EPROM-Simulator.

Der hängt beim (damaligen) Windows-95-PC an einem parallelen Druckeranschluß (mit Standardadresse, weswegen nachgerüstete PCI-Karten o.ä. nicht unbedingt funktionieren, weil die tolle Software nur ein paar bekannte Adressen abklappert). Speicherschutz wie bei Windows XP und Nachfolger darf es bei der alten Software nicht geben, denn die spielt selbst mit der Hardware. Ist halt DOS-Windows-Software, da kann man nix machen ;-) Industriestandard!!1elf!

Beim SIMEPROM werden drei serielle(!) Datenströme in das Gerät gepumpt. Eine Leitung gibt den Takt vom PC ans Elnec-Gerät, denn dort drin sind schnöde Schieberegister (HC4094, wie schon beim mc-Eprommer aus den

Gruß, Ralf

Ich habe das Protokoll vom SIMEPROM anhand der Schaltung revörs enscheniert. Die ist nicht besonders umfangreich und beim Durchklingeln fast selbsterklärend.

Bei diesem PIKprog könnte es gewisse Ähnlichkeiten geben. Ein EPROM-Simulator benötigt 16 Adreßleitungen (für ein 64kB SRAM/EPROM) und

Gruß, Ralf

PIC wird seriell programmiert. Es gibt Takt, Daten und dann noch Reset. Der kennt drei Zustände: L/H/Vpp. Eine der Fallen besteht z.B. darin, dass der H hat, wenn Udd angelegt wird. Aber da gibt es noch mehr Kram, was die Kiste machen muss.

MfG hjs

Hallo Hans-Juergen,

Du schriebst am Wed, 09 Oct 2024 11:26:28 +0200:

Ja, kann sein - so einfach ist das inzwischen schon lange nicht mehr. Schon recht betagte PICs können eine "low voltage" Programmierung, bei der die Umschaltung in den Programmiermodus durch ein "Telegramm" im Reset-Zustand vorbereitet wird und erst danach die eigentlich Programmierung stattfinden kann. Zwisachendurch gab's AFAIR aber auch mal ein paar, bei denen die "low voltage"-Programmierung mit einem speziellen (Port-) Pin eingeschaltet wurde, was dann aber etwas ungünstig mit der Nutzbarkeit der Ports zusammentraf, d.h. es ging nur entweder "low voltage"-Programmierung oder volle Port-Nuitzung, "manchmal" etwas ungünstig.

Geht noch viel schöner. Ob Portpin oder Reset steht im sog. configuration word. Jetzt kann man dort auf Portpin einstllen und diesen auch auf Ausgang initialisieren. Da ist dann nix mehr mit Reset. Wird aber doch zum Programmieren gebraucht. Das configuration word muss ja schließlich auch übers Programmierinterface dort rein. (Aber auch dafür gibt es eine Lösung.)

MfG hjs

Am 08.10.24 um 21:42 schrieb Ralf Kiefer:

Das meiste von dem Zeug hat unter OS/2 sehr wohl in der VDM mit Speicherschutz funktioniert. Der virtuelle LPT-Treiber hat bei Direktzugriffen einfach exklusiven Zugriff auf das Device angefordert und dann die Port-Register direkt für diese Anwendung freigegeben. x86 CPUs können AFAIR bis 0x400 jede I/O-Adresse einzeln für eine DOS-VM freigeben.

Und selbst unter Linux mit Wine geht so etwas. Mein Programmer (Conitec) hat auch noch Parallelport. Ich habe aber schon ewig kein Windows mehr. Man kann aber einer Wine-Anwendung exklusiven Zugriff auf einen Parallelport einräumen. Leider wurde der Support dafür wohl aus den

Marcel