mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Atmega128 Prioritaeten


Autor: Pablo Escobar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
servus!

die prioritaeten im atmel sind ja ueber die adresse des jeweiligen
interruptvektornamen definiert. kann man diese prioritaeten irgendwie
veraendern?

des weiteren wird im avr-gcc-tutorial und auch im avr-libc-user-manual
davon abgeraten interrupt-nesting zu benutzen, dass ich also weitere
interrupts aufrufen kann, waehrend ich gerade in einer ISR bin. wie ist
das? benutzt man das wirklich nicht? problematischerweise wird ja beim
eintritt in einen interrpt das globale IR-flag zurueckgesetzt. das muss
ich nun in der ISR wieder setzen, um nesting zu aktivieren. dabei kann
mir aber der eine oder andere hoeherpriorisierte interrupt rausgehen,
wenn dieser direkt zwischen ruecksetzen und setzen des globalen bits
aufgerufen wird.

wie wird das also beim atmel gehandhabt?

Esco

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interrupt-Prioritäten gibt es bei den AVRs nicht wirklich. Die Priorität
gilt nur für gleichzeitig auftretende Interrupts.

Während der Abarbeitung der ISR ist das I-Flag deaktiviert, damit kein
anderer Interrupt dazwischen funkt. Setzt man das I-Flag von Hand, dann
muss man sicherstellen, dass keine Konflikte entstehen. Dies wird
schwierig, wenn mehr als zwei Interrupts genutzt werden.

Deshalb sollte man lieber die ISRs so kurz wie möglich halten und auf
die Interrupt-Freigabe im Interrupt verzichten.

...

Autor: Pablo Escobar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aha. ja wie macht man das normalerweise? also ich moechte gerne alles
in ISRs abarbeiten. dabei moechte ich mich auf sehr kurze ISRs
beschraenken und die eigentliche arbeit dann in 3 timerinterrupts
machen lassen. ich habe dann 3 timer (eigentlich 4, aber einer faellt
wegen der vorgegebenen priorisierung leider weg...) die alles
abarbeiten: 120 µs, 1ms und 500ms. der 120 µs-task hat dann die
hoechste prioritaet und interruptet immer die beiden anderen. wobei der
1ms-task dann noch den 500ms-task interrupten kann (sonst wuerden die ja
nie aufgerufen werden). oder wie handhabt ihr das, dass dann auch alles
zum richtigen zeitpunkt abgearbeitet wird und das dann noch mit
unterschiedlichen aufruffrequenzen? ich moechte das ganze gerne ohne
"real-time"-os machen.

Esco

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich kann nur für ASM sprechen.

Ich richte mir meist ein Register mit Boolschen Variablen (Flags) ein,
setze in der ISR das entsprechende "Jobflag" und frage in der
Mainloop die Jobflags der Reihe nach ab. Ist eins gesetzt, wird die
entsprechende Routine ausgeführt und das Jobflag gelöscht.
Die Timer-ISR mit der schnellsten Aufrufzeit kann ihre Arbeit dann
selbst machen, somit schafft sie ihre Arbeit auch bei längeren
Mainloop-Jobs.

Einige Beispiele in ASM mit kleineren AVRs (der 128er kann ich nicht
löten) findest du auf www.hanneslux.de/avr/ , wobei da auch nicht alles
optimal ist. Ein Beispiel mit Int-Freigabe im Int ist auch dabei, und
zwar der Tiny15-Fahrtregler im Modellbaubereich.

...

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>sonst wuerden die ja nie aufgerufen werden

