Hallo, ich habe gerade Zwei AVR in Bearbeitung (ATMega168 / AT90USB162) In beiden Systemen habe in eine kleine Fifo Funktion siehe Unten. Die Erstimplentierung war unter LIBC V1.4.6 / WinAVR 20070525 auf dem ATmega168 Dort schien alles IO zu sein. Die Data wurden richtig im Fifo gespeichert und ich konnnte die werte auslesen (zumindest denke ich das) Mit der Umstellung auf die neue AVR Studio 4 Version 14 und der neuen LIBC V1.6.0 WinAVR 2071212 und erstes Project mit AT90USB162 wurden variablen überschreiebn und ich erhielt teils nur noch Müll aus dem Fifo. Meine analysen ergaben, das die Memcopy Funktion bzw. der Compiler/CodeGenerator hier etwas nicht richtig macht. (siehe vermeintlich fehlerhafte ASM-Code ) in den Zeilen 4b0: f0 01 movw r30, r0 4b2: 11 24 eor r1, r1 Wird R30,R31 mit den in R0,R1 stehen Werten geladen ... Diese sind aber zu diesem Zeit für die Funktion in einem nicht definiertem Zustand zu mal in den Zeilen 4ba: 0d 90 ld r0, X+ 4bc: 01 92 st Z+, r0 R0 mit Speicher Daten geladen wird ( also kann in R0 irgendwas stehen)!! Beim AT90USB162 stellte ich dann fest, das über das Speicherende hin aus geschreiben, gelesen wurde .... Als ich beim Debuggen R0 zu Null setzte wurden meine Daten richtig im Fifo eingetragen/ausgelesen !! Als ich dann die LIBC V1.4.6 mit dem WinAVR 20071221 verwendete war die Welt auf dem AT90USB162 scheinbar IO. Siehe (ASM-Code (Besser ?) Nun untersuchte ich den Code auf dem AT Mega168 mit dem Ergebniss: was ich auch immer für eine libc.a dazu linke hier immer der "vermeintlich fehlerhafte ASM-Code" generiert wird !! Weis hier jemand Rat ?? Danke und Gruß MacGyver /* ----------------------------------------------------------------------*/ ASM-Code (Besser ?) 00000d66 <fifo_ubOUTWrite>: d66: 9c 01 movw r18, r24 d68: 80 91 fa 01 lds r24, 0x01FA d6c: 82 30 cpi r24, 0x02 ; 2 d6e: 19 f4 brne .+6 ; 0xd76 <fifo_ubOUTWrite+0x10> d70: 8f ef ldi r24, 0xFF ; 255 d72: 90 e0 ldi r25, 0x00 ; 0 d74: 08 95 ret d76: 8f 5f subi r24, 0xFF ; 255 d78: 80 93 fa 01 sts 0x01FA, r24 d7c: 80 91 f7 01 lds r24, 0x01F7 d80: 90 e0 ldi r25, 0x00 ; 0 d82: 6e e0 ldi r22, 0x0E ; 14 d84: 70 e0 ldi r23, 0x00 ; 0 d86: 0e 94 07 16 call 0x2c0e d8a: dc 01 movw r26, r24 d8c: a1 50 subi r26, 0x01 ; 1 d8e: be 4f sbci r27, 0xFE ; 254 d90: f9 01 movw r30, r18 d92: 8e e0 ldi r24, 0x0E ; 14 d94: 01 90 ld r0, Z+ d96: 0d 92 st X+, r0 d98: 81 50 subi r24, 0x01 ; 1 d9a: e1 f7 brne .-8 ; 0xd94 <fifo_ubOUTWrite+0x2e> d9c: 80 91 f7 01 lds r24, 0x01F7 da0: 8f 5f subi r24, 0xFF ; 255 da2: 80 93 f7 01 sts 0x01F7, r24 da6: 82 30 cpi r24, 0x02 ; 2 da8: 18 f4 brcc .+6 ; 0xdb0 <fifo_ubOUTWrite+0x4a> daa: 80 e0 ldi r24, 0x00 ; 0 dac: 90 e0 ldi r25, 0x00 ; 0 dae: 08 95 ret db0: 10 92 f7 01 sts 0x01F7, r1 db4: 80 e0 ldi r24, 0x00 ; 0 db6: 90 e0 ldi r25, 0x00 ; 0 db8: 08 95 ret /* ----------------------------------------------------------------------*/ vermeintlich fehlerhafte ASM-Code 00000498 <fifo_ubOUTWrite>: 498: 9c 01 movw r18, r24 49a: 80 91 21 02 lds r24, 0x0221 49e: 84 30 cpi r24, 0x04 ; 4 4a0: c8 f4 brcc .+50 ; 0x4d4 <fifo_ubOUTWrite+0x3c> 4a2: 8f 5f subi r24, 0xFF ; 255 4a4: 80 93 21 02 sts 0x0221, r24 4a8: 90 91 02 02 lds r25, 0x0202 4ac: 8e e0 ldi r24, 0x0E ; 14 4ae: 98 9f mul r25, r24 4b0: f0 01 movw r30, r0 4b2: 11 24 eor r1, r1 4b4: eb 5d subi r30, 0xDB ; 219 4b6: fd 4f sbci r31, 0xFD ; 253 4b8: d9 01 movw r26, r18 4ba: 0d 90 ld r0, X+ 4bc: 01 92 st Z+, r0 4be: 81 50 subi r24, 0x01 ; 1 4c0: e1 f7 brne .-8 ; 0x4ba <fifo_ubOUTWrite+0x22> 4c2: 80 91 02 02 lds r24, 0x0202 4c6: 8f 5f subi r24, 0xFF ; 255 4c8: 80 93 02 02 sts 0x0202, r24 4cc: 84 30 cpi r24, 0x04 ; 4 4ce: 10 f0 brcs .+4 ; 0x4d4 <fifo_ubOUTWrite+0x3c> 4d0: 10 92 02 02 sts 0x0202, r1 4d4: 84 e0 ldi r24, 0x04 ; 4 4d6: 90 91 21 02 lds r25, 0x0221 4da: 89 1b sub r24, r25 4dc: 90 e0 ldi r25, 0x00 ; 0 4de: 08 95 ret C-Code : /* ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ */ ubyte fifo_ubOUTWrite (TUMsg *ubdata) { // ubyte ubi; if (fifo_ubOUTTest() == 0) { FIFO_ubCntOUT++; memcpy (&FIFO_astOUT[FIFO_ubWrOUT], ubdata, sizeof (TUMsg)); #if 0 for ( ubi =0; ubi < sizeof (TUMsg); ubi++) { FIFO_astOUT[FIFO_ubWrOUT].aubBytes[ubi] = ubdata->aubBytes[ubi]; } #endif FIFO_ubWrOUT++; if (FIFO_ubWrOUT > (FIFO_OUT_SIZE-1)) { FIFO_ubWrOUT = 0; } return (0x00); /* Write to Fifo OK */ } return (0xFF); /* No space in Fifo left */ } /* ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ */
Da is nix fehlerhaft.
1 | 4ae: 98 9f mul r25, r24 |
2 | 4b0: f0 01 movw r30, r0 |
3 | 4b2: 11 24 eor r1, r1 |
4 | 4b4: eb 5d subi r30, 0xDB ; 219 |
5 | 4b6: fd 4f sbci r31, 0xFD ; 253 |
6 | 4b8: d9 01 movw r26, r18 |
7 | 4ba: 0d 90 ld r0, X+ |
8 | 4bc: 01 92 st Z+, r0 |
9 | 4be: 81 50 subi r24, 0x01 ; 1 |
10 | 4c0: e1 f7 brne .-8 ; 0x4ba <fifo_ubOUTWrite+0x22> |
Mit "mul r25, r24" wird r25 mit r24 multipliziert und in r0 und r1 abgelegt. das Ergebnis wird in den Z Pointer geschrieben (r30, r31). Dies müsste dieser Dereferenzierung entsprechen.
1 | &FIFO_astOUT[FIFO_ubWrOUT] |
Anschließend wird in der Schleife kopiert.
Danke Simon, ich verstehen aber nicht wieso im AT90USB162 dieser Code dann nicht richtig tut. ... erst nach dem ich R0 zu Null gesetzt hatte, wurden die Daten richtig referenziert ! Gruß
Roland Schmidt wrote: > Danke Simon, > > ich verstehen aber nicht wieso im AT90USB162 dieser Code dann nicht > richtig tut. > ... erst nach dem ich R0 zu Null gesetzt hatte, wurden die Daten > richtig referenziert ! > > Gruß Komisch. Was heißt denn "nicht richtig tut"? Fehlermeldung vom Compiler ja wohl eher nicht. Stürzt der Prozessor ab? Oder kopiert er es einfach (scheinbar) nicht? Ich kann bisher eigentlich kein Problem bei der FIFO Funktion erkennen auf Assembler-Ebene. Hast du denn beim Kompilieren für den 90USB162 auch diesen als Zielplattform ausgewählt? (mit -mmcu)
Hallo Simon, den AT90USB162 habe ich mit -mmcu ausgewählt, da sonst das Debuggen mit MKII nicht geht... Ja der Prozessor hängt sich weg ! Bei den Untersuchungen habe ich gesehen, dass die Fifo Write Fktn ans Ende des RAM Schreibt (letzten 2 Byte und weiter am Anfang 12 Byte. Das Löschen von R0 lies dann die Daten richtig in den Fifo kopieren .. Ich werde nächste Woche noch mal versuchen mehr heraus zu bekommen in dem ich auf die LIBC V1.6.0 gehe und auf die entsprechenden Details achten kann. Ich hoffe ich kann dann nochmal auf deine Expertise zurückgreifen .. Danke und Gruß
Roland Schmidt wrote: > ich verstehen aber nicht wieso im AT90USB162 dieser Code dann nicht > richtig tut. Weil er keinen Multiplizierer besitzt. Das war eine fehlerhafte Einordnung der AT90USB82/162 in dieser Version (mangels ausreichender Informationen seitens Atmel). Guck dir mal die Version vom Juni 2008 an stattdessen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.