Interrupt aus main aufrufen AVR

Justus Jonas schrieb:

Konkret geht es um den Transmit Complete interrupt, welchen ich gerne einmal per Hand auslösen würde.

Such mal nach "Software Interrupt"

Justus Jonas schrieb:

ich würde gerne eine Interrupt Routine auf meinem ATmega2560 per Hand aufrufen.

cli rcall <symbolischer Name des Vectors, z.B.: UTXC0addr>

Das ruft natürlich wirklich nur die ISR auf, ändert nichts am Status der Hardware.

Hugo H. schrieb:

The RXCn Flag can be used to generate a Receive Complete interrupt (see description of the RXCIEn bit).

Soll das nur am "Sprachgefüge" liegen?

Can be used heisst, dass das Bit intern mit der Interrupt-Einrichtung verkabelt ist und es 'can' ein Interrupt-Enable-Bit gesetzt werden, sodass jenes Bit den Interrupt ausloest.

Bei 8 Bit AVR macht der RETI Befehl genau das gleiche, wie RET. Deswegen kann man theoretisch Interrupthandler wie ganz normale Funktionen aufrufen. Ich habe allerdings nicht herausgefunden, wie man das in C anstellt.

Bei 8 Bit AVR macht der RETI Befehl genau das gleiche, wie RET.

?

RETI behaves differently in AVRe, AVRxm, and AVRxt devices. In the AVRe series of devices, the Global Interrupt Enable bit is cleared by hardware once an interrupt occurs, and this bit is set when RETI is executed. In the AVRxm and AVRxt devices, RETI will not modify the Global Interrupt Enable bit in SREG since it is not cleared by hardware while entering ISR. This bit should be modified using SEI and CLI instructions when needed.

Hugo Hurtig schrieb:

Wenn ich Spaß dran habe probiere ich es mal aus

Wäre nicht das umgekehrte Vorgehen angebracht - wenn man sich unsicher ist, erst ausprobieren, und danach sich hier äußern?

S. Landolt schrieb:

? RETI behaves differently in AVRe, AVRxm, and AVRxt devices.

Da hast du jetzt ein paar spezielle AVR Serien genannt, die ich dabei nicht im Sinn hatte. Ehrlich gesagt sagen mir diese drei Abkürzungen nichts. Wo hast du die her, dass ich da mal nachlesen kann?

Ob durch den Funktionsaufruf das globale I Flag gesetzt wird, spielt bei dem angefragten Anwendungsfall keine Rolle. Denn es war vorher an und soll auch nachher an sein (nehme ich an).

Die Screenshots stammen aus https://ww1.microchip.com/downloads/en/devicedoc/atmel-0856-avr-instruction-set-manual.pdf

ein paar spezielle AVR Serien

?

AVRe sind die 'normalen von früher', AVRxt die 'neuen' - was ist an denen "speziell"?

Justus Jonas schrieb:

ich würde gerne eine Interrupt Routine auf meinem ATmega2560 per Hand aufrufen.

AVRs kennen keine Software Interrupts!

Justus Jonas schrieb:

Konkret geht es um den Transmit Complete interrupt, welchen ich gerne einmal per Hand auslösen würde.

Auf ein kaputtes Konzept, einen solchen Flicken setzen zu wollen, ist 99.999% der Fälle eine dumme Idee.

Mein Rat: Mindestens 2 Schritte zurück gehen und neu nachdenken.

Yalu X. schrieb:

USART0_TX_vect();

Das habe ich probiert, aber zumindest im Simulator klappt das nicht. Dann habe ich zum ATmega328p gewechselt, aber auch damit klappte es nicht. Siehe Screenshot. Wenn ich dort noch einen schritt weiter debugge, beginnt das Programm wieder am Anfang von main().

Offenbar springt er an die falsche Adresse. Man sieht das auch im *.lss:

1

00000080 <ISR>:

2

#include <avr/io.h>

3

4

ISR(USART_TX_vect) // ISR(USART_TX_vect) 

5

{

6

    PORTB |= 1; // PB0 auf HIGH

7

  80:  e5 e2         ldi  r30, 0x25  ; 37

8

  82:  f0 e0         ldi  r31, 0x00  ; 0

9

  84:  80 81         ld  r24, Z

10

  86:  81 60         ori  r24, 0x01  ; 1

11

  88:  80 83         st  Z, r24

12

}

13

  8a:  08 95         ret

14

15

0000008c <main>:

16

17

18

int main() 

19

