Interrupts reagieren wärend Schleifen nicht

Platz für Code muss nicht unbedingt quadratisch ausgefüllt werden.

Jan S. schrieb:
> Wie kann es sein das Schleifen interrupts verhindern???

Tun sie nicht. Ursache liegt woanders. "volatile" vergessen?

> Platz für Code muss nicht unbedingt quadratisch ausgefüllt werden.

He? Was soll das? Oder versteh ich den Witz nicht, oder is das kein 
Witz?

> Tun sie nicht. Ursache liegt woanders. "volatile" vergessen?

Also mit volatile habe ich es auch auf zwei Arten versucht:
1. volatile char read_mems=0;
2. char volatile read_mems=0;

Bringt beides nichts. Sonst Vorschläge? Oder hab ich was falsch 
verstanden? Eigentlich sagt man damit doch das die Variable nicht 
wegoptimiert werden soll, oder?

>Zu grobe Körnung des Schleifpapiers?
Man was is denn los heute? is meine Frage wirklich so dämlich oder sind 
manche Leute heut nur komisch drauf. Eigentlich bekommt man in diesem 
Forum sonst immer relativ intelligente Antworten....

Vielleicht bekomm ich ja noch ein paar gute Tipps ;-)

Grüße Jan

Jan S. schrieb:
> He? Was soll das? Oder versteh ich den Witz nicht, oder is das kein
> Witz?

Doch, ist es. Das war eine Anspielung auf die begrenzte Lesbarkeit 
deines Codes. Ritter Sport kam mir da sofort in den Sinn. Ein paar 
strategisch plazierte Leerzeilen hätten schon Wunder gewirkt.

> Also mit volatile habe ich es auch auf zwei Arten versucht:

Beides identisch.

> Man was is denn los heute? is meine Frage wirklich so dämlich

Nö, aber manchmal hat man grad einen Clown gefrühstückt. Du hast den 
Standardfehler gemacht, nur jenen Teil des Programms zu zeigen, in dem 
du den Fehler vermutest aber nicht findest, aber nicht den Teil, in dem 
er sich tatsächlich befindet. Sowas reizt den erwähnten Clown.

such mal nach einem asm"cli"


oder einem fehlenden asm"sei" in der initialisierung ;-)

A. K. schrieb:
> Ritter Sport kam mir da sofort in den Sinn.
ist doch praktisch und füllt bei tetris gleich drei halbe reihen ;-)

Ok, das is schon richtig. Ein paar leerzeilen könnt ich echt mal 
spendieren ;-)
>Beides ok.
Hmm, aber warum funktioniert das senden dann trotzdem nicht. Wenn ich es 
mir mit Wireshark ansehe, fragt mein Board mit einer Broadcast Anfrage 
an, aber sendet dann auf die Antwort hin nicht...

>Du hast den Standardfehler gemacht, nur jenen Teil des Programms zu zeigen,in dem 
du den Fehler vermutest aber nicht findest, aber nicht den Teil, in dem er sich 
tatsächlich befindet.
Aber wie soll ich denn den Teil zeigen wo der Fehler liegt, wenn ich das 
wüsste, hätte ich ja nicht das Problem das ich den Fehler nicht beheben 
kann. Soll ich ma meinen ganzen Code posten? Aber das is ne Menge...

Jan S. schrieb:
> Aber wie soll ich denn den Teil zeigen wo der Fehler liegt, wenn ich das
> wüsste, hätte ich ja nicht das Problem das ich den Fehler nicht beheben
> kann.

Mit Anspielungen habe ich heute echt kein Glück bei dir. ;-)

Versuch dir mal vorzustellen, wie irgendjemand sonst drauf kommen soll. 
Das ist kein Forum für Magier und solche die es werden wollen, auch wenn 
es von kaputten Glaskugeln nur so wimmelt.

> Soll ich ma meinen ganzen Code posten?

Darauf läuft es raus. Nur eben passend eingedampft. Soll heissen: 
Sukzessive alles aus dem Code rauswerfen, was zum Problem nicht 
beiträgt. Im dem, was dann übrig bleibt, liegt das Problem. Und das muss 
klein genug sein, dass sich hier jemand das anschaut. Ansonsten stehen 
die Chancen schlecht.

PS: Es schadet auch nicht, wenn man verrät, mit welchem Werkzeug und für 
welchen Controller man entwickelt.

PPS: Und wenn man das dann noch im richtigen Forum unterbringt, und 
nicht bei FPGAs, dann ...

(Mod: Thread nach µC u. dig. Elektr. verschoben)

Moin!
Ich habe jetzt ma meinen Code so eingekürzt das man das denke ich ganz 
gut überblicken kann. Desweiteren habe ich das versucht zu 
ent-Ritter-Sporten ;-)
Falls noch was fehlt oder irgendwas unklar ist bitte fragen. Ich hoffe 
es kann mir jemand helfen. Ich bin nämlich im Moment völlig ratlos.

Hier der Code:

1

unsigned short start_stop  = 0;    //wait for parameters via Ethernet

2

3

/***** send-arrays *****/

4

short *xn_re_buff1, *xn_re_buff2;  //memory allocation in rec_matlab_data(...)

5

short *xk_re_buff1, *xk_re_buff2;

6

short *xk_im_buff1, *xk_im_buff2;

7

8

//FFT-CORE

9

int *xn_re_p, *control_p, *scale_sch_p, *addr_in_p;  //Input