Grundsätzlich gilt bei den AVRs: Wenn eine ISR aufgerufen wird, wird
das I-Flag gelöscht. Dann wird die ISR abgearbeitet und beim Rücksprung
ins Hauptprogramm wird automatisch das I-Flag wieder gesetzt. Wenn in
der Zwischenzeit (also während der Abarbeitung der ISR) ein
Interrupt-Ereignis von einer anderen Quelle auftritt, wird das
dazugehörige Interrupt-Flag gesetzt. Nach dem Rücksprung aus der o.g.
ISR wird zunächst mindestens ein Befehl im Hauptprogramm ausgeführt und
dann die zu dem zwischenzeitlich aufgetretenen Interrupt gehörende ISR
aufgerufen. Dann gilt das selbe wie oben. Es geht normalerweise kein
Interrupt verloren, es sei denn, eine ISR dauert zu lange und während
diese abgearbeitet wird treten mehrere Interrupts von der anderen
Quelle auf. Dann wird nach dem Rücksprung nur einmal die entsprechende
ISR aufgerufen, alle anderen Ereignisse gehen verloren.

Nested Interrupts sind gerade dann gefährlich, wenn Interrupts in sehr
kleinen Abständen kommen, da es dann zu einem Stack Overflow kommen
kann. Deshalb sollte man sie vermeiden, wo es nur geht. Die Methode,
die Hannes anführt (mit Jobflags und Bearbeitung von Aktionen, die
nicht zu zeitkritisch sind, im Hauptprogramm) ist sicherlich für die
meisten Anwendungen die beste. Ich selbst habe damit bisher nie
Probleme gehabt.

Bei Deiner 120µs-Interrupt-Geschichte musst Du natürlich darauf achten,
dass die dazugehörende ISR wesentlich weniger als 120µs in Anspruch
nimmt, sonst geht wirklich was verloren.

Gruß

Johnny

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mach nur ein Interrupt mit dem größten gemeinsamen Teiler (oder wie
nennt man das Ding doch gleich?); hier 40 µs. Der prüft zunächst, ob
die 120 µs-Routine fällig ist, anschließend, ob die 1 ms dran ist und
zum Schluß der 500 ms-Job.

Autor: Pablo Escobar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, dann ist aber das problem, dass man keine langen jobs mehr
durchfuehren kann. desweiteren hab ich dann keine echtzeit mehr fuer
die ganzen tasks. bei der 4-timer-loesung hast du ja zumindest
echtzeitgarantie fuer alle aufrufe. der niederste job wird dann
garantiert in echtzeit abgearbeitet. und man kann dann ohne grossen
aufwand ausrechnen, wie lange welcher job braucht und weiss ganz genau,
wann welcher job aufgerufen wird, und wann er beendet ist.

Esco

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"der niederste job wird dann garantiert in echtzeit abgearbeitet."

OhGottogottogottogott !

Nochmal gaaanz laaangsam zum Mitschreiben, der AVR hat keine
Prioritäten !

Wenn der langsamste Interrupt 121µs dauert, dann kannst Du Dir den
120µs Timerinterrupt sonstwohin stecken, der geht definitiv ab und zu
verloren.



Peter