{

20

    DDRB |= 3;  // PB0 und PB1: Ausgang

21

  8c:  e4 e2         ldi  r30, 0x24  ; 36

22

  8e:  f0 e0         ldi  r31, 0x00  ; 0

23

  90:  80 81         ld  r24, Z

24

  92:  83 60         ori  r24, 0x03  ; 3

25

  94:  80 83         st  Z, r24

26

    USART_TX_vect();

27

  96:  0e 94 3e 00   call  0x7c  ; 0x7c <__bad_interrupt>

28

  PORTB |= 2; // PB1 auf HIGH

29

  9a:  e5 e2         ldi  r30, 0x25  ; 37

30

  9c:  f0 e0         ldi  r31, 0x00  ; 0

31

  9e:  80 81         ld  r24, Z

32

  a0:  82 60         ori  r24, 0x02  ; 2

33

  a2:  80 83         st  Z, r24

34

}

35

  a4:  80 e0         ldi  r24, 0x00  ; 0

36

  a6:  90 e0         ldi  r25, 0x00  ; 0

37

  a8:  08 95         ret

38

39

000000aa <_exit>:

40

  aa:  f8 94         cli

41

42

000000ac <__stop_program>:

43

  ac:  ff cf         rjmp  .-2        ; 0xac <__stop_program>

Anstatt "call 0x7c" würde ich hier "call 0x80" erwarten. Ich habe mit -O1 compiliert.

Du musst die ISR vor main() platzieren.

Stefan F. schrieb:

Anstatt "call 0x7c" würde ich hier "call 0x80" erwarten.

Auf die Auflösung dieses Rätsels bin ich gespannt.

LG, Sebastian

... falsche Adresse. Man sieht das auch im *.lss

Also bei mir stimmt es im .lss-File. Zu meiner C-Umgebung kann ich aber leider nichts sagen, die ist irgendwie zusammengestoppelt.

Ich habe unter Linux den gleichen Fehler:

1

stefan@stefanspc:~/Downloads$ cat > test.c

2

#include <avr/io.h>

3

4

ISR(USART_TX_vect) // ISR(USART_TX_vect) 

5

{

6

    PORTB |= 1; // PB0 auf HIGH

7

}

8

9

10

int main() 

11

{

12

    DDRB |= 3;  // PB0 und PB1: Ausgang

13

    USART_TX_vect();

14

  PORTB |= 2; // PB1 auf HIGH

15

}

16

17

stefan@stefanspc:~/Downloads$ avr-gcc -Wall -gdwarf-2 -std=gnu99 -O1 -mmcu=atmega328p test.c

18

test.c:3:1: warning: return type defaults to ‘int’ [-Wimplicit-int]

19

 ISR(USART_TX_vect) // ISR(USART_TX_vect) 

20

 ^

21

test.c: In function ‘ISR’:

22

test.c:3:1: warning: type of ‘__vector_20’ defaults to ‘int’ [-Wimplicit-int]

23

test.c:6:1: warning: control reaches end of non-void function [-Wreturn-type]

24

 }

25

 ^

26

stefan@stefanspc:~/Downloads$ avr-objdump -h -S a.out

27

28

a.out:     file format elf32-avr

29

30

...

31

32

0000007c <__bad_interrupt>:

33

  7c:  0c 94 00 00   jmp  0  ; 0x0 <__vectors>

34

35

00000080 <ISR>:

36

#include <avr/io.h>

37

38

ISR(USART_TX_vect) // ISR(USART_TX_vect) 

39

{

40

    PORTB |= 1; // PB0 auf HIGH

41

  80:  28 9a         sbi  0x05, 0  ; 5

42

}

43

  82:  08 95         ret

44

45

00000084 <main>:

46

47

48

int main() 

49

{

50

    DDRB |= 3;  // PB0 und PB1: Ausgang

51

  84:  84 b1         in  r24, 0x04  ; 4

52

  86:  83 60         ori  r24, 0x03  ; 3

53

  88:  84 b9         out  0x04, r24  ; 4

54

    USART_TX_vect();

55

  8a:  0e 94 3e 00   call  0x7c  ; 0x7c <__bad_interrupt>

56

  PORTB |= 2; // PB1 auf HIGH

57

  8e:  29 9a         sbi  0x05, 1  ; 5

58

}

59

  90:  80 e0         ldi  r24, 0x00  ; 0

60

  92:  90 e0         ldi  r25, 0x00  ; 0

61

  94:  08 95         ret

62

63

00000096 <_exit>:

64

  96:  f8 94         cli

65

66

00000098 <__stop_program>:

67

  98:  ff cf         rjmp  .-2        ; 0x98 <__stop_program>

68

69

stefan@stefanspc:~/Downloads$ avr-gcc --version

70

avr-gcc (GCC) 5.4.0

71

Copyright (C) 2015 Free Software Foundation, Inc.

72

This is free software; see the source for copying conditions.  There is NO

73

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Falk B. schrieb:

Passt. Die ISR liegt auf Adresse 0x80, und der rcall ruft sie auf. Ganz normal.

Warum zum Teufel geht das bei dir, und bei mir nicht?

Passt.

Genau - funktioniert hier realiter.

Falk B. schrieb:

Da fehlt das #include "avr/interrupt.h"

