Programmierlogikfrage

Hallo,

Folgendes Szenario:

Im Mainprogramm ist eine whileschleife, welche die CPU ununterbrochen in den Idlemode schickt.

In einer Timerinterruptbehandlungsroutine sind ein paar Aktionen.

Gedacht ist es so: Hat der Timer seine Arbeit erledigt, wechselt die CPU wieder zurück ins Hauptprogramm und legt die CPU in der Whileschleife schlafen.

Was passiert jetzt, wenn gerade der Befehl zum schlafengehen kommt und im gleichen Moment ein Timerinterrupt. Laut meiner Mikroprozessorvorlesung arbeitet die CPU den vorigen Befehl noch zu Ende ab. Dies würde nach meinem Verständnis dazu führen, dass a) der Interrupt kommt, b) der Befehl "Schlafenlegen" zuendebearbeitet wird und c) die CPU dann schläft und der Timerinterrupt dann für immer und ewig blockiert ist, weil er gerade in der Behandlungsroutinde steckt.

In mein Szenario korrekt? Oder was ist an diesem Denkansatz falsch?

MfG,

Markus

Reply to
Markus
Loading thread data ...

"Markus" schrieb im Newsbeitrag news:44ef1314$0$10149$ snipped-for-privacy@newsspool2.arcor-online.net...

Sicher.

Klar, BEVOR sie guckt, ob ein Interrupt ansteht (egal wann er elektrisch bei der CPU ankam), und jenes tut sie BEVOR sie den naechsten Befehl ausfuehrt

(obwohl nicht auszuschliessen ist, das irgendwo auf der Welt ein uC existiert, der sich dabei verheddert, z.B. der 80286 hatte ein fehlendes Bit im Segmentdeskriptor, der 68HC11 bekam das EEPROM-Programmieren durcheinander, es gibt schon uC bei denen die Entwickler was uebersehen haben, aber erstaunlich wenig im Vergleich zu Software).

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
 Click to see the full signature
Reply to
MaWin

"MaWin"

Hi MaWin,

Ja aber nun bearbeitet eine CPU ja mehrere Befehle gleichzeitig. Hab jetzt den Fachbegriff vergessen. Ein Befehl lädt beispielsweise grad ausm Register, ein anderer schreibt grad was irgendwohin und ein weiterer wird beispielsweise gerade in der ALU ausgeführt. Das heißt 3 oder mehr Befehle können technisch alle zur gleichen Zeit "on-the-fly" sein. Was ist wenn der "Schlafenlegebefehl" beispielsweise schon "angefangen" wurde.

MfG,

Markus

Reply to
Markus

"Markus" schrieb im Newsbeitrag news:44ef17bf$0$1394$ snipped-for-privacy@newsspool3.arcor-online.net...

Noe. Nicht dein Microcontroller.

Und bei komplexeren (Pentium etc.) muessen die Entwickler der CPU halt aufpassen, das so was richtig behandelt wird. Lass das also deren Problem sein.

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
 Click to see the full signature
Reply to
MaWin

"MaWin"

Hm? "Pipelining" heißt das laut meinem Script. Solltest du Recht haben, dass der 8015 das nicht macht, ist mein Script unvollständig differenziert bzw. an allen Stellen ohne Beispiele *grml*.

Reply to
Markus

MaWin schrieb:

Naja, selbst ein Atmel lädt den nächsten Befehl aus dem Flash während er den aktuellen Befehl ausführt. Das ist auch schon eine primitive Pipeline.

Ja.

Jan

Reply to
Jan Lucas

Markus schrieb:

Du darfst MaWin ruhig glauben.

Was für ein Script? Eines über aktuelle Prozessorarchitekturß Was glaubst Du, wie alt der 8051 ist...

Gruß Henning

--
henning paul home:  http://www.geocities.com/hennichodernich
PM: henningpaul@gmx.de , ICQ: 111044613
Reply to
Henning Paul

Dann mögest Du bitte mal Dein Skript mit dem Text in Wikipedia vergleichen:

formatting link

Weiterhin solltest Du im Skript über Serialisierung/Sequentialisierung lesen. Es gibt nämlich Befehle, die eine Pipeline erst mal leerlaufen lassen, bevor sie bearbeitet werden.

Außerdem sollte man nicht annehmen, dass der Befehl zum Idlemode die Interrupts löscht. Solange ein IR anliegt, sollte der Befehl Idle nichts bewirken.

Norbert

Reply to
Norbert Hahn

Noch ein Tip am Rande zum Themenkreis:

Bei einem onchip Timerint trifft Deine Befuerchtung bei einem "normalen" Design hoechstwahrscheinlich nie zu, siehe ja auch die Antworten der anderen - aber wenn Du dann mal von einer externen Quelle aufgeweckt wirst versuche sicherheitshalber, falls waehlbar, immer auf Pegel zu triggern und nicht auf Flanke - so wie ich einmal. Obwohl ich gestehen muss dass das Verhalten (wie meistens bei gut dokumentierten Architekturen) in meinem Fall eh korrekt beschrieben wurde hatte ich es zuerst einmal tagelang (!) konsequent ueberlesen.

Auch habe ich damals gesehen das nicht alle Hersteller unter sleep mode

100%tig das gleiche verstehen. Hier gibt es fliessende Unterschiede in Richtung totalem power down.

Bei manchen koennte der geschilderte angenommene "Fehler" eventuell sogar ganz untergehen weil, sofern z.B. wie bei Dir ja der Oszillator weiterlaufen muss, nach kuerzester Zeit der gerade eben angelaufene sleep mode durch den anstehenden Timerint gleich wieder aufgehoben wird. Je nach Kern gibt es halt dann ein paar definierte Zyklen Wartezeit und es geht gleich weiter.

Auch ist zu beachten, falls Du mit einem ICE arbeitest, das im Gegensatz zu heutigen JTAG-Methoden manche alte bondout chips das nicht richtig nachvollziehen konnten. Hierzu muss halt erneut die Doku herhalten.

Viel Spass bei Deinem Projekt!

mfg Charlie

btw: darf man fragen was es werden soll?

Reply to
Karl M. Prager

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.