Rainer Ziegenbein wrote in news: snipped-for-privacy@e-technik.tu-chemnitz.de:
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.
Hallo,
ich setze den PC f=FCr Me=DFaufgaben 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=FChren. 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=DF
Wolfgang
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.
Linux/Pascal.
... die standen bei mir allerdings nicht.
Grusz, Rainer
Ja, ich weiss. Hab ich noch nicht probiert, steht aber auf der Liste.
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
Also bei meiner Motorsteuerung kommt es auf Reaktionszeiten im Mikrosekundenbereich an .....
Also mit DOS funktioniert das
RTLinux habe ich mal angesehen - so toll bez=FCglich Echtzeitf=E4higkeit ist das gar nicht.
Mir geht es darum, da=DF ich die Systeminterrupts (Timer, Schnittstellen .=2E.) selber nutzen kann und eigene Interruptservice-Routinen einh=E4ngen kann, da=DF ich auf die Ports zugreifen kann usw...
Gru=DF
Wolfgang
einhängen
Dann wäre ein Mikrocontrollerboard angemessener. PCs sind nicht für die Sorte Anwendung gedacht.
MfG JRD
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
(Bitte zukuenftig nicht alle Zitatebenen ineinandermischen. Das verwirrt ungemein. Danke.)
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.
Das geht mMn alles unter Linux, aber wenn Du Reaktionszeiten kleiner 1ms garantieren musst, wuerde ich das nicht machen.
Grusz, Rainer
Wolfgang Weinmannschrieb: "
uCosII aber nicht für USB.
Dirk
Das kommt dann in zweiter Instanz. Zuerst m=F6chte ich eine m=F6glichst komfortable Entwicklungsumgebung mit viel Speicher und wenig Begschr=E4nkungen. Und das stellt f=FCr mich mein PC mit einer AD/DA/IO- und einer Timerkarte dar. Und mit dem PC kann ich auch Floatingpoint bequem einsetzen, alle m=F6glichen komplizierten math. Funktionen usw. Mit nem Controller siehts da nicht so gut aus.
einen Microcontroller auszulagern, und den PC so von den
Das w=E4re f=FCr mich ein R=FCckschritt - mit DOS bekomme ich meine zeitkritischen Bereiche mit dem PC in den Griff
mfG
Wolfgang
Wolfgang Weinmann schrieb:
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
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
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.
Martin Laabs schrieb:
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
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.
Behelfsmässig kann man zu Entwicklungszwecken alte FPUs wie MC68882 an Controller oder 8 Bit CPUs hängen (
MfG JRD
Hi!
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-
Das ist ansich ein Krampf. Der PC wird damit für etwas verwendet, wüfür er nicht gedacht ist.
Microcontroller auszulagern, und den PC so von den
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
Und das es groß und speicherintensiv ist.
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.
Martin Laabs schrieb:
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.
Ja, mehrere (Realtime-Linux Hochgeschwingigkeitskamera-treiber, ADC-Treiber)
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.
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
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
Johannes Bauer schrieb:
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
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.