Leben ohne Interrupt

Allgemeine Themen rund um den Propeller Mikrocontroller und Elektronik
Antworten
Benutzeravatar
drohne235
Administrator
Beiträge: 2284
Registriert: So 24. Mai 2009, 10:35
Wohnort: Lutherstadt Wittenberg
Kontaktdaten:

Leben ohne Interrupt

Beitrag von drohne235 »

Der Propeller ist ja bekanntlich in seiner Architektur etwas anders als andere Prozessoren. Das macht Spaß, aber an der einen oder anderen Stelle ist es für mich persönlich schon etwas mühsam, sich von den bisherigen Denkstrukturen zu lösen.

Eine solche Besonderheit des Propellers - die gegenüber allen anderen Prozessoren und Mikrocontrollern fehlenden Interrupts - möchte ich hier ein wenig zur Diskussion stellen. Wie kommt man ohne Interrupts aus? In den letzten Monaten habe ich im Internet oft Neugierige und Neulinge erlebt, die sich ob der fehlenden Interrupts gleich wieder abgewendet haben. Aber ist das richtig so, sind die fehlenden Unterbrechungsmöglichkeiten so eine große Behinderung?

Meine provokante These zum Thema: Interrupts sind ein Relikt der Computersteinzeit! ;) Sie sind ein gewolltes, aber nicht wirklich gekonntes Multitasking. Wenn man die Entwicklung von Prozessoren und Mikrocontrollern betrachte und gedanklich die technischen Möglichkeiten und Notwendigkeiten nachvollzieht, so kommt man schnell zu den Wurzeln der Interrupts: Komplexität und Chipfläche waren in der Anfangszeit eine teure und knappe Ressource, an einen solchen Luxus von acht Prozessoren pro Chip, wie wir ihn zur Verfügung haben, war nicht zu denken. Und dennoch mußten diese Computer auf zeitkritische Signale reagieren. Sollten zum Beispiel Daten über eine Schnittstelle empfangen werden, so mußte der Prozessor innerhalb einer definierten Zeitspanne diese Daten einlesen und in entsprechenden Puffern speichern. Aber was macht man, wenn nur ein Prozessor zur Verfügung steht, der auch nur ein Programm abarbeiten kann? Richtig: ein Hardwaresignal, welches mit dem entsprechenden Ereignis gekoppelt ist, unterbricht die aktuelle Programmausführung, sichert den relevanten Prozessorstatus und startet eine "Unterbrechungsbehandlungsroutine" - unser Interrupt und seine Interruptroutine. Dieser Mechanismus ist also einfach aus der Not geboren, welche eine Architektur mit sich bringt, die nur einen Prozessor verfügbar hat.

Anders der Propeller: Warum soll ich den Aufwand betreiben und einen einzelnen Prozessor in seiner Arbeit unterbrechen - mit allem damit zusammenhängenden Aufwand an Speicherplatz und Rechenzeit - wenn ich auch einen eigenen Prozessor verwenden kann, welcher sich ganz ausschließlich um diese Aufgabe kümmert? Und gerade durch diese Aufteilung der Arbeit auf wirklich real vorhandene Hardware ergibt sich eine sehr deterministische Reaktionszeit des Systems - ein wichtiger Punkt, wenn es um die Bedienung von zeitkitischer Hardware geht.

Ein oft gelesenes Argument gegen den Propeller: Ohne Interrupts muß man alles im Polling machen! Nun ja, dieser Vorwurf gilt nach meiner persönlichen Meinung nur, wenn man das Problem nur oberflächlich betrachtet.

Auch in einem System mit Interrupts gibt es immer eine Stelle an der letztlich Polling stattfindet. Nehmen wir als Beispiel ein Terminalprogramm, welches über eine serielle Schnitstelle kommuniziert. Sicher findet in einem klassischen System die zeitkritische Bedienung der Schnittstelle selbst per Interrupt statt. Aber das Hauptprogramm, welches die Zeichen dann auf dem Bildschirm darstellt, wird letztlich auch wieder nur per Polling genau jene von der Interruptroutine befüllten Puffer überwachen. Mir fällt keine Anwendung ein, wo es die Mischung von Polling und Interruptmechanismen letztlich nicht gibt. Und mir fällt auch keine Anwenung ein, wo eine klare und saubere Verteilung der Funktionen auf real vorhandene Hardware und Verzicht auf die Krücke "Interrupt" nicht nur Vorteile bringt. Was soll also diese Festhalten am "veralteten" Interruptsystem, mag man an dieser Stelle gleich fragen?

