Hi, ich habe hier bei mir noch einen Arduino UNO sowie einen Leonardo rumzuliegen und würde gerne einen mit dem "ArduinoAsISP"-Code aus der Arduino IDE, die ich auf einem Windows Laptop habe, als Programmiergerät für andere AVRs (vor allem ATtiny13a) nutzen. Mein selbst zusammengebauter Desktop PC läuft mit mehreren Linux-Distributionen. Ich würde nun gerne den ATtiny13a in Assembler auf einer Linux-Distribution per Arduino programmieren. Am liebsten ohne Inline-Assembler in der Arduino IDE, stattdessen in einem Texteditor -> durch Assembler -> hex -> mit avrdude höchsten Reicht da avrgcc, das binutils enthält mit GNU Assembler oder wie richte ich das ein? Danke im Voraus Pascal
Assembler in der Arduino Umgebung...? Nur in Libs werden *.S Dateien übersetzt. Du wirst also eine Arduino Lib formen müssen, wenn du auf Inline Assembler verzichten möchtest.
Hallo Pascal, Du kannst LunaAVR (Linux 64Bit) als Basissystem verwenden und über die Interface- und Modul-Implementierung direkt auch Assemblerfunktionalität mit einbinden. Somit ist ein Wechsel zwischen Hochsprache und Assembler direkt möglich. Es sind unterschiedliche Programmiertechniken möglich. Siehe: [1] http://avr.myluna.de/doku.php?id=de:about [2] https://forum.myluna.de/
Arduino F. schrieb: > Assembler in der Arduino Umgebung...? Genau diese Umgebung möchte ich ja verlassen Karl M. schrieb: > LunaAVR Luna an sich kannte ich bisher nicht, scheint aber eine gute Lösung für mein Problem zu sein. Sehe ich mir gleich an. Ansonsten bin ich auch für Lösungen ohne GUI zu haben, mit denen ich Assemblercode aus einer Datei in Machinencode umwandeln und mit avrdude per Terminal den hex File hochlade
Und wieder einmal gewinnt bei Linux-Fragen ubuntuusers Für alle die wie ich einen Attiny13a in Assembler auf Linux programmieren wollen: https://wiki.ubuntuusers.de/AVR/
Pascal schrieb: > Reicht da avrgcc, das binutils enthält mit GNU Assembler Ja, avr-gcc genügt vollauf. Zudem bietet er schlagende Vorteile, denn es ermöglicht, C und C++ mit Assembler zu kombinieren. Tatsächlich ist avr-gcc lediglich ein Treiberprogramm, das anhand der Endung die passenden Subtools aufruft: C: .c C++: .cc, .cxx, .cpp, .cp, .c++, .C, .CPP Assembler: .s Assembler+cpp: .S, .sx Auch andere Endungen wie .asm können verwendet werden:
1 | avr-gcc -x assembler-with-cpp foo.asm ... |
"cpp" steht dabei für C-Präprozessor. Darauf achten, dass das -x vor dem Dateinamen steht. Um C mit Assembler kombinieren zu können, müssen beide die gleiche Aufrufkonvention verwenden: http://gcc.gnu.org/wiki/avr-gcc#Calling_Convention Ein Beispiel für C++ und Assembler: main.cpp
1 | extern "C" int val; |
2 | extern "C" int asm_func (int); |
3 | |
4 | extern "C" int c_func (int arg) |
5 | {
|
6 | val = arg; |
7 | return 0; |
8 | }
|
9 | |
10 | int main() |
11 | {
|
12 | return asm_func (1); |
13 | }
|
foo.sx
1 | .data |
2 | |
3 | .global val |
4 | val: .word 123 |
5 | |
6 | .text |
7 | |
8 | .global asm_func |
9 | asm_func: |
10 | ;; Incoming argument is in R25:R24 |
11 | SBIW R24, 1 |
12 | ;; Tail-calling c_func |
13 | RJMP c_func |
14 | |
15 | #include <avr/io.h> |
16 | |
17 | .global INT0_vect |
18 | INT0_vect: |
19 | reti |
20 | |
21 | .global __do_copy_data |
Übersetzen:
1 | avr-gcc -mmcu=attiny13a -c main.cpp -Os # gibt main.o |
2 | avr-gcc -mmcu=attiny13a -c foo.sx # gibt foo.o |
3 | avr-gcc -mmcu=attiny13a main.o foo.o -o foo.elf # link zu foo.elf |
Ergebnis:
1 | foo.elf: file format elf32-avr |
2 | |
3 | Disassembly of section .text: |
4 | |
5 | 00000000 <__vectors>: |
6 | 0: 09 c0 rjmp .+18 ; 0x14 <__ctors_end> |
7 | 2: 23 c0 rjmp .+70 ; 0x4a <__vector_1> |
8 | |
9 | ... |
10 | |
11 | 00000038 <c_func>: |
12 | 38: 90 93 61 00 sts 0x0061, r25 ; 0x800061 <__data_start+0x1> |
13 | 3c: 80 93 60 00 sts 0x0060, r24 ; 0x800060 <__data_start> |
14 | 40: 90 e0 ldi r25, 0x00 ; 0 |
15 | 42: 80 e0 ldi r24, 0x00 ; 0 |
16 | 44: 08 95 ret |
17 | |
18 | 00000046 <asm_func>: |
19 | 46: 01 97 sbiw r24, 0x01 ; 1 |
20 | 48: f7 cf rjmp .-18 ; 0x38 <c_func> |
21 | |
22 | 0000004a <__vector_1>: |
23 | 4a: 18 95 reti |
24 | |
25 | 0000004c <main>: |
26 | 4c: 81 e0 ldi r24, 0x01 ; 1 |
27 | 4e: 90 e0 ldi r25, 0x00 ; 0 |
28 | 50: fa cf rjmp .-12 ; 0x46 <asm_func> |
29 | |
30 | ... |
:
Bearbeitet durch User
Da avrdude scheinbar die "neueren" ATtiny13 (getestet habe ich ATtiny13A-PU und ATtiny13-20PU) nicht unterstützt, habe ich folgende Lösung gefunden: Ich habe aus dem gut funktionierenden MicroCore von MCUdude, einem Core für die Arduino IDE, der v.a. den ATtiny13a unterstützt, die avrdude.conf-Datei entnommen. Wird die zuvor vorhandene Datei durch diese ersetzt, existieren zwar nur noch 3 ATtinys, allerdings lässt sich mit avrdude -c stk500v1 -p t13a -P /dev/ttyACM0 -b 19200 -U flash:w:code.hex der ATtiny13a prima in Assembler über einen Arduino mit dem Arduino as ISP Sketch auf einem Linux-PC programmieren. Ich habe mir seit mehr als einer Woche jetzt den Kopf über nichts anderes zerbrochen, das mit dem MicroCore habe ich mehr aus Verzweiflung als aus Nachdenken getan. Ich hoffe, dass niemand anderem dasselbe widerfährt. Mit freundlichen Grüßen Pascal
Wozu in Assembler programmieren?! Selbst im Bereich des High Performance Computings ist es wirklich selten, dass man statt C/C++ ASM nutzt. Man bereitet sich dadurch nur enorm viel unnötige Arbeit und dadurch unnötig viele Kopfschmerzen...
Dieter schrieb: > Selbst im Bereich des High Performance Computings ist es wirklich > selten, dass man statt C/C++ ASM nutzt. In dem Bereich versucht man auch nicht sein Programm in 1k Memory unterzubringen. Dieter schrieb: > Man bereitet sich dadurch nur > enorm viel unnötige Arbeit und dadurch unnötig viele Kopfschmerzen... Aber kann viel Speicher und Rechenzeit sparen. Hochsprachen sind bequem und wenn man zuviel Speicher hat kann man den auch mit Interpretern füllen und Python benutzen, aber was machst Du, wenn Dein 'Compiler Version String' schon den halben verfügbaren Speicher füllt?
Horst schrieb: > .. viel ... Es gibt immer ein paar super schlaue, welche das schlecht reden, wovon sie keine Ahnung haben. Das tot treten, was sie nicht kennen. Und genügend Priester, welche keinen Gott neben dem ihren duldem, gibts auch. Wenn unser "Autor: Pascal (Gast)" seinen ATTiny13A mit Assembler bespielen will, ist das seine Sache. Und ich finde es völlig OK, dass er uns seine Hürden und Lösungen mitteilt. Weiter machen! Auch wenn ich es nicht unmittelbar verwerten kann.. lese gerne mit.
Horst schrieb: > In dem Bereich versucht man auch nicht sein Programm in 1k Memory > unterzubringen. Der C Compiler kann einiges optimieren. Wenn man diese Funktionalität entsprechend nutzt sprechen wir hier von ein paar Prozent Unterschied hinsichtlich des Speicherverbrauchs, dafür ist der Quelltext erheblich einfacher zu lesen. Bei den heutigen Preisen von µC ergibt es keinen Sinn (gerade im Privatbereich) auf einen möglichst billigen µC mit möglichst wenig Speicher zu optimieren, da investiert man lieber 1ct mehr und bekommt dafür den doppelten Speicher und kann sich die Arbeit sparen. Selbst im gewerblichen Umfeld ist es inzwischen teils sinnlos, wenn ich mir bei einer Stückzahl optimistisch 5ct pro µC spart sind das gerade mal 5000€ Einsparung, wenn meine Ings dadurch einen Monat oder auch nur Tage länger brauchen ist die Ersparnis dahin, man hat sich zudem den Weg für eine spätere Erweiterung/etc. verbaut bzw. darf dann wieder endlos optimieren...
Dieter schrieb: > Horst schrieb: >> In dem Bereich versucht man auch nicht sein Programm in 1k Memory >> unterzubringen. > > Der C Compiler kann einiges optimieren. Wenn man diese Funktionalität > entsprechend nutzt sprechen wir hier von ein paar Prozent Unterschied > hinsichtlich des Speicherverbrauchs, dafür ist der Quelltext erheblich > einfacher zu lesen. Das ist in dieser Allgemeinheit falsch und falsch. Der C-Compiler kann je nach Aufgabe auch mal 300% größeren und 1000% langsameren Maschinencode ergeben. Im Mittel über eine große Codebasis bleiben zwar vielleicht nur jeweils 50% Overhead übrig, aber im Einzelfall kann es eben auch deutlich mehr sein. Und auch besagte 50% können am Ende den Unterschied ausmachen zwischen "paßt noch in den Flash" oder eben nicht. C ist per se nicht leichter lesbar als Assembler. Nur weil du keinen lesbaren Assemblercode schreiben kannst oder noch nie welchen gesehen hast, gilt das nicht automatisch für andere [1]. C Code ist zwar tendentiell kürzer, aber bei Winz-µC wie dem ATTiny13 des TE fällt das nicht ins Gewicht. > Bei den heutigen Preisen von µC ergibt es keinen Sinn (gerade im > Privatbereich) auf einen möglichst billigen µC mit möglichst wenig > Speicher zu optimieren Das tut er ja gar nicht. Ich denke mal, er sieht das als sportliche Herausforderung, mit dem kleinsten µC auszukommen. Oder er hat nun mal nur den tiny13 und will versuchen, damit so weit wie möglich zu kommen. > Selbst im gewerblichen Umfeld ist es inzwischen ... Äpfel und Birnen. Beim Hobby berechnet man keinen Stundensatz. Wenn man Spaß am Gerät hat(te) dann ist das mehr wert als alles andere. [1] das gilt beileibe nicht nur für Assembler, sondern auch für andere als unlesbar verschrieene Sprachen. Ich finde bspw. Perl eine ausgesprochen angenehme Sprache, in der man extrem gut lesbaren Code schreiben kann. In anderen Sprachen wie z.B. Python oder Java geht das nicht - da fehlten schlicht die Sprachmittel. In der Gegenrichtung kann man allerdings in jeder Programmiersprache unlesbaren Code schreiben. Insofern ist "ich habe mal unlesbaren Code in Sprache X gesehen" kein Argument für irgendwas.
Horst schrieb: > Dieter schrieb: >> Man bereitet sich dadurch nur >> enorm viel unnötige Arbeit und dadurch unnötig viele Kopfschmerzen... > > Aber kann viel Speicher und Rechenzeit sparen. Genau deswegen, weil ich jetzt genau über die benötigten Taktzyklen in meinen Programmen Bescheid weiß, kann ich z.B. UART bitbangen. i2c zum Beschreiben und Auslesen einer 24AA16I/P EEPROM hatte ich schon mit dem MicroCore innerhalb der Arduino IDE gemacht, allerdings war das Einsetzen von Portmanipulation in C, um eine nutzbare Geschwindigkeit zu erhalten, nötig. Da ist sbi ddrb,2 und cbi portb,2 meiner Meinung nach simpler und gleichzeitig effektiver. Vielleicht bekomme ich auch USB noch irgendwann mal hin - der ATtiny85 im digispark kann das ja. Wäre eine neue Herausforderung. Ich werde euch in diesem Forums wissen lassen wann ich etwas neues, Arbeit erleichterndes entwickelt habe. Axel S. schrieb: >> Bei den heutigen Preisen von µC ergibt es keinen Sinn (gerade im >> Privatbereich) auf einen möglichst billigen µC mit möglichst wenig >> Speicher zu optimieren > > Das tut er ja gar nicht. Ich denke mal, er sieht das als sportliche > Herausforderung, mit dem kleinsten µC auszukommen. Mir geht es nicht um den Preis - ATtinys sind winzig klein, haben 8 statt 28 Pins wie z.B. der ATmega328P,und haben minimale Hardware - also gibt es da noch was softwareseitiges zu entwickeln, da keine fertigen Librarys existieren. Ist eben so ne Art Herausforderung, wie ich einen Attiny13a bspw. schon mit Tasten ohne PC programmiert habe ;) Ich denke, dass hardwarenahe Programmierung sehr sinnvoll sein kann (nicht bei großen PCs, aber bei kleinen wie den MCUs hier. Außerdem könnte man ja aus 2 ATtinys einen Dualcore-Tiny bauen..
(ich meine mit "keine fertigen Librarys" z.B. Für UART)
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.