Hallo! Ich würde mich gerne wieder intensiver mit meinem 8535 unter Linux beschäftigen, bin im Moment aber ziemlich frustriert. Punkt 1: Ich möchte auch in Assembler schreiben, möglichst kompatible zum ABR-Studio. Ich habe mich also für tavrasm entschieden. Meine Sourcen kann ich wunderbar kompilieren, aber dann muss ich sie ja auch noch auf den AVR schreiben. Ich habe vor meiner Pause mit avrprog und einem einfachen Adapter nur aus Kabeln und Stecker meinen AVR über die parallele Schnittstelle beschrieben. Die Hex-Dateien, die tavrasm, bzw. die anderen Assembler erzeugen, schmecken avrprog aber wohl nicht: error in intelhex file - this program only accepts rectype 00(data) or 01(eof) Damit kann ich leider gar nichts anfangen. Weiß jemand, was ich dagegen tun kann? Punkt 2: Ich würde die größeren Sachen gerne mit dem avr-gcc kompilieren. Hat früher ja auch alles mal geklappt. Anscheinend hat er aber jetzt Probleme mit der avr-libc, weil er bei jedem Aufruf von PORTC oder ähnlichen Sachen, wie zum Beispiel in dieser Zeile, volatile struct Stepper stepperL={10, 0, {0x01,0x02, 0x04, 0x08 }, 0, PORTC, 4}; ausgibt: robot.c:10: error: initializer element is not constant Wenn ich hardcore den PORTC durch 0x15 ersetze, kompiliert mein Programm. Auch wenn das Ersetzen wahrscheinlich totaler Unsinn ist, so scheint es doch ein Problem mit den IO-Macros in den avr-libc Header-Dateien zu geben. Hat zu diesem Punkt jemand eine Idee? Vielen Dank für eure Hilfe! Andreas
Zu Punkt 1: was spuckt der tavrasm denn so aus als Hexfile? Hast Du denn mal reingesehen, vielleicht spuckt er ja nur ein Binärfile aus? An Deiner Stelle würde ich allerdings, wenn Du ohnehin an avr-gcc als C-Compiler denkst, dann auch gleich dessen Assembler nehmen. Kompatibel zu AVR Studio bist Du über die COFF-Files hinsichtlich des Debuggers/Simulators, und wenn Du unbedingt auf deren Editor stehst, kannste den ja dennoch benutzen. (Wobei ich an diesen Editoren nichts aufregendes finde, ich finde die alle gleichermaßen schlecht. Ich bin von Emacs verwöhnt. ;-) Je nach tatsächlichem vom tavrasm erzeugten Format kannst Du das ja mit avr-objcopy noch konvertieren. Wäre ohnehin noch ein Test, kann avr-objcopy oder avr-objdump es denn einlesen? Die können auch ihex einlesen. :101D56006174277320616C6C206279206E6F772E18 :081D66000A002000CE11FFFF6E :00000001FF ^^ An dieser Stelle steht übrigens der record type. Davor steht noch die Länge (Anzahl der Datenbytes im Record), die ist hier also 16 (0x10), 8 bzw. 0, gefolgt von der Adresse (0x1d56, 0x1d66, 0). Danach kommen die Datenbytes, abschließend eine simple Prüfsumme. Zu 2.) RTFDoc, please. Insbesondere das Kapitel über »Special function registers« (einschließlich der Ergänzung) solltest Du Dir zu Gemüte führen. Kurz gesagt, daß das jetzt nicht mehr so einfach geht, ist der Preis, den man dafür zahlen muß, daß stattdessen ein PORTB = 0xff; myvar = PINB; DDRC |= (1 << 3); usw. funktioniert. Es ist übrigens sehr fraglich, ob das Sinn hat, sowas überhaupt noch in einer Tabelle anzugeben. Die Compiler- optimierungen werden dafür dann nicht mehr greifen, d. h. Dein Code würde vermutlich auf MMIO zurückfallen, wenn er den entsprech- enden IO-Port anspricht. Das funkioniert zwar, ist aber langsamer. Siehe auch den Teil der FAQ, der die Übergabe von Portadressen an Funktionen beschreibt.
Hallo! Vielen Dank für deine Hilfe! Ich werde mir die Hex-Dateien jetzt noch mal genauer ansehen. Das avr-libc-Problem habe ich jetzt mit jemandem aus einem C-Channel gelöst bekommen. Mann, der hat ja vielleicht über die avr-libc Header-Dateien geschimpft. Ich habe mir dann eigene Definitionen angelegt, mit denen es dann wunderbar läuft. Die Doku werde ich aber besser trotzdem noch durcharbeiten. Vielen Dank! Andreas
Bitte 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.