Ein anderer Punkt: Die Aufteilung der Funktionen im Hive. Getrennt muß man die Aufteilung der Funktionen auf drei getrennte Mikrocontroller im Hive betrachten. Es ist sicher sinnvoll zusammengehörige Funktionen quasi als Funktionskomplex zu betrachten und einen solchen Komplex nicht aufzutrennen, bzw. auf mehrere Chips zu verteilen. So ist es gut das sich alle Benutzerschnittstellen in Bellatrix befinden: im Extremfall kann so die gesamte Funktionalität einer Benutzeroberfläche in Bellatrix integriert werden. Die Daten von der Maus um zum Beispiel ein Menü zu bedienen, müßen Bellatrix überhaupt nicht verlassen. Erst die Information ob und welcher Menüpunkt angeklickt wurde muß übertragen werden, um die entsprechende Funktion auszuführen.

Also, wie sieht das mit euch und den Interrupts aus? Sehe ich die Sache so falsch, ist der Propeller und seine Struktur eine Sackgasse oder ein Repräsentant der zukünftigen Entwicklung?
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
Benutzeravatar
laserjones
Beiträge: 291
Registriert: Fr 19. Jun 2009, 10:38
Wohnort: Hennef
Kontaktdaten:

Re: Leben ohne Interrupt

Beitrag von laserjones »

Aus meiner Position heraus kann ich deiner Sichtweise nur zustimmen. Ich muss dazu sagen, dass ich mich zwar gedanklich und theoretisch schon lange mit Mikrocontrollern befasse, meine praktische Erfahrung aber mangels "Bastelzeit-Budget" fast null ist. Ich habe einige wenige einfache PIC-Programme realisiert, bei denen ich mich mit Interrupts aber nicht herumschlagen musste. Insofern sehe ich beide Philosophien sozusagen aus jungfräulicher Position, und von dort aus erscheint mir das Interrupt-Konzept tatsächlich als (für 1-Kern-Architekturen unvermeidliche) Krücke, das einer intuitiven, "direkten" Programmierung eher zuwiderläuft.

Auf das "Problem" der fehlenden Interrupts sollte man bei Propeller m. E. frühestens dann stoßen, wenn acht Kerne nicht mehr ausreichen, um für jede echtzeitkritische Funktion einen eigenen Cog reservieren zu können. Und selbst dann sollte es Lösungen geben, soweit die Rechenkapazität insgesamt noch ausreicht. Denn ein hinreichend schnelles Polling eines externen Signals (das man bei geschickter Aufgabenverteilung auf die Cogs zumeist hinbekommen dürfte) ist im Ergebnis ja genauso gut wie eine Interrupt-Reaktion. Die wenigsten Signale sind ja so kurz, dass man sie mit einer ausreichend schnellen Schleife nicht "erwischen" würde.

Simples Beispiel: Wenn ich einen Cog nur dazu abstelle, in einer sehr kurzen und entsprechend schnellen Schleife z. B. 16 Eingänge abzufragen und die Ergebnisse in einen Puffer zu schreiben, den ich dann vom Hauptprogramm aus in aller Ruhe abfragen kann, habe ich im Ergebnis das Äquivalent eines Prozessors mit sieben frei verfügbaren Kernen und 16 (simulierten) Interrupts. Da kann ich wahrhaftig keinen Nachteil gegenüber einem herkömmlichen Controller mit nur einem Kern und echten Interrupts erkennen.
Momentan ist richtig, momentan ist gut – nichts ist wirklich wichtig, nach der Ebbe kommt die Flut. (Herbert Grönemeyer)
;-)
Beiträge: 16
Registriert: Do 10. Dez 2009, 20:08

Re: Leben ohne Interrupt

Beitrag von ;-) »

Meiner Meinung nach sind Interrupts durchaus sinnvoll: Irgendwann wird man mal dazu kommen, dass eine Anwendung batteriebetrieben sein soll, dann hat man das Problem des Stromverbrauchs. In den vielen solchen Fällen kann man den Prozessor die meiste Zeit schlafen legen und nur dann aufwecken, wenn z.B. ein Pin getoggelt wird. Mit Polling dagegen hängt er die ganze Zeit in einer Schleife fest.
Im Bezug auf Situationen, in denen viel Rechenkapazität übrig ist bzw. der Stromverbrauch keine Rolle spielt, kann ich deinen Standpunkt durchaus verstehen.


grüssse
;-)
Benutzeravatar
drohne235
Administrator
Beiträge: 2284
Registriert: So 24. Mai 2009, 10:35
Wohnort: Lutherstadt Wittenberg
Kontaktdaten:

