Zufällig bin ich darauf gestossen, dass es avrasm2 ein Mal für ganz
kurze Zeit als macOS command line tool gab (XC8 V2.05 und V2.10). Mit
Hilfe eines alten MacBook das nur noch mit Mojave lief gelang es mir
dann auch das XC8 V2.05 zu installieren und auf mein Catalina zu
kopieren. So wie es aussieht läuft das Program auch auf Catalina. Die
Aufgabe die jetzt noch bleibt, wie komme ich am einfachsten zu einem
aktuellen Satz der inlcude Files von Microchip zu den AVR8 Kontroller?
Unter AVR Studio 7.0 sind die alle unter
Peter S. schrieb:> Ich hätte jetzt einfach jeweils die Neusten genommen. Oder gibt es etwas> das dagegen spricht?
In aller Regel ist das neueste die beste Wahl. Auf jeden Fall für neue
Projekte.
Gute Idee daran habe ich erst gar nicht gedacht, ich wollte ja sowieso
schon lange vom AVR Studio in der VM auf MPLAB für macOS umsteigen aber
da fast alle meine AVR Projekte reine Assembler Projekte sind ist das
ohne avrasm2 natürlich nicht so toll. Ich hatte mal MPLAB (vor Version
2) installiert aber dann wegen dem fehlenden Assembler für macOS wieder
gelöscht und habe es fast verschlafen, dass eine macOS Version für kurze
Zeit enthalten war. Ich wüsste nur zu gern was die Hintergründe dafür
sind.
Peter S. schrieb:> da fast alle meine AVR Projekte reine Assembler Projekte sind ist das> ohne avrasm2 natürlich nicht so toll.
Wieso, es gibt doch im AVR-GCC den GAS.
Die Syntax ist leicht unterschiedlich, aber das lernt man schnell. Dafür
kann man aber Profi-Projekte mit mehreren Objekten erstellen und
zusammen linken. Man kann auch Libs erstellen oder C-Objekte dazu
linken.
Der GAS ist also deutlich leistungsfähiger, der AVRASM2 ist nur eine
Behelfslösung.
https://maxembedded.com/2015/06/setting-up-avr-gcc-toolchain-on-linux-and-mac-os-x/
Peter D. schrieb:> Dafür> kann man aber Profi-Projekte mit mehreren Objekten erstellen
Inwiefern macht das Zerlegen in mehrere Objekte ein Projekt zum
Profi-Projekt?
Das mit den Objekten ist eigentlich nur eine Hilfskonstruktion, um die
unsäglich langen Kompilierzeiten von C-Compilern einigermaßen erträglich
zu machen.
Avrasm2 hat das nicht nötig. Der kann auch die größten AVR8 in zwei,
drei Sekunden komplett füllen.
Was sollte es da bringen, den Code in Häppchen zu zerlegen (mal
abgesehen von der sinnvollen Aufteilung in einzelne Dateien, die man ja
auch dort machen kann)?
> C-Objekte dazu> linken.
Wer würde das ernsthaft wollen? Damit muss man doch einen großen Teil
des Vorteils der Assemblerprogrammierung wieder aufgeben.
c-hater schrieb:> Das mit den Objekten ist eigentlich nur eine Hilfskonstruktion, um die> unsäglich langen Kompilierzeiten von C-Compilern einigermaßen erträglich> zu machen.
Nö, das ist nicht der Grund.
Man vermeidet Seiteneffekte der einzelnen Module aufeinander.
Man kann damit Namen funktionslokal halten, d.h. muß nicht darauf
achten, daß es keine Namenskonflikte gibt. Auch kann man den Linker die
Plazierung von Variablen automatisch machen lassen.
Wenn man aber eh nur winzige Programme schreibt, ist das natürlich nicht
nötig.
c-hater schrieb:> Wer würde das ernsthaft wollen?
Es kann durchaus sein, daß vielleicht 1% des Codes genaue
Echtzeitanforderungen einhalten müssen. Dann kann man diesen in
Assembler schreiben. Die restlichen 99% schreibt man natürlich bequem in
C.
Um das Assemblergerüst zu erhalten, schreibt man die gewünschte Funktion
als Dummy mit allen Namen, Variablen und Parametern in C und läßt sie
nach Assembler übersetzen. Dann fügt man nur noch den Assemblercode ein.
Den C-Dummy muß man dann aus dem Projekt entfernen, damit er nicht
nochmal übersetzt wird.
Peter D. schrieb:> Es kann durchaus sein, daß vielleicht 1% des Codes genaue> Echtzeitanforderungen einhalten müssen. Dann kann man diesen in> Assembler schreiben. Die restlichen 99% schreibt man natürlich bequem in> C
Ganz egal welche Anforderung- Assembler erfüllt sie am besten. "Bequem
in C" ist sehr relativ.
Wer
Peter D. schrieb:> Um das Assemblergerüst zu erhalten, schreibt man die gewünschte Funktion> als Dummy mit allen Namen, Variablen und Parametern in C und läßt sie> nach Assembler übersetzen. Dann fügt man nur noch den Assemblercode ein.> Den C-Dummy muß man dann aus dem Projekt entfernen, damit er nicht> nochmal übersetzt wird.
für bequem hält stellt sich wohl auch sonst öfter die Frage: Warum
einfach wenns auch kompliziert geht?
@Gerhard H.
Wenn man täglich Assembler verwendet, wie Du, kennt man natürlich das
Linker-ABI auswendig.
Für diejenigen, die aber nur ganz selten Assembler dazu linken müssen,
ist der Weg über den C-Dummy der bequemere. Der Compiler weiß dann
schon, welche Register welche Argumente übergeben und wie die
Syntaxkonventionen für Variablen und Funktionen sind.
https://en.wikipedia.org/wiki/Application_binary_interface
Peter D. schrieb:> Um das Assemblergerüst zu erhalten, schreibt man die gewünschte Funktion> als Dummy mit allen Namen, Variablen und Parametern in C und läßt sie> nach Assembler übersetzen. Dann fügt man nur noch den Assemblercode ein.
Genau, erspart eine Menge Kopfschmerzen.
Peter D. schrieb:> Den C-Dummy muß man dann aus dem Projekt entfernen, damit er nicht> nochmal übersetzt wird.
Ich entferne es normalerweise nicht, auskommentieren ist viel besser,
falls nachträglich noch etwas in C geändert wird...
Es geht hier nicht im C versus Assembler sondern darum, dass viele
meiner Projekte in reinem Assembler geschrieben sind. Das grösste hat
ca. 64kbyte code. Beim gcc Assembler stört weniger die eher etwas
gewöhnungsbedürftige Syntax als vielmehr das unbrauchbare Listing. Und
das noch viel mehr in einem gemischten Projekt. Das mit dem globalen
Namensraum ist kaum ein Problem, da gibt es verschiedene Mittel um das
in den Griff zu bekommen. Ich habe einfach keine Lust meinen ganzen
Sourcecode gcc konform zu machen. Auch ist ein AVR Prozessor in meinen
Augen viel zu klein um sich Sorgen wegen Teilkompilieren oder Namensraum
zu machen. Ich will als erstes einfach weg von Windows. Gemischte
Projekte habe ich auch schon, aber viel Freude am Resultat habe ich noch
nicht, auf alle Fälle reicht der Vorteil gewisse Module der
Bequemlichkeit halber in C programmieren zu können nicht aus um den
Frust am mässigen Resultat zu kompensieren. C und Assembler mischen
scheint nicht wirklich das Ziel der Toolchain zu sein und so bleibt es
bei Inline Assembler wenn ich in einem C Projekt kritische Teile in
Assembler programieren will oder muss.
Peter S. schrieb:> Auch ist ein AVR Prozessor in meinen> Augen viel zu klein um sich Sorgen wegen Teilkompilieren oder Namensraum> zu machen.
Genau so ist das. Die AVR8 sind klein genug, dass man sie problemlos
vollständig in Asm programmieren kann. Vieles ist sogar in Asm deutlich
einfacher umzusetzen. Man denke z.B. nur an konstante Tabellen mit mehr
als 32k Elementen oder mehr als 64k Speicherbedarf. Das ist mit dem
avrgcc absoluter Krampf.
Thread beobachten
Seitenaufteilung abschalten