Hallo! Wie kann ich in C++ (Boreland C++ V3.1) die Serielle und die Parallelle Schnittstelle ansprechen und welche include Files brauche ich dazu? danke schon mal AiM
Ich will ja nicht unfreundlich erscheinen, aber schon unter den aktuellsten 10-20 Beiträgen in dieser Kategorie findest du auf deine Fragen umfassende und kompetente Antworten
Und wo? Ich habe die Suchfunktion benutzt und auch selbst einige Treads gelesen. Aber da habe ich "nur" Seriell gefunden und auch nur in Windows und Linux. Boreland C++ V3.1 ist aber ein reines DOS Programm. Davon sthet dort aber nichts. gruß AiM
Unter (echtem) DOS kannst Du serielle Schnittstellen entweder über die BIOS-Funktionen (int14) ansprechen (sehr rudimentäre Unterstützung, blockierend, keine sonderlich hohen Datenraten beim Empfang erzielbar) oder aber Du musst den Schnittstellenbaustein selber programmieren (mit I/O-Befehlen à la inp/outp). Das ist nicht wirklich ratsam, da das absolut nicht portierbar ist und nur unter "echtem" DOS (also unter keiner Windows-Variante) funktioniert. Obendrein ist gerade die Programmierung eines stabil funktionierenden Interrupttreibers unter DOS auch nicht ganz trivial, da das ganze Gekröse mehr schlecht denn recht dokumentiert ist und eine Sammlung abstruser Besonderheiten darstellt. Eine Alternative wäre die Verwendung eines sogenannten FOSSIL-Treibers, der über eine ähnliche Programmierschnittstelle wie die BIOS-Interrupts angesprochen wird, aber deutlich mehr Funktionalität bietet (interruptgesteuertes Senden/Empfangen, hohe Datenraten, mehr als nur die vier Standardschnittstellen ansprechbar etc.). Aber auch dieser Ansatz ist absolut nicht portabel. Die parallele Schnittstelle lässt sich für die Ansteuerung von Druckern ebenso über die dafür vorgesehene BIOS-Schnittstelle (int17) ansprechen, bei anderen Anwendungen muss auch hier die Schnittstelle direkt durch I/O-Befehle (inp/outp) angesprochen werden. Letzteres ist eine auch heute noch sehr beliebte "Technik", die auch unter Linux und -mit Hilfsprogrammen- aktuellen Windowsversionen eingesetzt wird, aber auch nicht portierbar ist. Das grundlegende Problem ist hier DOS, was nie ein echtes Betriebssystem war und das Konzept eines Devicetreibers nie richtig umgesetzt hat. Die meisten Programme pfuschen selbst an der Hardware herum, weshalb die Hardware bei allen Rechnern exakt gleich sein musste (-> "IBM-Kompatibel"), was gewissermaßen die große Koalition der Hardwareentwicklung war (Stagnation statt Fortschritt). DOS ist glücklicherweise ganz doll tot. Welchen Sinn aber hat es, heutzutage noch mit einem DOS-C-Compiler DOS-Programme zu schreiben?
"Boreland C++ V3.1 ist aber ein reines DOS Programm." Oh, ich wusst nicht, dass der noch für DOS ist. Sowas sieht man nicht mehr oft :)
"Boreland C++ V3.1 ist aber ein reines DOS Programm." Das stimmt übrigens nicht ganz, BC++3.1 ist auch ein übrigens ziemlich guter Compiler für 16-Bit-Windows-Programme. Damals war Borland noch unumstritten Microsoft überlegen, aber kurz darauf, als die ersten 32-Bit-Compiler 'rauskamen, hat Borland Kunden aufs allergründlichste verarscht. Borland C++ 4.0, der "großartige" 32-Bit-Compiler, sollte Programme für die damalige einzige 32-Bit-Windows-Version (NT 3.1) erzeugen können ... lief aber nicht darunter. Und der mitgelieferte Debugger war noch steinzeitlicher als die alte "windbag"-Version, mit der Microsoft einen damals beglückte. Bis es dann den ersten vermutlich benutzbaren Compiler (nebst IDE) von Borland für Win32 gab, war der Zug abgefahren und Microsoft hatte mit Visual C++ 2.0 den ersten brauchbaren Microsoft-Compiler abgeliefert. Im übrigen waren die C++-Compiler von Borland teilweise auch schon ein Rückschritt gegenüber älteren Borland-Compilern; die Qualität der Dokumentation von BC++3.0/3.1 erreichte nicht ansatzweise die Qualität des deutschsprachigen Handbuchs von Turbo C 2.0 ... das war das von Arne Schäpers. Borland setzte damals mit etwa einem halben Regalmeter mehr auf Quantität. Auch schade.
Weiß nicht ob es die schon in Borland 3.1 gab aber in 5.0 gibt es die bios.h Einfacher geht es nun wirklich nicht.
>> Welchen Sinn aber hat es, heutzutage noch mit einem DOS-C-Compiler
DOS-Programme zu schreiben?
1) Läuft auf fast allen (auch älteren) Computern
2) Ist echtzeitfähig
Wenn jemand ne möglichkeit kennt Windows echtzeitfähig zu machen dann
bitte her damit.
Glaube aber kaum dass das möglich ist.
Den Punkt 2 akzeptiere ich nicht. DOS ist alles mögliche, aber nicht echtzeitfähig. Es mag einfacher sein, für bestimmte Aufgaben mit DOS-Programmen ein zeitlich deterministisches Verhalten zu erzielen, aber dann dürfen diese Programme keine der Funktionen verwenden, für die das "D" steht (Dateisystemzugriffe). Sobald mit etwas größeren Datenmengen gearbeitet werden soll oder auch nur irgendeine rudimentäre Art des Multitasking erforderlich ist, versagt DOS. DOS läuft im x86-Realmode, mit der wundervollen Segmentitis und einem auf 1 MByte beschränkten Adressraum. Scheduler? Fehlanzeige. (Ernsthafte) Devicetreiber? Fehlanzeige. Unterstützung modernerer Hardware, die nicht mit plumpen I/O-Befehlen angesprochen werden kann, da deren I/O-Adressen nicht feststehen (PnP, PCI etc.) ist so ohne weiteres nicht möglich. Grauenerregend schlechte Performance bei Dateisystemzugriffen, keine Dateinamen (ich weigere mich, 8.3-Kürzel als Dateinamen zu bezeichnen) ... naja, da muss ich nicht weiter drauf 'rumreiten. Je nach Anforderungen an die "Echtzeitfähigkeit" können übrigens die ernstgemeinten Windows-Versionen durchaus als zumindest "weich" echtzeitfähig bezeichnet werden; wenn allerdings Reaktionsgeschwindigkeiten unter 1 msec erforderlich sind, dann hängt das stark von der verwendeten Hardware ab und überfordert üblicherweise den durchschnittlichen Programmierer, da man in diesem Falle kaum um das Schreiben eigener Devicetreiber umhinkommt. Es gibt allerdings auch kommerzielle Toolkits, die einem diesbezüglich das Leben stark vereinfachen können, wie beispielsweise die Produkte von www.kithara.de. Bei einem abgeschlossenen System erscheint jedoch die Verwendung eines "richtigen" Echtzeitbetriebssystems ratsam, da gibt es beispielsweise QNX, OS-9000 (Microware) und für Leute, die Win32-Programmierung gewohnt sind, das RTOS-32 von der Firma OnTime. Nicht zu vergessen diverse mehr oder weniger echtzeitfähig gemachte Linux-Varianten.
Aber auf alle fälle hat man in DOS nicht das problem des Multitaskings (außer man programmiert es) und kann somit auf Änderungen an den Schnittstellen sofort reagieren und muss nicht warten, bis der das Programm wider an der Reihe ist. Das Problem sehe ich ja täglich bei meiner Arbeit. Mal steht das Förderband wie es soll, mal wider nicht, es hat sich dabei aber nichts geändert, außer dass ein 2. Programm gestartet wurde. Wie soll es sonst möglich sein z.B. Schrittmotoren in DOS direkt über die Parallele Schnittstelle (über Schrittmotorendstufen) zu steuern und warum klappt das dann nicht in Windows? Weil es da das Multitasking ständig gibt, ..... Echtzeitdateizugriffe sind in DOS auch nicht möglich, aber es ist möglich, ohne nennenswerte Verzögerung auf Schnittstellen zuzugreifen und auf Änderungen der Schnittstellen zu reagieren.
Nun, für den ersten Fall ist bei "richtiger" Hardware der Interrupt erfunden worden, und das schon lange, bevor IBM die Grundschaltung des Parallelports verbrochen hat. Hardware, die bei Ereignissen Interrupts auslösen kann, ermöglicht das Reagieren auf Ereignisse, ohne daß gepollt werden muss, so daß diese Ereignisse auch von richtigen Betriebssystemen bearbeitet werden können. Wie vieles andere am Design des IBM PC ist die parallele Schnittstelle ein Paradebeispiel dafür, wie man Hardware gerade nicht aufbauen sollte. Ich kenne das PC-Design recht gut (habe ein original IBM Hardware Reference Manual des IBM PC/XT, in dem neben vollständigen Schaltplänen auch ein kommentiertes BIOS-Assemblerlisting abgedruckt ist), und habe des öfteren den Verdacht gewonnen, daß das ganze als Studentenulk von einigen Werkstudenten entwickelt wurde, die zeigen wollten, was man alles falsch machen kann ... schlimmerweise hat dann irgendeine Marketing-Drohne das Zeug gesehen und irgendeinem Vorgesetzten vorgeführt, der aufgrund seiner durch die Position inhärenten Inkompetenz das ganze als geniale Idee verstand und produzieren ließ; die Werkstudenten trauten sich dann nicht mehr, das ganze als den Murks bloßzustellen, als der er ursprünglich gedacht war. Das ist zwar nur eine Theorie, aber ich fürchte, daß sie zutreffen könnte. - Interruptleitungen mit Active-High-Pegeln - bei 64K I/O-Adressraum (16 Adressleitungen) nur 1K (10 Adressleitungen) ausdecodieren sind nur zwei der grundlegenden Designfehler des PC-Designs. Die "Weiterentwicklung" zum PC/AT hat dann den Schwachsinn erst recht zementiert, ich sach' nur "A20-Gate". Sei's drum. Die parallele Schnittstelle für die Ansteuerung von irgendwas anderem als Druckern zu verwenden, ist eine Frickellösung. Leider sieht das ursprüngliche PC-Design von ISA-Karten abgesehen keine brauchbare Schnittstelle für einfache Hardwareansteuerung vor, daher ist es zumindest verständlich, daß diese Schnittstelle so oft (fehl)verwendet wird. Die Probleme liegen auf der Hand, sobald ein Betriebssystem ins Spiel kommt: Polling (zyklisches Abfragen) verbietet sich unter jedem Multitaskingbetriebssystem, ob es nun irgendein Windows oder auch was anderes ist.
Zur Frage: Vielleicht hilft "conio.h"? (Siehe http://www.geocities.com/SiliconValley/Lakes/7156/laser.htm) Zum übergeordneten Problem: > ich sach' nur "A20-Gate". Hehe, Du folterst die Wissenden.... Andererseits.....das "A15"-Gate meines ersten CP/M-Rechners war schon genial (nicht meine Idee). ... Der Erfolg der Fehlkonstruktion PC (mehr noch: AT) hat den gleichen Grund, der auch MS zum Erfolg führte: IBM hat schlicht nichts dagegen unternommen, daß in Taiwan alles gnadenlos nachgebaut wurde. Ebenso wie MS nichts dagegen hat, wenn die Leute sich privat XP-Professional und Office kopieren. Falk P.S.: Bei Betriebssystem können "open", "ioctl", "read", "write" und "close" fast alle Probleme lösen.
> ich sach' nur "A20-Gate".
Und selbst im neusten P4/Athlon ist dieses steinzeitliche Gemurkse noch
drin. Als ob da noch jmd ein System draufpackt, dass diesen Wrap
braucht...
@AiM
Wäre es nicht sinnvoller auf einem Steuerrechner nicht während des
betriebs Programme zu starten, sondern diesen Rechner unr dafür zu
verwenden? Was spricht denn jetzt gegen ein echtes Echtzeitsystem? Also
eines, das auch etwas mehr komfort bietet.
>>Was spricht denn jetzt gegen ein echtes Echtzeitsystem? Also
eines, das auch etwas mehr komfort bietet.
Also bei den echten Echtzeitbetriebssystemen die ich kenne: Einfach der
Preis.
Wenn jemand was anderes kennt gibt es nichts dagegen einzuwenden sich
so etwas zumindest mal anzusehen.
Also ... was echte Echtzeit angeht ... ein stinknormaler PC kann das. Habe selbst - mit Tools von RT-DOS (o.ä.) - damit programmiert. Schon etwa 2000 gab es Beschreibungen, wie man den Linux-Kernel Echtzeitfähig machen kann (ich glaube in Linux Magazin). Damit, und einem alten PC sollte das Argument 'Geld' keine Rolle mehr spielen ;-) Günter
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.