PC hardwarenah programmieren - welches OS - welche Sprache

[Johannes Bauer]

Henning Paul wrote:

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...

Nö, das geht freilich nicht. Aber es passieren auch schon ohne die
Hardware genug Programmierfehler, besonders bei "komplexen" Strukturen
wie (doppelt) verlinkten Listen oder ähnlichem, wo man mal schnell nen
Pointer etwas zu weit verschoben hat. Da ist UML unschlagbar.

Gruß,
Johannes

 

[B. Spitzer]

Hallo Jan,

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
Aber bitte schön neu Simulieren und das Timing kontrollieren!!

zu schreiben. Und damit sind auch Reaktionszeiten im
10tel/100stel-Nanosekundenbereich machbar.
Wow! FPGAs, die mit 10 bzw. 100GHz rennen. Von welcher Fima sind

die denn? Oder sollte hier ľs stehen? Und auch da ist bisweilen
mehr als ein Taktzyklus nötig, bis die Reaktion da ist.

tschuessle
Bernhard Spitzer
--
bash.org - Top 100...
<erno> hm. I've lost a machine.. literally _lost_. it responds to ping, it
works completely, I just can't figure out where in my apartment it is.

 

[Henning Paul]

Johannes Bauer schrieb:

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

Nö, das geht freilich nicht. Aber es passieren auch schon ohne die
Hardware genug Programmierfehler, besonders bei "komplexen" Strukturen
wie (doppelt) verlinkten Listen oder ähnlichem, wo man mal schnell nen
Pointer etwas zu weit verschoben hat. Da ist UML unschlagbar.

Das glaube ich gern. In einer der letzten c'ts gabs aber eine kostenlose
Lizenz für VMware 4.5. Das ist dann sogar noch schöner, USB-Geräte lassen
sich durchschleifen. Das ist bei meinem USB-Gebastel schon sehr nützlich
gewesen.

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

 

[Hans-Georg Lehnard]

"Wolfgang Weinmann" schrieb

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

Die Sprache ist zwar grundsätzlich egal, aber es hat schon einen Grund,
warum Betriebssysteme in C geschrieben werden.

Echzeitreaktionen in us Grössenordnung kannst du dir bei einem
Betriebssystem, welches üblicherweise auf PC's läuft abschminken.

1. Muss erst einmal dein Interrupt vom Prozessor angenommen werden, wenn er
nicht gerade durch einen anderen gesperrt ist. (Plattenzugriff,
Netzwerkkarte, DMA usw können schon mal für einige 100ms sperren)
2. Dann liest deine Interruptroutine z.B. was von einem Port in den Speicher
und setzt ein Flag, dass Daten da sind.
3. der nächte Timerinterrupt (100ns - 1ms üblich) startet den Sceduler und
der schaut dann nach wer auf dieses Datum gewartet hat. Wenn deine Task zum
verarbeiten der Daten dann die höchste Priorität hat kommt sie dann dran.
4. Jetzt müssen nur noch die Register des unterbrocenen Prozesses gesichert
werden und die deiner Task geladen werden. Da du auch noch mit floating
point arbeiten willst kommen noch die floting point Register dazu. Kernels
und Sceduler benutzen keine floating point routinen.
4. jetzt ist deine Task dran und kann die Reaktion auf ein Ausgabeport
schreiben oder sonst was tun.

Da kannst du froh sein wenn du garantierte und nicht zufällige ms schaffst.

Gruß

Hans-Georg

 

[Stefan Schulte]

Hallo!

"Hans-Georg Lehnard" <hans-georg.lehnard@gmx.de> schrieb im Newsbeitrag
news:djltmg$2bc1$1@ulysses.news.tiscali.de...

"Wolfgang Weinmann" schrieb

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

Die Sprache ist zwar grundsätzlich egal, aber es hat schon einen Grund,
warum Betriebssysteme in C geschrieben werden.

Echzeitreaktionen in us Grössenordnung kannst du dir bei einem
Betriebssystem, welches üblicherweise auf PC's läuft abschminken.
[...]