Re: Leben ohne Interrupt

Beitrag von drohne235 »

Ich denke für einen Modus mit extrem geringem Stromverbrauch geht man bei der Propellerstruktur folgendermaßen vor:

1. Alle unnötigen COG's werden beendet; nur eine COG bleibt als "Wächter" aktiv.
2. Der Systemtakt wird bis auf ein Minimum reduziert.
3. Die Wächtercog begibt sich über waitpeq(state,mask,0) oder waitpne in einen Wartezustand, aus welchem er bei dem definierten Ereignismuster aufwacht und das restliche System wieder weckt.

Ohne externe Hardware kommt man da wohl auf irgendwo in den Bereich von 50 µA. Und das funktioniert ja gerade weil der Prop nicht pollt, sondern eine COG quasi auf das Ereignis wartet. Pollen würde ja bedeuten, das die Cog in einer Schleife ständig abfragt, hier geht sie aber in einen Wartestatus. Irgendwo verschwimmen da aber letztlich ein wenig die Grenzen. Funktionell würde es ja keinen Unterschied machen, ob ich eine COG pollen lasse oder per wait* in einen Schlafzustand schicke - in beiden Fällen ist eine COG genau damit beschäftigt auf das Ereignis zu warten. Allerdings verbraucht eine COG Wartezustand von einem wait*-Befehl nur ca. 1/10tel einer COG in einer Pollingschleife.

Einen Mikrocontroller der per Interrupt aufwacht macht irgendwie ja letztlich genau das gleiche denke ich - er beendet die aktuelle Programmausführung und wird halt durch das Ereignis aufgeweckt. Könnte man beim Prop auch ohne Interrupt machen - und muß es ja auch, weil man keine andere Wahl hat... :)

Für einen extrem geringen Verbrauch braucht man noch was externes, wie diese 3nA-Standbyschaltung, aber da wird die Kiste ganz einfach eingeschaltet wenn man sie braucht:

http://forums.parallax.com/forums/defau ... 5&m=272615
http://forums.parallax.com/forums/attach.aspx?a=22665
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
Benutzeravatar
oog
Beiträge: 103
Registriert: Do 30. Jul 2009, 14:12
Kontaktdaten:

Re: Leben ohne Interrupt

Beitrag von oog »

drohne235 hat geschrieben:Der Propeller ist ja bekanntlich in seiner Architektur etwas anders als andere Prozessoren. Das macht Spaß, aber an der einen oder anderen Stelle ist es für mich persönlich schon etwas mühsam, sich von den bisherigen Denkstrukturen zu lösen.

...

Also, wie sieht das mit euch und den Interrupts aus? Sehe ich die Sache so falsch, ist der Propeller und seine Struktur eine Sackgasse oder ein Repräsentant der zukünftigen Entwicklung?
Ja, der Propeller ist schon sehr besonders. Ich persönlich arbeite gern mit Interrupts und finde es schade, dass der Prop sie nicht unterstützt.

Was mir noch mehr fehlt ist der Returnstack.
Wärend der Laufzeit schreibt der Prop die Adresse des Unterprogramm-Calls als Rücksprungwert in freie Bits des Return-Befehl. Deshalb kann man ein Unterprogramm nicht an unterschiedlichen Stellen mit einem Return verlassen, sondern nur an genau einer Stelle.
Rekursion ist damit auch nicht so ohne weiteres möglich.

Dafür bekommt man eine sehr ordentliche Rechenleistung.
Benutzeravatar
drohne235
Administrator
Beiträge: 2284
Registriert: So 24. Mai 2009, 10:35
Wohnort: Lutherstadt Wittenberg
Kontaktdaten:

Re: Leben ohne Interrupt

Beitrag von drohne235 »

Code: Alles auswählen

Ja, der Propeller ist schon sehr besonders. Ich persönlich arbeite gern mit Interrupts und finde es schade, dass der Prop sie nicht unterstützt.
Keine Frage, an Interrupts hat man sich gewöhnt und die damit verbundenen und erprobten Lösungsansätze kommen halt immer ganz automatisch - ist bei mir ja nicht anders... :)

