PC hardwarenah programmieren - welches OS - welche Sprache

[Wolfgang Weinmann]

Hallo,

ich setze den PC für Meßaufgaben ein. Und das bis heute unter Dos mit
Borland-Pascal 7auf einem Pentium-4-Rechner mit 3GHz.!!!

Eigentlich kann ich damit alle meine Messungen durchführen. Mir ist
halt kein Zugriff auf USB und neueres bekannt.

Mit was (OS und Sprache) programmiert ihr einen Pc, wenn es ans
eingemachte geht und harte Echtzeitbedingungen anstehen?

Gruß

Wolfgang

 

[Martin Laabs]

Wolfgang Weinmann <Wolfgangweinmann@aol.com> wrote:

Mit was (OS und Sprache) programmiert ihr einen Pc, wenn es ans
eingemachte geht und harte Echtzeitbedingungen anstehen?

Es gibt zwar RT-Linux aber so wirklich schön ist das nicht. Wenn
es klein und übersichtliche sein soll kannst du es mit ecos versuchen.
Ansonsten ist auch QNX erwähnenswert was jedoch etwas kostet.

Tschüss
Martin L.

 

[Rainer Ziegenbein]

Wolfgang Weinmann wrote:

Mit was (OS und Sprache) programmiert ihr einen Pc, wenn es
ans eingemachte geht

Linux/Pascal.

und harte Echtzeitbedingungen anstehen?

.... die standen bei mir allerdings nicht.


Grusz,
Rainer

 

[Matthias Weingart]

Rainer Ziegenbein <rainer.ziegenbein@e-technik.tu-chemnitz.de> wrote in
news:435A4676.9353D236@e-technik.tu-chemnitz.de:

Wolfgang Weinmann wrote:

Mit was (OS und Sprache) programmiert ihr einen Pc, wenn es
ans eingemachte geht

Linux/Pascal.

Es gibt da ja RT-Linux... Ob man allerdings USB als Echtzeitmedium
betrachten kann, kommt halt drauf an, was bei Dir Echtzeit ist (1ms?).

M.
--
Bitte auf mwnews2@pentax.boerde.de antworten.

 

[Rainer Ziegenbein]

Matthias Weingart wrote:

Wolfgang Weinmann wrote:

Mit was (OS und Sprache) programmiert ihr einen Pc, wenn es
ans eingemachte geht

Linux/Pascal.

Es gibt da ja RT-Linux...

Ja, ich weiss. Hab ich noch nicht probiert, steht aber auf der
Liste.

Ob man allerdings USB als Echtzeitmedium betrachten kann,
kommt halt drauf an, was bei Dir Echtzeit ist (1ms?).

Na, eher darauf, was bei Wolfgang Echtzeit ist.

Ich habe seine Frage so verstanden, dass er einen Ersatz fuer
DOS+BorlandPascal sucht - und das ist bei mir Linux+FreePascal
(das uebrigens eine TurboPascal-Kompatibilitaetsmodus hat).

Wenn er wirklich echte Echtzeit sucht, ist klar, dass er auch
ein echtes Echtzeitsystem benutzen sollte.


Grusz,
Rainer

 

[Wolfgang Weinmann]

Ob man allerdings USB als Echtzeitmedium betrachten kann,
kommt halt drauf an, was bei Dir Echtzeit ist (1ms?).

Also bei meiner Motorsteuerung kommt es auf Reaktionszeiten im
Mikrosekundenbereich an .....

Wenn er wirklich echte Echtzeit sucht, ist klar, dass er auch
ein echtes Echtzeitsystem benutzen sollte.

Also mit DOS funktioniert das

Es gibt zwar RT-Linux aber so wirklich schön ist das nicht. Wenn
es klein und übersichtliche sein soll kannst du es mit ecos
versuchen.
Ansonsten ist auch QNX erwähnenswert was jedoch etwas kostet.

RTLinux habe ich mal angesehen - so toll bezüglich Echtzeitfähigkeit
ist das gar nicht.

