Moin,
gibt es eigentlich kostenlose C-Bibliotheken Codes oder etwas in der Art, womit man vernünftig Multitasking auf uC realisieren kann? Ich kenne von der FH nur RTKernel[1], aber das kostet 1500 Euro, das ist für privates Experimentieren etwas teuer.
MfG,
Markus
[1]
Was fuer Multitasking auf welchem uC? Geben tuts da vieles, sogar einen angepassten Linux-Kernel:
Ciao,
Horst
--
Horst Laschinsky
Universitaet Erlangen-Nuernberg - Physikalisches Institut I
Erwin-Rommel-Str. 1, Room: 209, 91058 Erlangen - Tel: ++49 9131 85-27062
http://www.antares.physik.uni-erlangen.de/~htlaschi/index.html
"Markus" schrieb im Newsbeitrag news:443bd753$0$18271$ snipped-for-privacy@newsread2.arcor-online.net...
Vergiss Multitasking, echte paeemtive zeitscheibengesteuerte round robing Prozessverwaltung braucht man praktisch nie, selbst speicherprogrammierbare Steuerungen SPS machen das nicht so.
Verwende lieber den Begriff "ereignisgesteuerte Prozeduren", oder gleich "Interruptroutinen" und du merkst, das jeder uC das schon in Hardware eingebaut hat. Dafuer braucht es kein Betriebssystem.
-- Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net homepage: http://www.geocities.com/mwinterhoff/ de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/ Read 'Art of Electronics' Horowitz/Hill before you ask. Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
"MaWin"
Praeemtiv meinte ich auch gar nicht. Sorry hätte ich sagen sollen.
Also braucht man für Kooperatives Multitasking gar keinen extra Code? Hab ja noch nie einen uC direkt programmiert. Sorry wenn die Frage komisch ist.
MfG,
Markus
"Markus" schrieb im Newsbeitrag news:443bf209$1$18279$ snipped-for-privacy@newsread2.arcor-online.net...
Fuer kooperatives Multitaksing reichen 2 Funktionen und eine Queue: PostMessage und GetMessage, wie sie bei Windows 16 bit heissen. Und 2 Funktionen mit der von ihnen verwalteten Datenstruktur wirst auch du kaum als Betriebssystem bezeichnen.
Siehste. Vergiss auch kooperatives Multitasking. Interruptgesteuert ist (meistens) der richtige Ansatz, wenn ein uC auf externe Ereignisse reagieren soll. Das Hauptprogramm macht dann zeitunkritisches Zeug in einer Schleife, die Interrupts rufen Funktionen auf die das Ereignis entgegennehmen und (falls es bearbeitet werden muss oder zu Zustandsaenderungen fuehrt) setzt daraufhin ein paar Variablen.
-- Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net homepage: http://www.geocities.com/mwinterhoff/ de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/ Read 'Art of Electronics' Horowitz/Hill before you ask. Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Was meinst Du mit "gar keinen extra Code"? Oder vielmehr, was willst Du eigentlich genau machen? Willst Du nur auf externe (oder auch in- terne) Ereignisse zeitnah und unabhaengig von einem wie auch immer gearteten Hauptprogramm reagieren? Dann brauchst Du in der Tat nicht viel "extra Code" sondern musst im wesentlichen nur die Interrupt- vektoren auf die entsprechenden Interrupt-Service-Routinen setzen.
Oder willst Du wirklich verschiedene Programme "gleichzeitig" ab- laufen lassen? In dem Fall kommst Du wohl um das Design eines ge- eigneten Schedulers nicht herum. Bedenke aber, dass aufgrund der oftmals bei uCs nicht vorhandenen Speicherschutzmechanismen ggf. jeder Job in der Lage ist, das Mul- titasking auszuhebeln.
Es ist uebrigens gar nicht mal sooo aufwendig, einen primitiven Scheduler zu schreiben. Sogar praeemptives Multitasking ist nicht die Welt, solange Du Dich aufs Wesentliche beschraenkst (feste Zeitscheiben, feste Reihenfolge der Jobs etc.).
Ciao,
Horst
--
Horst Laschinsky
Universitaet Erlangen-Nuernberg - Physikalisches Institut I
Erwin-Rommel-Str. 1, Room: 209, 91058 Erlangen - Tel: ++49 9131 85-27062
http://www.antares.physik.uni-erlangen.de/~htlaschi/index.html
eCos uCos rtems xinu
Reicht das?
Mit freundlichen Grüßen
Frank-Christian Krügel
Ereignisgesteuert != Multitasking. Ereignisgesteuert == Zustands- automaten, im Allgemeinen mit explizit mitgeführtem Zustand.
Man sagt auch, Multitasking ist was für Leute, die ihre Anwendung nicht als Zustandsautomat formulieren können. Und zugegebenermaßen ist Multitasking für "Batch"-Verarbeitung sehr bequem.
Kooperatives Multitasking geht auf einem uC auch nicht anders als auf dem PC. Ein paar C-Routinen zur Verwaltung von Task-Kontexten, Synchronisation und so Kram, sowie eine kleine Assembler-Routine zum Stack-Umschalten.
Stefan
"Markus" schrieb
Hallo Markus,
hast du nur an der FH davon gehört, oder auch damit gearbeitet und verstanden wie man in einer Multitaskumgebung programmiert ? Wenn nicht, benutze erst einmal die vorhandene Windows oder Linux API um zu verstehen wie so etwas funktioniert. Lies die Bücher von Tannenbaum und Labrosse (uCos) . Dann schreibst du dir locker selbst dein eigenes Mini-Multitasking für einen beliebigen uController.
Gruß
Hans-Georg
Markus schrieb:
Welche uC willst Du denn verwenden?
Gruß Guido
Stefan Reuther schrieb:
Mit Missbrauch von setjmp/longjmp geht das sogar in purem C, und abgesehen von 2 Arrayindizes praktisch architekturunabhängig.
"Hans-Georg Lehnard"
wie man in einer Multitaskumgebung programmiert ?
Sowas machen wir im Praktikum im Fach Prozessdatenverarbeitung. Habe aber erst einen Termin von 8 Stück gehabt.
MfG,
Markus
"Markus" schrieb:
proc Real-Time Kernel:
Christian.
Ethernut
-- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
sch
Es gibt noch den Ansatz des Polling in alten Lehrb=FCchern. Das ist nur im Testsystem und in CPU's ohne Interrupt sinvoll.
Hier werden die Ger=E4te der Reihe nach abgefragt, ob sie Daten zur Verarbeitung haben. Zum Testaufbau finde ich die Anordnung sinvoll, da hier der Funktion einfach Daten =FCbergeben werden k=F6nnen, ohne dass ein Interrupt ausgel=F6st werden muss. Au=DFerdem ist ein ein solches Programm einfacher zu schreiben, da der Prozessor sich immer in einer stabilen Phase befindet und keine zeitkritischen Prozesse unterbrochen werden k=F6nnen. Wenn es mit Polling l=E4uft, so l=E4sst sich mit ein wenig Aufwand der Aufbau meist auch in Interrupt umbauen. (Interruptleitungen verbinden, bei zeitkrischen Funktionen den Interrupt sperren und Stabilit=E4ts=FCberpr=FCfungs- funktionen einbauen).
Einige hier finden Polling f=FCr einfache Steuerungen v=F6llig ausreichend. (und die befassen sich beruflich mit Elektronik im Gegensatz zu mir)
Bei Interruptbasierten Programmen befindet sich im Hauptprogramm ein Startcode und dann nur noch eine Sleep-Schleife [Windows-Programme verwenden einen =E4hnlichen Mechanismus, wenn sie auf Benutzereingaben warten].
Dann versuchen 5 Philosophen mit 5 Gabeln an einem rundem Tisch Spagetti zu essen! So einfach ist es doch nicht.
Dem Linux-Kernel l=E4sst sich einiges abschauen. Der implementiert sogar 3 verschiedene Modelle.
(f=FCr alle die das Bsp. nicht kennen: 1. Alle Philosphen heben gleichzeitig eine Gabel hoch. 2. Sie stellen fest, dass sie keine 2. Gabel haben. 3. Sie legen die Gabeln wieder hin. 4. Sie beginnen erneut bei 1. ) [Bsp. stammt in groben Z=FCgen aus einem Turbopascal Buch, ich kann mir gut vorstellen, dass die Berufsgruppe durch andere ersetzt wird (Basic-Programmierer, Mathematiker, Datensch=FCtzer, Windows-Nutzer, .=2E.)]
Im Idealfall klapt das mit der festen Zeitscheibe aber irgendwann wird die Anwengung erweitert und es treten diese Konkurrenzprobleme auf. (ich finde den Ansatz von Linux gut und er sieht recht einfach aus und die Umsetzung ist auch nicht die Welt)
...was fuer nen uC definitic Overkill ist.
Nope. Das Ganze ist sogar bekannt unter dem Namen "Philosophenproblem".
Nur, wenn man IPC braucht. Wenns aber nur darum geht, einzelne voneinander unabhaengige Jobs laufen zu lassen, dann gibts i.d.R. keinerlei Probleme diesbezueglich.
"nicht die Welt" ist ein bisserl untertrieben. Der Linux-Scheduler besteht aus mehr als aus nur kernel/sched.c... Nichtsdestotrotz ist es nicht schwer fuer nen uC (bei dem man norma- lerweise genau weiss, was er zu tun hat) praeemptives Multitasking zu implementieren. Wenn man aber versucht, die Eier legende Woll- milchsau zu schaffen, dann ists genauso schwer wie fuer einem "rich- tigen" Computer.
Ciao,
Horst
--
Horst Laschinsky
Universitaet Erlangen-Nuernberg - Physikalisches Institut I
Erwin-Rommel-Str. 1, Room: 209, 91058 Erlangen - Tel: ++49 9131 85-27062
http://www.antares.physik.uni-erlangen.de/~htlaschi/index.html
| ...was fuer nen uC definitic Overkill ist.
Nun ja, ist ein ARM9 oder so mit knapp 400 MHz noch ein =B5C? oder diese = h=FCbschen Linux-komplett-PC-Chips mit VGA und allem Primborium incl. ?
Marte
Gute Frage. Gibts denn eine "offizielle" Definition von "uC"? Persoenlich wuerde ich sagen alles, was "mehr" ist als nur eine reine CPU (insb. z.B. Buscontroller on chip hat). Oder man definierts ueber das Anwendungsgebiet. Dann waere aber ggf. auch ein Pentium ein uC, wenn er nicht in einem Computer steckt son- dern irgendwoanders "reine Kontrollaufgaben" uebernimmt.
Ciao,
Horst
--
Horst Laschinsky
Universitaet Erlangen-Nuernberg - Physikalisches Institut I
Erwin-Rommel-Str. 1, Room: 209, 91058 Erlangen - Tel: ++49 9131 85-27062
http://www.antares.physik.uni-erlangen.de/~htlaschi/index.html
"Horst Laschinsky" schrieb im Newsbeitrag news: snipped-for-privacy@news.dfncis.de...
Ja, Programmspeicher und Datenspeicher ON CHIP. Der ARM ist also keiner, die Linux-Kisten auch nicht.
-- Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net homepage:
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.