PCI-Veraltung - IEEE1284 (EPP,ECP,LPT)-Druckerport-ASIC

Ich habe ein Produkt in Serienfertigung, bei dem die eingebettete CPU jetzt veraltet ist.
Ich muss diese CPU durch eine kostengünstigere Alternative ersetzen. Aus politischen (und praktischen) Gründen habe ich keine Wahl, welche CPU ich verwenden soll.
Die ursprüngliche CPU hatte einen Begleitchip, der einen Druckeranschluss bereitstellte. Der Ersatz hat diese Funktion nicht.

Der Druckeranschluss wird/wurde von einem alten (und sehr alten/veralteten) RTOS für Debug-Zwecke verwendet. Ich würde dieses Betriebssystem gerne ändern, aber aufgrund der Komplexität wird das nicht passieren, bevor wir die Produktion des aktuellen Designs aufgrund von Engpässen einstellen.

Die Ersatz-CPU hat keinen IEEE1284-Anschluss (auch bekannt als EPP, ECP, LPT, SPP, Drucker usw.)

Ich habe hoch und niedrig gesucht und kann keinen ASIC finden, der IEEE1284 auf einem 3,3-V-PCI-Bus implementiert. Die einzigen Teile, die ich finden kann, die jemals waren, sind auch veraltet.

Ich kann VHDL-Soft-IP finden, aber die Mächtigen wollen kein FPGA im Design, und auf jeden Fall sind die Kosten für das IP viel zu hoch.

Gibt es also (auf die Gefahr hin, des "Einkaufens" beschuldigt zu werden) einen Hersteller, der immer noch ein 3,3-V-PCI-IEEE1284-ASIC-Gerät (manchmal als SuperIO bezeichnet) herstellt, das zu niedrigen Kosten in relativ geringen Produktionsmengen zum Verkauf in ( oder Import nach) Europa?

TIA,

Muss es über PCI sein? Sie können sicherlich noch USB -> LPT-Konvertierungsgeräte erhalten. Oder es könnte möglich sein, einen schnellen Mikrocontroller auf den PCI-Bus zu setzen und ihn das erforderliche Verhalten implementieren zu lassen.
Die Schnittstelle ist für Low-Level-Debugging. Ich bin mir nicht einmal sicher, ob das RTOS einen USB-Treiber für einen generischen USB-LPT-Anschluss haben wird (ich habe keinen gesehen), und selbst wenn, müsste er früh während des Bootens installiert werden, um das Debuggen verfügbar zu machen diese Zeit. In jedem Fall würde ein USB-Miniport OS-Indirektion verwenden, um einen Druckerport bereitzustellen. Jeder Chip muss sich auf der Standard-PC-LPT1-IO-Adresse befinden.
Ich denke, der Vorschlag eines schnellen Mikros auf dem PCI-Bus würde in die gleiche Richtung gehen wie die FPGA-Route, die ich lieber verwenden würde. Es ist ein weiteres programmierbares Gerät und wird daher von anderen nicht gemocht.

Antworten (2)

Ich schlage vor, Sie schlagen den LPT-Port im Code ein. Ein AVR-Beispiel finden Sie hier . Alternativ können Sie das Debuggen über eine neue bevorzugte Schnittstelle durchführen und dann nur für alte Debug-Geräte eine Zwischenhardware erstellen, die diese neue Schnittstelle in die alte LPT-Schnittstelle übersetzt. Das ist gut für die Zukunft, denn Sie können LPT komplett fallen lassen, wenn RTOS endlich einen Ersatz bekommt.

Das wird nicht funktionieren. Der LPT-Port wird im ECP-Modus von den RTOS-Interna zum Debuggen verwendet. Es wird erwartet, die „Standard“-Adresse des LPT-Ports zu verwenden. Diese Adresse würde auf PCI, ISA oder LPC laufen. Schrecklich, ich weiß, aber so ist es eben.

Sie könnten einen CPLD-Chip verwenden, um auf dem PCI-Bus zu sitzen und den ECP-Port zu implementieren. Ja, es wird einige Verilog-Entwurfsarbeit erfordern, aber es gibt anständige PCI-Bus-Modelle auf Opencores, gegen die getestet werden kann. Es handelt sich oft um ein Einzelchip-Design, da Sie keine für ein FPGA erforderliche Konfigurationshardware benötigen.

Hier ist ein Open-Source-Projekt, das ein CPLD verwendet, um einen IDE-Adapter für den ISA-Bus als Motivation zu implementieren: http://dangerousprototypes.com/2012/02/13/xt-ide-adapter-tested-and-working/

In den Vintage Computer Foren http://www.vintage-computer.com/vcforum arbeiten mehrere Leute an diesem Zeug

Wenn er kein FPGA will, ist wahrscheinlich auch ein CPLD draußen.
Die "Machthaber" kennen den Unterschied vielleicht nicht :-)
Vor allem dann wird es ein No-No sein. Sie könnten damit durchkommen, wenn Sie erklären, dass es etwas völlig anderes ist.