Ich glaube mich zu erinnern, vor langer Zeit von einem Projekt/Bausatz gelesen zu haben, finde dazu aber nix mehr im Netz.
Über eine Festplatten-Schnittstelle (weiss nicht mehr welche) war das Modul mit dem PC verbunden. I/O wurde mit Schreib/Lesebefehle gemacht, und zwar wirklich so, dass man einfach ein File unter einem bestimmten Pfad mit einem bestimmten Inhalt anlegte oder überschrieb - oder eben auslas.
ATA-Schnittstelle zweckentfremdet. Das Festplatten-Interface als universelle E/A-Schnittstelle.
In diesem Beitrag wird das ATA-Interface als Einfachschnittstelle zum Anschließen anwendungsspezifischer Einrichtungen vorgestellt. ATA dient dazu, in den PC eingebaute Geräte mit dem Motherboard zu verbinden. Zum Anschließen externer Geräte ist es nicht geeignet. Die ATA-Standards beschreiben nicht nur verschiedene Interfaces, sondern auch die Programmschnittstelle zu den angeschlossenen Geräten. Die herkömmliche parallele ATA-Schnittstelle ist ein E/A-Interface mit 16 bit breitem Datenbus. SATA (Serial ATA) ist die Weiterentwicklung zum seriellen Hochgeschwindigkeits-Interface. Um den PC mit zusätzlichen Schnittstellen auszurüsten, können handelsübliche ATA-Schnittstellenkarten eingesetzt werden, die im Vergleich zu speziellen E/A-Steckkarten deutlich kostengünstiger sind. Die Vorteile eines solchen Einfach-Interfaces ergeben sich vor allem beim Systemhersteller, der komplette Anwendungslösungen zu liefern hat.
Elektronik, Band 55 (2006) Heft 1, Seite 56-60 (5 Seiten, 9 Bilder)
Noch eine Idee: Man kann auch SCSI-Schnittstellen benutzen. Habe bei einem ELTEC Framegrabber gesehen, der einen SCSI-Host-Controller zum Transfer der digitalisierten Frames in den Hauptspeicher eines PCs benutzt.
Das wäre sehr verwunderlich, denn das Dateisystem hat weitreichende Freiheit, wie es die Daten intern organisiert. Und dieses Verhalten wäre von dem betreffenden Device kaum vorherzusagen.
Die IDE-Schnittstelle selbst kann man allerdings sehr wohl für allgemeines I/O missbrauchen. In ihrer ursprünglichen Form ist es sowieso nichts signifikant anderes als ein AT-Bus (alias 16-Bit ISA).
Mutmaßlich gab es einen Treiber, der ein DOS-Device zur Verfügung gestellt hat, auf das man per File open/Read/Write zugreifen konnte. Das ging auch schon unter DOS und geht bis heute. In memoriam LPT1 z.B.
Meine Erinnerung sagt, dass eine bestimmte Datei (Name vorgegeben) an einem bestimmten Ort (Pfad vorgegeben) mit definiertem Inhalt (z.B. ON/OFF) geschrieben werden musste (ev. genügte bereits das Vorhandensein der Datei, weiss es nicht mehr).
Meine Infos über HD-Schnittstellen sind rudimentär, aber ich gehe mal davon aus, dass bei den für oben beschriebenen Vorgängen eindeutige Muster erkenn- und auswertbar vorliegen. Notfalls könnte so ein I/O-Modul die Anwesenheit der Datei bzw. deren Inhalt prüfen und entsprechend reagieren. Wäre dann halt nicht mehr Echtzeitverhalten.
Ich erinnere mich wirklich nur noch daran, sowas gelesen zu haben und interessiere mich, wie es im Detail gelöst wurde und ob es (noch) erhältlich ist.
Aber eine, die in der Praxis nicht zuverlässig funktionieren wird. Die ATA-Schnittstelle operiert nun einmal nicht auf "Dateien", sondern auf Sektoren, und wie das Eine in das Andere übersetzt wird, obliegt den undokumentierten Tiefen des Betriebssystems. Da können (und werden) z.B. Puffer zwischengeschaltet sein, die Schreibzugriffe erheblich verzögern und wiederholte Lesezugriffe komplett unterdrücken.
Der Grundgedanke, der die Sache so attraktiv macht, ist doch gerade, daß keine besonderen Treiber benötigt werden. Es kommen die Standardtreiber des OS zum Einsatz und zwar ganz automatisch. Das sieht nämlich eine generische ATA-HD, darauf eine normale Partitionsstruktur und eine Nutzpartition mit einem ihm bekannten Filesystem (z.B. FAT16, das können alle).
Ja, und es erfordert auf der "anderen" Seite halt nur eine Elektronik, die sich wie eine kleine Festplatte mit entsprechendem Inhalt verhält.
Dazu braucht man die Funktionsweise des verwendeten Filesystems nicht mal zu verstehen, man erzeugt es einfach auf einer echten HD und kopiert dann deren Inhalt quasi als Konstante in die Firmware.
Die einzige Ausnahme ist der Netto-Inhalt des oder der "Nutzfiles". Welche Sektoren der virtuellen Festplatte das sind, kann man ohne großen Aufwand an der Vorlage-HD feststellen. Ich nenne den Teil mal "IO-Daten" und den Rest der virtuellen Plattenstruktur "konstante Sektoren"
Die Firmware des Adapters muß also dann nur folgendes Sachen machen:
1) ATA-Schnittstelle bereitstellen (ungefähr ein Dutzend Kommandos, für das meiste davon sind nur Dummy-Implementierungen nötig, die einfach nur "OK" sagen oder konstante Daten zurückliefern)
2) Schreibzugriffe auf konstanten Sektoren der virtuellen Platte wegwerfen, aber als erledigt melden.
3) Lesezugriffe auf konstante Sektoren mit dem Inhalt eben dieser Sektoren beantworten.
4) Zugriffe auf die Sektoren mit IO-Daten rausfiltern und nach Wunsch behandeln.
Das anspruchsvollste davon ist 1), man braucht dazu halt eine ATA-Spezifikation und muß herausfinden, welche der Kommandos man zwingend unterstützen muß, damit die Sache funktioniert.
Davon bin ich ausgegangen, andere hier haben dem aber eher widersprochen.
Einfach die Daten der Schnittstelle zu nutzen, wäre elektrisch gesehen einfach, softwaremässig aber nicht. Und bei Verwendung der vorhandenen Treiber muss nach der Schnittstelle entsprechend eine Logik die Daten übernehmen und verarbeiten.
Genau. Und von sowas meine ich gelesen zu haben. Nur: wo? Elektor?
DOS-Devices können direkt beschrieben werden. Also z.B. echo OFF >device_name
Nein. Der gleiche Zugriff mehrfach ausgeführt würde deutlich andere Muster ergeben.
Würde mich wundern. Das wäre auch eine außerordentlich unsinnige und störanfällige Lösung. Zumal bereits andere Patch-Level des gleichen Betriebssystems sich beim I/O-Zugriff anders verhalten dürfen und das auch tun (Cache-Strategie).
Unter Unix ist so etwas gang und gäbe, allerdings sind es da auch entweder Device-Namen, die dort allerdings einen Pfad haben, oder gleich eigene Dateisysteme, wie /proc oder /sys. Heißt, ohne speziellen Treiber geht da auch nichts.
Einen Controller mit parallelem SCSI Interface kann man auch ohne Protokoll-ASIC bauen, z.B. so:
formatting link
Und SCSI bietet verschiedene Geraeteklassen, d.h. man kann den Controller statt zu einer Festplatte auch zu einem Prozessor- oder Communication-Device machen ... dann ist das absolut kein "Missbrauch der Schnittstelle" mehr.
Natürlich muß man in dieser Anwendung auf Applikationsebene oder auf Systemebene der besonderen Natur der selbstgebastelten "Festplatte" Rechnung tragen. D.h.:
1) Die Files im virtuellen fs dürfen natürlich weder gelöscht noch truncated oder appended werden, sonst kommen u.U. die fs-Strukturen durcheinander (sofern im RAM gecached). Da hilft dann nur noch umount/mount.
2.a) Nach jedem Schreibzugriff ist ein flush() fällig (oder besser)
2.b) sämtliche Caches sind von vorherein zu deaktivieren
Doch. Das klappt unter Unixioden genauso wie unter Windows. Gerade das ist ja das Goodie so einer Lösung. Man braucht keine speziellen Treiber, für keins der üblichen OS und muß sich auch nicht mit Rechte-Restriktionen des OS herumschlagen.
Wirklich sauber ist so eine Lösung natürlich nicht, das ist klar, aber es ist die einfachste und billigste Möglichkeit, um Daten sehr schnell zwischen einer Anwendung mit Benutzerrechten und externer Elektronik auszutauschen. Ideal, um Q&D mal was auszuprobieren, was hohe Datendurchsätze erfordert. Und für rein "private" Anwendungen sicher auch als Dauerlösung geeignet.
auch der Parallel-Port wurde derart missbraucht. Die Firma Syquest hatte mal ein Laufwerk, das über den Printerport angeschlossen war. Der Parallel-Port verhält sich so wie ein SCSI-Port. Es fehlt nur eine Steuerleitung. Dieses Laufwerk war unter dem Name SparQ bekannt. Nachteil: Es gibt keine Treiber und Medien (1GB) für diese Laufwerke. Schade eigentlich.
Mit dem DOS-Befehl Print konnte man aber auch Daten direkt in den Port schreiben.
Mein Freecom CD-Laufwerk lief ueber den LPT Port. Das war IIRC ein TSR-Programm unter DOS und damit stand dieses Laufwerk als weiterer Laufwerksbuchstabe zur Verfuegung. Koennte sein dass ich das noch irgendwo habe. Man schmeisst ja nix wech :-)
--
Gruesse, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Man muss schon ein Filesystem realisieren, am besten FAT oder sowas. Das kann auch statisch sein (feste Datei liegt auf ganz bestimmten Sektoren). Nachteil ist die ungünstige Vorhersagbarkeit des Timings. Wenn da ein Cache dazwischen ist, landen die Daten möglicherweise erst mit einer oder 30 Sekunden Verzögerung im File. (Mit der "write-through"-Option kann man das in Windows aber für einzelne Files abschalten). Da die ATA-Schnittstelle aber fast ausgestorben ist, würde ich eher auf USB setzen. SATA zu implementieren ist ihmo ohne Spezialchips auch sehr aufwendig.
ferner muss man das Dateisystem fest vorschreiben und aufpassen, dass der Dateisystemtreiber nicht auf die Idee kommt, die Datei /nicht/ in Place zu überschreiben.
Vorausgesetzt, man befindet sich im Raum des kleinsten gemeinsamen Nenners bezüglich des Dateisystems. Realistisch betrachtet bleibt da FAT16 übrig. Und dann ist es an der Zeit zu beten, dass der Dateisystemtreiber für das jeweilige Betriebssystem sich hinreichend wie erwartet verhält, damit das Kartenhaus nicht einstürzt.
Portablen Lösungen verpasst man ein Netzwerk-Interface und von mir aus einen SMB-Server. Das ist ein standardisiertes Protokoll, wenn auch proprietär. Oder noch besser, ein Web-Interface. Das läuft mutmaßlich auch in 20 Jahren noch, selbst, wenn es dann nicht mehr so bunt und flackernd, wie die dann aktuelle Konkurrenz ist. Aber selbst über SMB kann man 15 Jahre alte Geräte noch weitgehend problemlos ansprechen.
Privat mag jeder machen, was er will. Im Beruflichen Umfeld, würde ich einen MA, der so etwas anschleppt, streng zur Rede stellen, weil sich durch die nicht bestimmungsgemäße Sekundärnutzung der vom Dateisystemtreiber erzeugten I/O-Zugriffe vollkommen unkalkulierbare Betriebsrisiken ergeben. Das kann 2 Jahre laufen und dann von einem Tag zum anderen den Dienst quittieren, ohne dass man praktikable Möglichkeiten hätte, etwas dagegen zu unternehmen, da es ja kein Defekt an einem der beteiligten Geräte ist.
Also da müssten schon einschlagende Argumente für so eine Lösung sprechen, wie z.B. sauteure Spezialhardware mit >100.000? Wiederbeschaffungswert, die durch so eine Lösung noch ein paar Jahre in die Verlängerung geschickt werden kann.
etwas aber bedeutet, dass die nutzenden Programme für den Dateizugriff direkt auf der Win32-API aufsetzen. Bereits in einem ANSI-C oder auch C++ Programm geht das nämlich nicht mehr. Und damit hätte man die gerade gewonnene Plattformunabhängigkeit komplett unterwandert.
Ja, ist aber eher lahm und benötigt für proprietäre Geräte auch immer proprietäre Treiber. Eher Netzwerk. Handelsübliches GBit LAN schafft mittlerweile >50MB/s Netto und ist wirklich Plattformunabhängig, wenn man geeignete Protokolle nutzt.
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.