Mulitasking ist vielleicht nicht der richtige Ausdruck ... Ich versuche schon seit Tagen eine einfache Schaltuhr auf einem ATmega8 in C zu "programmieren". Dazu hab ich schon etliche Threads durchgeackert und jede Menge Codeschnipsel gelesen, schlauer bin ich dadurch nicht geworden. Dazu möchte ich bemerken, dass ich KEINE DCF-Uhr haben möchte, sondern einfach eine normale Quarzuhr - bei welcher dann ein Ausgang mehrmals (4x) pro Tag ein bzw. wieder ausschaltet. Bei der ganzen Leserei ist mir jedoch eines aufgefallen: Der Quarz liefert den Takt - die genaue Frequenz kann ich feststellen oder verwebde dann halt eine echten Uhrenquarz - die Genauigkeit ist nicht unbedingt das Problem. Die Impulse werden nun mit Prescaler geteilt und dann hochgezählt usw..... das ist mir klar. Aber (Obwohl ich soweit noch lange nicht bin!): jetzt kommt der Zähler resp. die Uhrzeit dann irgendwann, sagen wir um 12:30, zu dem Punkt, wo geschaltet werden soll (okay, ich hoffe mal, irgendwann kriege ich das hin), jetzt wird doch ein Unterprogramm (Interrupt?) aufgerufen und abgearbeitet - werden da dann gleichzeitig auch die Impulse gezählt oder nicht ???? Wenn JA, wäre das ja im entferntesten Sinne Multitasking ... Wenn NEIN, dann muss die Uhr ja zwangsläufig falsch gehen ...
Also in C kann ich nicht helfen, aber eine Uhr mit einer Zusatzfunktion, wo ein Relais geschaltet wird, ist in dem Sinne keine Multitasking. If H=12 And M=30 then relais=1 End if Die Uhr läuft ununterbrochen weiter...
Kurt W. schrieb: > werden da dann gleichzeitig > auch die Impulse gezählt oder nicht ???? Wenn du die Impulse mit einem Timer zählst, dann schon. Die übliche Vorgehensweise ist diese: Uhrenquarz an einen 16bit Timer. Der Uhrenquarz hat 2^15Hz, ein 16bit Timer würde also alle zwei Sekunden überlaufen und ein Interrupt erzeugen. Wenn dir eine Auflösung von zwei sekunden genügt, kannst du das so lasse, wenn nicht musst du den Timer bei jedem Interrupt mit 2^15 = 0x8000 vorladen. In der ISR (Interrupt Service Routine) würde ich dann die Sekunden/Minute/Stunde hochzählen. In C könnte das so aussehen:
1 | sek++; //oder sek=sek+2; wenn du die Variante ohne vorladen wählst. |
2 | if(sek>59) |
3 | {
|
4 | sek=sek-59; |
5 | min++; |
6 | }
|
7 | if(min>59) |
8 | {
|
9 | min=min-59; |
10 | stunde++; |
11 | }
|
12 | if(stunde>23) |
13 | stunde=0; |
Und nachdem die die Zeit weitergezählt hast könntest du dann den Vergleich mit der Einschaltzeit machen:
1 | if((stund==st_ein)&&(min==min_ein)) |
2 | PORTA |= (1<<PA0)); |
Ja, wenn Du einen Hardwaretimer mit automatischer Rückladung verwendest. Der triggert z.B. jede sek. den IRQ und fängt dann automatisch wieder von vorne an. In der IRQ oder durch polling des Overflow Bits muß Du dann die Zeit hochzählen, schalten etc. Wenn Du also nicht länger als eine Sekunde die Auswertung des Timer Überlaufs unterbrichst dann geht die Uhr korrekt. Multitasking ist dann noch mal ein bisschen was anderes ...
Es scheint mir ja fast so, dass dir noch eine Menge Grundlagen fehlen. Multitasking ist ein relativ eng gefasster Begriff in der Informatik. Die Wikipedia definiert das z.B. so: > Der Begriff Multitasking [ˌmʌltiˈtɑːskɪŋ] (engl.) bzw. Mehrprozessbetrieb > bezeichnet die Fähigkeit eines Betriebssystems, mehrere Aufgaben (Tasks) > (quasi-)nebenläufig auszuführen. Da du auf deinem AVR wohl kein (echtes/brauchbares) Betriebssystem laufen lassen wirst, gibt es in diesem Sinne auch kein Multitasking. Dein AVR besitzt auch nur eine CPU und kann demnach in jeder Zeiteinheit auch nur einen einzelnen Befehl ausführen. So nun zur Praxis: Dein Fall entspricht eigentlich so ziemlich genau dem "Standardfall", welcher z.B. unter [1] beschrieben wird. In einem Timerinterrupt kannst du dich um die Inkrementierung der Zeit kümmern, da dies regelmäßig und zuverlässig zu bestimmten Zeiten geschehen muss. So könntest du z.B. mit den typischen 32.768 kHz eines Uhrenquarzes einen Zähler erhöhen und dich ggf. um den Overflow der Minuten bzw. Stunden kümmern. Das ist eine relativ kurze Aufgabe, die sich ideal dafür eignet von einem Interrupt erledigt zu werden. Weniger zeitkritisch wäre dann die eigentliche Ansteuerung der Ausgänge. Daher würdest du dies in deiner "Hauptschleife" tun. Hier vergleichst du einfach immer wieder die aktuelle Zeit mit dem Zeitfenster, in dem irgend etwas passieren soll und führst ggf. die Aktion aus. Je nach deinen Programmierkenntnissen würdest du die Zeiten und die dazugehörigen Aktionen in einer Tabelle vorhalten, um das Ganze so flexibel wie möglich zu halten. Mit freundlichen Grüßen, Karol Babioch [1]: https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Interruptgesteuerter_Programmablauf
Falk Brunner schrieb: > Alles was man braucht ist ein Timer, den Rest kann man nahezu > beliebig schlecht programmieren. Die ISR sollte halt nicht länger als eine Sekunde brauchen.
:
Bearbeitet durch User
Karol Babioch schrieb: > Dein AVR besitzt auch nur eine CPU und kann demnach in jeder Zeiteinheit > auch nur einen einzelnen Befehl ausführen. Nur ein Core ist kein Grund kein Multitasking zu machen.
Hmm. Schafft es jemand das Inkrementieren einer Variable länger als eine Sekunde dauern zu lassen? :) Ohne Tricks wie Delayschleifen!
Wird eng, aber man kann ja auch noch den Takt heftig runtersetzen. :-)
greg schrieb: > Hmm. Schafft es jemand das Inkrementieren einer Variable länger als eine > Sekunde dauern zu lassen? :) Ohne Tricks wie Delayschleifen! Anfänger schaffen es manchmal alles möglich in die ISR einzubauen, was darin nicht zu suchen hat...
:
Bearbeitet durch User
Danke erstmal für die Antworten.
@ Karol Babioch:
> Das ist eine relativ kurze Aufgabe ... Weniger zeitkritisch ...
Nochmals für mich:
1)
Der Quarz gibt einen Impuls ...
Der Timer zählt diesen Impuls
UND (!!!)
zur gleichen Zeit arbeitet die CPU ein bit aus irgendeinem
beliebigen Unterprogramm ab.
ODER 2)
Ein Unterprogramm wird aufgerufen und mit jedem Impuls des Quarzes wird
ein bit des Progis abgearbeitet ....
während dieser Zeit werden vom Timer die Impulse nicht gezählt.
Oder liege ich da komplett falsch ???
Der Timer arbeitet im Hintergrund unabhängig von der CPU. Wenn der Timer überläuft kann (und soll er in diesem Fall) ein Interrupt auslösen. Kurt W. schrieb: > zur gleichen Zeit arbeitet die CPU ein bit aus irgendeinem > beliebigen Unterprogramm ab. Diese "bit" nennt man Befehl @TO: Mal eine Frage: Weißt du was ein Interrupt ist?
:
Bearbeitet durch User
Hi, Kurt W. schrieb: > zur gleichen Zeit arbeitet die CPU ein bit aus irgendeinem > beliebigen Unterprogramm ab. Nein, zur "gleichen" Zeit kann die CPU nur eine Instruktion ausführen, s.o. Kurt W. schrieb: > Oder liege ich da komplett falsch ??? Ja. Einen dedizierten Quarz, um die Impulse zu zählen brauchst du wahrscheinlich gar nicht. Die Verwendung eines Timers samt dazugehöriger ISR reicht schon. Der Interrupt unterbricht dann in regelmäßigen Abständen (z.B. jede Sekunde) den "normalen" Programmfluss und erhöht den Zähler. In der Hauptschleife vergleichst du einfach stets die aktuelle Zeit mit den Vorgaben. Du solltest dich tatsächlich nochmal mit den Grundlagen vertraut machen. Das ist hier schon ziemliches Standardrepertoire und mit ein wenig Einlesen sollten sich deine Fragen von selbst klären. Es mag durchaus sein, dass du mit der Implementierung im Speziellen Probleme bekommen wirst (je nach Programmiererfahrung), aber der Ablauf im Allgemeinen ist doch recht einfach zu durchschauen. Mit freundlichen Grüßen, Karol Babioch
Ich weiß jetzt nich wie weit der TO ist, aber wenn er es noch nicht kann sollte er sich Timer und Interrupt ansehen. Hier eine sehr kurze Erklärung: >Ein Interrupt (Unterbrechung) unterbricht ein laufendes Programm, wenn ein >bestimmtes Ereignis, auf das reagiert werden soll, stattgefunden hat. Die >Reaktion wird in der sogenannten Interrupt Service Routine (kurz: ISR) >definiert. >Einfach gesagt, ein Interrupt stoppt ein laufendes Programm nach dem >Ausführen der aktuellen Zeile, ruft die ISR auf und nach deren Ausführung >startet das Programm wieder, ab der Zeile, vor der es durch Interrupt >angehalten wurde. >Ein Timer ist ganz einfach ein bestimmtes Register im µC, das völlig ohne >Zutun des Programms, also per Hardware, hochgezählt wird. Das alleine >wäre noch nicht allzu nützlich, wenn nicht dieses Hardwareregister bei >bestimmten Zählerständen ein Interrupt auslösen könnte. >Ein solches Ereignis ist der Overflow (Überlauf): Da die Bitbreite des >Registers beschränkt ist, kommt es natürlich auch vor, dass der Zähler so >hoch zählt, dass der nächste Zählerstand mit dieser Bitbreite nicht mehr >darstellbar ist und der Zähler wieder auf 0 zurückgesetzt wird. Dieses >Ereignis nennt man den Overflow und es ist möglich an dieses Ereignis ein >Interrupt zu koppeln. Der Timer kann Impulse zählen, die vom Oszillator kommen oder in einem Pin eingespeist werden. Da de µC fast nichts zu tun hat, könntest du auch den gesamten µC mit einem Uhrenquarz betreiben.
:
Bearbeitet durch User
Siehe Timer, Interrupt und Multitasking. Und auch DOS konnt schon Multitasking, wenn auch nicht auf Anwendungsebene und ohne GUI. Diverse Treiber un Hilfprogramme liefen dort auch quasiparallel. Multitasking gibt es nicht erst seit dem Multi-CPU-Core-Zeitalter.
@ Karol Babioch >> Kurt W. schrieb: >> zur gleichen Zeit arbeitet die CPU ein bit aus irgendeinem >> beliebigen Unterprogramm ab. > > Nein, zur "gleichen" Zeit kann die CPU nur eine Instruktion ausführen, Okay, ich vergaß zu erwähnen, dass ich kein Programmierer bin und daher auch keine Grundlagen kenne, bis auf das bisserl, was ich hier im Forum gelesen UND verstanden habe (ich geb zu, das ist ziemlich wenig) Ich habe gerade erst mal vor 2 Wochen mit den µC´s angefangen. Der Sohn einer Bekannten, ein Informatik Student, hat mir am Anfang ein Grundgerüst zusammengebastelt, dass leider nicht funktionierte (wegen Kleingkeiten). Durch das Lesen hier im Forum habe ich es dann selbst nach ein paar Tagen zum Laufen gebracht. Leider hat der Mann im Moment so gut wie keine Zeit. Trotzdem möchte ich das mal begonnene Projekt fertig machen. Es ist ja nicht nur die Schaltuhr, es sollen da noch einige andere Funktionen dazu. Also ich bitte um Nachsicht, und ich bin auch nicht mehr im Studienalter .. Zurück zu meiner Frage: Eigentlich hast Du mit der oben zitierten Aussage bestätigt, dass ich doch nicht ganz falsch liege. wenn die CPU zeitgleich immer nur eine Instruktion ausführt, dann fehlen dem Timer eben diese paar Nano- oder Microsekunden ... (auch wenn es in der Praxis vielleicht keine Rolle spielt)
Kurt W. schrieb: > Also ich bitte um Nachsicht, und ich bin auch nicht mehr im Studienalter > .. Das ist ja prinzipiell kein Problem. Aber es ist halt nicht empfehlenswert mittendrin anzufangen und die Grundlagen bzw. die dahinter stehenden Konzepte außen vor lassen. Damit machst du es dir selbst nur unnötig schwer. Das zuvor bereits verlinkte AVR GCC Tutorial ist ein guter Punkt für den Einstieg und klärt alle deine bisher gestellten Fragen. Kurt W. schrieb: > Zurück zu meiner Frage: Eigentlich hast Du mit der oben zitierten > Aussage bestätigt, dass ich doch nicht ganz falsch liege. wenn die CPU > zeitgleich immer nur eine Instruktion ausführt, dann fehlen dem Timer > eben diese paar Nano- oder Microsekunden ... Nein, eine "ideale" Taktquelle vorausgesetzt fehlt gar nichts, solange kein Interrupt verloren geht. Mit freundlichen Grüßen, Karol Babioch
@ Max H.
Wie weit ich bin, steht jetzt in meinem vorigen Posting.
Durch Deine Aussage wird mir (hoffentlich) einiges klarer:
>das völlig ohne Zutun des Programms, also per Hardware, hochgezählt wird.
D.h. im Klartext, dass der Timer konstant weiterzählt, egal ob jetzt die
CPU zeitgleich irgendein Programm abarbeitet oder nicht.
sehe ich das so richtig ?
Kurt W. schrieb: > wenn die CPU > zeitgleich immer nur eine Instruktion ausführt, dann fehlen dem Timer > eben diese paar Nano- oder Microsekunden ... Der Timer läuft immer noch unabhängig von der CPU.
Karol Babioch schrieb: > Da du auf deinem AVR wohl kein (echtes/brauchbares) Betriebssystem > laufen lassen wirst, gibt es in diesem Sinne auch kein Multitasking. > Absoluter Blödsinn. > Dein AVR besitzt auch nur eine CPU und kann demnach in jeder Zeiteinheit > auch nur einen einzelnen Befehl ausführen. Absolut Falsch. Bitte verbreite hier doch keine gehobelte Entengrütze. So einen Quatsch kannst Du in Deinem Computerspiele-Forum los werden.
Kurt W. schrieb: > .h. im Klartext, dass der Timer konstant weiterzählt, egal ob jetzt die > CPU zeitgleich irgendein Programm abarbeitet oder nicht. Ja, die Zähler wird von deinem Programm aus "konfiguriert" und läuft dann unabhängig davon weiter und löst ggf. Interrupts aus. Mit freundlichen Grüßen, Karol Babioch
Kurt W. schrieb: > zeitgleich immer nur eine Instruktion ausführt, dann fehlen dem Timer > eben diese paar Nano- oder Microsekunden ... > (auch wenn es in der Praxis vielleicht keine Rolle spielt) Kann man so nicht sagen. Der Timer ist eine HW Einheit im µC und zählt ein Register auf bzw ab, unabhängig von der der CPU. Dem fehlen keine Nanosekunden wenn die ein Programm abgearbeitet wird. Hier mal meine Erklärung: Der Quarz (bzw Oszillator) gibt Impulse und taktet damit die CPU und taktet damit gleichzeitig den Timer Die CPU kann damit ein Programm abarbeiten, pro Impuls im Schnitt ca. 1/2 Maschinenbefehle. Erreicht der Timer einen vorherbestimmten Stand, kann die CPU "sofort" in ein anderes, möglicherweise unabhängiges Programm (Interrupt Service Routine) springen und dieses abarbeiten. Ist die ISR abgearbeitet, nimmt die CPU das unterbrochene Programm an der unterbrochenen Stelle wieder auf. Der Timer wird unabhängig von der CPU weitergetaktet. Liegt an der Fähikeit des Programmierers diese Möglichkeiten zu nutzen und/oder zu variieren. Die eine CPU in einem AVR kann zu einer Zeit nur das Hauptprogramm oder das Programm in einer ISR abarbeiten.
halli schrieb: > Absoluter Blödsinn. Wieso? Ich habe mit dem Zitat von oben nahe gelegt, dass Multitasking zumindest ein Betriebssystem (und damit Prozesse) voraussetzt. Das ist bei AVRs nicht üblich und nur mit sehr viel Mühe überhaupt möglich. Die mir bekannten Projekte sind wohl eher als Proof-of-Concept zu verstehen. Wirklich benutzt tut das keiner. halli schrieb: > Absolut Falsch. Bitte verbreite hier doch keine gehobelte Entengrütze. Was soll daran denn bitte falsch sein? Du scheint selbst nämlich nicht den Hauch einer Ahnung von der ganzen Thematik zu haben ... Mit freundlichen Grüßen, Karol Babioch
@ Max H. Danke für die Info, Genau das wollte ich wissen! @ halli (Gast) Bitte nicht unhöflich werden.
> dann fehlen dem Timer eben diese paar Nano- oder Microsekunden
Der Zähler zählt unabhängig von CPU weiter. Du musst den einfach so
einstellen, dass er z. B. jede Sekunde die ISR aufruft. Dem Timer fehlt
gar nichts, wenn der nur so schnell zählen darf, dass du genügend Zeit
hast den mal kurz wieder auf den Startwert zu setzen bevor der Zähler
den nächsten Takt erhält. (Dazu setzt du den Vorteiler des Zählers auf
256.) In der ISR setzt du als erstes den Timer wieder auf den Startwert.
Dann erhöhst du die Variable "Sekunde" um 1. Hier beendest du das ISR
Programm. Den Rest erledigst du in deiner Endlosschleife im
Hauptprogramm.
Bei uCs ist es fast wie im wahren Leben. Mensch = CPU Wecker = Timer Den Wecker kann der Mensch einstellen, wann der klingeln so. Dann macht der Mensch was anderes, z.B. Schnee schippen. Wenn dann der Wecker klingelt, kann man das hören und den Kuchen aus dem Ofen nehmen. Egal wieviel Schnee man schippt, der Wecker geht gleich. Und wenn man das Klingeln überhört, selber schuld ;-)
Falk Brunner schrieb: > Bei uCs ist es fast wie im wahren Leben. > > Mensch = CPU > Wecker = Timer >... Der Vergleich gefällt mir. So habe ich das noch nie gesehen. Ich würde dem Timer aber eher mit einer Eieruhr vergleiche.
:
Bearbeitet durch User
Ergänzung. Wenn man den Wecker hört, geht man rein und nimmt den Kuchen aus dem Ofen. Die Aufgabe Schnee schippen ist kurz unterbrochen wurden, geht aber gleich weiter. Die deutlich WICHTIGERE Aufgabe, Kuchen aus dem Ofen ist zeitnah erledigt worden, Wecker sei dank. Und wenn das Schee schippen beendet ist, kann man Kuchen essen. ;-)
Und noch was zum Thema Multitasking. Der Wecker und Mensch können echt parallel arbeiten, weil es eigenständige physikalische Objekte sind. Der Mensch (CPU) kann immer nur eine Sache tun. Z.B. Holz hacken oder Zaun streichen. Nun kann er z.B. 2h Holz hacken und 2 Stunden Zaun streichen, dann wieder 2h Holz hacken und wieder Zaun streichen. Schaut man am Abend das Ergebnis an, hat der Mensch quasi parallel zwei Dinge erledigt. Real aber immer im Wechsel. Hier sieht man auch, wo eine Grenze liegt. Schaut man nun jede Stunde, macht er mal das eine, mal das andere. Er könnte nun im 5 Minuten Wechsel Holz hacken und Zaun streichen, aber dadurch würde er mehr rumlaufen als effektiv arbeiten. Bei CPUs ist das ähnlich, nur in einem anderen Zeitmaßstab. Die können problemlos alle paar Millisekunden was vollkommen anderes machen, aber nicht unbedingt alle paar Mikrosekunden.
Hi. Fall es jemanden interessiert: AVR-threadlib. Fuer tinyUSBboard als fertiges Beispiel erhaeltlich: http://matrixstorm.com/avr/tinyusbboard/#examples MfG
greg schrieb: > Hmm. Schafft es jemand das Inkrementieren einer Variable länger als eine > Sekunde dauern zu lassen? :) Ohne Tricks wie Delayschleifen! Sollten wir hier einen heißen Anwärter für einen Wettbewerb haben ?
Helmut S. schrieb: > In der ISR setzt du als erstes den Timer wieder auf den Startwert. Das sollte der Timer eigentlich selbst machen. > Dann erhöhst du die Variable "Sekunde" um 1. Hier beendest du das ISR > Programm. Den Rest erledigst du in deiner Endlosschleife im > Hauptprogramm. Gerade bei IRQ-Aufrufen im ms- oder gar s-Bereich kann man auch gleich die restlichen Variablen hochzählen. Also wenn Sekunde>59, dann Sekunde=0 und Minute++ .... etc. Karol Babioch schrieb: > Wieso? Ich habe mit dem Zitat von oben nahe gelegt, dass Multitasking > zumindest ein Betriebssystem (und damit Prozesse) voraussetzt. Das ist > bei AVRs nicht üblich und nur mit sehr viel Mühe überhaupt möglich. Ich weiß nicht. Die Register in einem TimerIRQ auf den Stack schieben, den Stack wechseln, die Register von dem neuen Stack zurückschreiben und 'zurückspringen' ist für mich weder ein Betriebssystem, noch viel Mühe. Für den TO ist jetzt aber wichtiger, dass der Timer unabhängig von der CPU Takte zählt und bei erreichen einer vorher definierten Marke der CPU ein Signal gibt, damit diese zwischendurch etwas Anderes erledigen kann und anschliessend wieder damit weiter macht, wobei sie unterbrochen wurde. D.h. wenn Du den Timerinterrupt verstanden hast, zählt Deine Uhr quasi von ganz alleine und im Hauptprogramm kannst Du Dich dann um so Dinge wie Zeitvergleiche oder Uhr stellen kümmern. Es geht keine Sekunde verloren. Gruß Jobst
:
Bearbeitet durch User
http://www.mikrocontroller.net/articles/Datei:Interrupt_Programme.gif Dieses Bild sollte am besten darstellen wie das Programm abläuft! Der Rest wurde oben schon erwähnt
Jobst M. schrieb: >> Dann erhöhst du die Variable "Sekunde" um 1. Hier beendest du das ISR >> Programm. Den Rest erledigst du in deiner Endlosschleife im >> Hauptprogramm. > > Gerade bei IRQ-Aufrufen im ms- oder gar s-Bereich kann man auch gleich > die restlichen Variablen hochzählen. > Also wenn Sekunde>59, dann Sekunde=0 und Minute++ .... etc. Nicht nur 'kann', sondern sogar 'soll' bzw. 'muss'. Denn die Uhr muss korrekt zählen, auch wenn das Hauptprogramm 20 Sekunden lang Däumchen dreht oder auf einen Tastendruck vom Benutzer wartet, der aber gerade am Klo ist. Erfolgt die Zeitweiterschaltung komplett in der ISR, dann ist das gewährleistet. Eine Uhrzeit sieht man am besten als eine komplette Einheit ein, die eben aus 3 Teilen besteht. In der ISR wird die Uhrzeit als ganzes weitergestellt und nicht nur Teile davon. Sekunden, Minuten, Stunden, Tage, ... weiterzählen ist doch Pipifax für den AVR. Die paar Instruktionen hat man in der ISR praktisch immer, ohne dass gleich alles andere den Bach runter geht.
Jobst M. schrieb: > Die Register in einem TimerIRQ auf den Stack schieben, > den Stack wechseln, die Register von dem neuen Stack zurückschreiben und > 'zurückspringen' ist für mich weder ein Betriebssystem, noch viel Mühe. Und eben auch kein Multitasking nach obiger Definition von Wikipedia. Das erfordert nämlich ein Betriebssystem und damit die Prozesse bzw. Threads. Das was du beschreibst ist der "typische" Interrupt gesteuerte Ablauf auf einem Mikrocontroller. Mit freundlichen Grüßen, Karol Babioch
Hallo Auch auf dem Atmega 8 ist was möglich. Falk hat ja die Richtung vorgegeben. Es kommt nur drauf, wie man es macht. Such doch mal nach Nibo2 und Multitasking. Habe es mit dem ATmega 128 gemacht. Es gibt aber ein sehr schönes Tut dazu. Alles erklärt. Kann es dir auch als pdf schicken. achim
Karol Babioch schrieb: > Und eben auch kein Multitasking nach obiger Definition von Wikipedia. Das ist halt der Unterschied zwischen echtem und Wiki-Wissen. Was soll denn das von Jobst beschrieben Verfahren sein, wenn nicht Multitasking? Die Anwesenheit eines komplexen Betriebssystems zu fordern, damit aus dem beschriebenen Verfahren ein Multitasking wird, ist schlicht Quatsch. Im Gegensatz zu Jobst bin ich uebrigens der Meinung, dass es sich auch bei einer einfachen MT-Implementation schon um ein Betriebssystem handelt. Aber auch das aendert nichts daran, dass die Wiki-Definition Quatsch ist - dann koennte man auch definieren, dass es sich nur um ein MT-System handelt, wenn ein Computer vorhanden ist.
Quack schrieb: > Das ist halt der Unterschied zwischen echtem und Wiki-Wissen. Definitionen haben schon ihren Sinn. Ohne solche ist es nämlich schwierig sich über irgendetwas zu unterhalten und nicht völlig aneinander vorbei zu reden. Und dein "echtes" Wissen stellt nun mal auch kein halbes Jahrhundert Informatik auf den Kopf. Quack schrieb: > Was soll > denn das von Jobst beschrieben Verfahren sein, wenn nicht Multitasking? Das von Jobst beschriebene Verfahren ist auch dasjenige, das wir dem Threadersteller hier seit gestern versuchen nahe zu legen. Dabei handelt es sich aber nicht um Multitasking, sondern um die Abarbeitung eines Interrupts in Form einer Interrupt Service Routine. Diese wird aber im gleichen Kontext wie auch das restliche Programm ausgeführt. Demnach also kein Multitasking nach obiger Definition. Quack schrieb: > Die Anwesenheit eines komplexen Betriebssystems zu fordern, damit aus > dem beschriebenen Verfahren ein Multitasking wird, ist schlicht Quatsch. Die Anwesenheit eines Betriebssystem wird gefordert, damit es die Abstraktion "Prozess" (bzw. "Thread") gibt, die in sich gekapselt und unabhängig von anderen Prozessen sind und prinzipiell etwas völlig anderes tun - ohne zu wissen, dass sie nicht alleine ausgeführt werden. Demnach macht auch der Begriff eines Kontextwechsels keinen Sinn, weil nun einmal alles im gleichen Kontext ausgeführt wird. Im Übrigen ist es zwar schön und gut sich darüber zu "streiten", dem Threadersteller bringt das aber herzlichst wenig. Überhaupt bin ich der Meinung, dass die letzten Einträge hier wohl mehr verwirren als weiterhelfen, auch wenn ich dabei eine nicht untergeordnete Rolle gespielt habe. Der Threadersteller sollte wohl eher einmal den typischen Ablauf eines Mikrocontroller-Programms begreifen, anstatt auf irgendwelche Bibliotheken hingewiesen zu werden, die Versuchen Multitasking auf AVRs zu implementieren. Mit freundlichen Grüßen, Karol Babioch
> Definitionen haben schon ihren Sinn. Wikipedia ist für mich allerdings keine Definitionsgrundlage. Hast Du Dir auch die Informationen zu dem Thema mal in der englischen Wiki angesehen? > Das von Jobst beschriebene Verfahren ist auch dasjenige, das wir dem > Threadersteller hier seit gestern versuchen nahe zu legen. Nein, das stimmt nicht. > Dabei handelt > es sich aber nicht um Multitasking, sondern um die Abarbeitung eines > Interrupts in Form einer Interrupt Service Routine. Diese wird aber im > gleichen Kontext wie auch das restliche Programm ausgeführt. Demnach > also kein Multitasking nach obiger Definition. Du hast meine Beschreibung offensichtlich überhaupt nicht verstanden. > Die Anwesenheit eines Betriebssystem wird gefordert, damit es die > Abstraktion "Prozess" (bzw. "Thread") gibt, die in sich gekapselt und > unabhängig von anderen Prozessen sind und prinzipiell etwas völlig > anderes tun - ohne zu wissen, dass sie nicht alleine ausgeführt werden. Und? Das tun die Prozesse in dem von mir beschriebenen Ablauf doch. Gruß Jobst
Karol Babioch schrieb: > Und dein "echtes" Wissen stellt nun mal auch > kein halbes Jahrhundert Informatik auf den Kopf. Dann argumentiere auf dieser Basis, aber nicht auf der von zweifelhaften Wikipedia-Zitaten. > Quack schrieb: >> Was soll >> denn das von Jobst beschrieben Verfahren sein, wenn nicht Multitasking? > Das von Jobst beschriebene Verfahren ist auch dasjenige, das wir dem > Threadersteller hier seit gestern versuchen nahe zu legen. Nein, ganz sicher nicht. Lies das nochmal nach, Jobst beschreibt, wie man im Interrupt den Stack umlaedt um von einem Kontext zum anderen zu wechseln: "Ich weiß nicht. Die Register in einem TimerIRQ auf den Stack schieben, den Stack wechseln, die Register von dem neuen Stack zurückschreiben und 'zurückspringen' ist für mich weder ein Betriebssystem, noch viel Mühe." Das ist preemptives MT, nicht das ordinaere Ausfuehren eines Interrupts. Der TO muss nur im Interrupt seine Uhr weiter zaehlen und anderswo seine Aktion ausloesen, wenn ein bestimmter Zeitpunkt eingetroffen ist. Das ist ueblicherweise die Hauptschleife, kann aber natuerlich auch ein anderer Interrupthandler sein. Wenn es nicht lange dauert, muss es auch nicht anderswo sein. >> Die Anwesenheit eines komplexen Betriebssystems zu fordern, damit aus >> dem beschriebenen Verfahren ein Multitasking wird, ist schlicht Quatsch. > Die Anwesenheit eines Betriebssystem wird gefordert, damit es die > Abstraktion "Prozess" (bzw. "Thread") gibt, Das sind keine unbedingt noetigen Eigenschaften eines Bestriebssystems. Andersrum wird auch hier wieder ein Schuh daraus: Implementiert ein System Prozesse und Threads, kann man davon ausgehen, dass es sich um ein Betriebssystem handelt. > Im Übrigen ist es zwar schön und gut sich darüber zu "streiten", dem > Threadersteller bringt das aber herzlichst wenig. Das ist richtig, aber Falschaussagen im Thread stehen zu lassen, schadet noch mehr. Das haettest du also bedenken sollen, bevor du die Diskussion um losgetreten hast mit deinem Wiki-Zitat.
Jobst M. schrieb: > Wikipedia ist für mich allerdings keine Definitionsgrundlage. Hast Du > Dir auch die Informationen zu dem Thema mal in der englischen Wiki > angesehen? Ja, und das ist weitestgehend kohärent. Auch dort ist von Prozessen, Scheduling und Kontextwechseln die Rede. Alles klassische Aufgaben eines Betriebssystems. Jobst M. schrieb: > Nein, das stimmt nicht. > Du hast meine Beschreibung offensichtlich überhaupt nicht verstanden. Scheint wohl fast so. Jobst M. schrieb: > Ich weiß nicht. Die Register in einem TimerIRQ auf den Stack schieben, > den Stack wechseln, die Register von dem neuen Stack zurückschreiben und > 'zurückspringen' ist für mich weder ein Betriebssystem, noch viel Mühe. Ich hatte wohl das "den Stack wechseln" überlesen. Ansonsten beschreibst du nämlich genau den Ablauf einer ISR. Zugegeben, damit kommt man dem Konzept des Multitaskings schon etwas näher, aber das Problem ist nach wie vor, dass du nur einen Adressraum hast, und sich die einzelnen Programmteile munter ihre Variablen überschreiben können. Eine Kapselung in Form von echten Prozessen sieht dein Konzept nämlich nicht vor. Mit freundlichen Grüßen, Karol Babioch
Nur nochmal zur Verdeutlichung: Prozess N läuft TimerIRQ wird ausgelöst Prozess N+1 läuft TimerIRQ wird ausgelöst Prozess N+2 läuft TimerIRQ wird ausgelöst : TimerIRQ Rette Register (incl. Staturregister) auf aktuellem Stack. Speichere SP in Variable N Inkrementiere N bis zur Maximalanzahl an Tasks hoch und fange dann von vorne an Schreibe inhalt von Variable N in SP Hole Register vom Stack RETI Und es ist Prozess 1 völlig egal, was Prozess 4 macht, solange sie nicht gleichzeitig auf die selbe Peripherie oder RAM zugreifen. Gruß Jobst
Karol Babioch schrieb: > Ja, und das ist weitestgehend kohärent. Auch dort ist von Prozessen, > Scheduling und Kontextwechseln die Rede. Das passiert ja auch. > Alles klassische Aufgaben eines Betriebssystems. DOS -> kein OS > aber das Problem ist nach > wie vor, dass du nur einen Adressraum hast, und sich die einzelnen > Programmteile munter ihre Variablen überschreiben können. Eine Kapselung > in Form von echten Prozessen sieht dein Konzept nämlich nicht vor. Windows98 -> kein OS AmigaOS -> kein OS ...OS -> kein OS Gruß Jobst
Jobst M. schrieb: > DOS -> kein OS > Windows98 -> kein OS Dann sind wir uns ja einig ;). Spaß beiseite: Ich kenne die Details der Speicherverwaltung der von dir genannten Systeme nicht. Aber gut, ich gebe dir recht. Mit diesen Ausführungen bzw. Beispielen im Hintergrund lässt sich das von dir beschriebene Konzept wohl auch als Multitasking bezeichnen, auch wenn es verglichen mit "modernen" Betriebssystemen äußerst primitiv ist. Ich habe Multitasking wohl etwas strikter ausgelegt. Nichtsdestotrotz ist das natürlich nicht unbedingt der typische Ablauf auf einem Mikrocontroller und für das Vorhaben des Threaderstellers auch gar nicht nötig. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Sorry, Karol - aber offensichtlich hast du ausser Wikipedia-Wissen nicht viel zum Thema MT zu bieten und versuchst gegenueber Leuten, die teilweise Dekaden Erfahrung damit haben irgendwie Recht zu behalten. :-(
Karol Babioch schrieb: > Nichtsdestotrotz ist das natürlich nicht unbedingt der typische Ablauf > auf einem Mikrocontroller und für das Vorhaben des Threaderstellers auch > gar nicht nötig. Ohne Deine 'Hilfe' wäre ihm der ganze Rotz auch erspart geblieben. Du liest Dir die Texte nicht richtig durch und schreibst irgendwas dazu, was aus irgendwelchen Halbwahrheiten besteht. Bestes Beispiel (noch vor dem mit dem überlesenen Stackwechsel): Kurt W. schrieb: > Der Quarz gibt einen Impuls ... > Der Timer zählt diesen Impuls > UND (!!!) > zur gleichen Zeit arbeitet die CPU ein bit aus irgendeinem > beliebigen Unterprogramm ab. Deine Antwort: Karol Babioch schrieb: > Kurt W. schrieb: >> zur gleichen Zeit arbeitet die CPU ein bit aus irgendeinem >> beliebigen Unterprogramm ab. > > Nein, zur "gleichen" Zeit kann die CPU nur eine Instruktion ausführen, > s.o. > > Kurt W. schrieb: >> Oder liege ich da komplett falsch ??? > > Ja. Bullshit! Kurt hat doch Recht. Genau so ist es. Auch wenn das 'Bit' ein Befehl ist. Gruß Jobst
:
Bearbeitet durch User
Quack schrieb: > Sorry, Karol - aber offensichtlich hast du ausser Wikipedia-Wissen nicht > viel zum Thema MT zu bieten Du bist natürlich frei dies so zu sehen. Quack schrieb: > versuchst gegenueber Leuten, die > teilweise Dekaden Erfahrung damit haben irgendwie Recht zu behalten. :-( In dem Beitrag über dir, habe ich doch das Zugeständnis gemacht, dass der von Jobst M. gemachte Ansatz wohl (oder übel) als Multitasking durchgeht und das meine anfängliche Auslegung tatsächlich etwas zu eng war. Nichtsdestotrotz korreliert der Begriff "Multitasking" ganz stark mit dem Begriff "Betriebssystem" und es ist äußerst schwierig seriöse Quellen zu finden, die vom Einen, nicht aber vom Anderen, sprechen, weil das Multitasking typischerweise eine Eigenschaft des Betriebssystems ist. Jobst M. schrieb: > Du liest Dir die Texte nicht richtig durch und schreibst irgendwas dazu, > was aus irgendwelchen Halbwahrheiten besteht. Ich versuche in der Regel durchaus gewissenhafte und hoffentlich korrekte Antworten zu liefern. Dies ist mitunter ein Grund warum meine Antworten verhältnismäßig lang sind. Das mir dabei der ein oder andere Fehler unterläuft, ist natürlich auch klar und es ist doch schön, wenn andere, wie z.B. du, mich darauf aufmerksam machen. Ich empfinde die daraus entstandene Diskussion durchaus als lesenswert, auch wenn sie nicht unbedingt hilfreich für den eigentlichen Threadersteller ist. Jobst M. schrieb: > Bullshit! Kurt hat doch Recht. Genau so ist es. Auch wenn das 'Bit' ein > Befehl ist. Na, gut, dass kannst du jetzt natürlich so interpretieren. Das geht aber fast ein bisschen in die Richtung Bestätigungsfehler [1]. Ich (und wohl auch die anderen, die versucht haben zu helfen) hatte zum damaligen Zeitpunkt das Gefühl, dass der Threadersteller das Konzept noch nicht ganz verstanden hatte und habe seine Aussagen scheinbar anders interpretiert als du das jetzt - im Nachhinein - tust. Die Nachfragen des Threaderstellers bezüglich der "verloren" gegangen Zeit geben mir ja wohl zumindest insoweit recht, dass da in der Tat noch Verständnisprobleme vorlagen. Mit freundlichen Grüßen, Karol Babioch [1]: https://de.wikipedia.org/wiki/Best%C3%A4tigungsfehler
:
Bearbeitet durch User
Karol Babioch schrieb: > Nichtsdestotrotz ist das natürlich nicht unbedingt der typische Ablauf > auf einem Mikrocontroller Nein, Kontext-Switching per Timer-Interrupt mit Stack-Swapping geht eigentlich schon wieder einen Schritt zu weit für das auf Mikrocontrollern "typische" Multitasking. http://www.mikrocontroller.net/articles/Multitasking Der Artikel ist doch ganz nett, das Stichwort ist kooperatives Multitasking. Die drei "Tasks" "taste_lesen", "led_blinken" und "uart_lesen" sind nicht wirklich getrennt, im Beispiel sind das gerade mal Unter-Funktionen.
Karol Babioch schrieb: > das Multitasking typischerweise eine Eigenschaft des Betriebssystems > ist. Sinnvollerweise wird diese Eigenschaft wenn vorhanden von einem Betriebssystem übernommen. An anderer Stelle würde es keinen Sinn ergeben. Aber beides in Abhängigkeit ist kein muss und das wird von vielen Quellen tatsächlich unterschlagen. Karol Babioch schrieb: > Ich empfinde die > daraus entstandene Diskussion durchaus als lesenswert Ich nicht. Karol Babioch schrieb: > [1] Ist schon klar, dass Du Dir schon die richtigen Begriffe zurechtgelegt hast, um eine Rechtfertigung dafür haben zu wollen, den Kopf aus der Schlinge zu ziehen, aber ich muss Dich enttäuschen: Karol Babioch schrieb: > als du das jetzt - im Nachhinein - tust. Ich habe das nicht im Nachhinein so interpretiert, ich habe das das erste Mal gelesen und habe es so gesehen, wie ich es immer noch sehe. Nur war es zu dem Zeitpunkt nicht mehr notwendig einzugreifen, da dieser Punkt schon geklärt wurde: Karol Babioch schrieb: > Ja, die Zähler wird von deinem Programm aus "konfiguriert" und läuft > dann unabhängig davon weiter und löst ggf. Interrupts aus. Merkwürdiger Weise auch von Dir, was Deine Aussage Karol Babioch schrieb: > Ich (und wohl > auch die anderen, die versucht haben zu helfen) hatte zum damaligen > Zeitpunkt das Gefühl, dass der Threadersteller das Konzept noch nicht > ganz verstanden hatte und habe seine Aussagen scheinbar anders > interpretiert als du das jetzt - im Nachhinein - tust. mehr wie eine Schutzbehauptung aussehen lässt ... So, ich habe jetzt keinen Bock mehr hier ...
Rudolph schrieb: > Der Artikel ist doch ganz nett, das Stichwort ist kooperatives > Multitasking. Ok, danke für die Referenz. Die kannte ich in der Tat noch nicht. Kooperatives Multitasking an sich war mir natürlich bekannt, nicht aber im Zusammenhang mit Mikrocontrollern. Das trifft es aber tatsächlich ganz gut. Jobst M. schrieb: > Ich nicht. Zumindest aber war es dir anscheinend wichtig genug mehrfach darauf einzugehen. Jobst M. schrieb: > Ist schon klar, dass Du Dir schon die richtigen Begriffe zurechtgelegt > hast, um eine Rechtfertigung dafür haben zu wollen, den Kopf aus der > Schlinge zu ziehen, aber ich muss Dich enttäuschen: Ich will hier überhaupt nicht meinen Kopf aus irgendeiner Schlinge ziehen. Übrigens eine ganz interessante Terminologie, die du hier wählst, wohl auch, um subtil durchsickern zu lassen, dass du es hier auf mich als Person abgesehen hast. Und ich hatte eben den Eindruck, dass du jetzt im Nachhinein alle Beiträge durchgehst und jedes meiner Worte umdrehst, um meine Kompetenz in Frage zu stellen. Und mit dem o.g. Link und den darin genannten Artikeln wollte ich dich nur darauf hinweisen, dass das menschliche Gehirn leider nicht objektiv arbeitet und oft dazu neigt, die Wahrnehmung dahingehend zu manipulieren, sodass das Beobachtete mit der Erwartung übereinstimmt. Letztendlich wollen wir doch alle hier helfen. Mag sein, dass hier nicht alles ideal gelaufen ist bzw., dass man dem Threadersteller besser helfen hätte können. Ich denke aber, dass er im Großen und Ganzen eine Hilfestellung erhalten hat, die ihn definitiv weiterbringt. Jobst M. schrieb: > Ich habe das nicht im Nachhinein so interpretiert, ich habe das das > erste Mal gelesen und habe es so gesehen, wie ich es immer noch sehe. > Nur war es zu dem Zeitpunkt nicht mehr notwendig einzugreifen, da dieser > Punkt schon geklärt wurde: Dann ist es umso verwunderlicher, dass du dies nun, wo das eigentliche Problem geklärt zu sein scheint, mir zum persönlichen Vorwurf machen willst. Jobst M. schrieb: > mehr wie eine Schutzbehauptung aussehen lässt ... Weniger eine Schutzbehauptung als eine Rechtfertigung für deinen zuvor gemachten Vorwurf. Jobst M. schrieb: > So, ich habe jetzt keinen Bock mehr hier ... Es zeugt natürlich von unendlicher menschlicher Reife, wenn man Vorwürfe persönlicher Natur in den Raum stellt, und sich dann vom Acker macht. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.