Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #208542 > unrolled thread
| Started by | R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) |
|---|---|
| First post | 2016-05-26 01:16 +0200 |
| Last post | 2016-06-03 10:07 +0200 |
| Articles | 20 on this page of 90 — 24 participants |
Back to article view | Back to de.sci.electronics
Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-05-26 01:16 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-05-25 17:12 -0700
Re: Analoge Frage in der Digitaltechnik Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-05-26 07:24 +0200
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-05-26 11:50 +0200
Re: Analoge Frage in der Digitaltechnik Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-05-26 12:14 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-05-26 07:29 -0700
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-05-26 23:49 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-05-26 15:00 -0700
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-05-27 00:47 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-05-26 16:33 -0700
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-05-27 02:28 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-05-26 18:07 -0700
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-05-27 10:43 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-05-27 07:47 -0700
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-05-28 00:07 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-05-27 15:51 -0700
Re: Analoge Frage in der Digitaltechnik Michael Baeuerle <michael.baeuerle@stz-e.de> - 2016-05-27 10:36 +0200
Re: Analoge Frage in der Digitaltechnik Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-05-27 13:40 +0200
Re: Analoge Frage in der Digitaltechnik horejsi <wolfgang@horejsi.de> - 2016-05-27 08:04 +0200
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-05-26 11:28 +0200
Re: Analoge Frage in der Digitaltechnik Rafael Deliano <rafael_deliano@arcor.de> - 2016-05-26 12:03 +0200
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-05-26 13:09 +0200
Re: Analoge Frage in der Digitaltechnik Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-05-26 13:42 +0200
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-05-26 14:38 +0200
Re: Analoge Frage in der Digitaltechnik Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-05-27 04:27 +0200
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-05-27 10:43 +0200
Re: Analoge Frage in der Digitaltechnik Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-05-27 14:47 +0200
Re: Analoge Frage in der Digitaltechnik Hanno Foest <hurga-news2@tigress.com> - 2016-05-27 15:08 +0200
Re: Analoge Frage in der Digitaltechnik Dieter Wiedmann <dieter.wiedmann@t-online.de> - 2016-05-27 17:08 +0200
Re: Analoge Frage in der Digitaltechnik Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-05-27 23:15 +0200
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-05-28 00:07 +0200
Re: Analoge Frage in der Digitaltechnik Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-05-29 18:52 +0000
Re: Analoge Frage in der Digitaltechnik usenet@mkarcher.dialup.fu-berlin.de (Michael Karcher) - 2016-05-29 21:09 +0000
Re: Analoge Frage in der Digitaltechnik Marcel Mueller <news.5.maazl@spamgourmet.org> - 2016-05-26 14:13 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-05-26 07:44 -0700
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-05-26 23:49 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-05-26 15:14 -0700
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-05-27 02:28 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-05-26 18:20 -0700
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-06-02 00:23 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-06-02 08:09 -0700
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-06-02 18:57 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-06-02 12:16 -0700
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-06-02 22:16 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-06-02 13:34 -0700
Re: Analoge Frage in der Digitaltechnik Eric Bruecklmeier <usenet@nerdcraft.de> - 2016-06-03 10:00 +0200
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-06-03 17:48 +0200
Re: Analoge Frage in der Digitaltechnik Eric Brücklmeier <usenet@nerdcraft.de> - 2016-06-03 18:08 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-06-03 10:50 -0700
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-06-03 22:51 +0200
Re: Analoge Frage in der Digitaltechnik Hanno Foest <hurga-news2@tigress.com> - 2016-06-04 05:13 +0200
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-06-04 11:43 +0200
Re: Analoge Frage in der Digitaltechnik Eric Brücklmeier <usenet@nerdcraft.de> - 2016-06-04 13:33 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-06-04 07:36 -0700
Re: Analoge Frage in der Digitaltechnik Myn Seudop <seudop@freenet.de> - 2016-06-04 06:50 +0000
Re: Analoge Frage in der Digitaltechnik Dieter Wiedmann <dieter.wiedmann@t-online.de> - 2016-06-04 14:16 +0200
Re: Analoge Frage in der Digitaltechnik R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-06-04 14:28 +0200
Re: Analoge Frage in der Digitaltechnik Michael Baeuerle <michael.baeuerle@stz-e.de> - 2016-06-02 18:37 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-06-02 12:17 -0700
Re: Analoge Frage in der Digitaltechnik Holger <me@privacy.org> - 2016-06-02 22:34 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-06-02 13:50 -0700
Re: Analoge Frage in der Digitaltechnik "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2016-06-03 08:49 +0200
Re: Analoge Frage in der Digitaltechnik Eric Bruecklmeier <usenet@nerdcraft.de> - 2016-06-03 09:52 +0200
Re: Analoge Frage in der Digitaltechnik Michael Welle <mwe012008@gmx.net> - 2016-06-03 11:00 +0200
Re: Analoge Frage in der Digitaltechnik Eric Brücklmeier <usenet@nerdcraft.de> - 2016-06-03 11:30 +0200
Re: Analoge Frage in der Digitaltechnik Michael Welle <mwe012008@gmx.net> - 2016-06-03 12:14 +0200
Re: Analoge Frage in der Digitaltechnik Eric Brücklmeier <usenet@nerdcraft.de> - 2016-06-03 12:17 +0200
Re: Analoge Frage in der Digitaltechnik Dieter Wiedmann <dieter.wiedmann@t-online.de> - 2016-06-03 12:52 +0200
Re: Analoge Frage in der Digitaltechnik Eric Brücklmeier <usenet@nerdcraft.de> - 2016-06-03 13:09 +0200
Re: Analoge Frage in der Digitaltechnik Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> - 2016-06-03 13:09 +0200
Re: Analoge Frage in der Digitaltechnik Eric Brücklmeier <usenet@nerdcraft.de> - 2016-06-03 13:10 +0200
Re: Analoge Frage in der Digitaltechnik "horst-d.winzler" <horst.d.winzler@web.de> - 2016-06-03 15:32 +0200
Re: Analoge Frage in der Digitaltechnik Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> - 2016-06-03 16:33 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-06-03 07:33 -0700
Re: Analoge Frage in der Digitaltechnik "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2016-06-03 13:33 +0200
Re: Analoge Frage in der Digitaltechnik Eric Brücklmeier <usenet@nerdcraft.de> - 2016-06-03 14:28 +0200
Re: Analoge Frage in der Digitaltechnik "horst-d.winzler" <horst.d.winzler@web.de> - 2016-06-03 15:15 +0200
Re: Analoge Frage in der Digitaltechnik "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2016-06-06 10:09 +0200
Re: Analoge Frage in der Digitaltechnik Eric Brücklmeier <usenet@nerdcraft.de> - 2016-06-06 10:22 +0200
Re: Analoge Frage in der Digitaltechnik "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2016-06-08 10:28 +0200
Re: Analoge Frage in der Digitaltechnik "horst-d.winzler" <horst.d.winzler@web.de> - 2016-06-06 10:52 +0200
Re: Analoge Frage in der Digitaltechnik all2001@spambog.com (Wolfgang Allinger) - 2016-06-06 07:40 -0300
Re: Analoge Frage in der Digitaltechnik Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-06-03 15:38 +0200
Re: Analoge Frage in der Digitaltechnik all2001@spambog.com (Wolfgang Allinger) - 2016-06-03 10:06 -0300
Re: Analoge Frage in der Digitaltechnik Edzard Egberts <ed_09@tantec.de> - 2016-06-03 16:20 +0200
Re: Analoge Frage in der Digitaltechnik Joerg <news@analogconsultants.com> - 2016-06-03 07:36 -0700
Re: Analoge Frage in der Digitaltechnik Andreas Barth <aba+nospam@not.so.argh.org> - 2016-06-03 16:46 +0000
Re: Analoge Frage in der Digitaltechnik "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2016-06-06 10:10 +0200
Re: Analoge Frage in der Digitaltechnik "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-06-03 07:29 +0000
Re: Analoge Frage in der Digitaltechnik Michael Baeuerle <michael.baeuerle@stz-e.de> - 2016-06-03 10:07 +0200
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Rafael Deliano <rafael_deliano@arcor.de> |
|---|---|
| Date | 2016-05-26 12:03 +0200 |
| Message-ID | <ni6hel$9c8$1@dont-email.me> |
| In reply to | #208555 |
> Da fehlt mir eindeutig das Wissen von damals. Das GAL Datenbuch ( Lattice ) und das PAL-Handbuch/Applikationsbuch ( MMI ) kann ich durchaus leihweise zur Verfügung stellen. Bezogen auf die Pinbelegung waren die eng festgelegt was Outputs sein durften. Vermutlich weil die Programmiergeräte der PALs das beschränkten. Bei Varianten ohne FlipFlops dürfte Auslesen recht unproblematisch sein. Aus dem Binärdump die Gleichungen zurückgewinnen wäre man eher in Software beschäftigt. "Registered" PALs waren auch recht eingeschränkt in dem was die FlipFlops konnten. Kniffelig wird es bei GALs da die FlipFlops potentiell Zustandsmaschinen ermöglichten. Und ein Copy Protection Bit das Auslesen verhindert. Offen natürlich ob das in Realität Problem ist: ich hätte vermutet daß 90% der GALs genau wie PALs als Adreßdecoder o.ä. verwendet wurden. MfG JRD
[toc] | [prev] | [next] | [standalone]
| From | R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) |
|---|---|
| Date | 2016-05-26 13:09 +0200 |
| Message-ID | <1mnuvin.1434lc91x1oehmN%R.Kiefer.SPAEM@gmx.de> |
| In reply to | #208557 |
Rafael Deliano wrote: > > Da fehlt mir eindeutig das Wissen von damals. > > Das GAL Datenbuch ( Lattice ) und das PAL-Handbuch/Applikationsbuch > ( MMI ) kann ich durchaus leihweise zur Verfügung stellen. Danke fürs Angebot. Bei den Bitsavers finden sich ein paar Bücher, z.B. von AMD und MMI. Mein Hintergrund ist der, daß ich damals zwar einige solcher Teile mit logischem Inhalt versehen hatte, mich aber nie um die Beschaltung gekümmert hatte, und die analoge Welt nicht meine ist :-( Soll heißen: der Stromlaufplan war genauso vorhanden wie die Schaltung, und mit Log/IC von Isdata hatte ich ein wenig gespielt. > Bezogen auf die Pinbelegung waren die eng festgelegt was > Outputs sein durften. Bei den PALs steht's quasi im Name, wie sich die Beinchen verhalten. > Bei Varianten ohne FlipFlops dürfte Auslesen recht > unproblematisch sein. Aus dem Binärdump die Gleichungen > zurückgewinnen wäre man eher in Software beschäftigt. Das soll der Probelauf werden :-) Kategorie: trivial. > Offen natürlich ob das > in Realität Problem ist: ich hätte vermutet daß > 90% der GALs genau wie PALs als Adreßdecoder o.ä. > verwendet wurden. Ich kenne die häufig als State Machines für DRAM-Timing (RAS, CAS, Refresh) oder in 68k-Schaltungen für die DTACK-Generierung. Mein damaliger Kollege "nebenan" baute mit ein paar GALs das DRAM als dual-ported am VMEbus, usw. Das lief alles mit Registerfunktionen und State Machines. Mein wesentliches Problem ist hier die analoge Welt zwischen den GPIOs und den Beinchen der zu testenden PALs, GALs, PROMs wie z.B. 82Sxxx, usw.. Ggf. muß ich mir diese variabel/konfigurierbar/austauschbar bauen, oder gleich unterschiedliche Adapter für die Targets bauen. Gruß, Ralf
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2016-05-26 13:42 +0200 |
| Message-ID | <dqo5qcFg703U1@mid.individual.net> |
| In reply to | #208561 |
Ralf Kiefer schrieb: > Mein wesentliches Problem ist hier die analoge Welt zwischen den GPIOs > und den Beinchen der zu testenden PALs, GALs, PROMs wie z.B. 82Sxxx, > usw.. Ggf. muß ich mir diese variabel/konfigurierbar/austauschbar bauen, > oder gleich unterschiedliche Adapter für die Targets bauen. Ich weiß gerade nicht, ob die Targets ggf. auch open-collector oder tristate Ausgänge haben könenn, oder wahlweise als Ein-/Ausgänge schaltbar sein könnten (bidirektionale Bus-Anschlüsse). Für einen ganz komfortablen Tester wären dann 2 GPIO Ausgänge hilfreich, mit denen die Eingangsspannungen zwischen 0, Vcc, Vcc/2 und offen geschaltet werden können. Dazu Komparatoren für die logischen Pegel an den Pins (low-undefined-high). Die 0,5/4mA Angaben erinnern mich an TTL-Kompatibilität, weil solche Eingänge im Low Zustand mehr Strom ziehen als bei High. Dafür könnte ggf. eine Kombination von 2 Widerständen und einer Diode für die Nachbildung der Last verwendet werden, damit im Low Zustand mehr Strom gezogen werden kann als bei High. Oder 2 GPIO Ausgänge mit unterschiedlichen Widerständen (s.o.). Für die Prüfung der internen Logik sollte je 1 genügend großer Widerstand ausreichen. Nur die Feststellung, was Eingang und was Ausgang ist, kann mehr Aufwand erfordern. Bei meinem TTL-Tester habe ich den Strom gegen 0 gemessen, um Eingänge von Ausgängen zu unterscheiden. Etwa 1,6mA war ein typischer TTL-Eingang, deutlich mehr oder weniger war ein Ausgang. Bei MOS fällt mir aber keine so einfache Testmethode ein. DoDi
[toc] | [prev] | [next] | [standalone]
| From | R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) |
|---|---|
| Date | 2016-05-26 14:38 +0200 |
| Message-ID | <1mnv0u5.p0wh40upydg2N%R.Kiefer.SPAEM@gmx.de> |
| In reply to | #208564 |
Hans-Peter Diettrich wrote: > Ich weiß gerade nicht, ob die Targets ggf. auch open-collector Hatte ich (bisher) nicht vorgesehen. Das sollte bei PALs, GALs und PROMs z.B. aus der 82Sxxx-Gattung nicht vorkommen, AFAIR. > oder tristate Ausgänge haben könenn, Die will ich per Software zunächst als Eingänge betrachten, bis das Gegenteil erkennbar ist. D.h. kein weiterer Aufwand in Hardware nötig. > oder wahlweise als Ein-/Ausgänge > schaltbar sein könnten (bidirektionale Bus-Anschlüsse). Diesen Fall habe ich mit obiger Vorgehensweise ebenfalls abgedeckt. > Für einen ganz > komfortablen Tester wären dann 2 GPIO Ausgänge hilfreich, mit denen die > Eingangsspannungen zwischen 0, Vcc, Vcc/2 und offen geschaltet werden > können. Low, High und offen/tristate kann ich mit einem GPIO von einem Portbaustein zum Anregen und einem GPIO zum Beobachten abdecken, wie in meinem ersten Posting oben hingemalt. Soll heißen: erkennt die Auswertung an einem Target-Beinchen einen Ausgang, geht der Portbaustein auf Eingang und stört nicht mehr weiter, indem er gegen den Target-Ausgang treibt. BTW ein Vorteil der Variante ohne die Optokoppler. VCC/2 hatte ich bisher nicht vorgesehen. Welchen Gewinn ziehe ich daraus? Ist das Target-Beinchen dauerhaft ein Ausgang, nutzt das nix. Ist das Target-Beinchen mit einem Enable versehen, d.h. zeitweilig tristate, kann ich das prüfen, indem ich an meinem GPIO-Ausgang wackle und ausschließlich mein eigenes Wackeln sehe. Ist das Target-Beinchen ein Eingang, gilt dasselbe wie für den Tristate-Ausgang. Habe ich was übersehen? Vermutlich bei Betrachtung von analogen Effekten ... > Dazu Komparatoren für die logischen Pegel an den Pins > (low-undefined-high). Na gut, als Steigerung nehme ich sehr viele AD-Wandler. So aufwendig sollte das nicht werden. > Oder 2 GPIO Ausgänge mit > unterschiedlichen Widerständen (s.o.). Diese Idee halte ich mal fest :-) > Bei meinem TTL-Tester habe ich den Strom gegen 0 gemessen, um Eingänge > von Ausgängen zu unterscheiden. Etwa 1,6mA war ein typischer > TTL-Eingang, deutlich mehr oder weniger war ein Ausgang. Bei MOS fällt > mir aber keine so einfache Testmethode ein. Das ist ein analoger Ansatz. Ich wollte den digitalen nehmen, wenn möglich. Gruß, Ralf
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2016-05-27 04:27 +0200 |
| Message-ID | <dqpqs3Fqgq0U1@mid.individual.net> |
| In reply to | #208567 |
Ralf Kiefer schrieb: > Hans-Peter Diettrich wrote: >> Für einen ganz >> komfortablen Tester wären dann 2 GPIO Ausgänge hilfreich, mit denen die >> Eingangsspannungen zwischen 0, Vcc, Vcc/2 und offen geschaltet werden >> können. >> Dazu Komparatoren für die logischen Pegel an den Pins >> (low-undefined-high). > > Na gut, als Steigerung nehme ich sehr viele AD-Wandler. So aufwendig > sollte das nicht werden. Ich befürchte Probleme mit den verschiedenen Logik-Familien, die unterschiedliche Lasten als Eingänge und unterschiedliche Ströme als Ausgänge haben können. Ich würde da ggf. mit mehreren Adaptern arbeiten, die an die verschiedenen Familien angepaßt sind. Die Komparatoren hätten den Vorteil gegenüber AD-Wandlern, daß sie während des Tests keine Wandlungszeit brauchen. Die Schwellen lassen sich einheitlich einstellen lassen, d.h. die Schaltschwellen müßten nur einmal (per DAC) einstellbar gemacht werden. >> Bei meinem TTL-Tester habe ich den Strom gegen 0 gemessen, um Eingänge >> von Ausgängen zu unterscheiden. Etwa 1,6mA war ein typischer >> TTL-Eingang, deutlich mehr oder weniger war ein Ausgang. Bei MOS fällt >> mir aber keine so einfache Testmethode ein. > > Das ist ein analoger Ansatz. Ich wollte den digitalen nehmen, wenn > möglich. Das war auch nur die Vorauswahl, zur Feststellung der Pinbelegung. Daraus konnte ich mit einiger Treffsicherheit auch exotische TTL Typen erkennen, ohne die Logik der Chips zu testen. Das war notwendig, um falsch oder garnicht gestempelte Chips zu erkennen, die beim Test des Herstellers durchgefallen waren. Einen Rechner oder GPIO Bausteine, mit denen ein programmierter Test möglich gewesen wäre, mußte ich ja aus den getesteten IC erst noch aufbauen (~1970). Ein allererster Test galt allerdings den Gnd/Vcc Pins, die waren ja nicht immer einheitlich (diagonal) angeordnet. Danach kam dann der Vergleich mit einem Baustein des entsprechenden Typs. Dafür hatte ich je zwei Fassungen, deren Pins über XOR Gatter und LED verglichen wurden. Trat beim Durchsteppen ein Unterschied auf, blieb der Signalgenerator stehen, so daß der defekte/abweichende Pin gleich erkennbar war. Diesen Pin konnte ich dann per Schalter ausblenden und weitertesten. Der Signalgenerator war ein einfacher Zähler, der über einen Adapter mit den Eingängen der IC verbunden wurde. Dabei war es wichtig, Taktsignale schneller wechseln zu lassen als J/K, und die wieder schneller als CLR. Ich bin schon gespannt, wie Du z.B. einen Zähler oder ein Schieberegister erkennen möchtest, ohne vorher deren Takteingang zu kennen. Mit meinem ersten Arduino dachte ich auch schon an eine Neuauflage meines IC-Testers, sah allerdings keinen Bedarf dafür, weil es ja kaum noch Produktionsausschuß zu kaufen gibt. Du scheinst jetzt aber Bedarf dafür zu haben - wozu eigentlich? DoDi
[toc] | [prev] | [next] | [standalone]
| From | R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) |
|---|---|
| Date | 2016-05-27 10:43 +0200 |
| Message-ID | <1mnwizj.s4rkllhbkt34N%R.Kiefer.SPAEM@gmx.de> |
| In reply to | #208588 |
Hans-Peter Diettrich wrote: > Ich befürchte Probleme mit den verschiedenen Logik-Familien, die > unterschiedliche Lasten als Eingänge und unterschiedliche Ströme als > Ausgänge haben können. Diese Aufgabe hatte ich gedanklich lange erfolgreich verdrängt. Ich hielt die Beschaffung der Daten vom "Spielen" mit dem Baustein für die Fleißaufgabe und das Extrahieren der Muster für die Herausforderung, insbesondere das mit State Machines. > Ich würde da ggf. mit mehreren Adaptern arbeiten, > die an die verschiedenen Familien angepaßt sind. Darauf könnte es hinauslaufen, wenn ich viele Familien abdecken möchte. Meine Priorität liegt bei den üblichen PALs und GALs, wie sie in den Rechnern der 1980er bis 1990er Jahre eingesetzt waren. Damit hast Du bereits die Antwort auf Deine Frage vom Schluß: es gilt alte Rechner zu erhalten. Standard-Gatter, egal ob 74xx, 40xx o.a., kann ich nachkaufen, wenn was kaputt ist. Aber PALs oder GALs? Also Inhalt retten, solange die Teile leben. Konkret: ich habe hier VMEbus-Karten, bei denen diese Bauteile thermisch stark beansprucht waren (braun verfärbte, ehemals weiße Aufkleber). Einzelne Karten sind "damals" schon abgeraucht. Meine Vermutung: die braun verfärbten Aufkleber könnten der entscheidente Hinweis sein. Interessanterweise fallen mir dabei als erstes VMEbus-Karten von Radstone ein, die ansonsten seinerzeit mit derselben Technik Militär und Luftfahrt ausgestattet hatten. Ok, sagte ich mir damals: so eine Karte in einer Pershing 2 braucht nicht lange laufen. Ab und zu mal ein Testlauf, und anschließend ein max. einstündiger Einsatz bis zum finalen Ende. Bei uns liefen die Karten dagegen rund um die Uhr, Monate, Jahre, häufig sogar ohne Neustart. > Die Komparatoren hätten > den Vorteil gegenüber AD-Wandlern, daß sie während des Tests keine > Wandlungszeit brauchen. Die Schwellen lassen sich einheitlich einstellen > lassen, d.h. die Schaltschwellen müßten nur einmal (per DAC) einstellbar > gemacht werden. Das wird ein Riesenaufwand und läuft auf ein Platinendesign hinaus. Ob mir dazu die Motivation reicht? > Das war auch nur die Vorauswahl, zur Feststellung der Pinbelegung. > Daraus konnte ich mit einiger Treffsicherheit auch exotische TTL Typen > erkennen, ohne die Logik der Chips zu testen. Das war notwendig, um > falsch oder garnicht gestempelte Chips zu erkennen, die beim Test des > Herstellers durchgefallen waren. Einen Rechner oder GPIO Bausteine, mit > denen ein programmierter Test möglich gewesen wäre, mußte ich ja aus den > getesteten IC erst noch aufbauen (~1970). Ein allererster Test galt > allerdings den Gnd/Vcc Pins, die waren ja nicht immer einheitlich > (diagonal) angeordnet. Dein Ansatz war viel weitergehender. Ich gehe davon aus, daß der Chip, den ich dokumentieren möchte, erstens funktioniert, zweitens Vcc und GND bekannt sind, weil ich das dem Layout der Wirtsplatine oder durch Durchklingeln rausfinden kann. Und: wenn da z.B. 16R8 draufsteht, wird eher nicht was anderes drin sein. Also weiß ich bei so einem Typ, wo mich Eingänge, Ausgänge, I/O oder mögliche Takteinspeisung erwarten. > Du scheinst jetzt aber Bedarf >dafür zu haben - wozu eigentlich? Zweitnutzen: ich entnehme einem alten Rechner einen Standardbaustein mit dem Verdacht, daß der "durchgebrannt" ist. Dann könnte ich den kurz in "meinen Apparat" stecken, und ich erhalte nach kurzem Test das Ergebnis, daß sich der Probant wie das verhält, was aufgedruckt ist, also z.B ein 74xx. Fehlerfreiheit kann ich damit nicht attestieren, aber grobe Fehler erkennen. Gruß, Ralf
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2016-05-27 14:47 +0200 |
| Message-ID | <dqque1F2pldU2@mid.individual.net> |
| In reply to | #208595 |
Ralf Kiefer schrieb: > Hans-Peter Diettrich wrote: > >> Ich befürchte Probleme mit den verschiedenen Logik-Familien, die >> unterschiedliche Lasten als Eingänge und unterschiedliche Ströme als >> Ausgänge haben können. > > Diese Aufgabe hatte ich gedanklich lange erfolgreich verdrängt. Ich > hielt die Beschaffung der Daten vom "Spielen" mit dem Baustein für die > Fleißaufgabe und das Extrahieren der Muster für die Herausforderung, > insbesondere das mit State Machines. Dann kommt Dir hoffentlich kein Busy Beaver unter ;-) [aber dafür fehlt then Chips wohl das genügend lange Band] So langsam reizt mich die Sache auch, selbst wenn ich keine passenden Chips habe. Aber dafür könnte ich ja einen zweiten Arduino benutzen, der die Logik simuliert. Das wird dann allerdings etwas langsam, da könnte man die ganze Analyse auch gleich auf einem PC simulieren... >> Ich würde da ggf. mit mehreren Adaptern arbeiten, >> die an die verschiedenen Familien angepaßt sind. > > Darauf könnte es hinauslaufen, wenn ich viele Familien abdecken möchte. > Meine Priorität liegt bei den üblichen PALs und GALs, wie sie in den > Rechnern der 1980er bis 1990er Jahre eingesetzt waren. Damit hast Du > bereits die Antwort auf Deine Frage vom Schluß: es gilt alte Rechner zu > erhalten. Hmmm, da könnte ich vielleicht noch ein paar Exemplare beisteuern. Allerdings nur Homecomputer, ohne VMEbus. Und mit PAL/GAL hatte ich selbst nie direkt zu tun, mir reichten für meine Rechner die Standard-Periperiechips ohne zusätzliche Bus-Elektronik. > Einzelne Karten sind "damals" schon abgeraucht. Meine > Vermutung: die braun verfärbten Aufkleber könnten der entscheidente > Hinweis sein. Ja. >> Die Komparatoren hätten >> den Vorteil gegenüber AD-Wandlern, daß sie während des Tests keine >> Wandlungszeit brauchen. Die Schwellen lassen sich einheitlich einstellen >> lassen, d.h. die Schaltschwellen müßten nur einmal (per DAC) einstellbar >> gemacht werden. > > Das wird ein Riesenaufwand und läuft auf ein Platinendesign hinaus. Ob > mir dazu die Motivation reicht? Das mußt Du wissen ;-) Ich hatte mal einen ganzen Stapel Platinen für Flash-ADC (4 Komparatoren), aber die dürften beim vorletzten Umzug untergegangen sein, zusammen mit meinen restlichen Gerätschaften und Bastelmaterial. > Dein Ansatz war viel weitergehender. Ich gehe davon aus, daß der Chip, > den ich dokumentieren möchte, erstens funktioniert, zweitens Vcc und GND > bekannt sind, weil ich das dem Layout der Wirtsplatine oder durch > Durchklingeln rausfinden kann. Und: wenn da z.B. 16R8 draufsteht, wird > eher nicht was anderes drin sein. Also weiß ich bei so einem Typ, wo > mich Eingänge, Ausgänge, I/O oder mögliche Takteinspeisung erwarten. Deshalb habe ich diesen Teil erst nachgereicht, mehr der Vollständigkeit halber. Den 16R8 habe ich mir mal oberflächlich angeschaut. Bei solchen PALs sollte es tatsächlich nicht so schwer sein, die Programmierung herauszubekommen. Hast Du auch schon mal daran gedacht, die Programmierung direkt auszulesen, oder ist das üblicherweise blockiert? Auf jeden Fall ist es hilfreich, wenn man das Innenleben kennt, da kann man für jeden Typ bzw. Familie ein entsprechend angepaßtes Testprogramm schreiben, mit Sonderbehandlung für die CLK, OE etc. Pins. > Zweitnutzen: ich entnehme einem alten Rechner einen Standardbaustein mit > dem Verdacht, daß der "durchgebrannt" ist. Dann könnte ich den kurz in > "meinen Apparat" stecken, und ich erhalte nach kurzem Test das Ergebnis, > daß sich der Probant wie das verhält, was aufgedruckt ist, also z.B ein > 74xx. Fehlerfreiheit kann ich damit nicht attestieren, aber grobe Fehler > erkennen. Hmm, bei gesockelten Bauteilen könnte das funktionieren. Andernfalls wird es schwierig, die Teile aus den (multilayer?) Platinen herauszubekommen, ohne die Durchkupferung zu beschädigen. Unsere Techniker haben dafür alle Pins abgezwickt und dann einzeln ausgelötet - der Chip war danach kaum wieder einzulöten, und schon garnicht in einen Testsockel zu stecken. Aber auf professionellen Platinen dürften die teuren bzw. speziellen Chips wohl alle gesockelt sein? DoDi
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2016-05-27 15:08 +0200 |
| Message-ID | <dqqv6aF2s6eU1@mid.individual.net> |
| In reply to | #208605 |
Am 27.05.2016 14:47 schrieb Hans-Peter Diettrich: > Hmm, bei gesockelten Bauteilen könnte das funktionieren. Andernfalls > wird es schwierig, die Teile aus den (multilayer?) Platinen > herauszubekommen, ohne die Durchkupferung zu beschädigen. Unsere > Techniker haben dafür alle Pins abgezwickt und dann einzeln ausgelötet - > der Chip war danach kaum wieder einzulöten, und schon garnicht in einen > Testsockel zu stecken. Das Auslöten sollte mit Heißluft kein Problem sein sofern die Pins nicht umgebogen sind. Es gab früher auch mal DIL-Entlötspitzen, mit denen man alle Pins gleichzeitig heiß machen konnte. Hanno
[toc] | [prev] | [next] | [standalone]
| From | Dieter Wiedmann <dieter.wiedmann@t-online.de> |
|---|---|
| Date | 2016-05-27 17:08 +0200 |
| Message-ID | <ni9ntj$q5p$1@gioia.aioe.org> |
| In reply to | #208606 |
Am 27.05.2016 15:08, schrieb Hanno Foest: > Es gab früher auch mal DIL-Entlötspitzen, mit denen man > alle Pins gleichzeitig heiß machen konnte. Gibts immer noch. Gruß Dieter
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2016-05-27 23:15 +0200 |
| Message-ID | <dqrs8sF8oo6U1@mid.individual.net> |
| In reply to | #208606 |
Hanno Foest schrieb: > Das Auslöten sollte mit Heißluft kein Problem sein sofern die Pins nicht > umgebogen sind. Es gab früher auch mal DIL-Entlötspitzen, mit denen man > alle Pins gleichzeitig heiß machen konnte. Das Problem sind die abgespreizten Pins der DILs, mit denen sich die IC vor dem Einlöten schon in der Platine festgehalten haben. Die reißen dann beim Auslöten gerne die Durchkontaktierung mit. DoDi
[toc] | [prev] | [next] | [standalone]
| From | R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) |
|---|---|
| Date | 2016-05-28 00:07 +0200 |
| Message-ID | <1mnxl3j.183bqn7maf8euN%R.Kiefer.SPAEM@gmx.de> |
| In reply to | #208605 |
Hans-Peter Diettrich wrote: > So langsam reizt mich die Sache auch, selbst wenn ich keine passenden > Chips habe. :-) > Aber dafür könnte ich ja einen zweiten Arduino benutzen, der > die Logik simuliert. Irgendwo lassen sich sicher ein paar alte PALs auftreiben ;-) "Damals" gab's meist eine kleine Schachtel neben dem Programmiergerät für die gehimmelten oder die obsoleten [1]. > Hmmm, da könnte ich vielleicht noch ein paar Exemplare beisteuern. > Allerdings nur Homecomputer, ohne VMEbus. Es ist ja wurscht, wo die PALs/GALs im Einsatz sind/waren. Im Apple //e hat's 1983 in der Großserie angefangen, AFAIR. In den ersten Mac-Baureihen (-/128/512/Plus) waren jeweils mehrere PALs auf der Hauptplatine. Viele c't-Projekte der 1980er Jahren lebten mit GALs. Usw. > Den 16R8 habe ich mir mal oberflächlich angeschaut. Bei solchen PALs > sollte es tatsächlich nicht so schwer sein, die Programmierung > herauszubekommen. Hast Du auch schon mal daran gedacht, die > Programmierung direkt auszulesen, oder ist das üblicherweise blockiert? Wenn die Fuses als Ausleseschutz nicht gebrannt wurden, geht das Auslesen. Dann ist die Sache natürlich trivial. Die Herausforderung sind die anderen, wo ich nur die Eingänge stimulieren kann und die Reaktion an den Ausgängen sehe. Genau darum geht's mir hier. Besonders interessant wird's beim Einsatz von State Machines. Ok, es gibt wohl noch andere Methoden an die Inhalte zu kommen ... > Auf jeden Fall ist es hilfreich, wenn man das Innenleben kennt, da kann > man für jeden Typ bzw. Familie ein entsprechend angepaßtes Testprogramm > schreiben, mit Sonderbehandlung für die CLK, OE etc. Pins. Klar. Bei einem PAL steht drauf, was mich erwartet. Bei einem GAL können sehr viele PAL-Typen emuliert sein, und ggf. noch darüberhinausgehende Funktionen drin sein. Die Wahl der GAL-Beinchen bietet erheblich mehr Spielraum. > Hmm, bei gesockelten Bauteilen könnte das funktionieren. PALs und GALs wurden häufig gesockelt, einfache Logik eher seltener. Auslöten kann funktionieren, wenn man den Chip wieder einlöten möchte/muß. Es gibt auch Situationen, wo ein verdächtiger Baustein bereits hilft, wenn man nach dem beinchenzerstörenden Auslöten definitiv weiß, daß dessen Innenleben kaputt war, weil dann der Fehler gefunden ist. > Aber auf professionellen Platinen dürften die > teuren bzw. speziellen Chips wohl alle gesockelt sein? Nicht unbedingt. Bei Platinen im Käfig kann es durchaus Fälle geben, wo die Höhe ausschlaggebend ist und die Chips in der unteren Etage gelötet werden müssen, damit die zweite Lage noch drüber paßt und nicht die maximale Höhe verletzt. Ich kenne (VMEbus-)Karten, bei denen unter den EPROMs oder unter Portbausteinen schmale TTLs oder die V.28-Leitungstreiber sitzen, um Platinenfläche zu sparen. Es kann billiger sein 12 Lagen Multilayer zu nehmen als die Funktion auf eine zweite Karte auslagern zu müssen. Bei den Karten aus meiner damaligen Firma gab's welche, bei denen wir bedarfsweise sogar die Chips der unteren Etage "ebenerdig" gesockelt hatten. Etwas größere Löcher und dort pinweise die Einlötsockel rein. Das geht, kostete aber einen "kleinen" Aufpreis beim Bestücken. Gruß, Ralf [1] Geschichte aus der Studentenzeit, d.h. als Hiwi in einer solchen Umgebung: man nehme Chips aus dieser Schachtel, am besten EPROMs mit Fenster, dann alle Beinchen der linken Seite zusammenbiegen und -löten, dann der rechten Seite, anschließend links die braune Ader dran, rechts die blaue Ader vom dreipoligen Kabel und ab in die Steckdose damit. Äh, ja, ein paar Meter Abstand sind empfohlen :-) Für die heutige Jugend (nicht schlimm, es ist gerade nach 22Uhr, die Jugendlichen sind nicht mehr im Netz): don't try this @home!
[toc] | [prev] | [next] | [standalone]
| From | Michael Schwingen <news-1457978346@discworld.dascon.de> |
|---|---|
| Date | 2016-05-29 18:52 +0000 |
| Message-ID | <slrnnkmejg.485.news-1457978346@a-tuin.ms.intern> |
| In reply to | #208567 |
On 2016-05-26, Ralf Kiefer <R.Kiefer.SPAEM@gmx.de> wrote: > >> Ich weiß gerade nicht, ob die Targets ggf. auch open-collector > > Hatte ich (bisher) nicht vorgesehen. Das sollte bei PALs, GALs und PROMs > z.B. aus der 82Sxxx-Gattung nicht vorkommen, AFAIR. Wenn ich das richtig sehe, kannst Du schon beim GAL16V8 den Output-Enable nicht nur global, sondern intern per Logik pro Pin steuern - dann hast Du bidirektional bzw. OC zu berücksichtigen. cu Michael
[toc] | [prev] | [next] | [standalone]
| From | usenet@mkarcher.dialup.fu-berlin.de (Michael Karcher) |
|---|---|
| Date | 2016-05-29 21:09 +0000 |
| Message-ID | <dr1448Fa0c3U1@mid.uni-berlin.de> |
| In reply to | #208672 |
Michael Schwingen <news-1457978346@discworld.dascon.de> wrote: > > Hatte ich (bisher) nicht vorgesehen. Das sollte bei PALs, GALs und PROMs > > z.B. aus der 82Sxxx-Gattung nicht vorkommen, AFAIR. > Wenn ich das richtig sehe, kannst Du schon beim GAL16V8 den Output-Enable > nicht nur global, sondern intern per Logik pro Pin steuern - dann hast > Du bidirektional bzw. OC zu berücksichtigen. Nicht erst bei GALs, und nicht erst in der "V"ersatile-Familie. Selbst der PAL16L8 zieht für seine 8 Output-fähigen Pins (6 devon sind I/O) jeweils ein eigenes Output-Enable-Signal aus der Matrix. Gruß, Michael Karcher
[toc] | [prev] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2016-05-26 14:13 +0200 |
| Message-ID | <ni6p98$nol$1@gwaiyur.mb-net.net> |
| In reply to | #208557 |
On 26.05.16 12.03, Rafael Deliano wrote: > Kniffelig wird es bei GALs da die FlipFlops potentiell > Zustandsmaschinen ermöglichten. Und ein Copy Protection > Bit das Auslesen verhindert. Offen natürlich ob das > in Realität Problem ist: ich hätte vermutet daß > 90% der GALs genau wie PALs als Adreßdecoder o.ä. > verwendet wurden. Och, da kenne ich andere Beispiele. Z.B. habe ich eine Erweiterung für den Atari ST 1040, damit er auch HD-Disketten lesen und schreiben kann. Da muss das GAL schon ganz schön ran. Es muss den Takt für den FDC bei HD Disketten von 8 auf 16 MHz hoch schalten, und bei Seeks wieder auf 8 MHz runter, weil die Spurwechselzeit ja konstant sein soll. Natürlich alles synchron, damit er nicht absemmelt. Dann musste man noch irgendeine Leitung pro Umdrehung toggeln, weil er sonst die Diskwechsel nicht korrekt erkannt hat. Das sind schon ein paar State Machines. Und die GALs im Maxon SCSI Controller konnte auch mehr als nur Adressen dekodieren. Marcel
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2016-05-26 07:44 -0700 |
| Message-ID | <dqogf2Fic6eU1@mid.individual.net> |
| In reply to | #208555 |
On 2016-05-26 02:28, Ralf Kiefer wrote: > Joerg wrote: > >> Ich kenne GAL und PAL nicht gut, aber es gab welche (damals, als die >> Beatles noch aus dem Radio quollen ...) , wo Pull-ups oder Pull-Downs >> intern aktivierbar waren. > > Ok, dann muß ich dort nachlesen. Da fehlt mir eindeutig das Wissen von > damals. > > >> Wieviel die zogen, weiss ich nicht mehr. Doch >> es kann sein, dass ein 10k Widerstand gegen den internen Pull-up keinen >> Hering vom Teller zieht. Muss man wahrscheinlich weniger nehmen. > > Waren die Pull-<irgendwohin> prinzipiell an jedem Beinchen zuschaltbar? > Oder nur bei den Eingängen? > Das weiss ich nicht mehr, nur dass manche staendig vorhandene interne Widerstaende nach VCC hatten. Manchmal 50k, manchmal weniger. > >> Den Sinn fuer Optokoppler sehe ich nur, wenn die Logikspannungen >> zwischen Deinem Tester-Board und dem Target (PAL, GAL) verschieden sind >> oder wenn das Target aus welchem Grund auch immer an einer anderen >> Spannungsquelle haengt (Gefahr der Rueckspeisung). > > Die hätten den Vorteil, daß unterschiedliche Qualitäten von GPIOs keine > Rolle spielen. AFAIR gibt's Parallelportbausteine, an denen Port A > andere Ausgangsbeschaltung als Port B oder die Handshakes hatte. > Da kannst Du auch einfache Bus-Treiber nehmen. Wird kleiner und billiger. Z.B. 74HCT245: http://www.ti.com/lit/ds/symlink/sn74hct245.pdf > >> Wenn das mein Job >> waere, wuerde ich es ohne Optokoppler machen und das Target gut >> elektronisch abgesichert von der Karte mitversorgen. > > Interessanter Einwand. Mit gut abgesichert meinst Du z.B. einen > Polyswitch in der 5V-Versorgung? Oder eher einen eigenen 78(L)05 (oder > was Vergleichbares) nur für das Target? > Mit Polyswitch habe ich nicht so gute Erfahrungen, weil einige abgeraucht sind. 78L05 ist schonmal eine gute Massnahme, oder eben was mit einstellbarem Strom. Frage dann per Logik die Versorgung ins Target ab, damit zum einen Dein Computer ueber den Kurzschluss weiss und zum anderen der 78L05 nicht so lange in knallheissem Zustand verbringt. Denn deren "Strombegrenzung" ist einfach nur ein thermisches Abregeln. -- Gruesse, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) |
|---|---|
| Date | 2016-05-26 23:49 +0200 |
| Message-ID | <1mnvo0d.4buind1oawbyvN%R.Kiefer.SPAEM@gmx.de> |
| In reply to | #208569 |
Joerg wrote: > >> Den Sinn fuer Optokoppler sehe ich nur, wenn die Logikspannungen > >> zwischen Deinem Tester-Board und dem Target (PAL, GAL) verschieden sind > >> oder wenn das Target aus welchem Grund auch immer an einer anderen > >> Spannungsquelle haengt (Gefahr der Rueckspeisung). > > > > Die hätten den Vorteil, daß unterschiedliche Qualitäten von GPIOs keine > > Rolle spielen. AFAIR gibt's Parallelportbausteine, an denen Port A > > andere Ausgangsbeschaltung als Port B oder die Handshakes hatte. > > > > Da kannst Du auch einfache Bus-Treiber nehmen. Wird kleiner und > billiger. Z.B. 74HCT245: > > http://www.ti.com/lit/ds/symlink/sn74hct245.pdf Die Portbausteine wollte ich nehmen, um einen ursprünglich als Ausgang benutzten GPIO auf Eingang umzuschalten, wenn sich das Target-Beinchen als Ausgang rausstellt. Z.B. bei den 16V8 kann auf der "Ausgangsseite vom Chip" jedes Beinchen beliebig als Ein- oder Ausgang genutzt werden. BTW Karten mit z.B. 8536 habe ich (mit geringem Lötaufwand für die Kabelmontage) zur Verfügung, eine Karte mit Portbausteinen und den Optokopplern 2630 könnte ich derzeit zu vermutlich annehmbaren Konditionen kaufen. Zu den Optokopplern 2630 (dual channel) fand ich dies hier z.B. bei Vishay: http://www.vishay.com/docs/84732/6n137.pdf In der Tabelle auf Seite 3 steht eine Menge drin, ich kann's bloß nicht geeignet auf meine Anforderung umsetzen :-( Die Ausgänge der Optokoppler sind o.K., d.h. der Wert des Pullup muß zum Target geeignet gewählt werden. Zu den Z8536: deren Ausgangsleistung sieht ziemlich mau aus, wenn ich das richtig erkenne :-( Dabei wären die hinsichtlich der Software so schön, weil die einen Pattern Match drin haben. > 78L05 ist schonmal eine gute Massnahme, oder eben was > mit einstellbarem Strom. Spontane Idee: die Spannung hinter dem 78L05 mit einem einfachen Komparator überwachen (z.B. LM339 -> GPIO). Spannung unter 4,0V? Dann Alarm bei der Software auslösen, die den Test sofort einstellt und die Versorgungsspannung vom Target abklemmt. Dazu kann ich den 78L05 mit +12V versorgen und diese abschaltbar machen. Das dürfte die billigste Variante hinsichtlich Bauteile- und Lötaufwand sein. Für "irgendwas mit einstellbarem Strom" fehlt mir die Ahnung :-( Eine geeignete Application Note traue ich mir dagegen schon zu "in Lötzinn zu gießen" :-) Gruß, Ralf
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2016-05-26 15:14 -0700 |
| Message-ID | <dqpaqlFnnsvU1@mid.individual.net> |
| In reply to | #208576 |
On 2016-05-26 14:49, Ralf Kiefer wrote: > Joerg wrote: > >>>> Den Sinn fuer Optokoppler sehe ich nur, wenn die Logikspannungen >>>> zwischen Deinem Tester-Board und dem Target (PAL, GAL) verschieden sind >>>> oder wenn das Target aus welchem Grund auch immer an einer anderen >>>> Spannungsquelle haengt (Gefahr der Rueckspeisung). >>> >>> Die hätten den Vorteil, daß unterschiedliche Qualitäten von GPIOs keine >>> Rolle spielen. AFAIR gibt's Parallelportbausteine, an denen Port A >>> andere Ausgangsbeschaltung als Port B oder die Handshakes hatte. >>> >> >> Da kannst Du auch einfache Bus-Treiber nehmen. Wird kleiner und >> billiger. Z.B. 74HCT245: >> >> http://www.ti.com/lit/ds/symlink/sn74hct245.pdf > > Die Portbausteine wollte ich nehmen, um einen ursprünglich als Ausgang > benutzten GPIO auf Eingang umzuschalten, wenn sich das Target-Beinchen > als Ausgang rausstellt. Z.B. bei den 16V8 kann auf der "Ausgangsseite > vom Chip" jedes Beinchen beliebig als Ein- oder Ausgang genutzt werden. > > BTW Karten mit z.B. 8536 habe ich (mit geringem Lötaufwand für die > Kabelmontage) zur Verfügung, Wenn es mehrere sind und Du damit Ersatz hast, dann ist das gut. > ... eine Karte mit Portbausteinen und den > Optokopplern 2630 könnte ich derzeit zu vermutlich annehmbaren > Konditionen kaufen. > > Zu den Optokopplern 2630 (dual channel) fand ich dies hier z.B. bei > Vishay: > http://www.vishay.com/docs/84732/6n137.pdf > In der Tabelle auf Seite 3 steht eine Menge drin, ich kann's bloß nicht > geeignet auf meine Anforderung umsetzen :-( > Dabei koennen wir Dir in dieser NG helfen. Aber: Der Koppler braucht mindestens 5mA, um gescheit durchzusteuern. Schafft das Dein 8536 ueberhaupt? > Die Ausgänge der Optokoppler sind o.K., d.h. der Wert des Pullup muß zum > Target geeignet gewählt werden. > > Zu den Z8536: deren Ausgangsleistung sieht ziemlich mau aus, wenn ich > das richtig erkenne :-( Dabei wären die hinsichtlich der Software so > schön, weil die einen Pattern Match drin haben. > Wenn die keine 5mA schaffen, vergiss die Optokoppler. Ich verstehe auch nicht so ganz, wozu die Optokoppler gut sein sollen. Kann man doch auch normale CMOS Buffer IC nehmen. Optokoppler nimmt man fast nur zwecks Potenzialtrennung. > >> 78L05 ist schonmal eine gute Massnahme, oder eben was >> mit einstellbarem Strom. > > Spontane Idee: die Spannung hinter dem 78L05 mit einem einfachen > Komparator überwachen (z.B. LM339 -> GPIO). Spannung unter 4,0V? Dann > Alarm bei der Software auslösen, die den Test sofort einstellt und die > Versorgungsspannung vom Target abklemmt. Dazu kann ich den 78L05 mit > +12V versorgen und diese abschaltbar machen. Das dürfte die billigste > Variante hinsichtlich Bauteile- und Lötaufwand sein. > Ja, das geht. Gleichzeitig muss die Software aber alle Port Pins entweder auf Low setzen oder als Eingaenge schalten, sonst versuchen diese, das PAL zu versorgen. > Für "irgendwas mit einstellbarem Strom" fehlt mir die Ahnung :-( Eine > geeignete Application Note traue ich mir dagegen schon zu "in Lötzinn zu > gießen" :-) > Im einfachsten Fall kommt vor Deinen 78L05, also in dessen 12V Zufuhr, ein LM317 als Strombegrenzer. Das ist bloss der LM317 selbst (gibt es ebenfalls in kleineren Bauformen) plus ein Widerstand. Wie das geht, siehst Du unter 9.3.3. auf Seite 12: http://www.ti.com/lit/ds/symlink/lm317.pdf Das ist ein recht praezise einstellbarer Strombegrenzer. Ein Festwiderstand sollte reichen. -- Gruesse, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) |
|---|---|
| Date | 2016-05-27 02:28 +0200 |
| Message-ID | <1mnvuso.1w9teoe1pdf698N%R.Kiefer.SPAEM@gmx.de> |
| In reply to | #208579 |
Joerg wrote: > Dabei koennen wir Dir in dieser NG helfen. :-) > Aber: Der Koppler braucht > mindestens 5mA, um gescheit durchzusteuern. Schafft das Dein 8536 > ueberhaupt? Diese bewährte, seinerzeit sauteure VMEbus-Karte hat auf der Seite der Portbausteine, dort allerdings keine 8536, keine Probleme. Der Kartenpreis lag seinerzeit deutlich über dem eines Consumer-PCs, soll heißen, daß meine Erwartungshaltung eine ganz andere ist wie bei einem Raspi oder Arduino. > Ich verstehe auch > nicht so ganz, wozu die Optokoppler gut sein sollen. Kann man doch auch > normale CMOS Buffer IC nehmen. Optokoppler nimmt man fast nur zwecks > Potenzialtrennung. Siehe anderes Posting: die Optokoppler bringen mir keinen Vorteil. Kartenkauf gestrichen. > Ja, das geht. Gleichzeitig muss die Software aber alle Port Pins > entweder auf Low setzen oder als Eingaenge schalten, sonst versuchen > diese, das PAL zu versorgen. Ist klar. Reset-Zustand vom Chip ist Eingang. > Im einfachsten Fall kommt vor Deinen 78L05, also in dessen 12V Zufuhr, > ein LM317 als Strombegrenzer. Das ist bloss der LM317 selbst (gibt es > ebenfalls in kleineren Bauformen) plus ein Widerstand. Wie das geht, > siehst Du unter 9.3.3. auf Seite 12: So einfach :-) Dann kann ich ein paar unterschiedliche Festwiderstände nehmen, die an einem Dreh-Codierschalter hängen. Flexibilität ... Gruß, Ralf
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2016-05-26 18:20 -0700 |
| Message-ID | <dqpln8Fpkg4U1@mid.individual.net> |
| In reply to | #208585 |
On 2016-05-26 17:28, Ralf Kiefer wrote: > Joerg wrote: > >> Dabei koennen wir Dir in dieser NG helfen. > > :-) > > >> Aber: Der Koppler braucht >> mindestens 5mA, um gescheit durchzusteuern. Schafft das Dein 8536 >> ueberhaupt? > > Diese bewährte, seinerzeit sauteure VMEbus-Karte hat auf der Seite der > Portbausteine, dort allerdings keine 8536, keine Probleme. Der > Kartenpreis lag seinerzeit deutlich über dem eines Consumer-PCs, soll > heißen, daß meine Erwartungshaltung eine ganz andere ist wie bei einem > Raspi oder Arduino. > Manchmal erlebt man in der Edel-Welt herbe Enttaeuschungen. Meine haerteste: Ein teurer Strip Chart Drucker (fuer EKG und Doppler) hatte eine Reset Funktion. Intern war die so "geloest", dass mal eben die 5V kurzgeschlossen wurden. Dies stand natuerlich nirgends in der Doku. Unser neu entwickeltes Geraet hatte ein Netzteil der 100 Ampere Klasse ... TZZT .. *POFF* > >> Ich verstehe auch >> nicht so ganz, wozu die Optokoppler gut sein sollen. Kann man doch auch >> normale CMOS Buffer IC nehmen. Optokoppler nimmt man fast nur zwecks >> Potenzialtrennung. > > Siehe anderes Posting: die Optokoppler bringen mir keinen Vorteil. > Kartenkauf gestrichen. > Schoen, dann kann das gesparte Geld fuer ein Abendessen mit der Herzallerliebsten eingesetzt werden :-) > >> Ja, das geht. Gleichzeitig muss die Software aber alle Port Pins >> entweder auf Low setzen oder als Eingaenge schalten, sonst versuchen >> diese, das PAL zu versorgen. > > Ist klar. Reset-Zustand vom Chip ist Eingang. > Das muss aber auch spaeter funktionieren, wenn das PAL oder GAL ploetzlich Kruke macht. Ich habe die Dinger frueher selbst nicht benutzt, weil die so unsaeglich viel Saft zogen und gelegentlich aus heiterem die spektakulaere Abrauche hinlegten. Konnte ich ab und zu bei meinen digitalen Kollegen sehen, die viel davon benutzten. > >> Im einfachsten Fall kommt vor Deinen 78L05, also in dessen 12V Zufuhr, >> ein LM317 als Strombegrenzer. Das ist bloss der LM317 selbst (gibt es >> ebenfalls in kleineren Bauformen) plus ein Widerstand. Wie das geht, >> siehst Du unter 9.3.3. auf Seite 12: > > So einfach :-) Dann kann ich ein paar unterschiedliche Festwiderstände > nehmen, die an einem Dreh-Codierschalter hängen. Flexibilität ... > Jetzt faengt der Baedecker-Effekt an, oder in Engineering-Speak der Feature-Creep :-) -- Gruesse, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) |
|---|---|
| Date | 2016-06-02 00:23 +0200 |
| Message-ID | <1mo6s3g.o5kym2k0pbfkN%R.Kiefer.SPAEM@gmx.de> |
| In reply to | #208542 |
</ingrid> wrote:
> Die erste
> Aufgabe: ich weiß nicht, welche Beinchen vom unbekannten Chip Ein- und
> Ausgänge sind. Dazu hatte ich diese Idee: ich nehme zwei GPIOs meiner
> Hardware für ein auszuhorchendes Beinchen, schalte den einen als
> Ausgang, den anderen als Eingang, beide an das auszuhorchende Beinchen,
> den Ausgang allerdings über einen Widerstand, damit's nicht raucht.
Ich bin nach der Diskussion, dem gedanklichen Spielen mit diversen
CPUs/Architekturen und Hardware-Aufbauten (ein Grab aus LS273 als Ports,
HCT244 als Treiber, usw.) und ein paar Tagen "sacken" lassen auf diese
Variante gekommen:
8536, Out2 >----------+
O --------
8536, Out1 >-+--> 74ALS125 >---| R1 |------+
| -------- |
| |
| -------- |
+--> 74ALS125 >---| R2 |------+
O -------- |
8536, Out3 >----------+ +-----[ Target
|
8536, In <---------------------------------+
Mit "Out1" lege ich mein Bitmuster an die Leitungstreiber an, mit "Out2"
schalte ich einen Leitungstreiber aus einem ALS125 über R1 (= 27kOhm /
<0,25mA) ans Target, bei mehr Strombedarf am Target kann ich über einen
kleineren R2 und mit Hilfe von "Out3" mein Bitmuster anlegen. Mit "In"
lausche ich, was sich am Target rührt. Ein ALS125 ist angegeben mit Ioh
= -15mA und Iol = 24mA.
Ich verspreche mir diese Vorteile von dieser Hardware: Ich habe
3state-Treiber vor dem Target. Soll heißen, daß bei Erkennen eines
Ausgangs am Target nichts dagegen treibt, nachdem ich mein Prüfmuster
abgeschaltet habe. Durch die ALS125 habe ich ein Budget von 15mA bei
einer logischen '1'. Außerdem kann ich die ALS125 noch in ausreichender
Stückzahl kaufen, notfalls passen genauso ALS126 in die Sockel [1]. Um
die "Gesundheit" der Ausgänge in den Portbausteinen 8536 brauche ich mir
so keine Sorgen machen. Ich kann die Spezialitäten der 8536 (Pattern
Match, u.a.) nutzen, was viele andere Parallel-Portbausteine nicht
haben.
Allerdings ist der Aufwand auf Seite meiner Hardware nicht ganz
unerheblich: ich brauche insgesamt 6 Portbausteine 8536 für 88 GPIOs,
dazu 11* 74ALS125. Ziel: 24pol. GALs/PALs mit 22 zu erforschenden
Beinchen.
Mein spezieller Vorteil gegenüber einer Lösung mit einer eigenen CPU,
z.B. Arduino o.ä.: ich kann das in meinem VMEbus unterbringen, wo ein
68060 mit 60MHz und 256MB RAM das Datensammeln übernimmt. Im OS-9 bastle
ich einen Treiber, wo ich völlig ungestört von anderen Prozessen im
Rechner schnellstmöglich an den Ports wackeln kann und der Code der
kurzen Schleifen vollständig im Cache (8kB = luxuriös viel :-) ) läuft.
Da laufen sogar die 8536 mit 4MHz (250nsec Zykluszeit), AFAIK. Soll
heißen, dqß ich trotz Software nur relativ kurze Pulse auf das Target
bringe, falls am Target-Beinchen doch mal etwas viel Strom im Spiel sein
sollte.
Die Strombegrenzung (LM317) fürs Vcc vom Target ist fest eingeplant.
Allerdings "kostet" mich diese Variante 3 Slots im Käfig! 2 für zwei
vorhandene VMEbus-Karten mit je 3* 8536 sowie mein Gebastel mit den
Leitungstreibern dazwischen.
Kritik und ggf. Verbesserungsvorschläge bleiben willkommen :-)
Gruß, Ralf
[1] Die andere Polarität kann ich beim Konfigurieren vom 8536
einstellen, d.h. triviale Software-Anpassung.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | de.sci.electronics
csiph-web