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"intval;
2
extern"C"intasm_func(int);
3
4
extern"C"intc_func(intarg)
5
{
6
val=arg;
7
return0;
8
}
9
10
intmain()
11
{
12
returnasm_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
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..