Mir geht es darum, daß ich die Systeminterrupts (Timer, Schnittstellen
....) selber nutzen kann und eigene Interruptservice-Routinen einhängen
kann, daß ich auf die Ports zugreifen kann usw...

Gruß

Wolfgang

 

[Rafael Deliano]

Also bei meiner Motorsteuerung kommt es auf Reaktionszeiten im
Mikrosekundenbereich an .....
Mir geht es darum, daß ich die Systeminterrupts (Timer,
Schnittstellen ...) selber nutzen kann und eigene > Interruptservice-Routinen einhängen
kann, daß ich auf die Ports zugreifen kann usw...

Dann wäre ein Mikrocontrollerboard angemessener. PCs sind nicht
für die Sorte Anwendung gedacht.

MfG JRD

 

[Jan Lucas]

Wolfgang Weinmann wrote:

RTLinux habe ich mal angesehen - so toll bezüglich Echtzeitfähigkeit
ist das gar nicht.

Mir geht es darum, daß ich die Systeminterrupts (Timer, Schnittstellen
...) selber nutzen kann und eigene Interruptservice-Routinen einhängen
kann, daß ich auf die Ports zugreifen kann usw...

Also so dicht wie bei DOS wirst du wohl nirgends rankommen. Bei RTLinux
wirst du wohl ein eigenes Kernelmodul schreiben müssen. Schon mal
darüber nachgedacht, die besonders zeitkritischen Sachen in einen
Microcontroller auszulagern, und den PC so von den Echtzeitanforderungen
zu befreien?

Jan

 

[Rainer Ziegenbein]

Wolfgang Weinmann wrote:

(Bitte zukuenftig nicht alle Zitatebenen ineinandermischen.
Das verwirrt ungemein. Danke.)

Ob man allerdings USB als Echtzeitmedium betrachten kann,
kommt halt drauf an, was bei Dir Echtzeit ist (1ms?).

Also bei meiner Motorsteuerung kommt es auf Reaktionszeiten
im Mikrosekundenbereich an .....

Wuerde ich nicht mit einem PC machen. Overkill.

Ich war mal beruflich gezwungen, eine Art Speicheroszi fuer
NF per AD-Wandler-Karte und Software zu realisieren. Meine
Schlussfolgerung daraus: Ist Quatsch. Das Aufwand-Nutzen-
Verhaeltnis stimmt nicht wirklich.

Mir geht es darum, daß ich die Systeminterrupts (Timer,
Schnittstellen...) selber nutzen kann und eigene
Interruptservice-Routinen einhängen kann, daß ich auf die
Ports zugreifen kann usw...

Das geht mMn alles unter Linux, aber wenn Du Reaktionszeiten
kleiner 1ms garantieren musst, wuerde ich das nicht machen.


Grusz,
Rainer

 

[Dirk Ruth]

Wolfgang Weinmannschrieb:
"

Hallo,

ich setze den PC für Meßaufgaben ein. Und das bis heute unter Dos mit
Borland-Pascal 7auf einem Pentium-4-Rechner mit 3GHz.!!!

Eigentlich kann ich damit alle meine Messungen durchführen. Mir ist
halt kein Zugriff auf USB und neueres bekannt.

Mit was (OS und Sprache) programmiert ihr einen Pc, wenn es ans
eingemachte geht und harte Echtzeitbedingungen anstehen?

uCosII aber nicht für USB.

Dirk

 

[Wolfgang Weinmann]

Dann wäre ein Mikrocontrollerboard angemessener. PCs sind nicht
für die Sorte Anwendung gedacht.

Das kommt dann in zweiter Instanz. Zuerst möchte ich eine möglichst
komfortable Entwicklungsumgebung mit viel Speicher und wenig
Begschränkungen. Und das stellt für mich mein PC mit einer AD/DA/IO-
und einer Timerkarte dar. Und mit dem PC kann ich auch Floatingpoint
bequem einsetzen, alle möglichen komplizierten math. Funktionen usw.
Mit nem Controller siehts da nicht so gut aus.