Autor: Stephan Henning (stephan-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@all
da versteht Mann gar nicht warum alle Atmel HURA schreien !!!!
Kopfschüttel.....

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo ist eigentlich das Problem?
Jedes Teil hat seine Grenzen. Bei halbwegs vernünftigem Programmierstil
leisten die AVRs schon allerhand.

...

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

beim AVR bleibt nur eine Implementierung per Software mit einigen
kompromissen.



Hannes

> Ich richte mir meist ein Register mit Boolschen Variablen (Flags)
> ein,setze in der ISR das entsprechende "Jobflag" und frage in der
> Mainloop die Jobflags der Reihe nach ab. Ist eins gesetzt, wird die
> entsprechende Routine ausgeführt und das Jobflag gelöscht.
> Die Timer-ISR mit der schnellsten Aufrufzeit kann ihre Arbeit dann
> selbst machen, somit schafft sie ihre Arbeit auch bei längeren
> Mainloop-Jobs.

Ich mache es genauso. Ich deklariere mich eine Variable (uchar,uint)
und setze in der ISR entsprechende Flag's fuer eine state maschine.

Leider klappt es nicht mit zeitkritischen Sachen wie Software PWM oder
hat jemand nen Tipp?

Sollte ich die Zeitkritischen Sachen mit in die ISR nehmen und in der
ISR die State Maschine mit Informationen versorgen?

stephan

>da versteht Mann gar nicht warum alle Atmel HURA schreien !!!!
>Kopfschüttel.....

Es zwingt niemanden die AVR's zunutzen. Bei entsprechenden
Anforderungen sollte man sich den passenden µC aussuchen. Ein
Mikrocontroller mit NMI waere hier wohl recht hilfreich.

Gruß,

Dirk

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Leider klappt es nicht mit zeitkritischen Sachen wie Software PWM
> oder hat jemand nen Tipp?

Software-PWM frisst wirklich Ressourcen, da kommt es auf jeden Takt in
der ISR an. Soft-PWM hatte ich dann voll in die Timer-ISR gelegt. Dazu
gab's exklusiv-Register für die ISR, um die Registersicherei
einzusparen.

Bei der Bezeichnung "State-Machine" oder "Zustandsautomat" halte
ich mich zurück. Ich vermute zwar, das mein Programmierstil etwas in
diese Richtung geht, kenne (verstehe) aber die genaue Definition nicht.

Das, was ich dieser Tage über Zustandsautomaten gelesen habe, passt
irgendwie noch nicht so richtig in meinen Kopf. Die Theorie ist mir da
etwas zu abstrakt.

...

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Hannes:
>Software-PWM frisst wirklich Ressourcen, da kommt es auf jeden Takt
>in der ISR an. Soft-PWM hatte ich dann voll in die Timer-ISR gelegt.
>Dazu gab's exklusiv-Register für die ISR, um die Registersicherei
>einzusparen.

Ok, das mit den exklusiv Register wusste ich bis jetzt nicht und
ehrlich gesagt dauert das push / pop laenger als die isr.

>Bei der Bezeichnung "State-Machine" oder "Zustandsautomat" halte
>ich mich zurück. Ich vermute zwar, das mein Programmierstil etwas in
>diese Richtung geht, kenne (verstehe) aber die genaue Definition
>nicht.

Da schliesse ich mich an ;)

Gruß,

Dirk

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Hannes:

Hattest du ein kleines Beispiel mit den exklusiv Registern ?

Ich werde ehrlich gesagt nicht wirklich schlau aus der AVR LIBC in
diesem Bereich.

Gruß,

Dirk

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hattest du ein kleines Beispiel mit den exklusiv Registern ?
>
> Ich werde ehrlich gesagt nicht wirklich schlau aus der AVR LIBC in
> diesem Bereich.

Ich auch nicht, denn ich versuche es gar nicht erst, da ich in
Assembler programmiere. Und wenn ich da Register ausschließlich für die
ISR reserviere (und in der Mainloop nicht anrühre), dann nenne ich das
exklusive Nutzung der Register. Die Reservierung erfolgt dann aber in
meinem Kopf und nicht in irgendwelchen Compiler-Anweisungen.

So kann man aneinander vorbei reden... ;-)

...

Autor: Stephan Henning (stephan-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dirk,
aha kommt vom Z80. Na NMI hilft auch nicht immer. Heist ja nur das der
Int kommt und die Quelle erst ermittelt werden muß.
Deswegen ja NMI ( Nicht Maskiert I..)

Was fehlt ist eine Funktion zum sortieren der "Anforderungen".
Geht ja um Prioritäten. Da helfen wirklich nur Hilfsflags um die
Interruptpriotitätenlogik anderer MCU´s zu Fuß nachzuerfinden.
Leider !!!

Wobei ich persönlich glaube das sich die meisten Sachen warscheinlich
auch ohne eine "Single Cycle" MCU bewerkstelligen lassen würden.
Und dann hat man diesbezüglich weniger den Kopf voll.
Ist aber meine ganz pers. Meinung.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.