Hallo allerseits, Für eine Art "Ereigniss-Meldeanlage" möchte ich ein vorhandenes serielles Modem zusammen mit einem Uralt-PC nutzen. Ablauf des ganzen: Ein Meldekriterium wird erkannt, ein Relais zieht an, und schaltet den PC und das Modem ein. Dieser PC hat dann nichts weiter zu tun als das Modem anzusprechen, die AT-Kommandos zu senden, und diese "Meldung" mit verschiedenen Zahlenfolgen weiterzugeben. Nach ein paar Minuten wird der Rechner dann von nem Zeitrelais wieder abgeschalten Welches OS würdet ihr mir hierfür empfehlen? Ich dachte an Free-DOS welches von Diskette läuft. Allerdings ist die Com-Port Programmierung unter DOS ja nicht das gelbe vom Ei... Trotzdem würde ich den PC gerne so weit wie möglich abspecken (kein HDD CD-Rom, usw.) um potentielle Fehlerquellen auszuschalten. Mit welcher Sprache lässt sich das am einfachsten realisieren? Pascal und C bzw. C++ wären kein Problem, allerdings wird verdammt schwer Beispielcode für DOS als Zielplattform zu finden. Für die Win32-Konsole gibts ja Code-Bespiele, aber für DOS? Notfalls könnte es auch Minix3-System werden, aber ich bezweifle doch stark, dass ich dann ein Minimalsystem von Diskette(n) starten kann. Auserdem wäre dann noch die Frage mit der Startzeit - je weniger, desto gut... (Auch deswegen darf es kein Win32 oder normales Linux-System sein) Wäre nett, wenn ich ein paar Tipps bzw. Links zu solchen "alten" Sachen bekommen könnte. Peter
Wenn das, was das Ereignis (mit einem 's') erkennt und das Relais anziehen lässt, ein µC ist, dann würde ich den PC und das Relais weglassen und statt dessen das Modem direkt an den µC hängen ... Wenn nicht bzw. wenn die Hardware/Software des das Ereignis erkennenden Gerätes nicht verändert werden kann, dann ist ein PC mit DOS durchaus eine Lösung. Im Detail gibt es dann verschiedene Möglichkeiten: Eine wäre die Verwendung eines skriptfähigen DOS-Terminalprogrammes (Procomm konnte soetwas, wenn ich mich recht erinnere), eine andere ein einfaches BASIC-Programm, das mit einem DOS-Basicinterpreter (QBASIC?) ausgeführt wird. Eine weitere wäre ein Pascal- oder C-Programm, das aber mit einem 16-Bit-DOS-Compiler erzeugt werden muss; die kann man in leicht angestaubt kostenlos bei Borland bekommen. Beispiele für die Programmierung der seriellen Schnittstelle unter DOS dürften auch heutzutage noch zu finden sein. Dein "Meldegerät" erfüllt allerdings nur sehr rudimentäre Ansprüche an ein solches, da bei der von Dir geschilderten Betriebsart keine Fehlererkennung oder gar -Behandlung möglich ist. Was passiert, wenn der Verbindungsaufbau des Modems nicht klappt? (Kabel gezogen, Störung bei der Post, angerufenes Modem reagiert nicht, angerufenes Modem besetzt) Eine Wiederholung der Meldung findet nicht statt und eine Rückmeldung über die erfolgreiche Zustellung der Meldung an das das Ereignis detektierende System ebenfalls nicht. Außerdem ist von der Verwendung von Diskettenlaufwerken abzuraten, die Dinger sind alles andere als zuverlässig. Besser ist die Verwendung einer CF-Karte in einem CF-IDE-Adapter. Das verhält sich wie eine Festplatte (darf nur nicht so oft beschrieben werden, aber das ist bei Deiner Anwendung kein Problem).
> Außerdem ist von der Verwendung von Diskettenlaufwerken > abzuraten, die Dinger sind alles andere als zuverlässig. Sind aber im Grunde genommen die einzigen Komponenten, die sich so lange quasi unverändert in PCs gehalten haben.
Und? Das sagt nichts über deren Zuverlässigkeit aus. Abgesehen von nass gelagertem Lochstreifen aus Papier kenne ich kein unzuverlässigeres Speichermedium als Disketten, vor allem 3.5"-Disketten. 5.25"-Disketten sind aus irgendwelchen Gründen zuverlässiger; ich habe hier welche, die vor über 10 Jahren beschrieben wurden und sich immer noch lesen lassen. Die ähnlich alten 3.5"-Disketten sind zu -geschätzt- 40% nicht mehr lesbar.
Das stimmt allerdings. Meine 5.25"-Disketten aus Zeiten des Commodore 64 (vor 18 Jahren?) sind nahezu alle lesbar.
>Sind aber im Grunde genommen die einzigen Komponenten, die sich so >lange quasi unverändert in PCs gehalten haben. Was jetzt als Beweis ihrer Zuverlässigkeit zu werten sein soll?
Sorry, eigentlich wollte ich keinen Glaubenskrieg wegen den Speichermedien anzetteln - selbstverständlich kann es auch ein System sein, dass von Festplatte startet. Aber meiner Erfahrung nach haben die Platten irgendwann den unschönen Effekt, dass sie garnicht anlaufen. In der Folge kommt ne Bios-Fehlermeldung und das Teil steht. Das wollte ich eben vermeiden. Zudem hat mich noch keine Diskette "einfach so" im Regen stehen lassen. Festplatten dagegen schon des öfteren (gerade bei alten Rechnern - und mit alt mein ich jetzt Teile mit ca. 500 MB in alten P1/120 MHz AT Rechnern). Das wollte ich eben vermeiden, deswegen - wenn es möglich ist - Start und Programmaufruf - von Diskette. Das Ereignis (sorry für das zweite 's' - aber besser 2 als garkeines :-) ist ein potentialfreier Schlieserkontakt einer gekapselten und zertifizierten Schalteinheit. Jede Änderung hätte ein neues Zulassung mit entsprechenden Kosten (keine Ahnung wie hoch) zur Folge. Irgendwann wenn sich das System bewährt hat, kann es auch auf einen uC umgestellt werden. Solange möchte ich den doch erheblichen Mehraufwand für die Controller-Entwicklung aufschieben. Evtl. kann dann auch die Funktion der Schalteinheit mit in den Controller integriert werden, aber soweit bin ich noch nicht... Aber zurück zur eigentlichen Sache: Sollte das Modem oder die Leitung nicht Ordnung sein, gibt es auch die üblichen Meldungen nach absetzen eines Kommandos zurück (z.B. "OK" "NO CARRIER" "BUSY" usw.) Damit kann dann auch ne Fehlerüberprüfung realisierung und war auch so gedacht. Ich wollte nur die Eigenentwicklung des seriellen Zugriffs vermeiden, und - soweit verfügbar - Codebeispiele bzw. -teile umschreiben. Die Verwendung von QBasic ist für mich ein K.O. Kriterium, da ich mit Basic bis jetzt wenig am Hut hatte, und es zudem überhaupt nicht einsehe an die bekannte Herstellerfirma eine Betriebssystemlizenz zu verschwenden - für die Verwendung nur eines Programms. (auch hier bitte keinen Glaubskrieg - ich akzeptiere und benutze grundsätzlich beide Welten, nur wäre eine XP Lizenz für das Downgrade auf DOS 6.22 zur Verwendung von QBasic absoluter Overkill...) Günstige bzw. sogar kostenlose Entwicklungsumgebungen für C/C++ hab ich gefunden - die Frage war nur, wo sind eher Code-Stücke für meine Zwecke auffindbar. Hat noch irgendwer Beispiel-Code für den seriellen Zugriff unter C bzw. C++? Oder einen Link zu Seiten auf denen man sowas finden könnte? Wäre für jeden Tip dankbar. Peter
> Sollte das Modem oder die Leitung nicht Ordnung sein, > gibt es auch die üblichen Meldungen nach absetzen > eines Kommandos zurück (z.B. "OK" "NO CARRIER" "BUSY" > usw.) Damit kann dann auch ne Fehlerüberprüfung > realisierung und war auch so gedacht. Das ist unbestritten. Damit kann das auf dem PC laufende Programm ein Problem feststellen. Wie aber meldet das Programm diesen Umstand dem Steuergerät und wie verhindert das Programm das Abschalten des PCs per Zeitschaltrelais, damit es beispielsweise Wahlwiederholungsversuche unternehmen kann? Soll sich das Programm erfolglose Ereignisse "merken", und diese zu einem späteren Zeitpunkt nochmal absetzen? Zur Programmierung: QBASIC war natürlich nur ein Beispiel. Das hier ist ein schon etwas fortgeschritteneres Beispiel für die Programmierung der seriellen Schnittstelle unter DOS in C mit Verwendung von Hardwareinterrupts - was für die geschilderte Aufgabe eigentlich nicht nötig ist, aber auch nicht stört. http://www.dogma.net/markn/articles/comports/comports.htm Als Ausgangspunkt ist das sicherlich ganz gut geeignet.
Hallo Rufus, danke für die schnellen Antworten. Stimmt, einen völligen Kommunkationsverlust würde die Relaisschaltung überhaupt nicht bemerken - vielleicht wird die später noch um eine PC gesteuerte Selbsthaltung erweitert. Aber dann müsste ich sicherstellen, dass die Parallelport-Pins nicht schon beim Einschalten des PC zufällig die Bitfolge fürs Ausschalten haben - und dann hätte ich wieder ein Problem. Aber dadrüber werde ich mir später noch genauere Gedanken machen. Wenn eine Meldung einmal überhaupt nicht durchkommt, wäre es auch nicht so schlimm, der Schaltempfänger mit der Telefonkopplung dient nur, um im Idealfall etwas Zeit zu sparen. Wenn es nicht klappt, dauert die Meldung eben ca. 10-15 Minuten länger - und bis jetzt hat man ja auch damit gelebt... Aber zurück zur Software: Der Zugriff über die C-Routinen wird sicher funktionieren, allerdings ist das dann doch recht viel Handarbeit. (Muß ich mir eh noch genauer ansehen) Parallel such ich mal weiter, vielleicht find ich ja doch was fast fertiges - weil aktuell ists von der Arbeit nicht viel Unterschied vom PC-C Programm zum uC-C Programm, wobei die Vorteile des uC überwiegen würden. Vielleicht find ich ja doch noch fertige Lib oder Pascal-Unit, dann mach ichs da drüber, andernfalls eben die Fleißarbeit... Falls doch noch irgendwer was brauchbares in dieser Richtung findet - ich bin für jeden Tipp dankbar. Peter
Hier mal ein paar Links die ich gefunden habe: Eine Seite, auf der verschiedene Programmiersprachen /-umgebungen gerade für ältere PCs vergleichen werden. Bei vielen davon auch mit Download-Möglichkeit: http://www.franksteinberg.de/psprach.htm Hier ein Link zu unter anderem auch einem Freeware-RS232 Treiber für DOS für verschiedene Sprachen (ASM,C,Pacal): http://www.shamrock.de/dostools.htm#v24oem Auf beiden Seiten wurden Links auf die Seiten (nicht auf die direkten Downloads) ausdrücklich erlaubt - sollte das anbringen von Links in diesem Forum dagegen nicht erlaubt sein, bitte diese Nachricht wieder entfernen. Wenn interesse besteht, kann ich ja die fertige Software bzw. den Quelltext hier mal veröffentlichen, damit andere nicht nochmal das Rad neu-erfinden müssen (obwohl es schon verschrottet wurde...) bis dann Peter
Mit QBASIC hatte ich früher auch mal gearbeitet. Die Ansteuerung der RS232 Schnittstelle ist recht einfach zu bewältigen! Gruss Johnny
Hab grad noch ein altes Beispiel gefunden für QBASIC: OPEN "com1:9600,n,8,1,cs,ds" FOR INPUT AS #1 a$ = INPUT$(1, #1) Das initialisiert und holt Zeichen rein, also wirklich recht simpel :-)
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.