mikrocontroller.net

Forum: PC-Programmierung Serielle & Parallelle Schnittstelle in C++


Autor: Michael A. (aim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael A. (aim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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 :)

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael Aigner
Ich denke auf dieser Seite solltest du fündig werden
http://www.franksteinberg.de/

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael A. (aim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael A. (aim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Willberg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Michael A. (aim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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.

Autor: Günter Wallnig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.