Schon mal darüber nachgedacht, die besonders zeitkritischen Sachen in > einen Microcontroller auszulagern, und den PC so von den
Echtzeitanforderungen zu befreien?

Das wäre für mich ein Rückschritt - mit DOS bekomme ich meine
zeitkritischen Bereiche mit dem PC in den Griff

mfG

Wolfgang

 

[Klaus P. Pieper]

Wolfgang Weinmann schrieb:

Das kommt dann in zweiter Instanz. Zuerst möchte ich eine möglichst
komfortable Entwicklungsumgebung mit viel Speicher und wenig
Begschränkungen. Und das stellt für mich mein PC mit einer AD/DA/IO-
und einer Timerkarte dar. Und mit dem PC kann ich auch Floatingpoint
bequem einsetzen, alle möglichen komplizierten math. Funktionen usw.
Mit nem Controller siehts da nicht so gut aus.

Ich habe früher dafür einmal den Watcom C++-Compiler mit dem
mitgelieferten DOS-Extender eingesetzt. Für meine Zwecke hatte ich damit
genügend Speicher, und die Reaktionszeiten waren trotz DOS-Extender OK.
Der Watcom-C++ wurde irgendwann einmal unter www.openwatcom.org frei zur
Verfügung gestellt, auf der Website steht auch, dass weiterhin
DOS-Extender mitgeliefert werden.

Und wenn es besonder komfortabel werden soll, kannst Du eine
PCI-CPU-Karte unter DOS für die Steuerung benutzen und die Darstellung
unter Linux / Windows auf dem Haupt-PC machen.

Gruß

Klaus


--
reply to pub . kp2 . pieper at ibeq . com

 

[Michael Schwingen]

In article <1130002140.375343.196780@g47g2000cwa.googlegroups.com>,
Wolfgang Weinmann <Wolfgangweinmann@aol.com> wrote:

Mir geht es darum, daß ich die Systeminterrupts (Timer, Schnittstellen
...) selber nutzen kann und eigene Interruptservice-Routinen einhängen
kann, daß ich auf die Ports zugreifen kann usw...

Sprich: Du willst eigentlich gar kein Betriebssystem, sondern direkt auf der
Hardware rumfummeln, so wie bei DOS.

Auch bei einem RT-System sind Timer, Schnittstellen etc. Sache des
Betriebssystems - und Interruptserviceroutinen kann man bei jedem System
einhängen, wenn man einen Gerätetreiber schreibt.

cu
Michael
--
Some people have no repect of age unless it is bottled.

 

[Jürgen Appel]

Martin Laabs schrieb:

Wolfgang Weinmann <Wolfgangweinmann@aol.com> wrote:

Mit was (OS und Sprache) programmiert ihr einen Pc, wenn es ans
eingemachte geht und harte Echtzeitbedingungen anstehen?

Es gibt zwar RT-Linux aber so wirklich schön ist das nicht. Wenn
es klein und übersichtliche sein soll kannst du es mit ecos versuchen.
Ansonsten ist auch QNX erwähnenswert was jedoch etwas kostet.

Was ist daran (RT-Linux) unschön?

Es ist wirklich echtzeitfähig (selbst bei DOS muß man da aufpassen, es gibt
üble TSRs, die möglicherweise zweitweise die Interrupts abschalten).
Realtime-Linux hat dann noch den Vorteil, daß man Linux als komfortables
Datenverarbeitungssystem mit dabei hat.
Man muß allerdings den echten Echtzeit-Teil seiner Software vom
nicht-Echtzeitteil (GUI, zeitunkritische Datenverarbeitung, ...) trennen.
Ersterer kommt in ein passendes Kernelmodul, das dann allerdings auch die
Linux-Systemfunktionen nicht benutzen kann und letzter läuft als normaler
Linux-Prozess.

Gruß
Jürgen

