Intteruptprioritäten AVR ändern/umgehen in C

Mensch danke, darauf wär ich nie gekommen! Du meinst ich soll die 
"_delay_ms(500);" Zeilen entfernen?

Danke Danke Danke!

Ohne was vom Code zu sehen kann man da schlecht Tipps geben.

Möglicherweise dauert die UART-ISR zu lange, weil sie ne FIFO bedient... 
man weiß es nicht.

Welche Möglichkeiten hast du, die IRQ-Latenz zu verringern?

Hallo Stephan,

vielen Dank für Deine zur Frage passende Antwort! Hab mal schnell 
nachgeschaut - aber leider täuscht mich meine Erinnerung nicht - das 
Int-Flag läßt sich nicht manuell setzen. Jedoch könnte man das ICP-ISR 
evtl. als Funktion aus dem Comp-Match-Int aufrufen - vielen Dank für die 
gute Idee!

Grüße
Robert

Es gibt mehrere Möglichkeiten:

1

ISR( TIMER1_CAPT_vect, ISR_NOBLOCK )

2

{

3

// ...

4

}

Dann kann der Interrupt unterbrochen werden.


Den langsamen UART-Interrupt kann man leider nicht unterbrechbar machen, 
da das Flag beim Eintritt nicht gelöscht wird.
Du kannst aber die UART mit nem Timerinterrupt pollen und den dann 
unterbrechbar machen.


Peter

Peter Dannegger schrieb:


> Den langsamen UART-Interrupt kann man leider nicht unterbrechbar machen,
> da das Flag beim Eintritt nicht gelöscht wird.

Doch geht auch. Allerdings nicht über diesen Mechanismus.

Stattdessen implementirt man es als normale ISR, deaktiviert direkt am 
Anfang die betreffende IRQ und dann folgt ein SEI. Am Ende alles retour.

So hab ich's mal in eienr länglichen Tmer-IRQ gemacht, die den 
IR-Empfang ausbrembste. Hat prima funktioniert. (Inzwischen geht's 
allerdings anders und ohne kaskadierende IRQ indem ich in der Timer-IRQ 
auf den IR polle.)

Wenn die Auswerte-Routinen für ICP/COMP nicht zu lange dauern, sehe ich 
keinen Grund, warum es nicht gehen sollte.

Robert B. schrieb:
> Mensch danke, darauf wär ich nie gekommen! Du meinst ich soll die
> "_delay_ms(500);" Zeilen entfernen?
>
> Danke Danke Danke!

Wenn das tatsächlich ernst gemeint ist, dann hat es wenig Sinn über 
irgendwelche ausgefuchsten Mechanismen zu debattieren. Dann stimmt 
vorher schon so einiges nicht, das bereinigt werden müsste.

Karl heinz Buchegger schrieb:
> Robert B. schrieb:
>> Mensch danke, darauf wär ich nie gekommen! Du meinst ich soll die
>> "_delay_ms(500);" Zeilen entfernen?
>>
>> Danke Danke Danke!
>
> Wenn das tatsächlich ernst gemeint ist, dann hat es wenig Sinn über
> irgendwelche ausgefuchsten Mechanismen zu debattieren. Dann stimmt
> vorher schon so einiges nicht, das bereinigt werden müsste.

Nein, war es natürlich NICHT! Es sind überhaupt keine _xs_delays in 
meinem ganzen Projekt. Die Antwort war um all jene glücklich zu machen, 
die glauben immer ihr lapidares Basiswissen kundtun zu müssen.

Ich "dekodiere" bzw. "enkodiere" einen seriellen Bus mit engen 
zeitlichen Vorgaben. Leider ist dafür auch mit Klimmzügen der 
Hardware-USART nicht ansatzweise in der Lage, so dass ich eben - extrem 
vereinfacht ausgedrückt - mit dem ICP-Int "dekodieren" und mit dem 
Compare-Match "enkodieren" muss. Da ich die Timing-Constraints einhalten 
muss ist das nicht so einfach. Die einzige "Beschleunigung" wäre es alle 
Bitzeiten vorher zu berechnen, was aber aufgrund von Telegrammlänge zu 
viel Speicher verbraucht: 30 Byte * 10 Bit/Byte * 2 Flanken/Bit * 
16bit/Flanke = 1,2KByte SRAM nur für ein Sende-Paket wenn nur 0xFF 
verschickt werden. Gleiches für RX = geht nicht. Also muss ich es leider 
wohl on-the-fly machen.

Die Möglichkeit Interrupts wieder global freizugeben scheint die Lösung 
zu sein. Es funktioniert alles wie gewünscht!

Vielen Dank!

Grüße
Robert