trotz aller Unkenrufe ist GPIB noch immer nicht tot. Es gibt GPIB-Adapter von NI, Keysight, Keithley, Tektronix, Teledyne/LeCroy, Rigol, GW-INSTEK, Ines, Prologix etc. es gibt/gab auch GPIB-Adapter-Projekte wie - Agipibi Thibault Vincent, Mathias Helsen - mega2560 - Russ Kessing - mega2560 - GPIBerry - Arduino nano - Emanuele Girlando - Arduino UNO - Elektor-Artikel 4.2011 - Renesas-CPU - Uni Ljubljana - AT90S8515, FT245BM - Sven Pauli - Atmega16 - Anders Gustafson - PIC - Steven Casagrande - PIC - Jan Petersen - AVR - Oliver Dahlmann - Dennis Dingeldein - usw. unterschiedlich sind die eingesetzten - Mikrocontroller: AVR, Renesas, PIC.. - Bustreiberchips: keine, 75160, 75161, 75162, etc. - Firmware: C, C++, ino-file, einfache Abfragen, Statemachines.. der Strombedarf einer GPIB-Lösung hängt ggf. stark von den verwendeten Bus-Treibern an den 16 Busleitungen ab. Eine Stromaufnahme von 70-110mA ohne Last für jedes der beiden Treiberchips kann ggf. auftreten. im Ruhezustand sollen alle Bus-Leitungen high sein. Der Treiber muss/soll dann keinen Strom gegen Masse treiben. Erst bei Aktivierung von Steuer- und oder Datenleitungen (aktiv low) muss Strom fließen. Treiber wie 75160, 75161, 75162 nehmen deutlich mehr Strom auf als für die Funktion nötig ist. Laut Spec sollen die Treiber bis 48mA gegen Masse und bis 5.2mA gg. VCC treiben können. - der Output-High-Pegel soll bei >2.5V liegen (typ. 3.4V) - der Output-Low-Pegel soll bei <0.5V liegen (typ.0.22V) damit stellt sich die Frage welche Bauteile mit niedriger Stromaufnahme als Treiber in Frage kommen. als maximale Datenrate steht im "Tutorial Description of the Hewlett-Packard Interface Bus" 1Mbyte/s über limitierte Distanz und 200-500kByte/s über die volle Distanz bis zu 20m. um alle zeitlichen Anforderungen der IEEE488-Spezifikation zu erfüllen wurden in den 80er Jahren Bustreiber eingesetzt wie 75160, 75161, 75162 und dazu passende GPIB-Chips wie TMS9914, uPD7210 für Controller-, Talker- und Listener-Funktion die per Mikrocontroller angesteuert wurden. 120-180 Bauteile sollten durch die speziellen Teile eingespart werden. einiges der Funktionalität dieser spezialisierten ICs können moderne uCs programmtechnisch abarbeiten - wenn man mit einer Echtzeitlücke leben kann die nur durch die obigen oder neuere spezialisierte Bausteine abzudecken war. wenn man die Echtzeitlücke außer acht lässt ist es denkbar moderne Treiber einzusetzen - die kaum Ruhestrom benötigen - die schnell schalten können - die 5mA bei 2.5V liefern können und - die 48mA bei 0.5V liefern können. wo ein Bauteil alleine das nicht leisten kann ist es ggf. denkbar einen Treiber zusammenzusetzen aus - einem Teil der High 5mA treiben kann und - einem Teil der Low 48mA treiben kann. es ist auch denkbar Treiber für 3.3V zu nehmen, da der High-Pegel nicht bis 5V reichen muss. Bei Abschalten des Geräts soll jedoch kein parasitärer Strom vom Bus in die Treiberausgänge fließen. Dies ist durch geeignete Maßnahmen sicherzustellen. es ist denkbar für den Low-Teil einzelne Mosfets einzusetzen. Ein Ruhestrom tritt dann nicht auf und auch keine parasitäre Bus-Belastung bei abgeschaltetem Gerät. dies als Anregung zur Diskussion. natürlich lassen sich Anforderungen ggf. entschärfen wenn nicht ein Controller mehrere Busteilnehmer bedienen muss und es ggf. einen Controller pro Busteilnehmer gibt.
:
Verschoben durch User
Ja. Alles gut. Und die Frage war ? Ob man mit Lowpower durchkaeme ? Ja, koennte man. Aber will man sich den Aufwand machen ? Solange ich mit einem Screenshot per Mobiltelephon durchkomme, lese ich doch keine Daten aus.
Und jeder der damit Geld verdienen muss, oder dessen Zeit nicht kostenlos ist, kauft sich einen NI USB GPIB Adapter oder vergleichbares fertiges. Das passt dann auch ans NI VISA.
Da liest du alte Specs, 8Mbyte/sec war schon vor 40 Jahre Praxis, wenn auch Herstellerspezifisch. Was ist die eigenliche Frage, bzw wozu das ganze. Wenn es darum geht, ein einziges Gerät an USB zu hängen, kein Problem, bei aber 3-4 Geräten sowie wenn einige abgeschaltet sind, sieht dies ganz anders aus, und wenn Extender/repeater im Einsatz sind sowieso.
Ganz sicher werde ich mir nie mehr einen NI Treiber laden. Dieses Zeug ist so was von invasiv. Das werden ein duzend Treiber geladen, welche gemaess Taskexplorer (Processexplorer) immer aktiv sind, dh RAM belegen. Um den Mist zu entsorgen muss man alle diese Treiber auf suspend setzen, weil sie sich gegenseitig regenerieren, dh wieder starten. Wenn alle auf suspend sind, kann sie alle killen, und dann auch loeschen.
chris schrieb: > Was ist die eigenliche Frage, bzw wozu das ganze. da ist keine eigentliche Frage - das ist eine Diskussion. Jeder kann das nehmen was er will/braucht und zahlen was er will/kann.
Megatroll schrieb: > Ganz sicher werde ich mir nie mehr einen NI Treiber laden. der Treiber von NI den ich vor Jahren zur Installation herunterlud war riesig. - ni4882_302.exe hatte 571Mb. - ni488_312.exe hatte 618Mb. dazwischen lagen 2 Jahre. im Treiber stand daß mein PCMCIA-GPIB-Adapter den ich kurz zuvor erworben hatte nicht mehr von NI auf meinem Rechner mit Win7 unterstützt wird. Kauf eines anderen Adapters wurde empfohlen. was treibt Menschen dazu selbst Projekte wie die oberen anzugehen? Langeweile? Kostendruck? der Wunsch etwas anders zu machen? mich interessierte es eine eigene Idee für einen Treiber umzusetzen.
Christian R. schrieb: > jeder der damit Geld verdienen muss, oder dessen Zeit nicht > kostenlos ist, kauft sich einen NI USB GPIB Adapter oder vergleichbares > fertiges. Das passt dann auch ans NI VISA. ja Chris. Das kann klappen oder nicht. als ich 2 Keithley-Geräte kaufte dachte ich kauf den GPIB-Adapter dazu von derselben Firma. Dann ist alles aus einem Haus. Nur leider lief die Software von NI nicht brauchbar damit. Das war ein übler zeitaufwendiger Lernprozess mit wenig Unterstützung seitens der Hersteller (jeder schob den schwarzen Peter von sich). Am Ende nahm ich dann den NI-Adapter. Vielleicht gibt es ähnliche Geschichten mit anderen Adaptern und anderer Software. auch wessen Zeit nicht kostenlos ist kann reinfallen. Das wurde mir damals schmerzlich klar.
Ich haett noch die Hardware fuer einen GPIB nach Serial Umsetzer. Mit einem Mega644. Ohne Code allerdings. Das Statediagram fuer GPIB ist eher kompliziert.
Megatroll schrieb: > Das Statediagram fuer GPIB ist eher kompliziert. Code gibt es ja von diversen Autoren. Vermutlich lässt sich der Code von Casagrande anpassen. Man müsste das näher ansehen. keine Ahnung ob man Statediagramme umsetzen muss um froh zu werden. Manche Software sieht recht einfach aus.
Ein Link auf ein anderes Projekt: https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/?PHPSESSID=06khs3r2kjldnja7rm9aqg6sq1 Die letzten Programmversionen sind so ab Seite 5 zu finden (habe ich nicht extra nachgesehen). Bustreiber werden nicht verwendet, was den Nutzen einschränken kann. Aber vielleicht kann es jemand mal gebrauchen.
m.n. schrieb: > Ein Link auf ein anderes Projekt: vielen Dank ! das zeigt dass noch Leben im Thema GPIB steckt. "Last year I also decided to write my own GPIB controller software for the Arduino (when I bought an HP-3478A). It worked.." "For the last 4 months or so, I have been working on an updated GPIB firmware for the Arduino." "My updated sketch implements the same pin assignment scheme, but the sketch is an almost complete re-write of Emanuele's original code with the remaining controller functions now implemented. SRQ and REN lines are now fully supported and device mode has also been added." das wird der ino-Code sein: https://github.com/Twilight-Logic/AR488 "AR488 is Licenced under the GNU Public licence." manche lehnen sich an Prologix an: "the use of the (quasi standard) Prologix command syntax.." "I tried it with an Atmega328p NANO board. It works OK if I don't use ++auto command." "Plugged the Uno into a USB port, uploaded the sketch, connected via 'screen' and it just worked." ist die Frage mit welcher Hardware man ggf. testen möchte wenn man es denn möchte.
Man muss da zwei Szenarien unterscheiden. Busse mit allen Geräten Aktiv (incl high speed bus) und busse wo Geräte am Bus hängen, aber abgeschaltet sind. Die Erhöhte Treiberleistung ist eigentlich nur wegen der abgeschalteten Geräte nötig. Wenn man wie bei High speed bus per definition das Abschalten der Geräte verbietet, dann genügt auch ein normaler uC ohne Treiber IC. Ein low power interface schafft maximal 4 Geräte, wobei PIC besser als AVR abschneided. Wenn genug Pins da sind, kann man SN75ALS165 sowie SN75ALS161 verwenden, vorteil
Falls wirklich noch jemand unbedingt einen USB GPIB Adapter oder eine GPIB Karte braucht hätte ich einen Tipp. Anstatt NI nehme ich immer die von ADLink. Die kosten nur die Hälfte und der Treiber ist nur paar MB groß und ist wirklich nur ein GPIB Treiber.
Wäre es nicht sinnvoll, das ganze Protokoll usw. in einem FPGA zu realisieren? Dann als Anbindung an den Mikrocontroller eine schöne SPI-Schnittstelle und vielleicht noch eine Interrupt-Leitung? Dann hätte man ein schönes FIFO usw. im FPGA und müsste sich um den ganzen Bus gar nicht mehr kümmern.
Nein, SPI ist nicht gut. Serial. Ein controller ist passender wie ein FPGA, flexibler. Denn sinnvollerweise macht man das Trivale auch gleich da rein. Wie zB UNLISTEN ALL LISTEN 29 Das Mehrfachadressieren benoetigt eigentlich niemand, dabei war's eine gute Idee fuer mehrere gleiche Einheiten, die sich nur um einem Parameter unterscheiden. Aber wer hat heute noch Tuerme von diesen Einheiten.
chris schrieb: > Busse mit allen Geräten Aktiv (incl high speed bus) und busse wo Geräte > am Bus hängen, aber abgeschaltet sind. ja Chris. > Die Erhöhte Treiberleistung ist > eigentlich nur wegen der abgeschalteten Geräte nötig. nicht nur. Denn selbst wenn alle Geräte einschaltet sind - nehmen wir an 15 Stück - so ziehen 14 Empfangsgeräte den Bus nach oben. Da sind passive Busabschlüsse und/oder aktive Treiber. das eine Gerät das sich nun bemerkbar machen will muss den Bus runterziehen - gegen alle anderen eingeschalteten Geräte. es gibt Geräte die open collector-Ausgänge haben und welche die push/pull Stufen haben. Die Spec erlaubt diese Unterscheidung. > Wenn man wie bei High speed bus per definition das Abschalten der > Geräte verbietet, dann genügt auch ein normaler uC ohne Treiber IC. da bin ich mir nicht so sicher. Siehe die Spec. > Wenn genug Pins da sind, kann man SN75ALS165 http://www.ti.com/lit/ds/symlink/sn74als165.pdf wandelt 8bit parallel in seriell um. Das ist eher kein Treiber für Ausgänge. Vermutlich meinst Du ein anderes Teil. Vielleicht den SN75ALS162? > sowie SN75ALS161 verwenden der ist sparsamer als 75161, braucht aber noch immer 55-75mA Ruhestrom. Bei 2 solchen Bausteinen ist es das Doppelte. wirklich gut daran ist daß bei "Power off" der Bus nur mit max. 40uA pro Pin belastet wird.
... schrieb: > Anstatt NI nehme ich immer die > von ADLink. Die kosten nur die Hälfte und der Treiber ist nur paar MB > groß und ist wirklich nur ein GPIB Treiber. Danke für den Hinweis !
Michael schrieb: > Wäre es nicht sinnvoll, das ganze Protokoll usw. in einem FPGA zu > realisieren? gute Idee. Fragt sich halt wie man die bisherigen Funktionen anders/besser aufteilt. es gab ja - Treiberstrom low - Treiberstrom high - rasche Reaktion in ein paar 100ns auf bestimmten Pins - langsamere Abarbeitung dann im Folgechip die harte Echtzeit machte der Treiberchip 75160/75161/75162. das weitere Protokoll lief dann in den Spezialchips und im uC. es gibt ARM-CPUs mit FPGA-Teil.
Megatroll schrieb: > Ein controller ist passender wie ein > FPGA, flexibler. Denn sinnvollerweise macht man das Trivale auch gleich > da rein. ja. FPGA braucht man nur wenn man rascher reagieren muss die CPU das kann. Daher früher diese 3-Teilung aus schnellster Reaktion durch den Treiber, die Zustandsautomaten dann im Spezial-GPIB-Chip und der Rest (auch Triviales) in der CPU.
Der Quasi-Standard für die Heimwerker - USB-nach-Seriell - Lösungen ist der Prologix Gpib-USB-Controller 6.0. Dessen Befehlssatz wird ziemlich weit unterstützt, daher versuchen die meisten Eigenbauten dazu kompatibel zu sein. http://prologix.biz/gpib-usb-controller.html
soul e. schrieb: > daher versuchen die meisten Eigenbauten dazu > kompatibel zu sein. das klingt sinnvoll.
zur Info, das mit dem FPGA gibt es schon. Habe leider die URL nicht mehr parat. Im Anhang das komplette Projekt. Verwendet einen Xilinx-FPGA. VHDL-Code ist im Packet inkludiert. Markus
Es gibt auch ein paar Projekte für GPIB mit dem Raspberry: http://elektronomikon.org/2017/04/28/raspberry-pi-gpib-shield/ https://loetlabor-jena.de/doku.php?id=projekte:raspi_gpib_shield:start Das ist eher etwas für ein einzelnes Hobbyprojekt, bei mir wäre das die Ansteuerung eines alte HP-Spektrumanalyzers aus den frühen 90ern. Für NI und Raspi scheint auch etwas möglich: https://xdevs.com/guide/ni_gpib_rpi/
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > Es gibt auch ein paar Projekte für GPIB mit dem Raspberry: > http://elektronomikon.org/2017/04/28/raspberry-pi-gpib-shield/ vielen Dank Christoph, das sieht so aus als ob wieder 75160/75161 werkeln und seltsamerweise danach noch Abschlusswiderstände die wohl im Chip selbst schon sein sollten. zusätzlich werden hier die Pegel noch direkt von den GPIB-Pins zurückgelesen, also nicht über das Treiber-IC selbst zurückgelesen. So sieht es jedenfalls aus.
Christoph db1uq K. schrieb: > Für NI und Raspi scheint auch etwas möglich: > https://xdevs.com/guide/ni_gpib_rpi/ vielen Dank Christoph, das schaut auch sehr interessant aus. Man sieht das Innenleben des NI-Adapters.
soul e. schrieb: > Ein Klassiker: http://www.ke5fx.com/gpib/readme.htm ja. "The GPIB Toolkit is provided with full C++ source code for public- and private-sector, educational and Amateur Radio / hobbyist use. Comments and feedback are always welcome. John Miles, KE5FX "
mir ist zu den Treibern nicht alles so ganz klar. es gibt laut Spec. open collector Treiber und Tristate-Treiber. wenn man open collector-Treiber nutzt, so haben diese ja keine Treiberfähigkeit nach VCC. Damit bleibt nur der passive Busabschluss als Treiberhilfe Richtung VCC. open collector-Treiber gibt es auch beim I2C-Bus. Man sieht wie rund die Signale da sind wenn man 3.9kOhm gegen VCC als Arbeitswiderstand vorsieht. so richtig schnell ist I2C ja nicht wenn man 3.9kOhm nutzt. Die Flankensteilheit hängt stark auch von der Kapazität des Kabels ab. beim GPIB-Bus sind 20m Kabellänge einiges an Kapazität. Ich habe mir das nicht in einer Simulation angesehen. Auf dem Oszi sah der I2C unschön aus. Wie kann da GPIB schöner aussehen? wenn man Tristate-Treiber nutzt, so hilft der Treiber mit die Leitung nach oben zu treiben. Nur müssen ggf. andere Busteilnehmer in der Lage sein gegen die aktiv nach high treibenden Treiber den Bus nach low zu ziehen. da der Bus ja funktioniert muss eine brauchbare Lösung umgesetzt worden sein. Eben dies muss man bei der Umsetzung ggf. beachten.
Matthias W. schrieb: > was treibt Menschen dazu selbst Projekte wie die oberen anzugehen Sie haben ein altes GPIB Gerät und wollen es fernbedienen ohne megateure NI Karten/Software.
Matthias W. schrieb: > es gibt laut Spec. open collector Treiber und Tristate-Treiber. Open Collector für die Steuerleitungen, da diese wired-or sind. Die werden von allen Geräten gleichzeitig aktiviert und jeweils losgelassen wenn das jeweilige Gerät soweit ist. Wenn kein Gerät mehr zugreift liegt der Ruhepegel an. Tristate ist für die Datenleitungen. Die werden stets nur von einem Teilnehmer getrieben und die anderen sind hochohmig bzw Eingang. Naja, fast. Beim parallel poll sind die Datenleitungen auch open collector und jedes Bit ist einem Gerät zugeordnet. So kann der Master mit einem Zugriff die Fehlerstati von acht Geräten prüfen. Dieser Betriebszustand ist aber quasi ausgestorben.
MaWin schrieb: > und wollen es fernbedienen ohne megateure > NI Karten/Software. ja. Dazu gibt es ja mittlerweile eine Menge Positiv-Beispiele daß so etwas gut möglich ist. Offenbar braucht eine keine Monster-Software dazu. Auch wenn die einfachen Lösungen nicht genau der Spec entsprechen.
soul e. schrieb: > Open Collector für die Steuerleitungen, da diese wired-or sind. Die > werden von allen Geräten gleichzeitig aktiviert und jeweils losgelassen > wenn das jeweilige Gerät soweit ist. > Wenn kein Gerät mehr zugreift liegt der Ruhepegel an. Danke ! das heißt daß ggf. 14 Geräte auf 20m Bus verteilt high sein können und eines zieht dann den Bus aktiv herunter. umgekehrt muss beim loslassen der Bus wieder rasch nach oben gezogen werden. wie es scheint gibt es eine Unterscheidung zwischen OC und Tristate-Treibern in der Spec. Man kann es wohl so oder so machen. Der Unterschied könnte unterschiedliche Flankensteilheiten umd damit erreichbare Busgeschwindigkeiten bedeutet.
Matthias W. schrieb: > wie es scheint gibt es eine Unterscheidung zwischen OC und > Tristate-Treibern in der Spec. Man kann es wohl so oder so machen. Der > Unterschied könnte unterschiedliche Flankensteilheiten umd damit > erreichbare Busgeschwindigkeiten bedeutet. Nein. Das hängt explitzit von der Funktion der Leitung ab. Für NDAC, NRFD und SRQ nimmt man OC, für DAV, EOI, ATN, REN, IFC und die Datenleitungen TS. Den DS75160A kann man von TS auf OC umschalten für Parallel Poll (Pin PE).
soul e. schrieb: > Nein. unter 2.8. Electrical Aspects (Tutorial Description) steht zu Driver Types: - "open collector only" SRQ, NRFD, NDAC - "open collector oder Tristate" ATN, IFC, REN, EOI, DAV, DIO1-8 demnach sind nicht alle Steuerleitungen immer open collector. Auf den Typenschildern der Geräte steht ggf. was im Gerät umgesetzt ist. Es kann da stehen SH1, AH1, T6 usw. Dahinter kann stehen E1 (open collector Treiber) oder E2 (Tristate-Treiber im Datenmode). das "E" bedeutet Driver Electronics wobei sich dies dann wohl auf ATN, IFC, REN, EOI, DAV und DIO1-8 bezieht. die 48mA Sink gelten für Tristate oder open collector. und die 5.2mA Source nur für Tristate. Bei open collector ist ja wohl kein extra Treiber nach VCC da - außer dem Busabschluss. bei den Bildern im Standard 488.1-1987 11.6.1987, 2.2.1988 S.75 sind open collector Treiber gezeigt (für NRFD, NDAC, SRQ).
soul e. schrieb: > Den DS75160A kann man von TS auf OC umschalten für Parallel Poll (Pin > PE). http://www.ti.com/lit/ds/symlink/sn75160b.pdf PE heißt vielleicht Pullup Enable?
Matthias W. schrieb: > PE heißt vielleicht Pullup Enable? Exakt. Die sind enabled im Tristate-Mode (als Datenleitungen) und disabled für Parallel Poll. Das ist der Betriebsfall wo man open collector braucht. Da zieht jedes Gerät bei Bedarf sein Datenbit auf Low, und der Controller liest dann das veroderte Ergebnis ein. In dem Schaltplan oben rechts auf Seite 3 ist ja der wegschaltbare Highside-Transistor gut zu erkennen. Der Baustein für die Steuerleitungen https://www.ti.com/lit/ds/symlink/sn75162b.pdf hat kein PE, da ist der Ausgangstyp fest zugeordnet. Was hast Du denn jetzt eigentlich vor? DS75160A/161A sind für genau diese Anwendung vorgesehen und leicht zu beschaffen. Notfalls kann man sie sogar von einer alten ISA-Karte runterlöten. Da ist dann auch gleich der passende Stecker dabei. Ein GPIB-Controller lässt sich auch mit normalen 74LS245 (besser LS645) aufbauen. Die Signale, bei denen Open Collector obligatorisch ist, werden von den Geräten bedient und vom Controller gelesen. Im Netz findet man sogar Projekte wo die Arduino-Pins direkt auf den Bus gehen. Das scheint also (bei kurzer Leitungslänge) auch noch zu funktionieren. (LS ist hier besser als HCT, weil bei HCT ein High-Pegel am Eingang bei abgeschalteter VDD zu Fremdspeisung führt)
soul e. schrieb: > DS75160A/161A sind für genau > diese Anwendung vorgesehen und leicht zu beschaffen. Wo gibt man die denn neu?
m.n. schrieb: > soul e. schrieb: >> DS75160A/161A sind für genau >> diese Anwendung vorgesehen und leicht zu beschaffen. > > Wo gibt man die denn neu? https://www.digikey.de/product-detail/de/texas-instruments/SN75160BDW/296-6844-5-ND/370216 https://www.digikey.de/product-detail/de/texas-instruments/SN75161BDW/296-6846-5-ND/370218
soul e. schrieb: > Was hast Du denn jetzt eigentlich vor? DS75160A/161A sind für genau > diese Anwendung vorgesehen und leicht zu beschaffen. ja. mit dem Nachteil des hohen Ruhestrombedarfs - siehe oben. > Ein GPIB-Controller lässt sich auch mit normalen 74LS245 (besser LS645) > aufbauen. ja. LS245 sind schnell, Tristate, PNP Inputs Reduce DC Loading on Bus Lines. nur eben passen sie nicht so gut zu dem was oben gefordert wird wie 5.2mA high und 48mA low. Im Datenblatt steht 12mA high, das ist viel mehr und kann ggf. Probleme machen wenn andere das dann runterziehen müssen. Für low stehen da 24mA, das ist die Hälfte von 48mA. > Im Netz > findet man sogar Projekte wo die Arduino-Pins direkt auf den Bus gehen. > Das scheint also (bei kurzer Leitungslänge) auch noch zu funktionieren. ja. Das heißt jedoch nicht daß es Spec-konform ist etwas so zu machen.
soul e. schrieb: > Ein GPIB-Controller lässt sich auch mit LS645 aufbauen. ja. http://www.ti.com/lit/ds/symlink/sn74ls641.pdf 74LS645-1 ist für 48mA sink ausgelegt. Damit passt das. Hysterese an den Bus-Eingängen passt auch. der High-level output current liegt mit 15mA zu hoch. der Betriebsstrom liegt mit 48-95mA hoch. Ist damit kein großer Vorteil gegenüber den Originaltreibern.
:
Bearbeitet durch User
Matthias W. schrieb: > nur eben passen sie nicht so gut zu dem was oben gefordert wird wie > 5.2mA high und 48mA low. Natürlich. Das sind Frickellösungen, die bei Bastlern meist funktioniert haben. Kein Ersatz für die normgerechten Treiber. Aber wer die nicht einsetzen will oder kann muss halt Einschränkungen in Kauf nehmen. Für eine professionelle Lösung nimmt man 75160/161 und fertig. Dafür gibts die ja.
soul e. schrieb: > Für eine professionelle Lösung nimmt man 75160/161 und fertig. Dafür > gibts die ja. mit den bekannten Nachteilen wie uralt, hoher Ruhe-Stromverbrauch. seltsamerweise gibt es sogar von einer Uni Wien ein Projekt wo neben die alten 75160/161 noch zusätzlich Bus-Abschlusswiderstände 3k/6.2k angebaut werden. ist das denn sinnvoll/nötig? im Datenblatt des DS75160A/DS75161A steht: "on chip bus terminators". "The IEEE488 required bus termination is provided internally with an active turn off feature which disconnects the termination from the bus when VCC is removed." ist dies denn nur bei DS75160A/DS75161A so gewesen - oder auch bei den sonst üblichen 75160/161?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.