Aber wenn man mal wirklich drüber nachdenkt: Was kann man mit Interrupts machen, was mit parallel laufenden COG's nicht geht? Mir fällt da so spontan nicht so sehr viel ein. Es gibt sicher Problemstellungen, die sich evtl. eleganter lösen lassen: Wenn man zum Beispiel mehrere relativ langsame Ereignisse und deren Bearbeitung in einer COG zusammenfassen möchte, so könnte man alle diese Serviceroutinen in einer COG zusammenfassen und durch die verschiedenen Ereignisse/Interrupts triggern lassen. Die Befehle waitpeq/waitpneq können ja nur auf genau ein definiertes Ereigniss/Muster reagieren. In so einem Fall müsste man wahrscheinlich wirklich pollen, aber wenn man mit einer Sprungtabelle arbeitet, welche man aus den Eingangswerten bildet, so kann man sicher genau so schnell arbeiten wie mit den meisten Interrupthandlern, denn ich schätze mal das Interrupts auch einiges an Ressourcen kosten um den Prozessorzustand zu sichern und wieder herzustellen. Das kommt vielleicht in die gleichen Größenordnungen wie ein Polling + Sprungtabelle.

Und an diesem Punkt sind wir dann auch bei PASM - was ja noch absonderlicher ist. :) Ich hab früher recht viel in Assembler programmiert, aber mit PASM werd ich so schnell nicht warm. Ich vermute, das ein guter PASM-Programmierer mit wenigen Befehlen einen virtuellen Interrupthandler für viele Interruptquellen realisieren kann - ich bin da immer extrem überrascht wie kompakt solche Lösungen immer sind. Und wenn man so einen Handler erstmal hat, muß man ja nicht mehr an die Grausamkeiten von PASM denken, sondern kann ihn ja fast genau so nutzen wie eine dedizierte Interrupthardware. Da ist dann nachher eigendlich kein Unterschied. Für mich persönlich ist PASM mehr ein Mikrocode - wobei mit den realtiv kleinen Cores ja auch nicht so viel geht und vielleicht auch nicht gehen muß. Nehmen wir mal an, jede COG hätte 32 K cogRam und auch entsprechend komplexere Befehle: Man würde doch ganz automatisch das Problem weniger faktorisieren und wieder monströse und monolithische Brocken programmieren. Vielleicht ist es ganz gut, das Problem in kleine Teile zu zerlegen; vielleicht ist es ganz gut für die Übersichtlichkeit. Ich meine, man muß auch mal in die Zukunft denken: in zwei, drei Jahren haben wir vielleicht solche Chips mit 64 oder 128 Cores - das ist doch irgendwie nur beherrschbar, wenn die Strukturen einfach sind.

Aber nochmal zurück zum Call, Return und Stack: Wenn man mehr braucht, als das was eine COG bietet, müßte man versuchen, sich halt wie mit einem Mikrocode einen gewünschten Prozessor zusammenzustellen. Es gibt auch schon entsprechende Bemühungen, schau dir mal die Zog (Zylin CPU Core) an:

http://forums.parallax.com/forums/defau ... 1&m=423939

Da wird gerade genau an so einer CPU gebastelt. Hab nur nicht so viel Zeit um das alles zu verfolgen. Die andere Alternative wäre Forth
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
Benutzeravatar
oog
Beiträge: 103
Registriert: Do 30. Jul 2009, 14:12
Kontaktdaten:

Re: Leben ohne Interrupt

Beitrag von oog »

drohne235 hat geschrieben:Aber wenn man mal wirklich drüber nachdenkt: Was kann man mit Interrupts machen, was mit parallel laufenden COG's nicht geht?
Nichts. Mit dem Propeller kann man wohl alles machen, was mit anderen Controllern auch geht - aber eben anders.
Man muss schon bereit sein, sich darauf einzulassen.

Genau so gewöhnungsbedürftig ist SPIN. Der Verzicht auf ein geordnetes Beenden von Strukturen (wie "}" in C, "end" in PASCAL u.s.w.) halte ich für unübersichtlich.
Programmcode wird nur verständlich, wenn man ihn im SPIN-Editor betrachtet. Bei einem Ausdruck auf Papier verliert man schnell die Übersicht. Gerade, wenn im Code Leerzeilen stehen, und man die Einrückungen nicht mehr einwandfrei erkennen kann. :?
Es ist auch kaum möglich, mal eben eine Programmidee in einem beliebigen Editor zu erstellen und später zu übertragen. Ohne Programmstrukturen mit definiertem Anfang und Ende ist es einfach unübersichtlich.

