Hallo zusammen, ich habe ein C-Projekt in AVR Studio 5 angelegt und es mit Leben gefüllt. Dieses läuft auch korrekt. Ich möchte nun den Flash Speicher des Controllers testen, dazu habe ich bei Atmel ein Application Note gefunden, mit den Quellcode besorgt, diesen auch den µC angepasst und kompiliert! Jetzt zum Problem: -CRC-Quellcode ist eine .asm Datei, diese lässt sich mit in AVR Studio als Projekttyp "avrasmproj" bauen. -Das andere Programm ist vom Typ avrgccproj! Wie kann ich das diese beiden vereeinen! Vielen Dank für eure Hilfe! Beste Grüße Locutus
Locutus schrieb: > Wie kann ich das diese beiden vereeinen! Gar nicht. Du müsstest den Assembler-Code nach gas portieren, den Assembler, der auch vom gcc benutzt wird. Oder das Ganze in C reprogrammieren.
Hi, danke für die schnelle Antwort. Es besteht also nicht die Möglichkeit, den erzeugten obj-code irgendwie zu linken oder so? Beste Grüße Locutus Ps.: Hat jemand vielleicht schon die Application Note 236 in C umgesetzt?
Locutus schrieb: > danke für die schnelle Antwort. Es besteht also nicht die Möglichkeit, > den erzeugten obj-code irgendwie zu linken oder so? Nur, wenn er mit gas erzeugt wurde.
Erzeugt der Atmel-Assembler überhaupt einen Object-Code? Oder klatscht der direkt alles in ein IHEX?
Johann L. schrieb: > Erzeugt der Atmel-Assembler überhaupt einen Object-Code? Nein. > Oder klatscht der direkt alles in ein IHEX? Ja. Eine Source-Datei geht rein, brennfertiges Binary kommt raus.
Einfach die Asm-Datei in *.S umbenennen und zum C-Projekt hinzufügen. Peter
Peter Dannegger schrieb: > Einfach die Asm-Datei in *.S umbenennen und zum C-Projekt hinzufügen. Wird in der Regel nicht direkt funktionieren, weil die Pseudo-Ops eben andere sind und ein paar andere Kleinigkeiten nicht passen.
Jörg Wunsch schrieb: > Peter Dannegger schrieb: >> Einfach die Asm-Datei in *.S umbenennen und zum C-Projekt hinzufügen. > > Wird in der Regel nicht direkt funktionieren, weil die Pseudo-Ops > eben andere sind und ein paar andere Kleinigkeiten nicht passen. Ganz zu schweigen davon, dass ein Code-Beispiel für den Atmel-Assembler sich wohl kaum an die GCC-ABI hält.
Jörg Wunsch schrieb: > Peter Dannegger schrieb: >> Einfach die Asm-Datei in *.S umbenennen und zum C-Projekt hinzufügen. > > Wird in der Regel nicht direkt funktionieren, weil die Pseudo-Ops > eben andere sind und ein paar andere Kleinigkeiten nicht passen. Dafür habe ich mir so eine Header-Datei gebastelt:
1 | #ifndef _GAS_REGPORT_H_ |
2 | #define _GAS_REGPORT_H_ |
3 | |
4 | |
5 | r0 = 0 |
6 | r16 = 16 |
7 | r17 = 17 |
8 | r18 = 18 |
9 | r19 = 19 |
10 | r20 = 20 |
11 | r21 = 21 |
12 | r22 = 22 |
13 | r23 = 23 |
14 | r24 = 24 |
15 | r25 = 25 |
16 | r30 = 30 |
17 | r31 = 31 |
18 | sreg = _SFR_IO_ADDR(SREG) |
19 | |
20 | porta = _SFR_IO_ADDR(PORTA) |
21 | portb = _SFR_IO_ADDR(PORTB) |
22 | portc = _SFR_IO_ADDR(PORTC) |
23 | portd = _SFR_IO_ADDR(PORTD) |
24 | |
25 | ucsra = _SFR_IO_ADDR(UCSRA) |
26 | ucsrb = _SFR_IO_ADDR(UCSRB) |
27 | ucsrc = _SFR_IO_ADDR(UCSRC) |
28 | |
29 | udr = _SFR_IO_ADDR(UDR) |
30 | #endif // _GAS_REGPORT_H_ |
Also die Register kennt er schon (WINAVR). Und die IO-Ports holt man sich mit #include <avr/io.h> rein. Alle .equ und .def kann man als #define umschreiben. Ich hatte kürzlich mal 64Bit in Assembler geschrieben. Und ich fand ein schönes Assembler-Beispiel im Web für die Syntax, finds aber nicht mehr. Das Beispiel im WINAVR ist leider wenig hilfreich, da fehlen die Aufrufe und Parameterübergaben zwischen C und Assembler. Peter
Oder für die ganz Harten: http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html http://www.ibm.com/developerworks/linux/library/l-ia/index.html
Peter Dannegger schrieb: > Das Beispiel im WINAVR ist leider wenig hilfreich, da fehlen die Aufrufe > und Parameterübergaben zwischen C und Assembler. Da ist ja auch nix zu machen... Einfach ein
1 | extern int foo_bar_blubb (int, char); |
die Funktion in Assembler implementieren und verwenden wie gehabt. Die Registerverwendung ist zB erklärt in http://www.rn-wissen.de/index.php/Avr-gcc/Interna#Registerverwendung Das reicht für 99.9% aller Feld-, Wald- und Wiesenprogramme. Das verbleibende 1/oo sind Funktionen, die Parameter/Ergebnis via Stack übergeben.
Peter Dannegger schrieb: > Das Beispiel im WINAVR ist leider wenig hilfreich, da fehlen die Aufrufe > und Parameterübergaben zwischen C und Assembler. Dann schreib' mal bitte eins, was hilfreicher ist. Ich habe damals lange gesucht, ein Beispiel zu finden, das nicht an den Haaren herbei gezogen ist. (Das existierende Beispiel stammt aus einer realen Anforderung hier im Forum.) Wie du selbst ja schon festgestellt hast: in aller Regel braucht man keinen zusätzlichen Assemblercode.
Johann L. schrieb: > Peter Dannegger schrieb: > >> Das Beispiel im WINAVR ist leider wenig hilfreich, da fehlen die Aufrufe >> und Parameterübergaben zwischen C und Assembler. > > Da ist ja auch nix zu machen... Einfach ein Und in die andere Richtung?
Samuel K. schrieb: > Und in die andere Richtung? ABI-Doku gelesen? Übergabe in r[24:25], ggf. mehr, wenn größerer Datentyp.
Samuel K. schrieb: > Johann L. schrieb: >> Peter Dannegger schrieb: >> >>> Das Beispiel im WINAVR ist leider wenig hilfreich, da fehlen die Aufrufe >>> und Parameterübergaben zwischen C und Assembler. >> >> Da ist ja auch nix zu machen... Einfach ein > > Und in die andere Richtung? Ditto. Mit dem Unterschied, daß Parameter nicht in den von der ABI geforterten Registern empfangen werden, sondern dort übergeben werden.
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.