1. Home
  2. Electronics (German)
  3. PC hardwarenah programmieren - welches OS - welche Sprache
  4. Page 2

PC hardwarenah programmieren - welches OS - welche Sprache

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

Reply to
Johannes Bauer
Loading thread data ...

Hallo Jan,

Aber bitte schön neu Simulieren und das Timing kontrollieren!!

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...
 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.
Reply to
B. Spitzer

Johannes Bauer schrieb:

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
Reply to
Henning Paul

"Wolfgang Weinmann" schrieb

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

Reply to
Hans-Georg Lehnard

Hallo!

"Hans-Georg Lehnard" schrieb im Newsbeitrag news:djltmg$2bc1$ snipped-for-privacy@ulysses.news.tiscali.de...

[...]

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

Reply to
Stefan Schulte

Hallo!

"Hans-Georg Lehnard" schrieb im Newsbeitrag news:djltmg$2bc1$ snipped-for-privacy@ulysses.news.tiscali.de...

[...]

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

Reply to
Stefan Schulte

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.

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

Reply to
Martin Klaiber

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

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
Reply to
Nick Müller

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.