Aber genug gemeckert. Der Chip ist es definitiv wert, sich dort einzuarbeiten. Welcher Controller bietet sonst schon eine echte Parallelverarbeitung? :mrgreen:
Und an diesem Punkt sind wir dann auch bei PASM - was ja noch absonderlicher ist. :) Ich hab früher recht viel in Assembler programmiert, aber mit PASM werd ich so schnell nicht warm.
Ja, auch da gibt es ein paar Fallstricke, insbesondere, da man bei jedem Befehl zusätzliche Flags setzen kann (Bedingte Ausführung, Ergebnis speichern oder nicht, Flags setzen oder nicht...).
Aber nochmal zurück zum Call, Return und Stack: Wenn man mehr braucht, als das was eine COG bietet, müßte man versuchen, sich halt wie mit einem Mikrocode einen gewünschten Prozessor zusammenzustellen. Es gibt auch schon entsprechende Bemühungen, schau dir mal die Zog (Zylin CPU Core) an:
Ja, das Projekt kenn ich.
Natürlich kann man einen Stack auch in PASM emulieren, aber er wird eben nicht von den Befehlen unterstützt, wo man es erwartet. Ohne das tolle Hive-Projekt wäre ich wahrscheinlich bis jetzt nicht in die Propeller-Programmierung eingestiegen.

Übrigens muss man auch bei der Hive-Programmierung auf Interrupts nicht verzichten, "Schatzi, kannst du mal eben..." oder "Hast du an den Müll gedacht?" :lol:

Gruß, oog :B4
Benutzeravatar
drohne235
Administrator
Beiträge: 2284
Registriert: So 24. Mai 2009, 10:35
Wohnort: Lutherstadt Wittenberg
Kontaktdaten:

Re: Leben ohne Interrupt

Beitrag von drohne235 »

Übrigens muss man auch bei der Hive-Programmierung auf Interrupts nicht verzichten, "Schatzi, kannst du mal eben..." oder "Hast du an den Müll gedacht?"
LOL

Wenn ich bastle hab die Interrupts abgeschaltet: Ich hab meiner Frau mal erklärt, dass ich in dieser Zeit quasi virtuell außer Haus bin, und ich gehe ja auch nicht bei wenn sie beim Training ist und unterbreche sie... ;)
Der Verzicht auf ein geordnetes Beenden von Strukturen (wie "}" in C, "end" in PASCAL u.s.w.) halte ich für unübersichtlich.
Hmm, stimmt. Das ist mir so noch nicht bewußt geworden. Ich frage mich wie das mit dem Sphinx-Compiler direkt auf dem Propeller läuft. Aber wahrscheinlich hat da eh noch nie jemand umfangreichere Projekte erarbeitet - wer hat nicht neben dem Propeller noch einen Notebook/Netbook stehen? Mit dem Propellertool und der dortigen Darstellung arbeitet es sich ja dann auch ganz gut, und die fehlenden Strukturzeichen fördern da mehr die Übersichtlichkeit. Aber ich hab mir gerade mal Quelltexte in einem einfachen Editor angeschaut - da ist das dann wirklich extrem unübersichtlich. Das bedeutet: Wenn wir Sphinx an den Hive anpassen, brauchen wir auch einen entsprechenden Editor für eine übersichtliche Darstellung, sonst kann man das vergessen.
Mit dem Propeller kann man wohl alles machen, was mit anderen Controllern auch geht - aber eben anders.
Man muss schon bereit sein, sich darauf einzulassen.
Das ist der Punkt. Dafür wird man in ein paar Jahren sagen, wenn wir bei Multicoreprozessoren mit gigantischen Ressourcen angekommen sind: "Ich hab damals sogar so Sachen wie den Propellerchip programmiert!" :twisted: Naja, ist in jedem Fall besser als vor der Glotze zu verschimmeln... ;)
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
Benutzeravatar
drohne235
Administrator
Beiträge: 2284
Registriert: So 24. Mai 2009, 10:35
Wohnort: Lutherstadt Wittenberg
Kontaktdaten:

Re: Leben ohne Interrupt

Beitrag von drohne235 »

Update 03.04.2010:

Nicht ganz unpassend zum Thema gibt es unter den Beiträgen des Parallax Contest 2009/2010 die Implementierung eines RTOS-Kernels für eine Cog. Ein Sheduler verwaltet dabei das Timing und eine Threadliste mit den Vektoren zu den Anwendertasks. So ist es möglich in einer Cog viele verschiedene kleinere Serviceroutinen zu handeln, ohne dafür eine eigene Cog zu verschwenden. Im Beispielcode findet man ein einfaches Signaldemo mit LED's und ein Beispiel mit zwei UART-Empfangs- und Senderoutinen.

Link: http://www.parallax.com/PropRTOS/tabid/852/Default.aspx
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
Antworten