Disign Frage (Interrupt oder Main)

[wkrug]

der realität zu tun zu haben den der Interupt des AD's (messung fertig) kommt nicht

Das mag ich jetzt fast nicht glauben.
Hast Du den Simulator auch wirklich lange genug laufen lassen ?
Die benötigten Flags werden auf jeden Fall auch im Simulator gesetzt.
Das Problem dabei ist, das die Simulation mit der tatsächlichen Taktrate gemacht wird, also erstmal 1000...2000 Befehle durchlaufen bevor der AD Interrupt kommt.
Gib beim Simulator mal den Cursor in die AD Interruptroutine und starte den Simulator mit Run to Cursor. Wenn sich da dann nach 1...2 Minuten! immer noch nichts tut würde ich die Interrupteinstellungen überprüfen.

Periphere Bausteine und Simulator sind allerdings wirklich ein Problem.
Man kann natürlich die Änderung an den einzelnen Pins, die die Peripherie erzeugt hätte, per Hand eingeben. Das ist aber schwierig und man vertut sich leicht.

Eine Möglichkeit wäre noch ein Debugging über JTAG mit Breakpoints. Das geht aber nur bei den größeren Controllern ( Ab ATMEGA 16 ) und so ein JTAG Interface ist auch nicht gerade billig.

[T.J.]

Um mal auf die Designfrage zurückzukommen: ich persönlich bevorzuge mehr Interruptgesteuert als polling. Beides hat natürlich vor und nachteile, aber die Vorteile der Interrupts überwiegen in meinen Augen deutlich.

a) es wird strukturierter und übersichtlicher
b) das ereignis wird immer überwacht, beim polling nur dann wenn du es abfragst
c) stromsparender, denn dann ist der sleepmode möglich

[Besserwessi]

Besonders wenn man nur eine Interruptquelle benutzt darf die ISR Routine auch recht lang sein und sogar warten. Bei mehreren Interruptquellen oder wenn die Interrrupts schnell kommen sollte die ISR Routine aber kurz sein, sonst verpaßt man was.

Der AD Wandler Ready Interrupt wird so weit ich weiss leider nicht richtig simuliert, den muß man dann gelegentlich per Hand auslösen. Den neuen Simulator habe ich aber auch noch nicht probiert.

[sechsrad]

Besonders wenn man nur eine Interruptquelle benutzt darf die ISR Routine auch recht lang sein und sogar warten.

neiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii n.

Interruptquelle > immer kurz

neiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiin .

sogar warten > total vermeiden.

[izaseba]

@sechsrad,
reinige mal Deine Tastatur, irgendwas klemmt da.

So pauschal kannst Du das nicht sagen, warum darf ich in einer ISR kein "Krieg und Frieden" machen, wenn der Anwendungsfall das zulässt ?

[wkrug]

warum darf ich in einer ISR kein "Krieg und Frieden" machen, wenn der Anwendungsfall das zulässt ?

Wenn ich nur eine einzige Anwendung mit nur einem Interrupt laufen habe, kann ich, bis auf ein paar spezielle Ausnahmen, die Anwendung genausogut im Main Programm laufen lassen.
Ein Interrupt soll ja möglichst schnell auf ein "Ereignis" reagieren.
Das funktioniert aber dann schon nicht mehr richtig, wenn bei 2 Interrupts einer "Krieg und Frieden" spielt. Der zweite Interrupt kann da sehr häufig durch den langen verzögert werden.

Für Dich als erfahrenen Programmierer ist es sicher kein Problem abzuschätzen, ob Du dir eine lange Interruptroutine leisten kannst oder nicht.
In 99% aller Anwendungsfälle wird man aber zu möglichst kurzen Interruptroutinen greifen müssen.
In einer Interruptroutine z.B. auf die Änderung eines Portzustandes zu warten, der eventuell nie eintritt, blockiert die komplette Abarbeitung des weiteren Programmes.
Ich versuche, soweit das irgendwie möglich ist, den weiteren Programmablauf fortzuführen (z.B. mit Zeitüberwachungen), auch wenn ein erwartetes Eingangssignal nicht kommt. Das Ganze natürlich im Main Programm.
Beispiel:
Ich starte einen externen A/D Wandler und warte auf ein "Conversation Ready".
Allerdings hat sich der A/D Wandler aufgehängt und tut schlichtweg gar nichts. In der "Ready" Warteroutine wird ein Timer abgefragt.
Erreicht dieser Timer einen Wert der höher ist als die maximale "Conversation Time" wir ein Fehlerzähler hochgezählt.
Wenn dieser Fehlerzähler den Schwellwert ( z.B. 3 ) erreicht wird der A/D Wandler resettet. Das Programm kann sich somit im Prinzip nicht festlaufen und liefert im schlimmsten Fall ( A/D Wandler defekt ) keine, bzw. falsche Wandlerergebnisse. Andere Subroutinen, wie eine Drehzahlmessung, können aber unabhängig davon weiterlaufen.

[Besserwessi]

In der Regel sollte die ISR schon kurz sein und nicht auf etwas externes warten. Wenn ein Interrupt zeitkritisch ist, muß man eventuell sogar die ISR Routine sogar in Assembler schreiben, denn zumindest GCC erzeugt ziehmlich viel extra code am Anfang und Ende der ISR Rotine.

Es gibt aber auch Ausnahmen, wo man den Datenaustausch von der Interrupts Routine zu Hauptprogramm sparen kann.
Ich habe zum Beispiel eine Anwendung wo im Main Teil nur ein SLEEP in einer Endlosschleife ist. Die ISR Routine gibt 10 Sekunden lang etwas aus. Nach der ISR routine geht der Controller dann in den Tiefschlaf bis zum Nächsten externen Interrrupt.

[sechsrad]

.....In der Regel sollte die ISR schon kurz sein.....


nicht nur wenn du die regel hast , sondern immer!

die freizeit kannst du in der main verbringen und nicht in einer isr.