--
GPG key:
http://pgp.mit.edu:11371/pks/lookup?search=J%FCrgen+Appel&op=get

 

[Rafael Deliano]

Das kommt dann in zweiter Instanz. Zuerst möchte ich eine möglichst
komfortable Entwicklungsumgebung mit viel Speicher und wenig
Begschränkungen.
Wenn das "embedded"-Produkt mit einem Industrie-PC

ausgeliefert wird, fein. Wenns am Ende aus pekuniären Gründen
bestenfalls ein ARM wird kann Luxusdemo auf PC auch Irrweg sein.
Ich kann mich an Leute erinnern die in 80er Jahren Sprach-
erkennungssysteme auf Sun-Workstations in Lisp programmierten
irgendwann fertig waren und dann "eben mal" auf billige Hardware
runterportieren wollten um zu verkaufsfähigem Produkt zu kommen:
von der Firma hat man nie mehr was gehört.

Floatingpoint
Behelfsmässig kann man zu Entwicklungszwecken alte FPUs wie MC68882

an Controller oder 8 Bit CPUs hängen
( http://www.embeddedFORTH.de Heft 7 ) allerdings ist der Aufwand
an Treibersoftware hoch und die Geschwindigkeit wegen des
komplizierten Zugriffs gebremst.

MfG JRD

 

[Jan Stumpf]

Hi!

Das kommt dann in zweiter Instanz. Zuerst möchte ich eine möglichst
komfortable Entwicklungsumgebung mit viel Speicher und wenig
Begschränkungen.
Das ist alle eine Frage der Grösse des ľC. Um z.B. ein 80C167

auszulasten musste schon verdammt viel rechnen. Und als EVA-Board gibt's
die auch einfach fertig zu kaufen. Wobei ich bis jetzt selbst mit nem
AtMega16 seltenst an Grenzen gestossen bin. Der ist schon verdammt schnell.

Eine Alternative würde ich aber noch in die Diskussion werden: Schonmal
an CPLDs/FPGAs gedacht? Da spielt die Komplexität im wesentlichen keine
Rolle, weil wenns zu komplex wird nimmt man halt den nächst größeren
ohne auch nur eine Zeile VHDL-Code neu zu schreiben. Und damit sind auch
Reaktionszeiten im 10tel/100stel-Nanosekundenbereich machbar.

Und das stellt für mich mein PC mit einer AD/DA/IO-

und einer Timerkarte dar. Und mit dem PC kann ich auch Floatingpoint
bequem einsetzen, alle möglichen komplizierten math. Funktionen usw.
Mit nem Controller siehts da nicht so gut aus.
Das ist ansich ein Krampf. Der PC wird damit für etwas verwendet, wüfür

er nicht gedacht ist.

Schon mal darüber nachgedacht, die besonders zeitkritischen Sachen in > einen Microcontroller auszulagern, und den PC so von den
Echtzeitanforderungen zu befreien?


Das wäre für mich ein Rückschritt - mit DOS bekomme ich meine
zeitkritischen Bereiche mit dem PC in den Griff
Die Schwierigkeit ist halt, wenns mal nicht funktioniert, suchste ewig

den Fehler. Du stellst die Basis deines gesamten Systems auf wacklige
Beine. Und das ist nicht gut!


mfg
Jan

 

[Martin Laabs]

Jürgen Appel <jappel@linux01.gwdg.de> wrote:

Martin Laabs schrieb:

Realtime-Linux hat dann noch den Vorteil, daß man Linux als komfortables
Datenverarbeitungssystem mit dabei hat.

Und das es groß und speicherintensiv ist.

Ersterer kommt in ein passendes Kernelmodul, das dann allerdings auch die
Linux-Systemfunktionen nicht benutzen kann und letzter läuft als normaler
Linux-Prozess.

Hast du schon mal ein Kernelmodul programmiert? Ich schon. Und ich muss
sagen das es nicht besonders komfortabel ist. Mit einem kleinen Fehler
muss man z.B. gleich neu boote.
Das ist bei DOS und co. zwar nicht unbedingt anders aber es geht viel
schneller.
Am Ende ist es nur ein Aufsatz (der weit in das System eingreift) für
ein Betriebssystem welche nie dafür gedacht war.

Tschüss
Martin L.

 

[Jürgen Appel]

Martin Laabs schrieb:

Realtime-Linux hat dann noch den Vorteil, daß man Linux als komfortables
Datenverarbeitungssystem mit dabei hat.
Und das es groß und speicherintensiv ist.

Das kommt darauf an, was man sonst noch alles will. Der Linux-Kernel selbst
paßt immer noch auf eine Floppy. Zugegebenermaßen lohnt sich dann i.a.
allerdings ein PC nicht mehr, weil der Hauptvorteil ja ist, daß man auch
normale Software drauf laufen hat. Andere Vorteile sind moderne Treiber
für Hardware wie z.B. Netzwerkkarten und (große) Festplatten.

Ersterer kommt in ein passendes Kernelmodul, das dann allerdings auch
die Linux-Systemfunktionen nicht benutzen kann und letzter läuft als
normaler Linux-Prozess.

Hast du schon mal ein Kernelmodul programmiert?
Ja, mehrere (Realtime-Linux Hochgeschwingigkeitskamera-treiber,

ADC-Treiber)

Ich schon. Und ich muss
sagen das es nicht besonders komfortabel ist. Mit einem kleinen Fehler
muss man z.B. gleich neu boote.

Ja, das kann (und wird) passieren. Das ist nunmal immer das Problem, wenn
man direkt an der Hardware rumfummelt. Andererseits sind die Teile des
Systems, die wirklich Echtzeit benötigen meist gar nicht so umfangreich
und kompliziert und können deshalb klein und einfach gehalten werden.

Die meisten Fehler macht man bei unwichtigerem Kram wie einem grafischen
Benutzerinterface oder der Datenauswertung. Das aber ist dann ein normaler
Linux-Prozess.

Das ist bei DOS und co. zwar nicht unbedingt anders aber es geht viel
schneller.

Am Ende ist es nur ein Aufsatz (der weit in das System eingreift) für
ein Betriebssystem welche nie dafür gedacht war.

Der Eingriff ist gar nicht so weitgehend. Bei RTLinux läuft einfach ein
anderes sehr kleines Realtime-OS, das den Linux-Kernel als Idle-Task
ausführt. Linux selbst wird gar nicht so sehr verändert.
(Mag sein, daß sich da in den neueren Versionen mehr getan hat. Meine
Programmiererlebnisse in diesem Bereich liegen einige Jahre zurück).

Gruß
Jürgen
--
GPG key:
http://pgp.mit.edu:11371/pks/lookup?search=J%FCrgen+Appel&op=get

 

[Johannes Bauer]

Martin Laabs wrote:

Hast du schon mal ein Kernelmodul programmiert? Ich schon. Und ich muss
sagen das es nicht besonders komfortabel ist. Mit einem kleinen Fehler
muss man z.B. gleich neu boote.

Mit der 2.6er hat sich viel getan (forced module unloading z.B.). Und es
gibt drüberhinaus UML. Beides zusammen macht Kernelentwicklung
verglichen mit anderen Betriebsystemen (Windows, Solaris) erheblich
komfortabler.

Gruß,
Johannes

 

[Henning Paul]

Johannes Bauer schrieb:

Mit der 2.6er hat sich viel getan (forced module unloading z.B.). Und es
gibt drüberhinaus UML. Beides zusammen macht Kernelentwicklung
verglichen mit anderen Betriebsystemen (Windows, Solaris) erheblich
komfortabler.

Ja, aber in einer Virtuellen Maschine _hardwarenah_ programmieren? Das will
ich sehen, ob da inb()s und outb()s funktionieren...

Gruß
Henning
--
henning paul home: http://www.geocities.com/hennichodernich
PM: henningpaul@gmx.de , ICQ: 111044613