Parallel Port

Hi,

ich dazu einfach einen Daten-Pin benutzen also Status-Pin und

L.

Reply to
Nomen Nescio
Loading thread data ...

Nomen Nescio schrieb:

Antworten.

einen Parallelport es sich handelt.

Gruss Wolfgang

--
No reply to "From"! - Keine Antworten an das "From" 
Keine privaten Mails! Ich lese die NGs, in denen ich schreibe. 
 Click to see the full signature
Reply to
Wolfgang Gerber

"Nomen Nescio" schrieb im Newsbeitrag news: snipped-for-privacy@dizum.com...

Ja, aber wenn die Verbindung Datenpin-Statuspin offen ist (Schalter aus), muss am Statuspin fuer definierten Pegel gesorgt werden, dazu muesste ein Widerstand als PullUp an

+5V, die man nicht hat, also braucht man dazu braucht einen zweiten Datenpin.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
 Click to see the full signature
Reply to
MaWin

MaWin schrieb:

Hi, ist es hier nicht notwendig erst mal zu wissen was er realisieren will? Er könnte doch auch einen PullDown aus Masse legen denn die hat er doch am Parallel-Port. Kommt doch nur drauf an was er machen will. Oder hab ich hier etwas falsch verstanden.

MfG Sven

Reply to
Sven Müller

.. und wenn das geschafft ist, braucht man unter Win NT, 2000, XP.. noch einen Treiber, der einen auf den I/O-Port zugreifen lässt. Sonst passiert nämlich einfach garnix, während man unter einem richtigen Betriebsystem wenigstens gesagt bekommt: "Der Prozess xyzzy wurde sicherheitshalber totgeschlagen, weil er versucht hat, ohne Erlaubnis die Adresse 0x378 zu befummeln."

Bei mir hat sich hierfür das Programm userport von Tomas Franzon bewährt.

Gruß, Gerhard

Reply to
Gerhard Hoffmann

"Sven Müller" schrieb im Newsbeitrag news:e06l4a$4bg$02$ snipped-for-privacy@news.t-online.com...

Das parallel-Port gilt als TTL-kompatibel, selbst wenn heut zu tage meist CMOS-ICs drin sitzen, aber bei TTL sind PullDowns halt kaum zu realisieren, rechne mal selber nach (Strom aus HI, Spannung damit LO erkennt wird, etc.)

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
 Click to see the full signature
Reply to
MaWin

"Gerhard Hoffmann" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

Ein RICHTIGES Betriebssystem wuerde so reagieren, das es den Portzugriff fuer DIESES Programm freischaltet und fuer alle anderen Programme so lange sperrt, eben ganz genau so als ob der erste Zugriff ein implizites open enthaelt und (nach 1 Minute Inaktivitaet oder so) der erste Zugriff eines anderen Programm vor dessen open ein ganz normales close bewirkt. Per I/O-Priviledges ganz einfach. Kein Totschlagsargument.

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
 Click to see the full signature
Reply to
MaWin

Mit anderem Worten, jedem erstbesten Spielkind auf der Maschine direkten Zugriff auf Hardware erteilen?

Gut, daß Du keinen Betriebssystemcode schreibst.

Sinnvollerweise gibt es direkten Zugriff auf Hardware nur wenn dies auch erlaubt ist und nicht immer dann, wenn gerade kein anderer da rummacht.

Wobei auf vernünftigen Plattformen der Prozess nicht gekillt wird sondern schlichtweg ein EPERM (permission denied) bekommt und er selber darauf sinnvoll reagieren sollte.

Man liest sich, Alex.

--
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison
Reply to
Alexander Schreiber

"Alexander Schreiber" schrieb im Newsbeitrag news: snipped-for-privacy@mordor.angband.thangorodrim.de...

Sicher, ich lass sogar jedes Spielkind an die Tastsur und Maus schubsen, das muss ein Betriebssystem abkoennen.

Oh, mindestens schon 2 Dinge geschrieben die die Bezeichnung Betriebssystem verdienen.