10

volatile char read_flg = 0;

11

volatile char read_mems = 0;

12

13

/*************************** Interrupt handler **********************************/

14

15

void AC97_int_handler(void * baseaddr_p)

16

{

17

static short ac97_ctr = 0;

18

19

*control_p &= (~WE_IN);

20

21

  if(start_stop && (read_flg == 0))

22

  {

23

    *xn_re_p = XAC97_mGetOutFifoData(XPAR_XPS_AC97_0_BASEADDR); // Read FIFO using non blocking read method

24

    *addr_in_p = ac97_ctr;

25

    *control_p |= WE_IN;

26

    ac97_ctr++;

27

28

    if(ac97_ctr == POINT_SIZE)  //if array 0 to 1023 is written

29

    {

30

      read_flg = 1;

31

      ac97_ctr = 0;

32

    }

33

  }

34

}

35

36

void FFT_Ready_Read_int_handler(void * baseaddr_p)

37

{

38

read_mems = 1;

39

}

40

41

/********************************** Main *****************************************/

42

43

int main(void)

44

{

45

  int i;

46

47

  /* start the application UDP_Server*/

48

  start_udp_server();

49

50

  XIntc_RegisterHandler(XPAR_XPS_INTC_0_BASEADDR ,

51

    XPAR_XPS_INTC_0_XPS_AC97_0_INTERRUPT_INTR,

52

    AC97_int_handler, (void *) 0);

53

54

  XIntc_RegisterHandler(XPAR_XPS_INTC_0_BASEADDR,

55

      XPAR_XPS_INTC_0_FFT_V5_PLBW_0_SH_MEM_RDY_INTR,

56

    FFT_Ready_Read_int_handler, (void *) 0);

57

58

    p_buffer = pbuf_alloc(PBUF_TRANSPORT, (PAYLOAD_CELLS * DATASIZE), PBUF_REF);  //1024 bytes = 512 samples á 2 byte or 256 samples á 4 byte

59

60

  alloc_memory(log2pts);  //for xn/xk buffers

61

62

  /* now enable interrupts */

63

  platform_enable_interrupts();

64

65

  /* receive packets */

66

  while (1) {

67

    xemacif_input(netif);

68

69

    if(read_flg)

70

    {

71

      //send time-signal

72

      mod_xn_re_p = (int *)shram_mod_xn_re->addr;

73

74

      for(i=0; i<(SH_MEM_SIZE/2); i++)

75

        xn_re_buff1[i] = *(mod_xn_re_p++);  //write data from shared Memory into Buffer

76

      p_buffer->payload = xn_re_buff1;

77

      transmit(p_buffer, &pc_addr);

78

79

      for(i=0; i<(SH_MEM_SIZE/2); i++)

80

        xn_re_buff1[i] = *(mod_xn_re_p++);

81

      p_buffer->payload = xn_re_buff1;  //address for sendbuffer

82

      transmit(p_buffer, &pc_addr);

83

84

      while(!read_mems);  //Wait for FFT  (WITHOUT THIS WHILE LOOP EVERYTHING WORKS FINE)

85

86

      read_flg = 0;

87

      read_mems = 0;

88

    }

89

  }

90

91

  return 0;

92

}

A. K. schrieb:
> PS: Es schadet auch nicht, wenn man verrät, mit welchem Werkzeug und für
> welchen Controller man entwickelt.

PUSH

Sieht aber nach nichts aus was ich kenne.

Wodurch wird der FFT Interrupt denn ausgelöst, bzw. sollte es? Im Code 
ist das für mich nicht ersichtlich.

Ich nutze das Sofware Development Kit (SDK 13.4) von Xilinx und mein 
"Controller" ist ein Virtex 5, welcher auf dem ML507 sitzt.
Das ganze soll ein FFT-Audio-Analyser mit anbindung an Matlab werden. 
Den FFT-Core habe ich mir mit dem Sysgen aus Matlab erzeugt und in XPS 
eingebunden. Und wie gesagt, ohne die while-schleife funktioniert auch 
das senden an Matlab.

Grüße Jan

Der Interrupt wird duch ein Signal des FFT-Cores erzeugt (fallende 
flanke auf eine Data-Valid Ausgang). Also sobalt meine Shared Memorys 
mit Ausgangswerten des FFT-Cores beschrieben sind, kommt ein Interrupt, 
der mir sagt das die Memorys ausgelesen werden können.

PS. Der Interrupt kommt. Das habe ich getestet.

Selbst wenn ich alles was nicht damit zu tun hat rausnehme, was ja nicht 
viel ist, weil ja das senden und der FFT-Core damit zusammenhängt, tritt 
das Problem immer noch auf. Wie kann ich das denn jetzt weiter 
analysieren bzw. debuggen bzw. irgendwas anderes? Ich brauche ja die 
while schleife, weil ich ja auf den FFT-Core warten muss... Bin echt am 
verzweifeln...

Trotzdem schon mal ein großes Danke für die vielen Antworten!!!

Der Verdacht richtet sich natürlich auf die transmit() Routine, die 
evtl. Interrupts sperrt, bzw. ausmaskiert. Wenn du nach transmit() 
nochmal explizit den Interrupt freigibst?
Ein Problem bei zeitkritischer Behandlung könnte auch sein, das 
transmit() in der Abarbeitungszeit unvorhersehbar ist ( Bus besetzt 
,Hardware noch busy etc.). Probiers mal ohne transmit().