Oh Mann, ja genau das war bei mir der Fehler.

Also halten wir fest: ISR kann man einfach wie normale Funktionen aufrufen.

Stefan Frings schrieb:

Oh Mann, ja genau das war bei mir der Fehler.

Merkwürdig: bei mir hier bringt der Compiler drei Warnungen, wenn ich das '#include <avr/interrupt.h>' weglasse - bei Ihnen nicht?

S. Landolt schrieb:

Merkwürdig: bei mir hier bringt der Compiler drei Warnungen, wenn ich das '#include <avr/interrupt.h>' weglasse - bei Ihnen nicht?

Siehe

Stefan F. schrieb im Beitrag #7338987: Ausgaben des Compilers

Ich habe die Warnungen schon gesehen, aber nicht erkannt, was deren Ursache ist.

Siehe ...

Da ich ausschließlich unter Windows arbeite, hatte ich mir Ihre Linux-Version gar nicht erst angeschaut.

Stefan F. schrieb:

Also halten wir fest: ISR kann man einfach wie normale Funktionen aufrufen.

Man kann auch im 10.Stock aus dem Fenster springen. Ratsam ist beides nicht.

Mal ganz deutlich gesagt: Interrupt-Services sind NICHT dafür gemacht, im Programm von irgendwo her aufgerufen zu werden - auch wenn es formal gehen sollte. Und wer da meint, daß er es dennoch braucht, der hat an anderer Stelle etwas ganz verkehrt gemacht.

W.S.

Stefan F. schrieb:

Also halten wir fest: ISR kann man einfach wie normale Funktionen aufrufen.

Ja. Sinnvoll ist das aber praktisch nie. I.d.R. hantieren ISRs ja irgendwie mit der Hardware, die den Interrupt ausgelöst hat. Und deren Status passt halt nicht. D.h.: es ist relativ wahrscheinlich, dass die ISR "anders" läuft, als im echten Interruptfall.

Christoph db1uq K. schrieb:

Früher (TM) hätte man eine Rücksprungadresse auf den Stack gelegt und dann einen Sprung auf die Interrupt-Routine gemacht. Aber das waren noch 6502-Tricksereien.

Nichts anderes passiert beim direkten Aufruf in C.

Peter D. schrieb:

[TXC-Interrupt]

Er wird doch nur benötigt, um bei RS-485 die Richtung des Transceivers umzuschalten.

Das mag die einzige nützliche Anwendung sein, die DU kennst, aber es gibt noch etliche mehr...

Stefan F. schrieb:

Nichts anderes passiert beim direkten Aufruf in C.

Sei froh, daß es sich hier um einen AVR handelt. Bei anderen Architekturen sieht sowas völlig anders aus, da wird ggf. auch der Stack gewechselt, der Programmlevel von User auf System oder Supervisor gewechselt, beim ARM7 ggf. auch Code (Arm/Thumb) und einige Register (Schattenregister) gewechselt usw.

Von wegen nichts ... Eben genau deshalb gibt es eine Reihe von Randbedingungen bei der Verwendung von C, die eine saubere Trennung zwischen dem Grundprogramm und den ISR erfordern. Und bei kleineren Plattformen (PIC, 8051 usw.) hat man oftmals keine reentranten Funktionen, weil lokale Variablen eben NICHT auf dem Stack stehen und RAM nur sehr begrenzt vorhanden ist, da sollte man sowas auch besser bleiben lassen.

Und Leute, die offenbar mit den AVR aufgewachsen sind, haben sich dann solche schlechten Manieren angewöhnt. Ja auch das ubiquitäre Verwenden von DI/EI gehört dazu.

W.S.

W.S. schrieb:

Sei froh, daß es sich hier um einen AVR handelt. Bei anderen Architekturen sieht sowas völlig anders aus

Ich weiss. Deswegen hatte ich das (siehe oben) extra nochmal ausprobiert, bevor ich hier Blödsinn verzapfe.

Manche Dinge sind eben Hardware spezifisch. Man kann nicht alles völlig generisch programmieren.

Stefan F. schrieb:

Manche Dinge sind eben Hardware spezifisch. Man kann nicht alles völlig generisch programmieren.

Das allerdings ist, was die nixwissenden C-Apologeten immer wieder versprechen, also inbesondere die, die nie nahe an der Hardware programmieren...

Die richtigen C-Programmierer wissen natürlich sehr wohl, dass es da eine Grenze gibt, die sich auch in C nicht wirklich überwinden läßt. Es läuft dann halt auf die allseits beliebten #ifdef-Orgien hinaus, wenn man nahe an der Hardware irgendwas "portabel" programmieren will.

Ich halte diese Art der "Portabilität" allerdings sowieso für einen ziemlichen Euphemismus. Wie wohl jeder, der beim Kompilieren solchen Codes in den #else-Zweig dieser #ifdef-Orgien gelangt...