Du bist eher der Informatik-Theoretiker, was ?`

Es GIBT semantisch keinen Unterschied, ob man das open implizit aus dem ersten Zugriff ableitet oder nicht.

Wegen Leuten wie dir, die das nicht begreifen, haben Benutzer die bekannten Probleme mit NT & Co., sind tausende von Programmen unter NT unbenutzbar, obwohl es dazu GAR KEINE Notwendigkeit gab. Nur dumme Programmierer bei M$.

Klar bekommt es das. WENN das Port von woanders gesperrt ist. Z.B. der Festplattenport vom FileSysetem weil DIESE Festpatte auch WIRKLICH verwendet wird, und nicht bloss bisher ungenutzt montiert ist.

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
 Click to see the full signature
Reply to
MaWin

Hallo Manfred,

Und weil die Eingänge TTL-kompatibel sind, selbst wenn CMOS drin ist, erkennen die einen offenen Pin eben auch als High-Level. Mir ist noch kein Parallelport begegnet, der das nicht so machen würde, auch wenn Du eifrig was anderes behauptest. Ich hab sogar schon ne Schaltung gesehen (Kopierschutzdongles), die die offenen Eingangspins Pins als Spannungsversorgung für die externe Schaltung nutzt.

Marte

Reply to
Marte Schwarz

So ist es.

Da eine gute alte Ingenieursregel sagt, daß man CMOS-Eingänge niemals offen lassen darf, ist ein Widerstandsarray an den Eingängen sowieso Pflicht.

Rein theoretisch könnte man es zwar auch nach Masse legen, aber mir ist noch kein realer Port begegnet, bei dem es nicht nach +5V gelegen hätte.

Reply to
Heiko Nocon

"Marte Schwarz" schrieb im Newsbeitrag news:e088pu$pko$ snipped-for-privacy@news2.rz.uni-karlsruhe.de...

Nun, und das ist halt auch genau so aufzufassen, als ob man einen echten TTL-Eingang offen lassen wuerde um HI zu erzielen. Geht, geht fast immer, macht man trotzdem nicht weil es gegen 'die Vorschriften' verstoesst. Ich schlage halt moeglichst nichts vor, was kein sauberes Design waere, zu mal es wirklich kein Aufwand ist, einen Widerstand an die Buchse zu montieren.

Das steht wo ? Oder hast du das gerade erfunden ?

Wohl kaum. Es werden auf HI geschaltete Ausgangspins gewesen sein.

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
 Click to see the full signature
Reply to
MaWin

Du lenkst ab.

Physischer Zugriff auf Tastatur & Maus ist was anderes als mit Code in der Maschine frei auf Hardware zuzugreifen.

Spezialsysteme (z.B. für Maschinensteuerungen) oder Universalsysteme?

Die Anforderungen für z.B. ein embedded OS für eine Maschinensteuerung unterscheiden sich doch recht drastisch von den Anforderungen für ein Multitaskingsystem für den Servereinsatz oder den Desktopeinsatz. Wo bei ersterem einfacher direkter Zugriff auf die Hardware sinnvoll sein mag, will man bei letzterem saubere Isolation und nur den Kernel an direkt die Hardware und alle anderen definierte Schnittstellen nutzen lassen.

Informatiker ja, Theoretiker nein. Dafür habe ich zuviele Produktivsysteme entworfen, entwickelt, aufgesetzt und betrieben.

Aber als Informatiker hat man[1] einen soliden theoretischen Hintergrund, der vielen "Praktikern" bitter abgeht - was in entsprechende grauenvoller Software resultiert[0]. Ich habe genug Mist aus der Ecke richten dürfen, wo jemand fröhlich drauflosgeschludert hat.

Wie bitte willst Du da stabilen und sicheren Systembetrieb sicherstellen? Mit dem Ansatz kann ich als unprivilegierter Nutzer einen Paßworternter anstelle des Loginprogramms setzen indem ich mir halt als erster die Tastatur als Device kralle.

Kaum. Ich würde den NT-Code nicht mit einem 3-Meter-Stab berühren ;-)

Nicht nur, aber zuviele. Der NT-Kern enthält, seiner Abstammung von VMS geschuldet, viele gute Konzepte. Erwartungsgemäß ist die Implementation durch Microsoft eine Katastrophe (ich sage nur: GDI im Kernelmode).

Aber Du kannst ein OS für einen eng umrissenen Zweck, z.B. ein embedded OS für eine Maschinensteuerung, nicht so einfach mit einem Universal-OS für Desktops & Server vergleichen - die Ressourcen und Anforderungen sind zu unterschiedlich.

So etwas wie einen "Festplattenport" in dem Sinne gibt es schon lange nicht mehr. Die Kommunikation z.B. mit den Diskcontrollern läuft bei aktueller PC und !PC-Server/Workstationhardware üblicherweise über das PCI-Interface. Und da brauchst Du entsprechende Treiber, um erstmal den Controller anzusprechen.

Und wenn Du Deinem Betriebssystem nicht das Ressourcenmanagement anvertrauen willst, dann kannst Du auch gleich wieder DOS fahren.

Man liest sich, Alex. [0] "O(n)? Hä? Is'n das? Relationale Algebra? Das is' ne DB, kein Mathe!" [1] Ok, sollte haben - es gibt genug peinliche Ausnahmen.

--
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison
Reply to
Alexander Schreiber

"Alexander Schreiber" schrieb im Newsbeitrag news: snipped-for-privacy@mordor.angband.thangorodrim.de...

Ein Universal mit GUI, ein missionkritisches fuer Luftfahrzeuge.

Darf ich deine Aufmerksamheit noch mal auf die Aussage lenken: Es GIBT keinen semantischen Unterschied, wie unschwer zu erkennen ist. Also auch keine unterschiedlichen Folgen.

Die Privilegien sind genau dieselben wie bei einem expliziten open, entweder der Prozess hat sie oder nicht, wobei ich zunaechsteinmal davon ausgehe das sie jeder Prozess hat, bis eben der erste das Port geoeffnet hat, aber das kann man je nach Port auch anders definieren. Der entscheidende Punkt ist: Man koennte es GENAU SO definieren wie bei expliziten opens (was man aber klugerweise nicht tut, sondern relaxter mit Verboten umgeht).

Als erster. Eben. Es spielt dabei keine Rolle, ob das per open oder Zugriff stattfindet.

Tja, Leute die wie du nicht lernen wollen, werden nie ueber die nachgeplapperten Erkenntnisse ihres (vermutlich) Studiums hinauskommen. Der NT-Code ist recht lehrreich.

Gerade und genau hier muss ich widersprechen. Gerade die VMS-Konzepte haben zu den Problemen von NT gefuehrt, weswegen die meisten Nutzer seit 20 Jahren doch lieber Win98 vorziehen - tzrotz seiner Schwaechen, aber der VMS-Anteil von NT ist eben nicht am Benutzer ausgerichtet. Mehr Unix dort zu uebernehmen waere besser gewesen, modernere Konzepte (Helios etc.) lagen auf dem Tisch.

Oh, GDI greift auf Hardware zu. Waehrend ich das durchaus einem normalen Prozess erlauben wollte so lange es eben kein anderer macht, warst du doch der Verfechter das das kein User-Prozess machen darf. Du widersprichst dir also selbst.

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
 Click to see the full signature
Reply to
MaWin

Hallo Manfred,

Bei echten TTL geht das immer. Man schaue sich die TTL Eingangsbeschaltung an und weiss warum.

Hast Du eine Zitatstelle für diese Vorschrift? Dass es besser ist und allgemein empfohlen wird, sei hier unbestritten. Offene TTL sind aber IMHO klar definiert, wenngleich unschön.

Das ist die einfache Praxis. Ich muss hier einschränken, dass ich vor allem die Pins 1,14,16 und 17 verwende. Diese liegen nach IEEE1284 mit OC-Ausgänge und 4k7 Pullup an 5 V, und das schon sehr lange.

OK, das waren die Controllpins.

Marte

P.S. eine schöne Übersicht gibts unter ftp://ftp.armory.com/pub/user/rstevew/LPT/zha96lpt.faq Hier vor allem §19

Reply to
Marte Schwarz

"Marte Schwarz" schrieb im Newsbeitrag news:e0be5r$f5d$ snipped-for-privacy@news2.rz.uni-karlsruhe.de...

Njet.

Falsch.

Horowitz/Hill Bd 2 S 132:

"Ein offener TTL-Eingang ist 'kaum High'. Er liegt auf dem Logikschwellwert (~1.3V), da jedoch kein Strom abfliesst, schaltet er den Eingangstransistor nicht ein. Von Zeit zu Zeit sieht man Schaltungsentwuerfe, in denen Eingaenge, die bei TTL eigentlich auf HIGH liegen sollten, offen bleiben. Tun sie dies niemals ! Es ist dumm und gefaehrlich. An einem offenen Eingang gibt es eine Stoersicherheit von null. Somit moennen Signale aus der Umgebung ueber kapazitive Kopplung kurze LOW-Spikes am Eingang erzeugen...."

Irgendwo gab es noch einen Hinweis, warum die Eingange nicht ohne Vorwiderstand an + kommen sollten, hat was mit Induktivitaet der VCC Chipzuleitung zu tun und dem Spannungsabfall darueber, so das der Eingang > VCC wird.

Was ist einfache Praxis ? Mir was in den Mund zu legen was ich nie gesagt habe ? Mann bist du krank. P.I.S.A. geschaedigt.

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
 Click to see the full signature
Reply to
MaWin

Multiusersysteme mit sauberer Hardwareabstraktion (Treiber), Isolation von Prozessen und Nutzern, Privilegientrennung?

Wenn man nur ein Singleusersystem baut, dann kann man sich natürlich einen erheblichen Teil der in Multiusersystemen üblichen Isolation sparen. Bei einem missionskritischem System für Luftfahrzeuge dürfte sowohl die Hardwareplattform relativ eng umrissen sein (und nicht: Was auch immer es gerade im Computerladen gegenüber billig gab) und die Softwarebstückung dürfte ähnlich restriktiv sein - da kommt bestimmt keiner mit Software aus obskuren Quellen a la Heft-CD mit "tollen Programmen!!".

Das stelle ich auch nicht in Abrede. Wenn man sich die NT Architektur ansieht und sich vorher mit VMS beschäftigt hat, dann trifft man alte Bekannte zuhauf. Es ist auch durchaus interessant zu sehen, an welchen Stellen MS gezwungen war, teilweise böse Kompromisse einzugehen um wenigstens noch etwas Performance aus dem Gesamtsystem zu kitzeln.

Lausige Performance in den ersten Versionen? Ok, da hat MS einfach zuviel von der Hardware verlangt und ein System gebaut, das aufgrund seiner Komplexität trotz alller Kompromisse erst seit wenigen Jahren erträglich läuft.

Wenn der Nutzer mit Win98 & Co glücklich ist, dann soll er es halt nutzen - aber in Netzen will man diesen Kram aus naheliegenden Gründen nicht haben, schon weil es unmöglich ist, diese Plattform vernünftig abzusichern.

Aber diese Plattform ist aufgrund ihrer Struktur so gottverdammt fragil, das es sich nur für unkritische Aufgaben eignet.

Oh ja, zumal man sich bei UNIX problemlos hätte bedienen können. Aber Cutler hat halt damals VMS mitentwickelt und hat bei Microsoft dann ein VMS++ gebaut. Wie gesagt, das sieht man _sehr_ deutlich in der internen Struktur der beiden Systeme.

Hmm, Helios sieht interessant aus. Leider sind die Transputer untergegangen (und selbst Parsytec baut keine HW mehr).

Nicht direkt, sondern auf (Video-) Treiber, die dann ihrerseits auf die eigentliche Hardware zugreifen.

Nö. Prozesse sollte nur in Ausnahmefällen direkt auf Hardware rumspringen. Normalerweise will man schon aus Gründen der Abstraktion und Isolation eine Treiberschicht zwischen Prozessen und Hardware.

Man liest sich, Alex.

--
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison
Reply to
Alexander Schreiber

MaWin schrieb:

Angaben zu TTL von Texas Instrument

Reply to
horst-d.winzler

Bei vielen Antworten weiß man genausowenig, ob sie richtig sind, wie bei den richtigen Namen.

Ich habe hier noch ein "Deutsches Einheits-Familien-Stammbuch" (Verlag für Standesamtswesen G.m.b.H., Berlin SW61, Gitschiner Straße 109). Da sind hinten drin zwei Seiten: Auswahl gebräuchlicher Namen, A: Vornamen deutschen oder germanischen Ursprungs B: Vornamen fremden Ursprungs

Damit, für den Eintrag in Euren Newsreader (Vorname/Name):

Andrä Ende Bartel Hanf Jobst Most Merten Bald Veit Zug Dagobert Drack Eginhard Gelz Erdmann Himmel Frowein Sprudel Godecke Dann Humbert Will Iwein Dampf Lebrecht Arm Odo Maß Schwerthelm Stich Sturmhard Regen Timm Trimm Wittich Mark Willi Brand

Wer davon nimmt, begeht keine Sünde. Grüße, H.

Reply to
Heinz Schmitz

[offener TTL-Eingang = H]

Ach *daher* kommt der Sch*** Kein Wunder, daß das alle Welt glaubt, wenn es in der "Bibel" steht. Aber wie das mit Bibeln so ist, selber denken gefällt mir besser...

Der extern meßbare Pegel ist *gar* kein Argument. Ansonsten:

man Innenschaltung man Basisschaltung man Inversbetrieb

Das ist das einzige Argument. Wobei ich die Störsicherheit nicht als "null" ansehen würde. TTL-Eingänge sind recht niederohmig. Der Wider- stand von der Basis des Eingangstransistors nach Vcc ist in der Größenordnung von 2k. Ein externer Widerstand von z.B. 4.7k nach Vcc hat praktisch keine zusätzliche Wirkung.

Abgesehen davon hatten wir *genau* diese Diskussion hier schon mal. Fazit (für mich): so lange man an die eigentlich unbenutzen Eingänge keine längeren Leiterzüge (oder Kabel) anschließt und diese in die unmittelbare Nähe schneller Logiksignale bringt, kann man TTL-Eingänge auch offen lassen damit sie H Pegel sehen.

XL

Reply to
Axel Schwenke

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.