Hallo zusammen, da ich wohl öfter taktgenaue Funktionen auf ATtinys brauche, habe ich mich notgedrungen entschlossen, tiefer in Assembler einzusteigen, da der C-Compiler mir dauernd hier und da die Timings kaputtoptimiert, wenn man mal eine falsche Zeile code einfügt. Inline-Assembler ist absurd unübersichtlich, wenn man mal mehr als 10 Befehle braucht. Ich möchte deshalb mal den eleganten Weg gehen, und 20% meiner Funktionen in Assembler realisieren. Ist soweit ja kein Problem, gibt genug Doku im Netz und mit etwas Glück findet man auch Sachen, die nicht 10 Jahre alt sind. Ich nutze AtmelStudio 6 und denke, dass so richtig coole MCU Programmierleute eh alle nur in ASM schreiben und deshalb die ASM IDE noch viel cooler sein muss, als die C IDE, die ja nicht besonders cool ist, aber gerade noch brauchbar. Jetzt kann ich mich mit der ASM IDE jedoch nicht anfreunden, und möchte gerne wissen, wo ich jetzt einen Haken hab vergessen zu setzen oder ob ich das Dingen gleich in die Tonne treten muss, denn merke, je grösser der Code, desto vermurkster das Produkt. Meine Fragen dazu sind: 1. Ich muss IO Ports anscheinend immer mit dem Macro _SFR_IO_ADDR(Register) ansprechen. Befehlskolonnen wie out _SFR_IO_ADDR(PORTB),r20 werden damit unerträglich unleserlich. In manchen Netzbeispielen schreiben die Leute jedoch direkt out PORTB,r20. Wie machen die das? Muss ich dazu irgendwas includen oder so? 2. Mein Autocomplete will in den .s Dateien nicht funktionieren. Ich muss sämtliche meiner Macros ausschreiben und sie werden auch nicht farblich hervorgehoben. Ich nutze die Funktion hauptsächlich, um direkt zu sehen, wo ich mich vertippt habe. Da die ASM Fehlermeldungen alles andere sagen, nur nicht, dass das Macro durch einen simplen Tippfehler nicht existiert, ist das Fehlen dieses Features unnötig nervig. 3. Wenn alles nicht hilft und es einfach so wie befürchtet ist, dass AtmelStudio nichts taugt... was nehmt ihr? Oder sind Assemblerprogrammierer eh eine aussterbende Spezies? Würde erklären, warum gefühlte 90% aller ASM Seiten im Netz mindestens 8 Jahre alt sind...
:
Bearbeitet durch User
Christian S. schrieb: > Ich möchte deshalb mal den eleganten Weg gehen, und 20% meiner > Funktionen in Assembler realisieren. Ist soweit ja kein Problem, gibt > genug Doku im Netz und mit etwas Glück findet man auch Sachen, die nicht > 10 Jahre alt sind. Welche Funktionen ? vllt hilft ja diese Anregung http://www.roboternetz.de/community/threads/64609-AtMega8-kleine-Bibliothek Christian S. schrieb: > 3. Wenn alles nicht hilft und es einfach so wie befürchtet ist, dass > AtmelStudio nichts taugt... was nehmt ihr? Oder sind > Assemblerprogrammierer eh eine aussterbende Spezies? Würde erklären, > warum gefühlte 90% aller ASM Seiten im Netz mindestens 8 Jahre alt > sind... Das ja schon Kampfansage und Aufruf zum "Krieg der Programmiersprachen der 16^99te" Atmelstudio4 ist schon i.O. und recht einfach zu bedienen, dass 6er hingegen dezent aufgeblasen aber mit ein wenig einarbeiten bekommt das auch in den Griff.
Christian S. schrieb: > _SFR_IO_ADDR(PORTB),r20 Dann definier Dir doch ein entsprechendes Makro mit einem kurzen knackigen Namen für _SFR_IO_ADDR(PORTB) (und auch aussagekräftige Makros für die Pin-Nummern) genauso wie Du es in C ebenfalls machen würdest. So wird sich der Code leichter lesen, leichter schreiben und leichter ändern oder portieren lassen.
:
Bearbeitet durch User
Bernd K. schrieb: > Christian S. schrieb: >> _SFR_IO_ADDR(PORTB),r20 > > Dann definier Dir doch ein entsprechendes Makro mit einem kurzen > knackigen Namen für _SFR_IO_ADDR(PORTB) (und auch aussagekräftige Makros > für die Pin-Nummern) genauso wie Du es in C ebenfalls machen würdest. > > So wird sich der Code leichter lesen, leichter schreiben und leichter > ändern oder portieren lassen. Mache ich bereits, aber ich dachte, es gäbe eine "richtigere" Lösung. Ausserdem steht und fällt es mit dem AutoComplete. Derzeit kann ich da wirklich genau so gut einen Texteditor nehmen....
AutoComplete - Braucht man das, ich glaube nicht. (Allerdings zugegeben, ich schreibe im 10-Finger-System) > schreiben die Leute jedoch direkt out PORTB,r20. Wie machen die > das? Muss ich dazu irgendwas includen oder so? Die von Atmel für den betreffenden Controllertyp gelieferte Datei, irgendwas mit ...def.inc. Ich arbeite noch mit AVR-Studio 4.11, die höheren 4er vergessen bei mir, warum auch immer, die Lesezeichen, und mit 5 oder 6 konnte ich mich nicht anfreunden.
>> schreiben die Leute jedoch direkt out PORTB,r20. Wie machen die >> das? Muss ich dazu irgendwas includen oder so? > Die von Atmel für den betreffenden Controllertyp gelieferte Datei, > irgendwas mit ...def.inc. Im Studio6 machst Du einfach ein Asm-Projekt auf und gibst dabei den Controller an. Mehr ist da nicht. Dann kann man je nach Typ/Adresse sein out oder sts PORTB,r20 im Programm hinschreiben. Autocomplete gibts da nicht, nur Syntax-Highlighting. Ansonsten ist die Arbeit in Asm unproblematisch. Die korrekten Namen der IO Register kannst Du Dir aus der entsprechenden .inc Datei im Atmel-Studio Verzeichnis unter AVR-Tools AVRAssembler2 Appnotes besorgen.
Es wäre schön, wenn ich noch Hilfe wegen dem fehlenden AutoComplete, oder wichtiger, dem damit verbundenen Problem, dass die Wörter nicht farblich hervorgehoben werden bekomme.
:
Bearbeitet durch User
Christian S. schrieb: > Ich nutze AtmelStudio 6 und denke, dass so richtig coole MCU > Programmierleute eh alle nur in ASM schreiben und deshalb die ASM IDE > noch viel cooler sein muss, als die C IDE, die ja nicht besonders cool > ist, aber gerade noch brauchbar. Jetzt kann ich mich mit der ASM IDE > jedoch nicht anfreunden, und möchte gerne wissen, wo ich jetzt einen > Haken hab vergessen zu setzen oder ob ich das Dingen gleich in die Tonne > treten muss, denn merke, je grösser der Code, desto vermurkster das > Produkt. Ach so einer bist du, na da hab ich was für dich: http://www.ee.ryerson.ca/~elf/hack/realmen.html Eine IDE und Codecompletion? Ich dachte du willst cool sein. Nimm einen Texteditor wie Vim oder Emacs und kompiliere über das Terminal oder einem Makefile. IDEs sind Spielzeuge für kleine Kinder. BTW Real Programmers use FORTRAN.
Christian S. schrieb: > manchen Netzbeispielen schreiben die Leute jedoch direkt out PORTB,r20. > Wie machen die das? Muss ich dazu irgendwas includen oder so? portb = _SFR_IO_ADDR(PORTB)
:
Bearbeitet durch User
Wenn Du davon redest teile deines Programms in Assembler schreiben zu wollen, nehme ich an den Rest schreibst Du in C und benutzt vermutlich GCC. Dann wird der Assembler der GCC Assembler sein und nicht der Atmel Assembler. In diesem Falle kannst Du deinen Assembler Code folgendermaßen einleiten:
1 | #include <avr/io.h> |
2 | #define __SFR_OFFSET 0 |
dann kannst du wie gewünscht auf die SFR Definitionen zugreifen (Beispiel unten). Musst aber bei SFR Adressen größer $3F selber für eine adäquate Zugriffsmethode sorgen.
1 | #include <avr/io.h> |
2 | #define __SFR_OFFSET 0 |
3 | |
4 | akku = 16 |
5 | |
6 | .global togle |
7 | |
8 | togle: in r16, PORTB |
9 | eor r16, r24 |
10 | out PORTB, r16 |
11 | pop r16 |
12 | ret |
13 | |
14 | .end |
Ich habe AVR Mikrocontroller bisher nur einmal in ASM programmiert (andere schon öfter), und zwar mit dem AVR Studio 4.19. Das klappte ganz ohne Probleme. Probier das doch mal, vielleicht geht's mit der alten Software besser.
Das geht mit der neuen Software hervorragend. Mann muss sich nur mit seinen Werkzeugen beschäftigen.
Hi >Das geht mit der neuen Software hervorragend. Mann muss sich nur mit >seinen Werkzeugen beschäftigen. Und worin besteht in Puncto Assembler der Vorteil gegenüber AVR Studio 4.19? MfG Spess
spess53 schrieb: > Hi > >>Das geht mit der neuen Software hervorragend. Mann muss sich nur mit >>seinen Werkzeugen beschäftigen. > > Und worin besteht in Puncto Assembler der Vorteil gegenüber AVR Studio > 4.19? > > MfG Spess Natürlich des Supports aller neuen Controller und Entwicklerwerkzeuge wegen. Allerdings, es braucht Festplattenplatz und einen schnelleren Rechner (oder mehr Geduld), wobei man natürlich sagen kann, daß ein assembliertes Hex schneller als ein entsprechendes Compilat erstellt ist ;-)
Thomas Holmes schrieb: > Das geht mit der neuen Software hervorragend. Mann muss sich nur > mit > seinen Werkzeugen beschäftigen. Im Falle des Studio6 ist nicht viel mit Beschäftigen. Zumindest im Falle von Assembler. Sogut wie alles (von der Aktivierung der EEPROM-Ausgabe abgesehen) ist passend voreingestellt, sodaß man sich sehr schnell auf das eigene Programm konzentrieren kann.
spess53 schrieb: > Und worin besteht in Puncto Assembler der Vorteil gegenüber AVR Studio > 4.19? Einzig die Unterstützung für böswilligerweise für das 4er nicht mehr unterstützte Target-Devices, z.B. Tiny441/841. Das wirklich Schlimme ist: die Sache hat ganz offensichtlich System! Es werden nicht nur sehr neue AVR-Produkte nicht mehr unterstützt (das wäre ja vielleicht noch akzeptabel im Sinne des "technischen Fortschritts", was auch immer das bei konstanter Architektur sein soll...). Nein: es werden ganz bewußt und mit voller Absicht (dank .net jederzeit im Code nachzulesen) ältere Programmer mit voller STK500-Kompatibilität nicht mehr unterstützt, bzw. vielmehr absichtlich "abgewürgt". Sehr einfach nachzuweisen ist das beim Mega1284P als Target. Der war zum Glück schon vom 4er voll unterstützt, läßt sich mit vielen Programmern aber mit dem 6er nicht mehr programmieren, die ihn unter 4 noch problemlos programmieren konnten bzw. das weiterhin können. Geht man der Sache dann auf den Grund, findet man die Schweinerei auf dem Tablett geliefert. No doubt, eine mit voller Absicht eingebaute rein fiktive Inkompatibilität. Schade, dass selbst bei .net keine Kommentare auf diese Analyse-Ebene gelangen können. Aber ich hatte bei der Analyse quasi den Wortlaut der Kommentare in den Ohren... Wie auch immer: Was so offensichtlich im Code manifestiert ist, kann man auch sehr leicht umgehen. Man muß nur zwei IL-Anweisungen modifizieren und das Scheiß-Studio spielt auch mit dem Mega1284P wieder. Mit dem ollen Programmer, der schon seit Urzeiten diesen Job gemacht hat. Pikant: Derselbe olle Programmer kann unter A-Studio 6.2 sehr wohl Tiny441/841 korrekt programmieren, nachdem man dem dem verfickten STK500-Modul die entsprechenden XML-Dateien untergeschoben hat, da greift die absichtlich eingebaute Inkompatibilität nämlich nicht, das haben die verdammenswerten Entwickler dieser Scheisse nicht vorhergesehen... Völlig Blinde Wichser, sogar zu doof, eine überzeugende Inkompatibilität in den Code einzubauen... Fazit: Reine Abzocke. Atmel will, daß jeder Benutzer die "Entwicklung" (hüstel) des Studios dadurch mitbezahlt, daß er die völlig überteuerten Programmieradapter von Atmel kauft. Nö, ich nicht, denn mir paßt die Entwicklungsrichtung des Studios absolut garnicht. Wenn ich ARM haben will, dann nehme ich nicht die von Atmel. Und für die AVRs würde ich am liebsten beim 4er Studio bleiben. Das 6er nehme ich im Moment nur aus einem einzigen Grund: weil ich es noch nicht geschafft habe, dem 4er die Tiny441/841 beizubiegen. Aber ich arbeite daran, daß zumindest das STK500-Modul mitspielt, der Assembler ist ja sowieso kein Problem (mit der entsprechenden Anleihe aus dem 6er). Ein funktionierender SimulatorV2 wird aber leider wohl zuviel Aufwand. Dafür müßte ich viel Langeweile haben, die habe ich aber leider eigentlich niemals...
c-hater schrieb: > böswilligerweise > das wirklich Schlimme ist > absichtlich "abgewürgt". > Schweinerei > das Scheiß-Studio > verdammenswerten Entwickler dieser Scheisse > Völlig Blinde Wichser, sogar zu doof Sicher, das Studio ist jetzt kein Paradebeispiel der Softwarekunst- und die Nachteile seiner OOP Basis samt der zugrundeliegend so vielschichtig wie fehlkonstruierten Win-Architektur kommen in Platzbedarf und Speed des Programms schön zur Geltung. Aber ich frage mich ernstlich: Muß man sich bei kostenloser Software, die doch zumindest ihren Zweck erfüllt derart echauffieren? > Fazit: Reine Abzocke. Für den aktuellen ICE Debugger habe ich seinerzeit knapp 50€ bezahlt und bin damit für alle Fälle gerüstet. Abgezockt sehe ich den AVR Entwickler damit nicht, zumal auch die vorhergehenden Werkzeuge nicht / wesentlich / an Wert verlieren.
Moby schrieb: > Aber ich frage mich ernstlich: Muß man > sich bei kostenloser Software, die doch zumindest ihren Zweck erfüllt > derart echauffieren? Nein, wenn sie wirklich ihren Zweck erfüllen würde, bräuchte man sich ganz sicher nicht zu echauffieren. Ja mehr noch: ich würde mich nicht mal derart echauffieren, wenn das Programm einfach nur Scheiße wäre. Ist schließlich für lau. Wenn ich mich über jedes beschissene Freeware- oder OSS-Programm derart aufregen würde, käme ich ja zu garnichts anderem mehr. Aber mit nachweisbar ganz offensichtlich absichtlichen Kompatibilitätsbrüchen ohne jede technische Notwendigkeit habe ich schon ein ernsthaftes Problem. Und dann echauffiere ich mich auch mal. Und ich werde das immer wieder tun, in der Hoffnung, daß sich der Scheiß rumspricht und Atmel irgendwann zurückrudert und auf diesen Scheiß zukünftig verzichtet. Sollen sie statt dessen meinetwegen für gewerbliche Nutzung einen Obelix verlangen. Kein Thema. Aber die Privatnutzer durch künstliche Inkompatibilitäten indirekt abzuzocken, das geht garnicht, das ist digitale Wegelagerei.
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.