.... vielleicht nochmal der Hinweis, daß der OP derzeit bereits unter
DOS (also einem nicht Realzeit-fähigem OS) programmiert. Es schien ihm
darum zu gehen, auf "moderne" Hardware wie z.B. USB zugreifen zu können,
ohne gleich um den Faktor 10^3 schlechter zu werden, und Grafik-(o.ä.)-
Routinen des OS verwenden zu können.

Ich habe auch schon mal daran gedacht und bin auf RT-Linux und FreeDOS gestoßen.
Allerdings habe ich zeitkritische Sachen auch eher für AVR oder CPLDs geplant.
(Sollte ich also zu sehr von mir auf andere geschlossen haben - tschuldigung

cu

Stef@n

 

[Stefan Schulte]

Hallo!

"Hans-Georg Lehnard" <hans-georg.lehnard@gmx.de> schrieb im Newsbeitrag
news:djltmg$2bc1$1@ulysses.news.tiscali.de...

"Wolfgang Weinmann" schrieb

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

Die Sprache ist zwar grundsätzlich egal, aber es hat schon einen Grund,
warum Betriebssysteme in C geschrieben werden.

Echzeitreaktionen in us Grössenordnung kannst du dir bei einem
Betriebssystem, welches üblicherweise auf PC's läuft abschminken.
[...]

.... vielleicht nochmal der Hinweis, daß der OP derzeit bereits unter
DOS (also einem nicht Realzeit-fähigem OS) programmiert. Es schien ihm
darum zu gehen, auf "moderne" Hardware wie z.B. USB zugreifen zu können,
ohne gleich um den Faktor 10^3 schlechter zu werden, und Grafik-(o.ä.)-
Routinen des OS verwenden zu können.

Ich habe auch schon mal daran gedacht und bin auf RT-Linux und FreeDOS gestoßen.
Allerdings habe ich zeitkritische Sachen auch eher für AVR oder CPLDs geplant.
(Sollte ich also zu sehr von mir auf andere geschlossen haben - tschuldigung

cu

Stef@n

 

[Martin Klaiber]

Hans-Georg Lehnard <hans-georg.lehnard@gmx.de> wrote:

"Wolfgang Weinmann" schrieb

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

Die Sprache ist zwar grundsätzlich egal, aber es hat schon einen Grund,
warum Betriebssysteme in C geschrieben werden.

Wird zwar langsam OT, aber dennoch möchte ich erwähnen, dass es auch
Betriebssysteme gibt, die nicht in C geschrieben sind (z.B. Oberon, ok,
ist kein Mainstream), und bevor sich Unix durchsetzte, war das AFAIK
der Normalzustand. Ich würde also sagen, der große Verdienst von C, das
IIRC bei der Entwicklung von Unix 'erfunden' wurde, ist die Abstraktion
von der Hardware, womit es möglich wurde, unterschiedliche Hardware in
der gleichen Sprache zu programmieren. Mit Echtzeitanforderungen hatte
die Entwicklung von C AFAIK aber nichts zu tun.

Echzeitreaktionen in us Grössenordnung kannst du dir bei einem
Betriebssystem, welches üblicherweise auf PC's läuft abschminken.

Erstens das, und wenn es ganz genau werden soll (was der OP wohl nicht
anstrebt), dann muss auch die Sprache selbst echtzeitfähig sein. Ob C
das leisten kann, weiß ich nicht. Ich benutze meist Ada, das soll laut
Spezifikation echtzeitfähig sein, habe es so aber noch nie benutzt.

Martin

 

[Nick Müller]

Martin Klaiber <martinkl@zedat.fu-berlin.de> wrote:

ist die Abstraktion von der Hardware, womit es möglich wurde,
unterschiedliche Hardware in der gleichen Sprache zu programmieren.

Das ist aber nicht C zu verdanken, sondern dessen libraries.

Mit Echtzeitanforderungen hatte die Entwicklung von C AFAIK aber nichts zu
tun.

C wird auch gerne als Hochsprachen-Assembler bezeichnet. Der "Verdienst"
von C ist die Möglichkeit recht nahe an die Hardware zu kommen.
Mit Pascal, Modula etc. eher eine absurde Idee.


Gruß,
Nick

--
Motor Modelle // Engine Models
http://www.motor-manufaktur.de