Re: MAX232

In article , =?UTF-8?B?SsO8cmdlbg==?= Appel writes: |> |> Windows war noch nie ein Realtime-OS. Theoretisch konnte Dein Programm an |> jeder beliebigen Stelle (z.B. zum Swappen) durchaus für eine Sekunde |> unterbrochen werden. Timing war nie garantiert, auch wenn es in der Praxis |> fast immer funktioniert haben mag.

Au contraire. Wenn es ein sauber programmierter Treiber ist, der auch brav mit Root-Rechten läuft, tut sich das OS im Zweifelsfall etwas schwer, dem das System kurzzeitig wegzuziehen.

Fällt zwar auch nicht unter die feine englische Art, aber wir sprechen hier schließlich auch von Konzepten, die älter sind als Windows.

Ich finde es in solchen Diskussionen immer spannend, wenn plötzlich der Fokus auf Windows gelenkt wird, als wäre das das einzige und allumfassende OS. Gerade im Embedded- und Industrial-Bereich ist es das nicht, auch wenn sich Microsoft alle Mühe gibt, auch dort die Rechnerlandschaft mit ihrer Seuche zu überziehen.

Rainer

Rainer Buchty schrieb:

Bei Treibern mag das wohl so sein, aber auch ein Treiber macht Windows nicht zum Realtime-OS: Einmal die Kontrolle abgegeben (damit nicht der Rest des Systems nicht stehenbleibt), gibt es keine Garantie die Kontrolle zu fester Zeit wiederzubekommen, wenn gerade ein anderer Treiber genauso denkt wie oben beschrieben.

Nicht ohne Grund gibt es für timingkritische Anwendungen spezielle Betriebssysteme (z.B. auch RTLinux, RTAI und andere)

Wir sprachen von seriellen Schnittstellen, Microsofts Meinung, diese seien genau wie parallele Schnittstellen veraltet und die Tatsache daß deren neueste Softwareversion angeblich schon keine Unterstützung für parallele Schnittstellen mehr besitzt.

Da gibt es aber auch keinerlei Probleme serielle Schnittstellen zu bekommen und dort, wo es auf genaues Timing ankommt, ist es bedeutend einfacher, das durch die Auswahl geeigneter Software auch zuverlässig realisieren zu können.

Gruß, Jürgen

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

Äähm...wenn ich nicht ganz irre, dann sitzt die MMU im 68882 - das ist nämlich genau das setup, mit dem mein Amiga werkelt, 68030+68882.

--

Ralph.

http://www.dk5ras.de/
Skispringen für Jedermann:
http://www.wsv08lauscha.de/veranstaltungen/jedermann/Tageskurs_Startseite.htm

Der Unterschied zwischen 020 und 030 ist eben intern eine MMU und Data-Cache. Die 020 hatte die MMU noch als externen Chip.

Beim 040 ist die MMU noch mehr simpliziert worden und größtenteils in Hardware realisiert, während es beim 030 noch Microcode war.

- Henry

--
www.ehydra.dyndns.info

881/882 waren die FPUs. Die einzelnen MMUs waren 68451 bzw. 68551.

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias

In article , "Ralph A. Schmid, dk5ras" writes: |> |> Äähm...wenn ich nicht ganz irre, dann sitzt die MMU im 68882 - das ist |> nämlich genau das setup, mit dem mein Amiga werkelt, 68030+68882.

68882=FPU

Rainer

Rainer Buchty schrieb:

So isses. Damals[TM] hatte ich ein Weile damit zu tun, in HP-Rechnern Platinen mit 68030/68882 gegen den dann endlich lieferbaren 68040 auszutauschen.

Viele Kunden haben mir die Entsorgung überlassen und ein Kumpel kannte welche aus der Amiga-Szene ;-)

Falk